Scrum

Эта статья была написана по методологии Scrum
	Скучающий автор написал её, пока пытался не уснуть на ежедевном созвоне авторов Абсурдопедии Если завтра на этой странице будет написано про самоходные гаубицы, не удивляйтесь: всего лишь поменялись требования. Внимание: картинка с мамонтом соответствует acceptance criteria и была согласована с Absurdopedia Owner на Mammoth Confirmation Session
	Development Team

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

Основные понятия

Для большой внушительности Scrum оперирует рядом церемониальных понятий, культовых артефактов и таинственных ритуалов.

• Scrum — непосредственно набор принципов. Термин произносится с придыханием, почтением и только высококлассными специалистами. Любой другой специалист не понимает принципов Scrum и поэтому не имеет права упоминать его всуе.
• Спринт — итерация в Scrum. Длится несколько недель и разделяется особыми митингами. В соответствии с буквой правил scrum каждый спринт представляет собой череду митингов, поэтому разработка продукта не ведётся, благодаря чему в него не внедряется некорректно работающий функционал. Поэтому по итогам каждого спринта продукт готов к релизу. В соотвествии с духом правил scrum ожидается, что на итоговых длинных митингах, подытоживающих спринт, команда разработчиков настолько заскучает, что завершит работу над имеющими задачами, и продукт также будет готов к релизу.
• Бэклог — список задач, которые как наивно полагается, кто-то будет решать.
• Диаграмма сгорания задач — хроника пикирующего бомбардировщика, описывает количество решённых задач, в идеале стремится быть графиком линейной зависимости, обычно же лежит горизонтально.

Роли в скрам-процессе

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

Первая категория:

• Скрам-мастер (scrum-master) — человек, ответственный за команду, проверяет посещаемость митингов, полное соответствие скрам-церемоний требованиям Scrum. Полезной деятельности не ведёт;
• Владелец продукта (product owner) — единственный человек, который знает, что должно получится, и единственный, кто заинтересован в результате;
• Команда разработки (development team) — кросс-функциональная команда разработчиков проекта. В соответствии с идеологией проекта, каждый участник команды является многоплановым специалистом, благодаря чему команда может функцинировать в любых условиях. Так, например, если одного из разработчиков схватил аппендицит, в команде должно быть несколько специалистов, способных быстро провести операцию и обеспечить разработчику возможность присутствовать на очередной встрече. Размер команды в идеале составляет от 3 до 9 человек, если по скраму ведётся футбольный матч, разрешается включить 11 человек + резерв. От команды ожидается участие во всех митингах, а также, по возможности, ведение разработки продукта.

Вторая категория:

• Пользователи (users) — не имеют никакого отношения к процессу разработки, однако незримо присутствуют в описании каждой задачи как якобы заинтересованная сторона;
• Клиенты, продавцы (stakeholders) — лица, которые инициируют проект и для кого проект будет приносить выгоду. Появляются в процессе разработки лишь изредка, чтобы сообщить, что весь продукт реализован не так и надо по-другому.
• Управляющие (managers) — бюрократическая составляющая проекта, люди, ответственные за замедление процесса разработки. Для принятия любого решения в рамках scrum-процесса необходимо подтверждение от менеджера, причём каждый менеджер утверждает, что это вне его компетенции и перенаправляет к следующему. В соответствии со стандартами scrum, когда круг замыкается, первый менеджер цикла обязан дать окончательный ответ
• Эксперты-консультанты (consulting experts) — всегда в отпуске.

Распорядок дня

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

• Pre-Daily Scrum meeting (15 минут): собрание команды разработчиков и скрам-мастера. Каждый участник рассказывает о том, какие встречи он посетил вчера, на каких собирается присуствовать сегодня, и встретил ли он какие-либо проблемы в ходе посещения встреч. Далее вместе со скрам-мастером команда решает, какую информацию лучше утаить от заказчиков и владельцев продукта, какую, наоборот, следует раскрыть более подробно;
• Daily Scrum meeting preparation (15 минут): генеральная репетиция Daily Scrum meeting, участники команды разработки делятся свои обновлениями, ориентируясь на замечания, озвученные в ходе Pre-Daily Scrum meeting;
• Daily Scrum meeting (30 минут): участники команды разработки делятся своими обновлениями с командой и владельцами продукта, а также прочими стэкхолдерами, отвечают на вопросы. При выступлении учитываются те выводы, к которым команда пришла в ходе Pre-Daily Scrum meeting и Daily Scrum meeting preparation;
• Scrum of Scrums (30 минут): встреча между несколькими scrum-командами, в рамках которой скрам-мастера перечисляют встречи, посещённые участниками их команд;
• Clarification session (30 минут): встреча, в ходе которой команда может задавать вопросы владельцам продукта относительно той или иной задачи;
• Backlog refinement (1 час): команда исследует backlog, задаёт вопросы владельцу продукта по всем непонятным моментам;
• Estimation session (1 час): команда оценивает исследованные на предыдущей встрече задачи в абстрактных единицах измерения, которые ничего не характеризуют и в принципе не поддаются формальному описанию;
• Reestimation session (1 час): проводится, поскольку в ходе предыдущей сессии некоторые уже оценённые задачи могли получить новые требования и, соответственно, теперь тянут на более высокую абстрактную оценку;
• Rereestimation session (1 час): аналогично предыдущему. Оценка, выставленная в ходе rereestimation-сессии считается окончательной и неизменной, однако благодаря гибкости методологии Scrum может быть изменена любым участником команды;
• Daily planning (1 час): на основе оценок, выставленных в ходе rereestimation сессии составляется план работы на день;
• Daily retrospective (1 час): Члены команды высказывают своё мнение о прошедшем дне. В рамках обсуждения идёт поиск ответа на два вопроса: «Что было сделано хорошо в прошедший день?» и «Что надо улучшить на следующий день?»;
• Just meeting: проводится в том случае, если по какой-то прчине запланированные встречи завершились раньше завершения рабочего дня. Проведение Just meeting считается признаком некачественного ведения scrum-процесса.

Помимо прочего, в конце спринта проводятся дополнительные встречи:

• Sprint estimation and planning: аналогично ежедневным встречам, но больше, длиннее и бесполезнее. Reestimation сессия не проводится, так как каждая задача переоценивается в рамках daily estimation, reestimation и rereestimation сессий.
• Demo session: нарезка наиболее ярких и драматичных моментов со всех встреч, проведённых в рамках спринта. Подготавливается скрам-мастером для демонстрации всем заинтересованным лицам. Как правило, отдельным митингов проводится закрытый показ только для участников команды разработки, после чего проходит открытый показ.