В этой статье я расскажу о нескольких анти-паттернах, получившие широкое распространение в организациях, которые замедляют обучение и снижают организационную гибкость.
Для Скрам-команд скорость обучения критически важна, ведь Скрам используется для разработки продуктов в комплексных средах, где «неизвестного больше, чем известного» (Кен Швабер). Чем чаще команда будет получать обратную связь, тем быстрее сможет подстроить продукт под изменяющиеся требования и архитектуру, тем больше шансов на успех.
Более короткие Спринты позволяют пройти большее количество циклов обучения, и ограничить риски стоимости и трудозатрат меньшим отрезком времени (Руководство по Скраму)
Рассмотрим несколько анти-паттернов, препятствующих обучению, а также шаги по их исправлению:
- Отсутствие инкремента: технические и нулевые Спринты.
- Неполная кросс-функциональность: компонентные, инфраструктурные, DevOps и discovery команды.
- Демонстрация "неготового" инкремента.
- Продление Спринта.
- Миграция работы из Спринта в Спринт.
- Команда считает, что улучшаться некуда.
Отсутствие инкремента: технические и нулевые Спринты
Иногда команды завершают Спринт без создания готового к выпуску на рынок инкремента. Частный случай — технические или нулевые Спринты с исключительным фокусом на инфраструктурных/технических задачах. Но оценить ценность любых активностей в Спринте можно лишь поставив минимальную новую функциональность, соответствующую критериям готовности (DoD). Так команда подтверждает, что инфраструктура работает, рефакторинг успешно состоялся, и продукт в готовом состоянии.
Решение: каждый Спринт завершать созданием инкремента, который Done или потенциально готов в выпуску, даже если большую часть времени команда занимается инфраструктурой или архитектурой. Выберите такую длину Спринта, но не более 30 дней, при которой станет возможно создавать готовый инкремент.
Неполная кросс-функциональность: компонентные, инфраструктурные, DevOps, Discovery команды
Неполная кросс-функциональность и компонентные команды порождают водопадный стиль разработки, длинные циклы релизов. Частный случай неполной кросс-функциональности — инфраструктурные и DevOps подразделения, которые работают в отрыве от команд, для которых создается инфраструктура. Команда может несколько Спринтов «пилить» API, и только через несколько недель во время интеграции узнать, что выбранное архитектурное решение не оптимально.
Discovery команды/подразделения создают артефакты, которые «перебрасывают» delivery командам. Они хорошо понимают клиентов, а delivery команды нет. Например, последние могут поздно обнаружить, что предложенные решения не подходят, ведь их трудно или невозможно реализовать технически.
Решение: создавайте максимально кросс-функциональные команды, которые говорят с клиентом на его языке, могут решить его проблему. Кросс-функциональность подразумевает, что Скрам-команда занимается discovery, delivery, инфраструктурой, разработкой, тестированием, архитектурой под ключ. При невозможности комплектации команд с полной кросс-функциональностью формируйте кросс-функциональные продуктовые группы, где несколько команд работают из одного Бэклога Продукта и постоянно обмениваются знаниями и полученной информацией. Избегайте функциональных колодцев.
Демонстрация "неготового" Инкремента
Иногда Скрам-команды из лучших побуждений демонстрируют заинтересованным лицам функциональность, не соответствующую "готовому" к выпуску на рынок инкременту. В одном кейсе, который я наблюдал, команда два месяца создавала ложные ожидания у стейкхолдеров. Когда же Владелец Продукта запросил выход в релиз, то оказалось, что продукт не готов, потому что текущее архитектурное решение не проходит нагрузочное тестирование, которое было отложено на потом. Как итог — разрушенное доверие и ложные ожидания относительно прогресса разработки.
Решение: будьте смелы и инспектируйте только "готовый" к выпуску на рынок инкремент. Это единственное мерило прогресса, благодаря которому мы можем делать адекватные прогнозы со стороны бизнеса.
Продление Спринта
Команды часто не успевают выполнить прогноз и продлевают Спринт, чтобы завершить работу. Спринт похож на лето. Лето заканчивается 31 августа, как бы нам не хотелось его продлить, наступила осень и пора писать сочинение «Как я провел лето». Маловероятно, что команда, продлившая Спринт, проведет работу над ошибками. Скорее всего, в следующем Спринте они повторят прежние ошибки и снова наденут шапки героев. Шанс больше узнать о себе как о команде и улучшить свою работу потерян, эмпирический контроль не работает.
Решение: относитесь к Спринту и его результатам как к временному промежутку. Что успели, то успели. Команда работает так, как она работает. Подобное отношение — основа для дальнейшего обучения и понимания того, на что вы способны.
Работа мигрирует из Спринта в Спринт
Важно, что команда поздно получает обратную связь от различных шагов процесса (тестирование, интеграция) и стейкхолдеров. Скажем, аналитика началась в первом Спринте, финальное тестирование завершено в четвертом. Поздно узнаем, что нужно переделывать. Организационное обучение замедленно. Это водопад, не Скрам.
Решение: во-первых, обратите пристальное внимание на декомпозицию задач и командную кросс-функциональность. Возможно, вы работаете с чрезмерно большими элементами Бэклога Продукта (PBI). Помните, что в разработке программного обеспечения всегда можно добиться дробления задач на представляющие ценность элементы длительностью не более нескольких дней. Развивайте этот навык. Во-вторых, возможно, команда работает в последовательном (водопадном) стиле разработки. Это плохая идея, потому что возвраты на предыдущие шаги процесса (аналитика, кодирование) неминуемы. Команде стоит взять на вооружение распараллеливание, работу в парах, моббинг, сворминг.
Команда считает, что некуда улучшаться
В комплексной среде подобное невозможно. Всегда есть области для улучшения. Люди, которые их не видят, будут стагнировать. Это хорошо понимают те, кто занимался профессиональным спортом. Если ты не стремишься стать лучше, то скоро не сможешь сделать и того, что делал вчера. Неужели компания, в которой работает команда, уже достигла мирового господства и обогнала Google, Tesla и находится в мировом топе по капитализации?
Решение: похоже, что Скрам-мастеру пора применить Скрам-паттерн Pop The Happy Bubble, лопнув пузырь счастья. Сформулируйте недостижимую, как линия горизонта, Perfection Vision и установите промежуточные Improvement Goals. Создайте Бэклог препятствий и планомерно улучшайтесь. А вот выбор скорости изменений уже всецело за командой.
Scrum ON!
