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