keepsimple
dark
en | ru

#7. Схема принятия и ведения проекта

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

Спойлер:

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

Шаг 1: Анализ требований

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

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

Шаг 2: Разработка первичной документации

BA начал составление SRS (Systems Requirements Specification) документа, в котором в общих чертах описывается то, что компания-исполнитель собирается разработать для заказчика. Полагаю, что в некоторых компаниях этот же документ может называться совершенно подругому, однако от этого его суть не меняется. Как мы уже знаем, Agile не подразумевает тщательной документации, поэтому глубина детализации допустимая при описании функционала будущего проекта определяется индивидуально для каждого проекта, в основном, после согласования с заказчиком.

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

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

Шаг 3: Создание эпиков

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

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

Шаг 4: Приоритизация Эпиков

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

MoSCoW, это аббревиатура, в которой M = Must (Необходимо), S = Should (Нужно), C = Could (Желательно, но не обязательно), W = Won’t (Не обязательно, либо, в некоторых случаях, не нужно). Так, каждый эпик оценивается и обозначается буквой, которая и определяет приоритет этого эпика. Обычно, «M»-ом обозначаются те эпики, без которых проект не имеет смысла, «S»-ом те, которые очень хотелось бы иметь, но без которых проект в принципе может жить на ранних стадиях, «C» указывает на то, что эпик было бы не плохо иметь, но он вполне может полежать в Бэклоге, пока не закончатся более приоритетные вещи, а «W» является знаком, что эпик может лежать в Бэклоге как просто интересная идея, к которой в какой-то момент можно вернуться.

Кстати, MoSCoW анализ, как и другие инструменты, можно спокойно использовать в проектах вообще не связанных с IT ☺)).

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

Шаг 5: Пользовательские Истории

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

Шаг 6: Оценка Пользовательских Историй и что такое Велосити (Velocity)

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

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

Итак, посмотрим как происходит оценка.

Существуют разные методы оценки Историй, однако наиболее популярный из них это Покер Планирования (Planning Poker). Суть метода в том, что каждому из разработчиков в команде выдается по 7 карт с числами Фибоначчи (1-2-3-5-8-13-21). Затем 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 проекта может рассчитать Велосити (Velocity), он же – тэмп команды. Велосити – это метрика, которая показывает, сколько задач в 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-ы дают возможность более-менее контролировать происходящее а не полагаться на случай.

Шаг 7: Составление Бэклога Спринта

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

Шаг 8: Ретроспективный Анализ

Как только Спринт закончился, команда проводит Демо (если есть такая договоренность с клиентом), и приступает к Ретроспективному Анализу (часто называют просто «Ретро», или «Ретроспектив»). Помимо того, о чем мы говорили обсуждая ритуалы Скрама, на этой встрече, Тимлид и/или PM могут отдельно для себя определить вклад каждого участника в прошедший Спринт, выписать главные проблемы, с которыми столкнулась команда, а также перепроверить насколько верно были оценены Истории. В идеале, информацию Ретроспектива можно выписать в виде протокола (Meeting Minutes), для будущего использования в сессиях Извлечения Уроков (Lessons learned session). На этих сессиях, которые, обычно, проходят от одного до нескольких раз в году, суммарно обсуждаются все те проблемы и странности, которые происходили с командами в прошедших проектах. По сути, это, своего рода Ретроспективный анализ Ретроспективных анализов (:D забавно звучит, но это близко к истине).

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

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

Итог

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

Шаги 1 и 2 необходимы только в начале проекта.

Шаги с 3 по 8 будут повторяться каждую итерацию, пока наша команда не завершит проект.

Следующая статья будет полностью посвящена тому, как писать Пользовательские Истории.