Этапы и мероприятия Scrum

7.2. Ежедневные встречи (daily)

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

увеличить изображение
Рис. 7.2. Процесс проведения StandUp

Знание о том, чем занимаются коллеги по команде, помогает в:

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

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

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

Каждый член команды должен отвечать на необходимые вопросы.

Важно, чтобы все, отвечая на вопросы, не вдавались глубоко в детали и, боже упаси, уж точно не пытались тут же их решать.

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

Для того чтобы перебороть неправильное развитие Scrum-процесса и направить дэйли в нужное русло, нужно:

• Соблюдать установленные правила. Правила не должны устанавливаться "сверху". Принципы работы и решения о применении правил должна принимать команда, но не Scrum-мастер и не владелец продукта. Визуализировать принятые правила полезно. Актуализировать правила, синхронизируясь с состоянием команды и окружающих условий, также очень важно.
• Думать о развитии. Scrum - полезная практика. С течением времени члены команды учатся правильно проводить встречи и быть эффективными в обстоятельствах постоянно меняющихся условий. Количество проблем, если соблюдать правила и заниматься совершенствованием рабочих практик, будет постепенно уменьшаться. Через некоторое время Scrum трансформируется в полностью операционную деятельность. Появится соблазн немного его разнообразить. Дайте волю этим стремлениям. Это поможет команде сплотиться и стать более производительной.

7.3. Груминг бизнес-задач

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

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

Эту активность по возможности необходимо проводить в очном режиме присутствия всех ее участников. В противном случае велика вероятность, что она разрастется во времени.

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

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

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

• эти задачи понятны всем членам команды;
• они имеют такой объем, что несколько из них могут быть сделаны за спринт;
• они оценены командой.

Чтобы груминг прижился в операционной деятельности каждой команды, необходимо следовать нескольким простым правилам:

• сделайте груминг частью вашего процесса;
• выработайте понятие готового бэклога спринта - "Definition of Done" (DoD).

Эти характеристики, в соответствии с которыми задачу можно брать в работу на спринт.

• Установите понятие "текущего" и "следующего" инкремента, что позволит владельцу продукта управлять объемом работ, выполняемых командой.
• Встречайтесь "вживую" всей Scrum-командой с владельцем продукта не реже раз одного раза в спринт для груминга и планирования релиза.
• Во время груминга работайте с бэклогом продукта, который был подготовлен и приоритизирован владельцем продукта.

Способ принятия решений (DoD) при проведении груминга о возможности взять задачу в работу - это не догма (в Scrum их практически нет). Этот способ выбирает команда и может изменить его в зависимости от своей "развитости". Могут быть использованы следующие подходы:

• Классический подход - консенсус. Преимущество этого метода состоит в том, что решение принимается всеми членами единогласно (это повышает мотивацию всех членов команды и осознание разделения ее ценностей, но, как правило, происходит очень медленно.
• Большинство. Это менее демократичный способ по сравнению с классическим, что может привести к снижению мотивации отдельных членов команды, но он является более быстрым. Если голоса разделились поровну, то можно либо продлить обсуждение, пока один человек не изменит мнение, либо всегда использовать правило выбора меньшей (вызов) или большей (запас) оценки.
• Оценка будущим исполнителем. Это метод, который наименее вписывается в дух Scrum. Решение принимает конкретный исполнитель, который будет далее реализовывать этот функционал, и команда остается за бортом "командной" работы. Он наиболее быстрый для принятия решения о работе, но в дальнейшем при злоупотреблении им команда рискует разбиться на индивидуумов.

Для того чтобы повысить профессионализм проведения груминга, целесообразно использовать методы оценки задач, о которых было сказано в "Планирование" , - к примеру, метод Planning Poker.

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

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