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

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

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

Роли в Scrum



Роли в Scrum делятся на два типа «поросята» и «цыплята» или, что то же самое полностью заинтересованные и частично заинтересованные. Эти названия происходят из одного анекдота:
Свинья идёт по дороге. Курица смотрит на нее и говорит: «А давай откроем ресторан!» Свинья смотрит на курицу и отвечает: «Хорошая идея, и как ты хочешь его назвать?» Курица думает и говорит: «Почему бы не назвать 'Яичница с беконом'?». «Так не пойдёт», — отвечает свинья, «ведь тогда мне придётся полностью посвятить себя проекту, а ты будешь вовлечена только частично.»


Основные роли («поросята»)



Product owner (владелец продукта) – человек, чьей основной обязанностью является формулирование и приоритизация требований. Зачастую, это представитель заказчика(или сам заказчик), который обладает некоторым видением продукта, пониманием предметной области и задач, которые продукт призван решать.

ScrumMaster(скрам мастер) – его обязанности: наблюдать за соблюдением принципов Scrum, решать спорные либо конфликтные ситуации, вести Scrum-совещания, заполнять обзор спринта и тому подобное.

Scrum team(скрам команда) – это разработчики проекта, команда(зачастую из 3-8 человек) состоящая из разработчиков, тестировщиков, аналитиков и т. д. В задачи команды, кроме собственно разработки, входит оценка сложности задач.

Побочные роли («цыплята»)



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

Итерации



Как уже было сказано, гибкие методологии подразумевают итеративность разработки. В Scrum итерации называются sprint (спринтами). Продолжительность спринта – величина постоянная и в зависимости от команды может варьироваться от двух до четырех недель. В конце каждого спринта команда предоставляет законченные продукт, количество фич в котором, несколько расширено по сравнению с предыдущим.

Поговорим немного о структуре спринта. Каждый спринт начинается с планирования того, какие задачи будут в ходе этого спринта выполнены. Этот процесс называется «sprint planning meeting» (Планирование спринта). Подробнее об этом в соответствующем разделе. Далее, следует собственно разработка. При этом команда ежедневно собирается на совещание «daily Scrum meeting»(ежедневное совещание) или «stand-up meeting», на котором каждые из членов команды докладывает о том, что он сделал с момента предыдущего совещания, какая ему необходима помощь (если необходима) и чем он планирует заниматься дальше. Структура доклада, может незначительно отличаться от команды к команде. Зачастую, это совещание ограничено по времени 15-20 минутами. Это, как и все прочие совещания, ведет скрам мастер команды. В его первоочередные обязанности так же входит решение проблем в коммуникации с другими командами. Каждый спринт завершается «sprint demo»(демонстрация спринта) и «retrospective мeeting»(Ретроспективное совещание). В процессе демонстрации спринта, команда, показывает владельцу продукта, а так же всем заинтересованным разработанную за спринт функциональность, отвечает на вопросы по ней (незаконченная функциональность не демонстрируется) .Смысл ретроспективного совещания в том, чтобы выявить хорошие и плохие аспекты прошедшего спринта, с целью постоянного совершенствования рабочего процесса.

Планирование спринта



Одним из наиболее важных и детально описанных процессов в Scrum, является процесс планирования спринта. Выглядит он следующим образом: Владелец продукта, предоставляет список своих пожеланий по расширению функциональности, именуемый в Scrum «user stroies»(пользовательские истории) скрам команде, упорядоченный в соответствии с их приоритетом. Задача команды состоит в том, чтобы оценить эти истории (не обязательно все, об этом дальше) на предмет сложности и трудоемкости в некоторых эталонных единицах – «story points»(очки историй). Очко истории – это некоторая единица определенная командой и являющаяся мерой сложности историй. Зачастую в качестве очков историй используются, так называемые «идеальные человеко-дни», то есть такие в которые «среднестатистический» член команды работает, не отвлекаемый никакими посторонними задачами. Очки истории могут так же определяться любым другим образом, по желанию команды, единственным требованием к очку истории, является его эталонность, то есть неизменность от спринта к спринту. На основании оценки историй и оценочной скорости команды (подробнее об этом в разделе «Оценка скорости команды»), скрам мастер, исходя из приоритетов указанных владельцем продукта, определяет, какие именно истории попадут в этот спринт. Далее, если владельцем продукта удовлетворен результатом – планирование спринта заканчивается. Если же владельца продукта результат не устраивает, он может переформировать список историй, то есть изменить их приоритеты, же разбить историю на части или сузить ее рамки. После этого команда, если это необходимо, производит переоценку, а скрам мастер формирует новый список историй для спринта. Процесс продолжается до тех пор, пока владелец продукта не согласится с видом спринта. Если скрам мастер видит, что ситуация зашла в тупик или что встреча затянулась слишком надолго (продолжительность совещания так же, изначально, устанавливает скрам мастер) в его обязанности входит решить данную проблему.

Scrum покер



Как мы уже говорили в процессе планирования спринта команде необходимо оценивать пользовательские истории предоставленные владельцем продукта. Для этой цели Scrum предлагает свою методику, под названием «Scrum poker»(Scrum покер). Правила этой «игры» таковы:

Все игроки (члены команды) получают колоду карт с числами: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 и иногда значками «?», «∞», «чашка кофе». Оглашается история, которую необходимо оценить. При необходимости уточняются рамки истории. Затем каждый член команды выкладывает карту с числом, которое, по его мнению, лучше всего соответствует количеству очков историй для данной истории, рубашкой вверх. Когда все выложили по карте, карты открываются. Числа означают соответствующее значение в очках историй (0 – означает, что трудозатраты на историю пренебрежимо малы), «?» – непонимание задачи, «∞» - задача слишком объемна для оценки, ее необходимо разбить на подзадачи, «чашка кофе» – просьба о перерыве. Если есть «?», то человеку, выложившему его, дают слово, и он задает вопросы о том, что ему непонятно (не исключено, что другие об этом просто не задумывались). Если вопросов нет, скрам мастер смотрит на значения на картах, если они совпадают, то данное количество очков историй полагается оценкой истории. Если же появились разногласия, скрам мастер просит представителей разных мнений обосновать свою оценку. Затем проходит второй тур голосования и так далее до тех пор, пока все оценки не сравняются. Очень редко бывает больше двух туров. Если команда сходится на символе «∞», то скрам мастер обращается к владельцу продукта с просьбой разбить историю на подзадачи. Затем команда оценивает подзадачи как отдельные истории.

Оценка скорости команды



Как мы уже говорили, вначале спринта команда оценивает сложность пользовательских историй предоставленных владельцем продукта. Но как определить, сколько очков историй команда сможет сделать за спринт? Ответить точно на этот вопрос невозможно, ведь оценивая истории, команда не может знать обо всех подводных камнях, которые выплывут при разработке. К тому же есть факторы, которые сложно предсказать, например, больничные. В конце концов, продуктивность разработчика так же величина не постоянная. Поэтому в Scrum используется понятие оценочной скорости команды. Данная оценка может происходить различными методами. Одна из методик (которую с некоторыми вариациями мы рассмотрим в данной статье) называется «yesterdays wether» (вчерашняя погода). Ее идея состоит в том, что погода сегодня вряд ли будет сильно отличаться от вчерашней. И хотя, касательно погоды это далеко не всегда верно, для оценки скорости команды этот подход работает довольно хорошо. Так же неплохо было бы включить в эту оценку различные перестановки в команде (приход-увольнение членов команды) и некоторые дополнительные известные факторы, такие как отпуска, побочные задачи. Данные факторы можно учитывать, с помощью таких параметров, как «focus factor»(коэффициент концентрации) и перерасчет очков истории на одного человека. Коэффициент концентрации – коэффициент, определяющий отношение количества времени посвященного работе над пользовательскими историями к общему рабочему времени, в среднем за спринт. Рассмотрим следующие примеры:

1)Команда из шести человек работала над проектом. Их оценочная скорость была 30 очков историй за спринт. Один из них уволился. Можно приблизительно оценить, что скорость команды упадет до 25 очков историй за спринт.

2) Команда работает по Scrum с двухнедельными спринтами, ее оценочная скорость была 30 очков историй за спринт. Скрам мастер знает, что в следующем спринте у команды будет трехдневный тренинг. Пусть коэффициент концентрации команды был f. Соответственно поскольку в следующем спринте команда 3 из 10 дней не будет заниматься проектом. Таким образом, команда теряет 3/10=30% своего времени. То есть коэффициент концентрации в этом спринте будет f*70%. А оценочная скорость, соответственно 30*f*70%/f=30*70%=21 очко историй.

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

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

Комментарии

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