Текст книги "Гибкое управление IT-проектами. Руководство для настоящих самураев"

Прежде чем взяться за дело и составить план нашего гибкого проекта, нужно перечислить все функции, которые клиент хочет увидеть в готовой программе. Один из способов решения этой задачи – организовать семинар по сбору пользовательских историй (story-gathering workshop). Для клиента и команды разработчиков это отличная возможность собраться вместе и записать пользовательские истории о системе, которую требуется построить.

Цель такого семинара – получить широкое представление о задаче. Мы как будто закидываем невод и пытаемся выудить как можно больше функций. Вы не обязательно будете реализовывать все эти функции. Семинар проводится скорее для того, чтобы все истории были на виду и мы видели общую панораму того, с чем придется работать.

Список того, что мы не собираемся делать (см. раздел 4.4), составленный на этапе создания стартовой колоды, может помочь вам на таком семинаре. Но обычно все сводится к тому, что вы усаживаетесь вместе с клиентом, рисуете несколько картинок и по ходу беседы о системе записываете истории на карточки. Вот и все.

Позвольте дать несколько советов о том, как организовать хороший семинар по сбору пользовательских историй.

Этап 1. Найдите большое открытое помещение

В этой комнате должно быть удобно перемещаться, должна быть возможность приклеивать картинки на стену и собирать карточки на большом столе. Необходимо обеспечить подходящую атмосферу для естественного творческого процесса.

Этап 2. Нарисуйте много картинок

Картинки отлично помогают обсуждать идеи о системе в режиме мозгового штурма и являются настоящим сокровищем для обнаружения пользовательских историй.

Персоналии (характеристики людей, которые будут работать с вашей системой) хороши для знакомства с клиентами. Функциональные схемы, технологические цепочки и сценарии очень пригодятся при ролевой игре и помогут по-настоящему ощутить, как должна работать система. Системные карты и схемы информационной архитектуры помогают организовать работу и разбить ее на составляющие. А концептуальные решения и бумажные прототипы представляют собой недорогие способы опробовать полученное содержимое и посмотреть, что работает.

Подчеркиваю, здесь нас интересует именно широкая перспектива. Старайтесь не углубляться в детали – картина должна оставаться обобщенной.

Но когда у вас будет несколько хороших картинок и вы будете понимать, как система должна работать, можете приступать к разработке картинок для конкретных историй.

Этап 3. Напишите много историй

С помощью новых схем и картинок проследите истории вместе с вашим клиентом, рассматривая отдельные пожелания по ходу работы.

Если большая часть вашей программы выводится на экран в одном-двух окнах, то возьмите их скриншоты и выделите на них небольшие функциональные элементы.

Из одной функциональной схемы, подкрепленной несколькими приблизительными бумажными прототипами, обычно можно получить большую часть ключевых историй для проекта.

Выделяя отдельные пользовательские истории, ищите небольшие самостоятельные элементы, касающиеся всех уровней программы (требующие для реализации от одного до пяти дней). Ничего страшного, если некоторые из историй будут сравнительно велики. В гибкой методологии они называются эпиками (epics) – это крупные пользовательские истории, на разработку которых уходит одна-две недели.

Эпики удобны при общем планировании, так как в них описываются крупные пожелания, за которые мы, возможно, и возьмемся, но пока уверенности в этом нет. Если у вас есть подобные крупные функциональные фрагменты, то считайте их обычными историями, а когда дело дойдет до разработки, просто разбивайте их на части.

В конечном счете от 10 до 40 пользовательских историй обычно заменяют 3–6 месяцев планирования. Если количество историй измеряется сотнями, то либо ваше планирование зашло слишком далеко, либо вы чрезмерно углубляетесь в детали. На данном этапе мы стремимся именно к ширине (а не к глубине) охвата материала. Поэтому поднимаемся на поверхность и не теряемся в дебрях.

Этап 4. Обсудите остальные вопросы в режиме мозгового штурма

Но как бы хороши ни были картинки, они не могут описать всего, что нам нужно для работы над проектом. В частности, еще нужно обсудить миграцию данных, нагрузочное тестирование, бумажную работу, связанную с недопущением корпоративного и бухгалтерского мошенничества, сопроводительную документацию по продукту, учебные материалы, двухнедельный срок на приемочные испытания, проводимые пользователем, и т. д. Требуется занести все эти детали (и не только) на карточки, расставить их приоритеты и работать с ними наравне с остальными отчетными данными по проекту.

Сейчас самое время вернуться к картинке, рассмотренной в начале раздела 4.5, и в режиме мозгового штурма обсудить все детали, которые требуются, чтобы проект получился максимально успешным.

Если еще остаются дела, с которыми необходимо разобраться (даже не относящиеся непосредственно к программной составляющей), выпишите их на отдельную карточку.

Этап 5. Подчистите список, чтобы он сиял

Как только будет готов первоначальный список, несколько раз просмотрите его и поищите элементы, которые случайно оказались продублированы. Посмотрите, чего недостает, сгруппируйте логически близкие истории и подготовьте простой и понятный список задач, которые требуется решить. Поздравляю! У вас есть первоначальный план проекта!

УЧЕНИК: Мастер, если очная коммуникация – самый эффективный способ обмена информацией о системе, означает ли это, что я должен тратить больше времени на обсуждение требований с моим клиентом и меньше времени на их запись?

МАСТЕР: Да, именно так.

УЧЕНИК: А значит ли это, что при сборе требований я должен отказаться от документации?

МАСТЕР: Нет. Цель – не избавиться от всей документации, так как документация сама по себе не является ни хорошей, ни плохой. Цель – напоминать себе о том, какой способ обмена информацией наиболее эффективен.

УЧЕНИК: То есть при сборе требований какая-то документация все же может присутствовать?

МАСТЕР: Конечно. Просто не нужно ставить ее во главу угла. Вместо этого необходимо сконцентрироваться на клиенте и на том, что он хочет получить от программы. При описании программы сознавай, что у документации есть границы. Пусть она будет вашим последним объяснительным средством. Но не первым.

УЧЕНИК: Благодарю тебя, Мастер. Я подумаю над этим во время медитации.

Что дальше?

Мы хорошо потрудились, дружище! Теперь мы видим, что пользовательские истории – это просто краткие описания функций, которые клиенты хотят видеть в программе, и вы еще на шаг продвинулись к созданию вашего первого плана гибкой разработки.

Следующая глава посвящена оценке, в ней мы рассмотрим, как придавать историям такие размеры, при которых они смогут выдерживать неизбежные затруднения, возникающие в процессе работы.

Итак, двигаемся вперед, чтобы развеять ореол таинственности, окружающий науку и искусство гибкой оценки.

Глава 7
Оценка: филигранное искусство угадывания

Будьте готовы к тому, что процесс оценки должен в известной степени опираться на реальность. Гибкая разработка в данном контексте разрушает распространенные иллюзии и напоминает, чем на самом деле являются наши изначальные общие оценки – это всего лишь не самые удачные догадки.

Но, обучаясь гибкому оцениванию проекта, вы перестанете требовать от предварительных оценок того, чего они не смогут вам дать (в первую очередь, речь идет о точности), и сосредоточитесь на том, что действительно важно. То есть на выстраивании плана, с которым сможете работать вы и ваш клиент и в который будете верить как он, так и вы.

Эта глава поможет вам научиться гибкой оценке пользовательских историй. Кроме того, мы рассмотрим некоторые эффективные методы группового оценивания, помогающие определять временные рамки тех или иных задач.

Давайте займемся этой проблемой. Когда речь заходит о формулировании ожиданий, связанных с оценкой софтверных проектов, всегда возникает ряд сложностей.

Точка оценки

«Основная цель оценки при разработке программ – не предсказать результат проекта, а определить, являются ли цели проекта достаточно реалистичными, чтобы их можно было достичь, контролируя проект». – Стив Макконнелл, Software Estimation: Demystifying the Black Art [McC06].

Это не означает, что наши оценки обязательно будут ошибочными (хотя почти всегда именно так и случается). Дело скорее в том, чтобы люди не ждали от оценок того, чего они не могут дать в принципе, – точного прогноза.

Ситуация такова, что в какой-то момент в ходе работы люди упускают из виду факт, что

Причем упускают его именно в тот момент, когда эти преждевременные, неточные, общие оценки недальновидно выдаются за четкие обещания, из-за которых во многих проектах начинаются неприятности.

Стив Макконнелл называет такое непродуктивное поведение конусом неопределенности (cone of uncertainty), напоминая о том, что на установочном этапе проекта приблизительные оценки могут варьироваться в диапазоне около 400 %. Настолько сильно могут отличаться наши оценки на различных этапах проекта.

Простая истина заключается в том, что точные заблаговременные оценки невозможны, и мы должны прекратить верить в их существование.

Единственный вопрос, ответ на который можно попытаться найти при предварительной оценке, следующий:

Нам нужен способ оценки, который позволил бы решать следующие задачи:

♦ планировать на будущее;

♦ напоминать нам о том, что наши оценки – это догадки;

♦ учитывать сложности, присущие создаваемой программе.

При гибкой разработке мы признаем, что не следует всецело доверять нашим первичным, обобщенным оценкам. Но мы также понимаем, что в самом начале проекта требуется рассчитать бюджет и обрисовать перспективы.

Чтобы этого добиться, мы поступаем так же, как и любой на нашем месте, кто желает получить правдоподобные оценки. Мы выполняем небольшой фрагмент работы, смотрим, сколько времени на это ушло, и используем полученный результат при дальнейшем планировании. Нам требуются две вещи:

♦ сравнение пользовательских историй (их размера) друг с другом;

♦ балльная система отслеживания прогресса.

Давайте рассмотрим каждый из этих аспектов детально и узнаем, как они помогают при планировании.

Относительные размеры

Предположим, нам известно, что одно шоколадное печенье можно съесть за 10 секунд. Перед нами стоит вопрос: сколько времени потребуется, чтобы съесть семь и четырнадцать таких печений (и еще запить стаканом молока)? Какова будет наша оценка?

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

Если вы среднестатистический человек, то оценка в случае с печеньем не составит для вас труда (это юмор), а остальные задачи окажутся значительно сложнее.

Разница между двумя упражнениями заключается в том, что с печеньями мы применяем относительную оценку, а с подсчетом карт – абсолютную.

Научные данные свидетельствуют о том, что относительная оценка удается любому представителю человеческого вида достаточно хорошо. Если мы кладем перед собой два камешка, то с достаточно большой точностью можем угадать, насколько один камень больше другого.

Большие проблемы начинаются тогда, когда мы пытаемся сказать, на сколько именно один камень больше другого (то есть дать абсолютную оценку).

Этот простой принцип является одной из основ гибкой оценки и гибкого планирования. Сравнивая пользовательские истории друг с другом и измеряя, насколько быстро мы сможем работать, мы получаем все элементы, необходимые для создания гибкого плана.

Отдельная проблема, связанная с относительной оценкой, заключается в том, что один день в наших оценках не всегда равен одному дню в наших планах. Команда будет работать медленнее или быстрее, чем мы запланировали.

Чтобы учесть это неравенство и избежать необходимости постоянной переоценки всех историй, при гибкой разработке для оценки применяется балльная система.

Балльная система оценки

Балльная система помогает отслеживать прогресс и давать относительные оценки без необходимости сравнения текущих обстоятельств с нашими оценками.

Допустим, исходя из первоначальной оценки, мы решили, что на реализацию данной истории должно уйти три дня, тогда как в реальности понадобилось около четырех.

Тогда можно попытаться скорректировать все полученные нами оценки на 33 %.

Но кому понравится работать с такими числами, как 1,33 или 6,66 дня? Такие величины дают не только ложное ощущение точности, но и ставят перед нами следующую проблему: вдруг после реализации еще нескольких историй, мы обнаружим, что наша оценка 1,33 на самом деле ближе к 1,66. Будем оценивать заново?

Чтобы оторваться от такого постоянного и бесконечного уточнения чисел, при гибкой разработке рекомендуется привязывать свои оценки к простой в использовании балльной системе и не соотносить их с обычными календарными сроками.

При работе с балльной системой единицы измерения уже не играют роли. Мы работаем с относительными величинами, а не с абсолютными.

Все, что мы пытаемся сделать, – это выразить величину задачи в числовом виде и относительно других задач. Если вам будет удобнее, можете считать гибкую оценку попыткой отсортировать истории по тому же принципу, по которому сортируются майки: маленькие, средние или большие.

Кроме того, наверстывая наши оценочные показатели и стараясь не отставать от них, нужно признать, что в итоге будут важны не оценки, а именно результат. При сравнении историй по размеру друг с другом мы можем переоценивать одни и недооценивать другие, так что в итоге картина выравнивается.

При использовании балльной системы мы достигаем определенных результатов, а исследования показывают, чем она особенно хороша:

♦ напоминает нам, что оценки – это всего лишь догадки;

♦ измеряет только длительность работы (не затухающую с течением времени);

♦ это быстрый и простой способ.

Да, действительно. Прежде чем мы начали заниматься гибкой оценкой, всякий раз, когда речь заходила об оценке, я говорил о днях, хотя на самом деле должен был говорить о баллах. Я допустил такое разночтение по двум причинам. Во-первых, нам было бы тяжело обсуждать саму концепцию оценки, говоря о баллах. Во-вторых, поскольку в некоторых гибких командах применяется оценка в днях, они просто называют их идеальными днями.

Идеальный день – просто еще одна разновидность балла для оценки истории. Под идеальным понимается совершенный рабочий день, когда вы ни на что не прерываетесь и имеете возможность работать восемь часов без всяких помех.

Разумеется, на работе идеальных дней не бывает, но некоторым командам эта концепция кажется полезной.

В принципе, идеальными днями можно оперировать, но лично я предпочитаю баллы. В основном потому, что при оценке в баллах становится очевиден сам факт оценки, а кроме того, при использовании баллов я могу не думать о том, совпадает ли мой идеал с вашим.

Далее в книге считайте понятия «день» и «балл» равнозначными. Далее я буду пользоваться в основном баллами, но иногда будут встречаться и дни.

Но хватит разговоров. Пора возвращаться на грешную землю. Далее мы обсудим два простых метода оценки, которые вы и ваша команда можете использовать для правильного определения размеров историй при гибком планировании.

Триангуляция

Триангуляция – это метод, при котором берется несколько ориентировочных историй, а остальные измеряются по ним, как по эталону.

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

Давайте внимательно рассмотрим список и выясним, есть ли в нем кандидаты на роль хороших эталонных историй. В идеале нам нужна маленькая история, средняя история и достаточно большая история, которая при этом сможет уместиться в одной итерации (то есть на выполнение которой может уйти от одной до двух недель). Кроме того, обратим внимание на следующие моменты:

♦ построение логических групп;

♦ выделение историй, охватывающих всю систему целиком (это нужно, чтобы содержательно наполнить ее архитектуру);

♦ поиск типичных черт, которые характерны для проекта на всех этапах его реализации.

Есть вещи, которые нужно держать в уме при поиске таких историй-кандидатов. Это должны быть самые обычные истории, с которыми обязательно придется столкнуться при работе.

После изучения списка начнем, например, со следующих трех историй.

Теперь нам есть с чем сравнивать, поэтому мы можем заняться оставшимися историями и сравнить их с данными вариантами.

Здесь может возникнуть вопрос: нужно ли постоянно оценивать заново имеющиеся истории? Ответ – да. Если вы начнете выстраивать несколько историй и среди них попадутся такие, длительность реализации которых определена неверно, то вы, конечно же, должны заново оценить такие экземпляры, так как иначе вам все время придется пересматривать скорость работы команды. Из-за этого планирование становится несколько неопределенным, потому что на различных запланированных этапах у вас получится разная скорость работы.

Кроме того, если вам придется заниматься работой, с которой вы никогда ранее не сталкивались, и вы не будете знать, как определить необходимое на нее выполнение время, проведите предварительное исследование (spike[13]13
  В литературе также встречается перевод этого понятия как «выброс» или «проба». – Примеч. пер.


[Закрыть]). Под ним в гибкой разработке понимается эксперимент, для выполнения которого ставятся жесткие временные рамки. В ходе такого эксперимента мы успеваем провести ровно столько исследований, сколько требуется для формирования оценок, а затем эксперимент останавливается (в данном случае сама история до конца не доводится).

Мудрость толп

В книге Джеймса Суровицки The Wisdom of Crowds [Sur05] рассказывается следующая история. В 1906 году британский ученый Фрэнсис Гальтон был шокирован результатом эксперимента, проведенного на сельской ярмарке.

Предположив, что профессиональный мясник сможет точнее угадать вес забитого быка, он был удивлен и разочарован тем, что толпа обывателей (практически не имевших опыта рубки мяса) смогла не просто угадать вес туши, но и сделать это с точностью до фунта.

Данный факт опровергал мнение сэра Фрэнсиса о том, что эксперты всегда правы и им не составляет труда превзойти в мастерстве толпу.

Разыгрывая покер-планирование, мы просто проверяем на прочность мудрость толпы, сравнивая прогнозы людей с нашими оценками. Мы спорим, что группе удастся предложить более точную догадку, чем любому отдельно взятому человеку.

Обычно предварительные исследования продолжаются не дольше пары дней и отлично подходят для того, чтобы гибко оценить что-либо и получить достаточное количество информации, позволяющее сообщить клиенту, сколько примерно будет стоить та или иная работа. И клиент может решить, стоит ли вкладывать деньги в эту работу.

Прежде чем закончить главу, рассмотрим еще один удобный инструмент командной оценки, помогающий прийти к общему мнению, – так называемое покер-планирование.

Покер-планирование

Покер-планирование – это игра, в ходе которой члены команды сначала оценивают пользовательские истории индивидуально (при помощи карточек с номерами – например, 1, 3 и 5 баллов), а затем вместе сравнивают результаты с получившимися у коллег.

В случае если все оценки примерно одинаковы, то общая оценка считается верной.

Но если возникают различия, команда обсуждает их и после прихода к общему мнению вновь проводит оценку.

Покер-планирование эффективно, так как оценки выставляют люди, выполняющие работу. Здесь я упомянул разработчиков, но оценки могут выставлять также администраторы баз данных, дизайнеры, технические писатели и другие специалисты, отвечающие за реализацию истории.

Сильной стороной данного метода является дискуссионная составляющая. Если кто-то говорит, что история совсем невелика, а другой считает ее, напротив, очень большой, не так важно, кто прав, а кто виноват (это выяснится на практике). Дело в том, что начинается ценная дискуссия, и вот это действительно важно.

Хотелось бы оговориться: покер-планирование – это не голосование (то есть три голоса молодых разработчиков не перевешивают голос одного опытного специалиста). Но так люди могут высказать свое мнение, что в идеале приводит к оптимальной оценке ситуации.

И не ведитесь на имеющиеся на рынке колоды для покер-планирования с номерами 8, 13, 20, 40 и 100 – они вам не понадобятся.

Будьте проще. Измеряйте истории в малых величинах (1, 3, 5 баллов – если случайно попадется эпик). Не гонитесь за ложным чувством точности, которое придают такие большие числа. На самом деле они только мешают работать.

УЧЕНИК: Мастер, верно ли то, что при гибкой разработке мы не гонимся за точностью при оценке, и все, что нам нужно, – это относительная оценка?

МАСТЕР: При оценке всегда нужно давать самую точную оценку, которую ты можешь дать. Поэтому было бы неправильно говорить, что гибкой разработке чуждо стремление к точности.

УЧЕНИК: То есть, оценивая пользовательские истории, мы должны стремиться как к точности, так и к относительности?

МАСТЕР: Да. Оценивай настолько точно, насколько можешь, только помни, что абсолютной точности все равно не достигнешь. Только при сравнении пользовательских историй друг с другом и при верном измерении скорости работы команды ситуация сложится для нас благоприятно и наши планы окрепнут.

УЧЕНИК: То есть я должен стараться дать максимально точную оценку, но еще больше обращать внимание на то, чтобы истории, с которыми я работаю, сравнивались друг с другом?

МАСТЕР: Да. При оценке небольшое количество работы дает далеко идущие последствия. Не стремись к чрезмерной точности оценок. Сравнивай истории друг с другом. Принимай их такими, какие они есть, и соответствующим образом корректируй ожидания.

УЧЕНИК: Спасибо, Мастер. Я подумаю об этом.

Что дальше?

Поздравляю! Научившись оценивать пользовательские истории относительно друг друга по балльной системе, вы получили все необходимое для создания своего первого гибкого плана.

При планировании гибких проектов мы остановимся на всех инструментах, которые нужны для прогнозирования, отслеживания и создания плана проекта, которому будете доверять и вы, и ваш клиент.

Затем, располагая планом и стартовой колодой, мы будем готовы перейти к главной части работы – реализации гибкого проекта.

Итак, приготовьтесь познакомиться с секретами гибкого планирования.