Недавно вышла статья "Agile мёртв" (https://www.linkedin.com/pulse/agile-dead-matthew-kern). Мне хотелось бы рассказать о том, почему, на мой взгляд, это признак взросления agile и отрасли IT в целом. О том, почему agile могут называть мёртвым, как это может быть связано с ожиданиями и границами применения, а также о недостатках при внедрении и использовании, из-за которых agile-методологии могут быть дискредитированы и нарушать собственные принципы. О том, чего касаются распространённые методологии, которые относят к agile, чего не описывают, а в чём могут вводить в заблуждение. О том, в чём они полезны, где может быть их место в различных уровнях работы над проектами, какие отдельные инструменты и практики agile приживаются и приносят пользу, а также каких принципов полезно придерживаться при внедрении и работе с ними.

1. Agile мёртв (!|?)
Александр Сидоров, PM, Яндекс

2. Agile is Dead
https://www.linkedin.com/pulse/agile-dead-matthew-kern
Kent Beck, Erik Dietrich, Dave Thomas, Richard Bishop, William Edmonson,
Andrew Hunt, Andrew Binstock, Mike Hadlow, Nathan Dintenfass, Garreth Dottin,
Kristopher Wilson, …

3. the more you try and practice
Agile the less agile you become,
and vice versa
Stuart Eccles

4. original stuff didn't cut it for
enterprise class systems
Scott Ambler

5. it died of oversimplification, and
provides myths
Hayim Makabee

6. Agile should not have been a
management process
Darren

7. • продолжать с Agile?
• вернуться к RUP, MSF, ГОСТ?
• комбинировать?
• в методологии ли дело?

8. Кейсы
• формальный RUP
• абсолютный Scrum-but
• планы, продуктовая работа + Agile без названия
• «самодельный» waterfall vs Agile без названия
• ASD + Agile без названия + IT Kanban
на похожих
продуктах

9. Кейс: формальный RUP
• бизнес-требования без пользователей
• системные без программистов
• архитектура отдельно
• задачи по требованиям
• календарный план – абстрактный
• изменения с пересогласованием
• реализация отдельно
• тестирование по здравому смыслу
• тяжёлое внедрение

10. Результат
• продукт, включаемый на день к приезду проверяющего
• не то, медленно, некачественно
• плохое взаимодействие между людьми, болезненные изменения
• нельзя согласовать изменения для интеграции своих же продуктов

11. Кейс: абсолютный Scrum-but - процесс
• product owner без связи с пользователями и предметной области
• постоянные изменения концепции
• масса работы насмарку
• ритуалы Scrum – четверть времени
• velocity – желаемое за действительное
• лишь бы продемонстрировать
• кроссфункциональность до абсурда
• концептуально разные продукты в программе

12. Результат
• ни один продукт не доделали – у инвестора лопнуло терпение
• что такое готово, когда будет и сколько ресурсов ещё потребует –
непонятно
• очень плохая продуктовая работа
• выгорание, текучка

13. Кейс: планы, продукт, Agile без названия
• каждый релиз – с планами, оценками, архитектурой, но они гибкие
• аналитик общается с пользователями
• решения придумывает вместе с архитектором
• архитектор – тимлид и пишет код
• с PM’ом и директором – задачи, сроки, ресурсы
• координация между группами
• планёрки по группам
• стендапы – под запись, доделывать, сразу за много не браться

14. Результат
• работающая система, сама себя продаёт, приносит прибыль
• работать приятно

15. Кейс: самодельный waterfall vs Agile без
названия
• несколько проектов в одной продуктовой
программе
• внедрение формального waterfall-like с
артефактами из RUP’а
• 1 PM согласился,
1 отказался
4 комбинировали

16. Только waterfall
+=
• не успевали внедрять новые компоненты
• не перешли на новую кодовую базу
• делали сложные ненужные функции
• в несколько раз превысили сроки
• конфликты в команде
• выпустили, но остались без премий

17. Только Agile
• игнорировали продуктовые требования, «мы лучше знаем, что
нужно пользователям»*
• не смогли сделать общую концепцию для управления
остальными продуктами
• ошибки, так себе документация
• получился набор инструментов для админа-гика
• сделали продукт при другом PM’е :(
* - the more you try and practice Agile…

18. Комбинация
• «второстепенные» продукты лучше главных
• в командах всё хорошо

19. Белые пятна Agile-методологий
сроки, ресурсы, каналы сбыта, бюджет
иллюзия достаточной продуктовой работы
отрицание долговременного проектирования и планирования*
эргономика, графический дизайн, тестирование*
multitasking, multimanagement, GTD * - не во всех

20. Когда дело не в Agile
• новый начальник внедряет Scrum по книжке
• никто ничего не знает о пользователях
• хотфикс блокера – в следующий спринт
• кроссфункциональность любой ценой
• тех. долг, или рефакторинг не user story
• вера, фанатизм, ритуалы, культ карго
• штраф за опоздание на стендап
• кое-как для демонстрации
• мнение большинства

21. ASD + Agile без названия + IT Kanban
• ASD на уровне всего проекта
• Scrum-but на уровне рабочих групп до 10 чел. и
1-2 нед.
• IT Kanban на уровне отдельных задач и
сотрудников
• продуктовая работа с пользователями,
правдоподобным прототипом, эргономикой
• руководитель договаривается, обеспечивает,
решает проблемы
ASD
Agile
IT
Kanban

22. Adaptive Software Development-like на уровне всего проекта
4-6 итераций по 4-6 нед. до полезного релиза
фокус на состоянии продукта, не процессе
Agile без названия: группы до 10 чел., итерации 1-2 нед.
спринты, стендапы, планирование, velocity
продуктовая работа – в основном на след. релиз, небольшая часть – на след. спринт
IT Kanban: доска с задачами, правила multitasking’а, multimanagement’а
концепция, ТЗ, архитектура, план
покодировали все части,
оценили, скорректировали
целое с заглушками для сложных
функций на машине разработчика
2 нед.
сложные функции
проработаны
стабильность,
производительность
остальные части продукта

23. Исключения
• поддержка существующей системы
• внедрение на готовой платформе
когда пользователь действительно не знает, что нужно
• самый первый прототип

24. Спасибо!
Комментарии, вопросы?
asidorov83@mail.ru

25. Подробнее
• ASD: Adaptive Software Development: A Collaborative Approach to
Managing Complex Systems, James A. Highsmith
• продуктовая работа: Inspired: How To Create Products Customers
Love, Marty Cagan