Еще одним примером тщательности изложения материалов Майком служат главы 9–11, посвященные приоритизации историй. Майк не ограничивается советом браться в первую очередь за истории с наивысшей стоимостью, а раскрывает ключевые аспекты стоимости: финансовые выгоды, затраты, инновации/знание и риск. Он дает четкие разъяснения по каждому из этих аспектов (включая общие представления о чистой приведенной стоимости, внутренней ставке доходности и других инструментах финансового анализа), а затем приводит ряд схем (с разной степенью упрощения) принятия решений по весам на основе рассмотренных аспектов стоимости.

Нередко новички в области agile-разработки полагают, что если применить определенную методологию 12, 19 или 8 раз, то это и будет Agile, Extreme, Cristal Clear или еще что-нибудь подобное. Однако на самом деле вы применяете методологию Agile, Extreme и т. п. только тогда, когда знаете достаточно, чтобы адаптировать ее к своей конкретной ситуации. Суть agile-разработки – непрерывное обучение и адаптация. Что Майк отлично делает в этой книге, так это знакомит нас с идеями и практикой, которые помогают вывести наши agile-оценку и agile-планирование на следующий уровень развития. Майк детально разъясняет, «как» подойти к делу, например провести оценку в пунктах и идеальных днях, и «почему» нужно подходить именно так, представляя плюсы и минусы показателей «пункты» и «идеальные дни». Хотя он обычно дает рекомендации (сам он предпочитает пункты), в книге достаточно информации, чтобы мы уверенно могли адаптировать методику к своей ситуации.

Именно в этом и заключается вклад Майка в данную область – сначала он помогает нам получать новые знания и опыт через оценку и планирование («как»), а затем принимать решения об использовании нового знания для адаптирования оценок и планов к новым, уникальным или просто конкретным ситуациям («почему»). Из полудесятка книг, которые я постоянно рекомендую своим клиентам, две принадлежат Майку. «Agile-подход к оценке и планированию» входит в мой список обязательных для изучения материалов для тех, кто хочет понять последние веяния в сфере agile-управления проектами.

«Agile-подход к разработке не годится для Yahoo! за исключением, быть может, небольших оперативных проектов, поскольку команды совершенно не занимаются планированием, а члены команд не могут оценить проделанную работу. Им приходится давать указания, что делать».

Это реальное высказывание, которое я неоднократно слышал, когда начинал руководить внедрением agile-подхода в Yahoo!. Люди, которые не понимают концепцию agile-разработки, полагают, что это просто отказ от документации и планирования, лицензия на свободное плавание. На самом деле такое представление предельно далеко от истины.

«Команды совершенно не занимаются планированием». Тот, кто говорит такое, забывает, что agile-команда раз в две недели посвящает полдня составлению перечня задач, которые необходимо выполнить, чтобы представить определенную полезную для пользователя функциональность через две недели. То, что команды распределяют процесс планирования на весь период реализации проекта, воспринимается как отсутствие планирования. Это не так, и agile-команды в Yahoo! создают продукты, которые нравятся нашим менеджерам по продуктам намного больше, чем продукты традиционных команд.

«Члены команд не могут оценить проделанную работу. Им приходится давать указания, что делать». Это классическое заблуждение. Упование на магическую способность менеджера по продукту или руководителя проекта предвидеть, чтó кто-то другой, эксперт в своем деле, может реально создать, самоубийственно для заказчика. Нередко такой подход на деле оборачивается простым соглашательством с нереалистичными целями заказчика. Члены команды при этом вынуждены работать круглые сутки и халтурить. А потом мы удивляемся, почему в нашей отрасли люди так быстро выгорают и почему так низок моральный дух.