Эмпиризм
Определение
Эмпиризм - это философское направление, согласно которому знание или обоснование исходят только или главным образом из чувственного опыта.
Опыт - источник знания, единственный критерий истины и основание всякой науки.
Рационализм - это уже противоположное эмпиризму направление, когда за основу берётся автономность разума от чувств и приоритетом является разум в познании. Порядок и связь идей в разуме соответствует порядку и связи вещей в мире.
Эмпиризм в Agile
Эмпиризм стоит в основе Agile, делая его подходы гибкими и позволяя быстро адаптироваться к изменениям, благодаря чему Agile и получает своё название - “гибкий”.
В Agile значительное место занимает адаптация к изменениям, что предполагает пересмотр первоначальных планов в пользу нового опыта и требований.
Сам по себе план редко когда сбывается и поэтому главное - уметь подстраивать план под новую действительность, когда задачи и приоритеты меняются.
Принципы гибкого подхода:
- Удовлетворение потребностей заказчика через регулярную и раннюю поставку.
- Поддержка изменения требований на любых этапах.
- Ежедневное сотрудничество между разработчиками и заказчиками.
- Внимание к техническому совершенству и качеству.
- Командная оценка эффективности работы и адаптация процессов.
Цикл Деминга-Шухарта
Agile использует итерационные циклы, основанные на эмпирическом цикле Деминга-Шухарта (Plan-Do-Check-Act), улучшая гибкость и эффективность процессов.
Сама по себе итеративная модель основана на цикле ДШ, но включает в каждом этапе те же самые этапы из вотерфола.
Отличие в том, что весь путь разработки разбивается на короткие итерации, после которых уже идут нужные корректировки. Сам такой подход позволяет избавиться от большого количества бюрократии, что делает процесс гибким и эффективным.
PDCA в повседневной работе команды
Каждая церемония Scrum напрямую отображается на один из этапов цикла PDCA. Спринт целиком представляет собой один полный оборот цикла.
| Этап PDCA | Scrum-событие | Что происходит |
|---|---|---|
| Plan | Sprint Planning | Команда выбирает элементы бэклога, формулирует цель спринта и составляет план работ на итерацию |
| Do | Ежедневная работа в спринте | Команда выполняет задачи, проводит Daily Standup для синхронизации и устранения препятствий |
| Check | Sprint Review | Команда демонстрирует инкремент стейкхолдерам, собирает обратную связь и сверяет результат с целью спринта |
| Act | Sprint Retrospective | Команда анализирует процесс работы, выявляет улучшения и формирует конкретные действия для следующего спринта |
Ключевой момент
PDCA - это не разовое действие, а непрерывный цикл. Каждый спринт запускает новую итерацию, и улучшения из ретроспективы сразу попадают в планирование следующего спринта.
На практике PDCA работает и на более мелком уровне. Разработчик, решая задачу, тоже проходит цикл - планирует подход, пишет код, проверяет результат через тесты и code review, вносит корректировки. Несколько таких микроциклов за день в сумме дают быструю обратную связь.
Петли обратной связи
Во все этапы итеративной разработки включены петли обратной связи для своевременного взаимодействия и планирования дальнейших работ командой.
После каждой итерации, в которой мы спланировали и сделали работу, у нас есть определённый результат, который можно откорректировать либо использовать для следующих этапов разработки продукта.
Уровни петель обратной связи
Петли обратной связи существуют на разных уровнях, и чем короче петля - тем быстрее команда узнаёт о проблеме и может адаптироваться.
| Петля обратной связи | Частота | Что даёт |
|---|---|---|
| Парное программирование | Секунды - минуты | Мгновенное выявление ошибок в логике, обмен знаниями в реальном времени |
| Unit-тесты и CI | Минуты - часы | Автоматическая проверка корректности кода, раннее обнаружение регрессий |
| Daily Standup | Ежедневно | Синхронизация команды, выявление блокеров, корректировка плана на день |
| Sprint Review | Раз в 1-2 недели | Валидация инкремента со стейкхолдерами, проверка соответствия ожиданиям |
| Ретроспектива | Раз в 1-2 недели | Улучшение процессов, командная рефлексия, устранение системных проблем |
| Релиз и пользовательский фидбек | Раз в месяц и реже | Проверка продуктовых гипотез, реальные данные от пользователей |
Принцип коротких петель
Чем короче петля обратной связи, тем дешевле исправление ошибки. Баг, пойманный на парном программировании, стоит минуты. Тот же баг, найденный пользователем в продакшене, может стоить дни или недели работы.
Команды, стремящиеся к зрелости, постепенно сокращают длину своих петель. Внедрение CI/CD, автоматизация тестов, более частые демо - всё это инструменты сокращения петель обратной связи.
Столпы эмпиризма в Agile
Эти столпы - это минимальный набор требований, без которых эмпиризм, а в этом случае и Agile, не будут работать.
- Прозрачность - делаем рабочий процесс видимым для всех участников.
- Таблицы, графики, схемы, документация, честное и открытое общение, фиксация договорённостей
- Инспекция - регулярная проверка прогресса и выявление отклонений.
- Ежедневные встречи, планирование, демонстрация, ретроспектива, обзор рисков
- Адаптация - корректировка процессов с целью минимизации отклонений.
- По результатам инспекции будет произведён процесс адаптации с теми же методами из инспекции
Прозрачность на практике
Каждый столп требует конкретных инструментов и практик для реализации.
Прозрачность
Цель - сделать так, чтобы любой участник процесса мог в любой момент понять текущее состояние работы без необходимости кого-то спрашивать.
- Information radiators - физические или цифровые доски (Jira board, Miro, физическая Kanban-доска), которые всегда на виду у команды и отражают актуальное состояние задач
- Definition of Done - согласованный и задокументированный список критериев, при выполнении которых задача считается завершённой. Убирает субъективность из оценки готовности
- Sprint Burndown - график, показывающий объём оставшейся работы в спринте. Позволяет на ранних этапах увидеть, укладывается ли команда в сроки
- Видимый бэклог - приоритизированный и доступный всем список задач. Стейкхолдеры видят, что запланировано, команда понимает приоритеты
Простой тест на прозрачность
Если новый член команды не может за 5 минут понять, над чем сейчас работает команда и какие задачи в приоритете - прозрачность недостаточна.
Инспекция
Регулярная и целенаправленная проверка артефактов и прогресса.
- Code review - проверка кода коллегами перед мержем, выявление дефектов и обмен знаниями
- Демонстрация инкремента - показ работающего продукта стейкхолдерам на Sprint Review для получения обратной связи
- Метрики и дашборды - velocity, cycle time, lead time, количество дефектов. Объективные данные вместо субъективных ощущений
- Bug triage - регулярный разбор найденных дефектов, приоритизация и принятие решений о сроках исправления
Адаптация
Конкретные действия по результатам инспекции.
- Action items из ретроспективы - каждая ретроспектива должна порождать 1-3 конкретных действия, которые команда берёт в следующий спринт
- Процессные эксперименты - команда формулирует гипотезу (“если мы начнём делать X, то улучшится Y”), пробует в течение спринта и оценивает результат
- Корректировка ёмкости - если velocity стабильно отклоняется от плана, команда пересматривает объём работ на спринт вместо попыток “догнать”
Связь столпов
Столпы работают только вместе. Без прозрачности нечего инспектировать. Без инспекции нет данных для адаптации. Без адаптации прозрачность и инспекция становятся бесполезным ритуалом.
Заключение
Эмпиризм в Agile служит фундаментом для создания гибких и эффективных рабочих процессов, позволяя командам быстро адаптироваться к изменяющимся требованиям и реализовывать проекты с оптимальными результатами.
Три практических вывода:
- Сокращайте петли обратной связи - каждая сэкономленная итерация обратной связи снижает стоимость ошибки
- Делайте работу видимой - скрытая работа и скрытые проблемы не могут быть исправлены
- Адаптируйтесь осознанно - каждое изменение процесса должно быть экспериментом с измеримым результатом