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