Agile: оценка и планирование проектов - [3]
В сфере разработки программного обеспечения для измерения размера продукта поначалу использовали количество строк программы (этот показатель до сих пор не вышел из употребления). В текущем планировании, однако, количество строк программы находит ограниченное применение по целому ряду причин, включая трудозатраты на их подсчет. Затем на сцену вышли функциональные точки (и несколько аналогичных идей). Функциональные точки устраняли некоторые проблемы показателя количества строк, но по-прежнему требовали значительных трудозатрат для подсчета (нужно было оценивать входные данные, выходные данные, файлы и т. п.). Впрочем, на пути широкого использования функциональных точек встали не трудозатраты, а их сложность. По моему мнению, именно увеличение сложности подсчета — беглый просмотр веб-сайта International Function Point User Group (IFPUG) дает хорошее представление об уровне этой сложности — привело к сокращению использования этого показателя.
Так или иначе, потребность в оценке «размера» софтверного проекта никуда не исчезла. Проблема с обоими историческими показателями имеет две стороны — их сложно определять и они основаны на каскадном подходе к разработке. Нам же требуется показатель размера, который просто определить и можно применять без необходимости проходить все требования и фазы проектирования.
Два критически важных отличия пунктов от количества строк программы и функциональных точек заключаются в том, что они проще в расчете и могут определяться на значительно более раннем этапе. Почему они проще? Да потому, что характеризуют относительный размер, а не абсолютный. Почему их можно определять на более раннем этапе? Да потому, что они относятся в большей мере к относительному размеру, чем к абсолютному. Как подчеркивает Майк, оценка с использованием пунктов — это обсуждение историй за круглым столом (обмен знаниями) и предположительная оценка относительного размера истории. Оценка относительного размера, в отличие от оценки абсолютного, осуществляется на удивление быстро. К тому же после нескольких итераций оценки размера и поставки продукта точность предположительных оценок, даваемых командой, значительно возрастает. Описание Майком «как» и «почему» при сравнении оценки в пунктах и идеальных днях позволяет глубоко понять эту критически важную тему.
Еще одним примером тщательности изложения материалов Майком служат главы 9–11, посвященные приоритизации историй. Майк не ограничивается советом браться в первую очередь за истории с наивысшей стоимостью, а раскрывает ключевые аспекты стоимости: финансовые выгоды, затраты, инновации/знание и риск. Он дает четкие разъяснения по каждому из этих аспектов (включая общие представления о чистой приведенной стоимости, внутренней ставке доходности и других инструментах финансового анализа), а затем приводит ряд схем (с разной степенью упрощения) принятия решений по весам на основе рассмотренных аспектов стоимости.
Нередко новички в области agile-разработки полагают, что если применить определенную методологию 12, 19 или 8 раз, то это и будет Agile, Extreme, Cristal Clear или еще что-нибудь подобное. Однако на самом деле вы применяете методологию Agile, Extreme и т. п. только тогда, когда знаете достаточно, чтобы адаптировать ее к своей конкретной ситуации. Суть agile-разработки — непрерывное обучение и адаптация. Что Майк отлично делает в этой книге, так это знакомит нас с идеями и практикой, которые помогают вывести наши agile-оценку и agile-планирование на следующий уровень развития. Майк детально разъясняет, «как» подойти к делу, например провести оценку в пунктах и идеальных днях, и «почему» нужно подходить именно так, представляя плюсы и минусы показателей «пункты» и «идеальные дни». Хотя он обычно дает рекомендации (сам он предпочитает пункты), в книге достаточно информации, чтобы мы уверенно могли адаптировать методику к своей ситуации.
Именно в этом и заключается вклад Майка в данную область — сначала он помогает нам получать новые знания и опыт через оценку и планирование («как»), а затем принимать решения об использовании нового знания для адаптирования оценок и планов к новым, уникальным или просто конкретным ситуациям («почему»). Из полудесятка книг, которые я постоянно рекомендую своим клиентам, две принадлежат Майку. «Agile-подход к оценке и планированию» входит в мой список обязательных для изучения материалов для тех, кто хочет понять последние веяния в сфере agile-управления проектами.
Джим Хайсмит,
директор по agile-практике в компании Cutter Consortium,
Флагстафф, Аризона, август 2005 г.
Предисловие
«Agile-подход к разработке не годится для Yahoo! за исключением, быть может, небольших оперативных проектов, поскольку команды совершенно не занимаются планированием, а члены команд не могут оценить проделанную работу. Им приходится давать указания, что делать».
Это реальное высказывание, которое я неоднократно слышал, когда начинал руководить внедрением agile-подхода в Yahoo!. Люди, которые не понимают концепцию agile-разработки, полагают, что это просто отказ от документации и планирования, лицензия на свободное плавание. На самом деле такое представление предельно далеко от истины.
Рассматриваются такие инструменты статистического анализа взаимосвязи, как корреляционный и регрессионный анализ. Техника работы в пакете Excel изучается на примере смоделированных данных. Затем полученные навыки применяются к анализу реальных данных по ценам в интернет-магазине и биржевым котировкам на Московской бирже.
Немного общих слов об ERP (планирование ресурсов предприятия), прикладных информационных технологиях в бизнесе, повышающих руководство потоками.
У вас есть идея? План, как сделать мир лучше? Блестящий проект, который обязательно должен состояться? Значит, вам нужны деньги. Можно продать что-нибудь ненужное – или нужное, – или взять кредит, или попросить денег у тех, кто будет рад жить в мире, где ваши мечты воплотились в реальный продукт. «Краудфандинг. Как найти деньги для вашей идеи» поможет вам преподнести проект так, чтобы в него поверили – помимо вас – все, кто о нем узнает. Неважно, есть ли у вас уже опыт сбора средств или вы только задумываетесь об этом – эта книга поможет вам самостоятельно осуществить краудфандинговый проект и претворить свою мечту в реальность.
В этой книге собрано сразу несколько историй, одна зажигательнее другой. Автобиография одного из самых ярких молодых бизнесменов последнего времени, начавшего свой первый бизнес в девять лет. История развития его компании Zappos, за десять лет с нуля разогнавшейся до миллиардного оборота. А главное – рассказ о том, как Тони и его соратникам удалось построить бизнес, радующий своим существованием не только владельцев, но и всех причастных к компании – от сотрудников и клиентов до поставщиков и партнеров.
Это первое руководство по комьюнити-менеджменту от российского практика. Внедрив инструменты выращивания лояльных сообществ, вы сможете: — создать точки концентрации лояльной аудитории, работая в соцсетях, мессенджерах и офлайн; — повысить вовлеченность; — защититься от троллинга; — превратить сообщество в воронку для новой аудитории; — воодушевить участников на ожидаемые действия. Книга содержит примеры организаций из разных сегментов и послужит азбукой для новичков и шпаргалкой для практиков.
Изучать маркетинговые инструменты на личном опыте — занятие дорогостоящее и рискованное. Не одна компания утонула, копируя действия конкурентов и используя потрёпанные годами шаблоны. Почему же старые методы ведения бизнеса уже не работают? Что такое маркетинг и существует ли он вообще? Как создать продукт, который будет пользоваться спросом у клиентов и приносить владельцу бизнеса деньги, радость и удовлетворение?