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

Цель данной, второй, части – определить роли участников предлагаемого процесса и порядок его реализации, включая используемые инструменты.

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

Градация ролей участников Scrum-процесса

Все участники процесса разработки по Scrum-методологии поделены на две группы:

• основных (их ещё называют «свиньями» - ничего обидного, просто в беконе с яичницей, любимом блюде завсегдатаев американских забегаловок, именно бекон – основа), и,
• вспомогательных («куры» - их участие только частично, от них требуются «яйца»).

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



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



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

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

Пользовательские истории

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

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

• Идентификатор – уникальный номер истории для её идентификации в будущем;
• Название – краткое, но не допускающее разночтений описание истории;
• Степень важности – зависит от предпочтений владельца проекта, но обычно представляет собой число. Тут только главное договориться, в какую сторону вырастает важность – от 0 до 10, или наоборот.
• Предварительная оценка – обычно имеется в виду – объема работ, но также и в целом всей истории.
• Способ демонстрации – порядок завершения истории и её представления «курам». Нередко здесь приводится описание используемых средств автоматизации проверки и тестирования.
• Критерии приемки – детали выполнения спринта, влияющие на представление проекта пользователям.
• Категория – определяет, к какому виду относится история: пользовательская, маркетинговая, для разработчиков. Вид категорий, их систематизация – приоритет владельца проекта.
• Используемые компоненты – обычно существенные компоненты, на которые необходимо указать, так как они заметно влияют на весь ход спринта. Это могут быть базы данных, специальная серверная технология и т.п.
• Идентификатор записи в журнале учёта ошибок – если такой журнал ведётся, что настоятельно рекомендуется.

Подготовка спринта к реализации

Перед тем как приступить к реализации спринта команда проводит его планирование. При этом по Scrum рекомендованы следующие операции:

• Планирование хода спринта – определяются его задачи, обязательства каждого разработчика и сроки. Обязательна оценка трудозатрат. Если задача оказывается слишком объёмной и не может быть решена в пределах суток, то она разбивается на подзадачи.
• Совещание по подготовке нового спринта не должно превышать более 8 часов. Причём делится совещание на 2 части. В первой владелец проекта и разработчики определяют набор задач, во второй части уже сами разработчики уточняют детали хода разработки.
• Ежедневные совещания – длятся не более 30 минут, участвуют в подобных «летучках» все вовлечённые в процесс (включая и «кур»), но право голоса имеют только «свиньи». Как рекомендация от опытных Scrum-методистов – проводиться подобные совещания должны постоянно в одном и том же месте, при одном и том же интерьере помещения.
• Вот перечень вопросов, на которые каждый разработчик должен ответить (в первую очередь – себе) на ежедневном совещании:
  1. Каков мой вклад в развитие проекта с момента последнего совещания?
  2. Какие задачи я должен поставить перед собой до следующего совещания?
  3. Какие я вижу трудности в разработке проекта?

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

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

Взаимодействие Scrum-команд

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

При проведении подобных совещаний Scrum-групп необходимо сфокусироваться на ответах на следующие вопросы общего характера:

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

Scrum-инструменты

Особенностью Scrum-методологии является ориентация на лозунг – «Будь проще». Действительно, методология практически не признаёт никаких общепринятых программных средств управления и организации работ.

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

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

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

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