Эмпиризм на практике: как проводить инспекцию и адаптацию
Узнайте, как эмпиризм работает в реальных Scrum командах. Практические способы применения прозрачности, инспекции и адаптации для принятия более точных решений при разработке ПО.
Большинство провальных проектов в разработке ПО терпят неудачу вовсе не из-за нехватки технических навыков. Они терпят неудачу потому, что работа строится на предположениях, ошибочных с самого первого дня, и никто не проверяет, подтвердились ли эти догадки на самом деле. Scrum опирается на эмпиризм. Эмпиризм утверждает, что знание приходит с опытом, а решения принимаются на основе того, что наблюдается на практике. На деле это означает, что вы перестаете гадать, чего хотят пользователи или сколько времени займет сложная задача, и начинаете оценивать то, что произошло в действительности.
Прозрачность лежит в основе
Инспекция бесполезна без прозрачности. Если на доске задач статус работы застыл на девяноста процентах в течение двух недель, никто не сможет оценить реальное положение дел. Если разработчики скрывают упавшие сборки из страха перед критикой, а лидеры продукта делают вид, что дата релиза неизменна, хотя объем задач удвоился, любые дальнейшие решения будут опираться на вымысел. Прозрачность требует общих стандартов, таких как четкий Definition of Done. Каждый, кто смотрит на работу, должен видеть одну и ту же реальность.
Возьмем качество кода. Если ваш Definition of Done не требует автоматизированных тестов, код, который работает только на локальной машине, может быть помечен как готовый. Когда стейкхолдеры видят этот элемент на Sprint Review, они верят, что прогресс есть. Позже интеграция ломается в продакшене. Этот сбой случился не из-за невезения. Это был провал прозрачности, который скрыл от команды реальные риски.
Инспекция не является микроменеджментом
Scrum включает пять событий, и четыре из них созданы специально для инспекции и адаптации. Инспекция не является аудитом со стороны внешнего руководства. Это критическая оценка, которую проводит сама Scrum Team, сверяясь с понятными целями. Если вы проводите инспекцию без четкой цели, вы просто тонете в деталях.
- Daily Scrum инспектирует движение к Sprint Goal, чтобы вовремя заметить возникающие препятствия.
- Sprint Review инспектирует Increment вместе со стейкхолдерами, чтобы оценить созданную ценность.
- Sprint Retrospective инспектирует людей, отношения, процессы и инструменты для повышения качества.
Обратите внимание на общую закономерность во всех этих событиях. Каждое событие сопоставляет артефакт с поставленной целью. Daily Scrum сопоставляет Sprint Backlog с Sprint Goal. Sprint Review сопоставляет Increment с Product Goal. Без конкретных артефактов инспекция превращается в обмен субъективными мнениями.
Адаптация требует действий
Инспекция без адаптации оказывается пустой тратой ресурсов. Если ваша команда каждые две недели проводит Sprint Retrospective и отмечает нестабильность релизов, но скрипты развертывания так и не меняются, вы теряете время. Адаптация означает внесение изменений сразу, как только инспекция показывает, что процесс или результаты выходят за допустимые границы.
Вот наглядный пример. Допустим, на четвертый день Sprint команда понимает, что у стороннего платежного шлюза нет документации по API. Команда, привыкшая действовать по шаблону, попытается пробить стену лбом и останется на ночные переработки, чтобы завершить исходные элементы Backlog. Эмпирическая команда адаптируется без промедления. Developers совместно с Product Owner корректируют Sprint Backlog, сохраняя Sprint Goal с помощью тестовой заглушки или меняя объем работ, пока драгоценное время не потеряно.
Короткие циклы снижают риски для бизнеса
Причина, по которой Scrum ограничивает продолжительность Sprint одним месяцем или менее, очень проста. Sprint очерчивает границы риска. Максимальная цена ошибочной гипотезы равна стоимости одного Sprint. Если вы работаете двухнедельными Sprint, вы тратите десять рабочих дней на создание Increment, оцениваете результат вместе с реальными стейкхолдерами и корректируете свой план.
Команды часто терпят неудачу в Scrum, потому что воспринимают его как конвейер. Они замораживают требования на полгода вперед, разбивают их на отрезки по две недели и называют это Agile. Это каскадная модель в миниатюре, а не эмпиризм. Настоящий эмпиризм признает, что меньше всего о проблеме известно в самом начале проекта. Больше всего знаний вы получаете тогда, когда создаете работающее ПО, наблюдаете за реакцией пользователей и без колебаний вносите изменения.