Чтение онлайн

Я бы хотел проиллюстрировать «как» и «почему» из книги Майка на примере глав 4 и 5, где детально показано, как оценивать пользовательские истории в пунктах или идеальных днях, а также приведены все за и против для каждого из этих подходов. Я практиковал оба подхода при работе с клиентами, но слова Майка помогли кристаллизоваться моим представлениям об оценке историй в пунктах и позволили понять, что пункты являются частью эволюции – эволюции в направлении простоты. Организации, занимающиеся разработкой программного обеспечения, давно ищут ответ на вопрос «насколько велик данный элемент программного обеспечения?». Строитель способен дать довольно обоснованную оценку, имея данные о площади здания. Оценки разных строителей могут варьировать, но размер фиксирован (хотя отделочные работы, требования к материалам и т. п. также влияют на оценку) и остается постоянным. Разработчики программного обеспечения давно хотят иметь подобный показатель.

В сфере разработки программного обеспечения для измерения размера продукта поначалу использовали количество строк программы (этот показатель до сих пор не вышел из употребления). В текущем планировании, однако, количество строк программы находит ограниченное применение по целому ряду причин, включая трудозатраты на их подсчет. Затем на сцену вышли функциональные точки (и несколько аналогичных идей). Функциональные точки устраняли некоторые проблемы показателя количества строк, но по-прежнему требовали значительных трудозатрат для подсчета (нужно было оценивать входные данные, выходные данные, файлы и т. п.). Впрочем, на пути широкого использования функциональных точек встали не трудозатраты, а их сложность. По моему мнению, именно увеличение сложности подсчета – беглый просмотр веб-сайта International Function Point User Group (IFPUG) дает хорошее представление об уровне этой сложности – привело к сокращению использования этого показателя.

Так или иначе, потребность в оценке «размера» софтверного проекта никуда не исчезла. Проблема с обоими историческими показателями имеет две стороны – их сложно определять и они основаны на каскадном подходе к разработке. Нам же требуется показатель размера, который просто определить и можно применять без необходимости проходить все требования и фазы проектирования.

Два критически важных отличия пунктов от количества строк программы и функциональных точек заключаются в том, что они проще в расчете и могут определяться на значительно более раннем этапе. Почему они проще? Да потому, что характеризуют относительный размер, а не абсолютный. Почему их можно определять на более раннем этапе? Да потому, что они относятся в большей мере к относительному размеру, чем к абсолютному. Как подчеркивает Майк, оценка с использованием пунктов – это обсуждение историй за круглым столом (обмен знаниями) и предположительная оценка относительного размера истории. Оценка относительного размера, в отличие от оценки абсолютного, осуществляется на удивление быстро. К тому же после нескольких итераций оценки размера и поставки продукта точность предположительных оценок, даваемых командой, значительно возрастает. Описание Майком «как» и «почему» при сравнении оценки в пунктах и идеальных днях позволяет глубоко понять эту критически важную тему.

Еще одним примером тщательности изложения материалов Майком служат главы 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! создают продукты, которые нравятся нашим менеджерам по продуктам намного больше, чем продукты традиционных команд.

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

Оценка и планирование – темы, по которым мне задают больше всего вопросов, особенно во вновь созданных командах. Простой подход к планированию не только итерации, но и проекта в целом – вещь, прямо скажем, неоценимая. Менеджеров по продукту волнует достижение целевых показателей по выручке и предсказуемое планирование релизов. Команды могут использовать гибкий подход и изменять направление разработки при необходимости, однако очень важно иметь стратегический план, которому они будут следовать. Кому нужно быстрое движение, если вы идете не в том направлении? Освоение искусства оценки сделанного и планирования дальнейших действий – важнейшее условие успеха для тех, кто хочет внедрить agile-подход в своей организации.

Учебный курс Майка по оценке и планированию пользуется наибольшей популярностью при освоении agile-подхода в Yahoo!. Он дает командам профессиональные знания и инструменты, необходимые, чтобы заниматься планированием именно в таком объеме, который требуется для оптимизации результатов. Это и в самом деле работает, если следовать рекомендациям Майка? Да. Эффект от применения agile-подхода в Yahoo! грандиозен. Команды, прошедшие курс Майка, сразу начинают использовать его рекомендации на практике. Мы стали выводить продукты на рынок быстрее, а команды буквально в восторге от agile-подхода.