���������� ������-������ 2009'3

Home k-press.ru


! ?

Гибкое (Agile) планирование в реальной жизни

Автор: Стефан Сурдек (Steffan Surdek)
Опубликовано: 09.07.2010
Версия текста: 1.1

Облегчаем переход
Планирование итераций
Создание пользовательских историй
Выявление владельца продукта
Backlog продукта
Backlog релиза
Backlog итерации
Назначение баллов пользовательским историям
Измерение производительности
Заключение

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

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

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

ПРИМЕЧАНИЕ

Коротко о гибкой (Agile) разработке ПО

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

На схожих фундаментальных концепциях основаны следующие современные способы анализа и операционного управления:

«Экономное» (lean) производство: производственная практика, считающая расточительными любые траты ресурсов, не приносящие пользы конечным заказчикам.

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

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

Данная статья поможет вам преодолеть эти сложности и перейти от просто итеративной разработки к действительно гибкой разработке. В статье затрагиваются следующие темы:

Облегчаем переход

Перед переходом на новый процесс следует обратить внимание на следующее:

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

Планирование итераций

Начнем с популярного вопроса: «Насколько длинной должна быть итерация?». Цель работы итерациями – налаживание регулярного взаимодействия со сторонами, заинтересованными в вашем продукте (клиентами, владельцем продукта и т.д.)

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

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

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

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

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

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

Создание пользовательских историй

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

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

Как <роль>, я хочу <цель>, чтобы <деловая выгода>.

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


Рисунок 1. Разбиение эпопеи на пользовательские истории.

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

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

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

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

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

Выявление владельца продукта

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

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

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

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

Backlog продукта

Владелец продукта отвечает за backlog продукта – набор пользовательских историй, которые должны быть реализованы в продукте. Для каждой истории должен быть выставлен приоритет.

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

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


Рисунок 2. Backlog продукта служит источником для заполнения остальных backlog-ов

Команда должна оценить размеры высокоуровневых историй в backlog-е продукта в баллах (так называемых story points). В процессе оценки участвуют все команды, вовлеченные в реализацию истории (разработчики, тестеры, технические писатели). Эти оценки дают владельцу продукта представление об относительной стоимости каждого куска функциональности.

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

Почему backlog не должен быть очень длинным? Это предложение происходит из принципа экономичной разработки (см. врезку Коротко о гибкой разработке ПО). Нет никакой пользы в том, чтобы держать в очереди объем работы больший, чем вы можете выполнить за разумное количество времени. Если из backlog-а выпадает хорошая идея, то через некоторое время она туда вернется, если это действительно ценная идея, отвечающая нуждам заказчика. Поэтому не бойтесь исключать некоторые вещи и не пытайтесь их хранить каком-то своем секретном резервном списке.

Backlog релиза

Перед началом работы над очередным релизом продукта владелец продукта просматривает backlog продукта, выявляет истории, которые должны быть реализованы в этом релизе, и переносит их в backlog релиза (release backlog).

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

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

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

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

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

Backlog итерации

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

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

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

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

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

Перед тем как команда вернется к backlog-у релиза, убедитесь, что все истории, запланированные на итерацию, действительно выполнены (а затем проверьте это еще дважды!). Все ли задания выполнены? Если история еще не до конца протестирована, возможно, вам стоит попросить разработчика помочь тестеру закончить работу. Исправьте дефекты, заведенные на все разработанные в этой итерации истории. Контролируйте качество: важно не то, как много работы вы сделаете за итерацию, а то, насколько мало ошибок окажется в конечном продукте.

Полезно сформулировать критерии завершения итерации. Например, чтобы история считалась завершенной, все высокоприоритетные дефекты (важности 1 и 2) должны быть исправлены. Все низкоприоритетные дефекты (важности 3 и 4) будут добавлены в backlog релиза и должны быть исправлены в следующей итерации. Важно не откладывать слишком надолго исправление дефектов. Иначе в конце работы над релизом их может накопиться слишком много, и вы окажетесь в неприятном положении.

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

Команда может добавлять в план итерации работу любого рода. Если для работы над историей необходимо предварительно спроектировать архитектуру системы, создайте для этого пользовательскую историю и заведите в ней такие задания, как «Проектирование», «Создание прототипа» или «Исследование». Цель создания таких историй - дать возможность владельцу продукта выставить им приоритеты. Если владелец продукта считает стоимость проведения исследования слишком высокой, он понизит приоритет этой истории или вообще исключит ее из текущего релиза.

Назначение баллов пользовательским историям

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

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

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

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

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

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

Покер Планирования – это способ командного согласования оценки сложности или объема работы при разработке программного обеспечения. В этом способе делается попытка минимизировать влияние, оказываемое на оценку преждевременными комментариями участников команды. Для каждого оцениваемого задания каждый член команды выбирает свою карту оценки (карты имеют значения 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100), таким образом, что его карту не видит никто из других игроков. После того как все игроки сделали свой выбор, карты раскрываются (и происходит обсуждение).

Измерение производительности

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

Сначала команда дает балльную оценку каждой пользовательской истории из backlog-а релиза. В начале каждой итерации команда выбирает истории, над которыми будет вестись работа в этой итерации. Чтобы заработать баллы, назначенные какой-либо истории, команда должна завершить все задания этой истории в этой итерации.

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

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


Рисунок 3. График производительности на протяжении нескольких итераций.

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

Таблица 1. Количество баллов за итерацию

Итерация

Баллы

1

28

2

32

3

36

4

34

5

33

6

37

7

31

8

35

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

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

На рисунке 4 показан backlog релиза, разделенный на 3 секции. В средней секции показано, какое количество работы может быть выполнено на основе сделанных выше предположений.


Рисунок 4. Экстраполяция объема завершенной работы

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

Заключение

Основная цель гибкого планирования – сделать как можно больший объем «известной» работы видимым всем участникам процесса. Мы говорим «известной», потому что по мере получения новых знаний о выполняемой работе вы можете добавлять в backlog новые истории. Это позволяет владельцу продукта поддерживать приоритеты историй в актуальном состоянии и гарантировать, что работа постоянно будет идти над наиболее важными вещами.

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

Я высказывал в этой статье свои собственные взгляды, которые могут не совпадать с мнением IBM.

Ресурсы

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

Серия статей "Architectural manifesto: Adopting agile development" на developerWorks (EN, март 2008 г. - январь 2009 г.) может помочь вам решить, подойдет ли гибкая разработка для ваших потребностей:

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

Copyright 1994-2016 "-"