Илан Голдштейн - Scrum без ошибок

даже если он несколько лет потратит на обучение, все равно ему не стать scrum-мастером, ведь качества гораздо важнее подтвержденной сертификации (см. лайфхак 4).

Те, кто склонен искажать Scrum, обычно цитируют Agile-манифест, чтобы оправдать отсутствие документации и дефицит планирования.

Манифест agile-разработки программного обеспечения

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

• люди и их взаимодействиеважнее процессов и инструментов;

• работающее программное обеспечениеважнее исчерпывающей документации;

• сотрудничество с заказчикомважнее согласования условий контракта;

• готовность к изменениямважнее следования плану.

То есть, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева.

Те, кто злоупотребляет Agile-манифестом, либо (а) не прочитали последнюю строку, либо (б) забыли последнюю строку, либо (с) проигнорировали последнюю строку.

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

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

Спринты тестирования

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

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

Другое проявление этого антипаттерна – программисты и тестировщики работают в разных спринтах. Например, тестировщики отстают на один спринт от программистов [16]. Такое становится возможным, если практика автоматизированного тестирования все еще недостаточно зрелая и зависимость от ручного регрессионного тестирования велика. Этот ступенчатый сценарий спринта неизбежно приводит к таким же «догоняющим» спринтам, которые обсуждались выше.

Бесконечные нулевые спринты

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

Эта предварительная работа, как правило, не подразумевает временных рамок и не обладает всеми типичными структурными элементами, которые есть в реальном спринте (бэклог спринта и четко сформулированные требования).

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

Рис. 1.4. Минимальный список задач для нулевого спринта

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