практики скрама
ScrumBut
У нас скрам, но...
мы не поставляем работающий инкремент продукта каждый спринт
Нет, вы серьезно?

Одна из ценностей Agile-манифеста гласит
Работающий продукт важнее исчерпывающей документации
Подумайте об этом немного. Подумали? Отлично, иногда это полезно:) А теперь давайте посмотрим на Scrum. Многие компании используют Scrum, даже вот наша. Во всех конфигурациях и формах.

В Скрам-гайде, основном документе, описывающем правила скрама говорится следующее

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

Стабилизирующий спринт

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

Нулевой спринт

Нулевой спринт предполагает проведения любых подготовительных работ, которые нужны для старта непосредственно самой разработки продукта. Ну вы понимаете, чтобы оооооочень хорошо подготовиться к началу первого спринта. Обычно в течение «нулевого спринта» делают вот такую работу:


  • создают беклог продукта
  • создают релизный план
  • разрабатывают дизайн архитектуры
  • разворачивают архитектуру

В нулевом спринте между тем есть одно противоречие - его результатом не является инкремент продукта. И он часто используется в тех компаниях, где менеджеры и коучи недостаточно информированы о правилах скрама и где преобладает «вотерфольные» привычки.



Спринты для различных фаз проекта

Признаться, это наше любимое извращение :) - разделить на спринты обычные вотерфольные этапы сбора требований, документирования требований, разработки, тестирования и внедрения. Эдакий Скрамфолл.

Ну то есть берете обычный вотерфольный проект размером эмммм в год, нарезаете каждый его этап на двухнедельные итерации и смело полируете сверху скрамовскими событиями и ролями. Выходит в целом отлично, но…
Это НЕ имеет НИКАКОГО отношения к скраму. Ну то есть совсем

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

Скрам основывается на теории управления эмпирическими процессами (то есть процессами получения опыта).

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

- Поделитесь вашим секретом успеха
- Всего два слова
- О! Так просто! Какие же?
- Правильные решения
- Понятно. А в чем секрет правильных решений?
- Одно слово
- Какое??
- Опыт
- А как получить этот опыт?
- Два слова
- Какие эти два слова?????
- Неправильные решения
«Эмпиризм утверждает, что знание приходит с опытом, а решения принимаются исключительно на основании того, что является известным. Скрам использует итеративно-инкрементальный подход для оптимизации прогнозируемости и управления рисками. В основе управления эмпирическими процессами заложены три главных принципа: прозрачность, инспекция и адаптация». -Скрам-гайд

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

А теперь вернемся к тем практикам, которые описали выше

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

Командам, которые сталкиваются с необходимостью таких спринтов можно было бы порекомендовать поработать над критериями готовности фичи (definition of done) и расширить их, включив туда все необходимые действия, чтобы результатом стала полезная и потенциально готовая к поставке в продуктив новая функциональность продукта

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

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


Скрамфолл.

Ну это вообще предел. Это когда вы хотели что-то изменить, но на всякий случай пока решили оставить все, как есть. Это не то, что мы вдруг склоняемся к проведению большой бумажной работы, это и есть ребята большая бумажная работа. Все, что было сказано про нулевой спринт, применимо к этой ситуации. И даже более того. Очевидная вещь, которая бросается в глаза сразу, что вы начнете получать обратную связь от пользователей о том, насколько ценно все, что вы делаете, только после нескольких десятков спринтов (в лучшем случае). А что если ответом будет отрицательная обратная связь? Что если все что вы делали - это не то, не работает и никому не надо? Это же месяцы работы и миллионы рублей, потраченные впустую. Нет никакой прозрачности результатов (мы же с вами понимаем, что результат «договор с вендором подписан» или «ТЗ согласовано», «Прошла защита на архитектурном комитете» так себе результат для оценки рабочего функционала?), нечего инспектировать, нет возможности что-то адаптировать (кроме тех же документов, хе-хе)

Заключение

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

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

Made on
Tilda