#7. Все этапы разработки проекта

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

Спойлер:  
 

 

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

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

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

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

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

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

BA начал составление SRS (Systems Requirements Specification) (либо PRD - Product Requirements Document) документа, в котором в общих чертах описывается то, что компания-исполнитель собирается разработать для заказчика. В разных компаниях этот документ может называться по разному, однако от этого его суть не меняется.

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

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

Итак, документ составлен, согласован с клиентом и добавлен в контракт, который подписывается обеими сторонами (клиент – компания-исполнитель).

BA создает эпики, которые попадают в Бэклог Продукта. Что такое эпики мы уже отдельно разбирали, добавлю лишь пару деталей.

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

В случаях, когда эпиков много, а клиент добавляет новые требования (если это предусмотрено контрактом, что нормально для Agile-проектов), BA и Владелец Продукта (PO) могут принять решение об их приоритизации.

Так как ресурсы всегда ограничены, и команда не может сделать все и сразу, PO обсуждает с BA подходы к приоритизации эпиков и выставляет приоритет каждому из них. Одной из наиболее простых и удобных техник приоритизации является метод анализа «MoSCoW» (Руки Кремля здесь нет).

MoSCoW, это аббревиатура, в которой M обозначает Must (Необходимо), S = Should (Нужно), C = Could (Желательно, но не обязательно), W = Won’t (Не обязательно, либо, в некоторых случаях, не нужно).

Так, каждый эпик оценивается и обозначается буквой, которая и определяет приоритет этого эпика. Обычно, «M»-ом обозначаются те эпики, без которых проект не имеет смысла.  
«S»-ом те, которые очень хотелось бы иметь, но без которых проект в принципе может жить на ранних стадиях.  
«C» указывает на то, что эпик было бы не плохо иметь, но он вполне может полежать в Бэклоге, пока не закончатся более приоритетные вещи.  
«W» является знаком, что эпик может лежать в Бэклоге как просто интересная идея, к которой в какой-то момент можно вернуться. Конечно, этот подход можно применять не только к Эпикам, но и к другим артефактам проекта, по необходимости.

Итак, BA и PO провели анализ и приоритизировали Эпики так, чтобы стали понятны главные приоритеты для команды разработки.

На этом этапе PO вместе с PM-ом, и в редких случаях – Тимлидом, составляют User Stories (Пользовательские Истории) для эпиков. Обычно, на старте проекта Истории составляются для нескольких, наиболее приоритетных Эпиков, чтобы команде было над чем работать первые несколько итераций. Остальные эпики разбиваются на истории постепенно, пропорционально свободному времени PM—а и PO.

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

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

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

Существуют разные методы оценки Историй, однако наиболее популярный из них это Покер Планирования (Planning Poker).

Суть метода в том, что каждому из разработчиков в команде выдается по 7 карт с написанными на них числами Фибоначчи (1-2-3-5-8-13-21). (Такие колоды, кстати, есть в продаже в Amazon/eBay)  
Затем PM зачитывает задачу (Историю), в которой написано что нужно разработать, и команда задает вопросы, чтобы полностью понять что нужно сделать. После того, как у команды больше нет вопросов PM просит всех участников оценить задачу. В этот момент каждый участник должен определить, насколько сложна эта задача для него лично, оценить ее выбрав одну из 7 карт и положить ее на стол рубашкой к верху (т.е. так, чтобы число не было видно).

Важным моментом является то, чтобы участники оценивали именно сложность этой задачи, а не то, сколько времени займет ее имплементация. Так, самая простая задача оценивается в 1 а самая сложная в 21. Оценочная единица называется Очки Истории (Story Points, SP).

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

Красота этого метода в том, что он позволяет выявить разночтения, тем самым качественно развив команду. Так, если большинство участников оценило задачу в 5-SP или 8-SP, а кто-то в 21-SP, тогда, вероятнее всего, он не правильно понял требования (или наоборот, он единственный кто понял все правильно).

Обычно, на этапе вскрывания Тимлид выясняет у участников правильно ли они поняли что должны сделать, и команда достигает некоего консенсуса, так, чтобы в итоге История была оценена в Story Point-ах одним из чисел Фибоначчи. Если 3 участника оценили ее в 8, а двое присвоили оценку 5, тогда за Тимлидом остается право решить, это задача на 5 или 8.

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

Ритуал оценки Историй может проводиться еженедельно, в зависимости от темпа разрабатываемых Историй PM-ом и PO. Как и везде, здесь тоже можно договориться и найти наиболее удобный срок.

Что дает нам оценка?  
После того, как прошло несколько итераций, и команда уже научилась относительно-точно оценивать Истории, PM проекта может рассчитать темп команды (он же - Велосити).

Велосити – это метрика, которая показывает, сколько задач в StoryPoint—ах может завершить команда за одну итерацию. К примеру, если команда за последние три Спринта завершила Историй на 35, 40 и 38 StoryPoint-ов, тогда PM может предположить, что в следующей итерации будет выполнено Историй не меньше чем на 35-SP.

Тимлиду, Велосити дает возможность выбирать именно то кол-во Историй, которые, наиболее вероятно, команда успеет выполнить в следующем Спринте, тем самым контролируя объем работ.

Так, на встрече Планирования Спринта, Тимлид просто осмотрит верхнюю часть списка Бэклога (которая состоит из ранее оцененных Историй в StoryPoint-ах, которые, в свою очередь, уже приоритизированы PO и PM-ом) и выберет только те задачи, суммарный вес которых не более 40-SP.

PM-у Велосити дает понимание темпа команды и позволяет измерять ее «пульс» в долгосрочной перспективе.  
Для PO это возможность приоритизировать Истории в Бэклоге таким образом, чтобы контролировать то, какие Истории команда добавит в следующий Спринт.

Если PO знает, что Велосити команды 29, а он хочет, чтобы одна из Историй оцененная в 21-SP была выполнена в ближайшее время, тогда он просто передвинет ее в верх Бэклога, и дождется следующего Планирования Спринта.

Пример: оцененные Истории и Задачи

 

За последние 4 Спринта команда выполнила работ на 24 – 24 – 27 – 25 StoryPoint-ов. PO, зная эту информацию, распределил приоритеты задач так, чтобы История разработки чата (Add system chat in the portal) точно попала в следующий Спринт.

Юридический отдел компании PO также попросил его обновить лицензионное соглашение на сайте (EULA), чтобы избежать проблем с законом. PO учел это пожелание, и приоритизированный Бэклог уже выглядел так:

 

Теперь, PO знает, что в следующем Спринте который, скажем, должен начаться 4го февраля и закончиться 18го, точно будет имплементирован чат и обновлено лицензионное соглашение.

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

Если команда использовала оценку StoryPoint—ами, тогда выбор задач для Бэклога следующего Спринта будет просто.  
Тимлид просто перетащит n-ное кол-во задач из верхушки Бэклога, в Бэклог Спринта, так, чтобы в StoryPoint-ах общий вес этих задач не превышал Велосити команды более чем на 5% - 10%.

Как только Спринт закончился, команда проводит Демо (если есть такая договоренность с клиентом), и приступает к Ретроспективному Анализу (часто называют просто «Ретро», или «Ретроспектив»).

Помимо того, о чем мы говорили обсуждая ритуалы Скрама, на этой встрече, Тимлид и/или PM могут отдельно для себя определить вклад каждого участника в прошедший Спринт, выписать главные проблемы, с которыми столкнулась команда, а также перепроверить насколько верно были оценены Истории.

В идеале, информацию Ретроспектива можно выписать в виде протокола (Meeting Minutes), для будущего использования в сессиях Извлечения Уроков (Lessons learned session).

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

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

Уважение времени участников проекта – это важная характеристика, свойственная качественному PM-у.

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

Шаги 1 и 2 необходимы только в начале проекта.  
Шаги с 3 по 8 будут повторяться каждую итерацию, пока наша команда не завершит проект.  
Следующая статья будет полностью посвящена тому, как писать Пользовательские Истории.