Методологии управления проектами, ч.2

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

Scrum

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

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

Алгоритм работы по системе Scrum1. Составление списка задач по проекту (Project backlog)
Это вообще все задачи, которые нужно сделать, чтобы завершить проект. Этот список постоянно пополняется, модерируется, сортируется, актуализируется. Не обязательно пытаться вписать сюда за один день все задачи, от старта продакшена до релиза - это невозможно. Достаточно перечислить задачи обозримого будущего, которые, вы точно знаете, придется делать. Для того, чтобы такие задачи выявить, нужно сесть и расписать большие этапы работы над проектом, разбив его на несколько частей. Например, “часть 1 - прототипирование боевки”, “часть 2 - разработка апгрейдов юнитов” и так далее.

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

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

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

Если вы вдруг решите погуглить дополнительную информацию про Scrum, то вы наткнетесь на то, что планирование задач в рамках этой методологии ведется не в часах, а в так называемых story points, которые являются некой абстрактной величиной, обозначающей не время, а сложность работы над задачей. При таком расчете 1 story point - это затраты, которые требуются на выполнение минимально сложной задачи на вашем проекте. Данный способ хорош тем, что он учитывает все риски, возникающие во время работы (перекуры, перерывы на кофе, отвлечения на другие задачи, вопросы коллег), а как показывает практика, сотрудникам при оценке задач учесть эти риски самостоятельно довольно трудно. Если у вас маленькая команда, или вы только начинаете разработку своего первого проекта - то я бы посоветовала вам не заморачиваться со story points и мерить все в человекочасах, делая скидку на издержки производства, а на story points переходить уже после того, как вы как следует освоитесь со Scrum методологией.

5. Работа над задачами спринта
В процессе работы задачи перемещаются по спискам, проходя различные этапы.

1) Список “Спринт”
Здесь лежат все задачи на текущий спринт.

2) Список “В работе”
Сюда переходят задачи, над которыми в данный момент работают специалисты.

3) Список “QA”
В этом списке находятся задачи, отправленные на тестирование. Задача не считается законченной до тех пор, пока тестировщик не подтвердит, что она действительно работает так, как это было задумано. Существует много примеров того, как нормально функционирующая в локальном билде программиста задача перестает работать на устройстве тестировщика, а также примеров того, как тестировщик умудряется найти новые способы “сломать” фичу, которую так старательно делал программист.

4) Список “Баг репорт”
Сюда попадают задачи, в процессе тестирования которых были выявлены неточности, или баги. Любая задача, фактическая реализация которой не соответствует тому, как данная задача была описана, после тестирования попадает в список “Баг репорт”, и работа над ней не заканчивается до тех пор, пока она все-таки не попадет в список “Готовых” задач.

5) Список “Готово”
Здесь находятся задачи, которые являются полностью выполненными. Нетрудно догадаться, что главной целью каждого спринта является перемещение всех задач из списка “Спринт” в список “Готово”.

6) Список “Заблокировано”
В этот список попадают задачи, за которые взялся специалист, но в процессе работы над ними он понял, что их невозможно выполнить без дополнительной смежной или параллельной работы другого специалиста. Пример: новый арт невозможно добавить в игру, потому что он еще не отрисован художником, а у художника на этот спринт другие задачи. Или программист UI сверстал интерфейс, а полностью внедрить его в игру для тестирования невозможно, так как отсутствует необходимый для этого функционал фичи. Такие накладки случаются, хотя их нужно стараться избегать. Появление задач в списке “Заблокировано” - это первый звоночек для вас о том, что вы что-то сделали не так при планировании.

6. Стендапы (Stand-up Meetings)
Стендап - это один из важнейших нюансов работы по системе Scrum. Он представляет собой ежедневное утреннее совещание всей команды разработчиков, которое проводится в режиме стоя (отсюда и название). Стоять нужно затем, чтобы никто не растекался мыслью по древу и не возникало долгих обсуждений. На стендапе каждый член команды кратко рассказывает чем он занимался вчера и что будет делать сегодня, упоминает трудности, с которыми столкнулся, обращается к коллеге, помощь которого по задаче ему потребуется сегодня. Выступление одного участника команды обычно не превышает 1-2 минут, но даже при такой емкой подаче информации стендапы несут в себе массу пользы.

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

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

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

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

7. Ретроспектива
Один из самых важных этапов работы в методологии Scrum - процесс анализа прошедшего спринта. На каждый спринт у вас есть равное количество человекочасов, или оптимальное количество story points (в зависимости от того, в каком формате вы ведете измерения). Равное оно потому, что все спринты одной длины и в них участвует равное количество человек. Это самое оптимальное количество вычисляется путем поиска среднего арифметического после двух-трех спринтов. В конце спринта строится так называемая диаграмма сгорания задач (Burndown chart).

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

Роли в Scrum

Так кто и как несет ответственность за выполнение тех, или иных этапов работы? В системе Scrum выделяют следующие роли для участников процесса:

1. Product Owner.
По сути, это или руководитель проекта, или главный геймдизайнер, или продюсер - кто выполняет эту роль, зависит от команды. Product Owner формирует и сортирует по срочности задачи в списке Project Backlog и Sprint Backlog. Он же формулирует задачи и цели каждого спринта.

2. Scrum Master
Это человек, который следит за тем, чтобы принципы Scrum не нарушались и все процессы, связанные с организацией труда, протекали в штатном режиме. По сути это человек, который знает о Scrum методологии больше всех и разрешает споры, которые возникают насчет процесса ведения спринта и дает дополнительную мотивацию команде, устраняя все возможные препятствия, возникающие на ее пути. В маленькой команде для этой роли как правило не выделяют отдельного человека, а эту задачу берет на себя Product Owner.

3. Команда разработчиков.

Давайте суммируем все вышесказанное:

1. Scrum берет поэтапность работы “водопадной” системы, при этом оставаясь гибкой благодаря возможности перемещаться между этапами и благодаря разбиванию проекта на несколько частей. Список задач определяется не текущим этапом, а нуждами проекта.

2. Количество задач в Scrum ограничено так же, как и в Kanban, но ограничено с учетом времени благодаря формированию общего значения человекочасов или story points. При этом задача является завершенной только после тестирования, что означает ее качественное выполнение: выбор между завершением всех задач спринта в срок и качеством их выполнения всегда падает в пользу последнего.

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

Немного о Trello

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

1. Простота использования
Существует великое множество различных программ для управления проектами, до Trello я пробовала только более сложные варианты (Unfuddle, Jira, Redmine). Программа, как и методология управления проектом, выбирается с оглядкой на каждый конкретный случай. Для больших и серьезных проектов функций Trello будет явно недостаточно. В крупных корпорациях подобного рода системы вообще пишутся отдельно и индивидуально. Но маленькой или начинающей команде, и даже команде из одного человека и Trello, и методология Scrum (пусть и в упрощенном виде) подойдут отлично.

2. Кастомизация списков
Возможность создавать свои списки, а также несколько досок на одном аккаунте (например, одна доска может быть с текущим спринтом, вторая - с архивами всех завершенных спринтов).

3. Кастомизация задач
Возможность настраивать кастомизированные метки (цветные отметки на задаче), добавлять участников в задачу, прикреплять файлы, прикреплять документы из Google Drive, делать, или не делать обложки для задач - все это можно настроить за 10 минут на ваш вкус.

4. Определение сроков
Возможность устанавливать сроки конкретной задаче.

5. Удобство управления
Удобство управления: карточки перетаскиваются из списка в список простым драг-н-дропом. В самой карточке хранится история всех ее изменений и перемещений между списками.

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