Недавно вышла статья "Agile мёртв" (https://www.linkedin.com/pulse/agile-dead-matthew-kern).
Мне хотелось бы рассказать о том, почему, на мой взгляд, это признак взросления agile и отрасли IT в целом.
О том, почему agile могут называть мёртвым, как это может быть связано с ожиданиями и границами применения, а также о недостатках при внедрении и использовании, из-за которых agile-методологии могут быть дискредитированы и нарушать собственные принципы.
О том, чего касаются распространённые методологии, которые относят к agile, чего не описывают, а в чём могут вводить в заблуждение.
О том, в чём они полезны, где может быть их место в различных уровнях работы над проектами, какие отдельные инструменты и практики agile приживаются и приносят пользу, а также каких принципов полезно придерживаться при внедрении и работе с ними.
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’ом и директором – задачи, сроки, ресурсы
• координация между группами
• планёрки по группам
• стендапы – под запись, доделывать, сразу за много не браться
15. Кейс: самодельный waterfall vs Agile без
названия
• несколько проектов в одной продуктовой
программе
• внедрение формального waterfall-like с
артефактами из RUP’а
• 1 PM согласился,
1 отказался
4 комбинировали
16. Только waterfall
+=
• не успевали внедрять новые компоненты
• не перешли на новую кодовую базу
• делали сложные ненужные функции
• в несколько раз превысили сроки
• конфликты в команде
• выпустили, но остались без премий
17. Только Agile
• игнорировали продуктовые требования, «мы лучше знаем, что
нужно пользователям»*
• не смогли сделать общую концепцию для управления
остальными продуктами
• ошибки, так себе документация
• получился набор инструментов для админа-гика
• сделали продукт при другом PM’е :(
* - the more you try and practice Agile…
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. Исключения
• поддержка существующей системы
• внедрение на готовой платформе
когда пользователь действительно не знает, что нужно
• самый первый прототип
25. Подробнее
• ASD: Adaptive Software Development: A Collaborative Approach to
Managing Complex Systems, James A. Highsmith
• продуктовая работа: Inspired: How To Create Products Customers
Love, Marty Cagan
Editor's Notes
проектирование
бизнес- и системные требования от marcom’ов и sale’ов, analyst-only, write-only, в спец. системе, архитектура мало связана с реализацией
планирование
это MS Project, PM->разработчик, вехи растягиваются
выполнение
статусы задач по почте, инструменты кто во что
тестирование
на основе здравого смысла
внедрение
так себе качество
взаимодействие с другими
никакой силой не объединить продукты в одно решение
проектирование
product owner без связи с пользователями, постоянные изменения, в т.ч. концепции, архитектура не прорабатывалась, временные решения
планирование
2 дня раз в 2 нед. + полчаса ежедневно, горизонт 2 нед., story points больше velocity т.к. «нужно больше», непонятно, что значит готовый релиз и когда будет
выполнение
мультименеджмент, много работы насмарку, переработки
тестирование
демонстрация, «eat your own dog’s food» замяли
внедрение
не дошли
взаимодействие с другими
непонятно, что у кого в каком состоянии, чтобы объединять и переиспользовать
аналитик общается с пользователями
решения придумывает вместе с архитектором
архитектор – тимлид и пишет код
с PM’ом и директором – задачи, сроки, ресурсы, внедрение, marcom, sale/presale
новая функциональность, релиз – отдельные обсуждения, оценки
координация аналитиков, разработчиков, тестировщиков, marcom, sales, внедрения
планёрки по группам
стендапы – под запись, доделывать, сразу за много не браться
сроки, ресурсы, каналы сбыта, бюджет
иллюзия, что продуктовой работы достаточно
отрицают необходимость долговременного проектирования и планирования (не все)
эргономика, графический дизайном, тестирование (не все)
работа отдельных участников над отдельными задачами, multitasking, multimanagement, GTD
особенно в условиях больших компаний и доработки существующих продуктов
подходит для проектов до 10 человеко-лет
больше – не пробовал
на уровне всего проекта
неск. недель на первоначальный план и прототип, а дальше 4-6 итераций по 4-6 нед. до готовой версии продукта
на уровне рабочих групп до 10 чел. и 1-2 нед.
Scrum-but со спринтами, стендапами, планёрками
на уровне отдельных задач и сотрудников
IT Kanban с доской по статусам
продуктовая работа с пользователями, правдоподобным прототипом, эргономикой
отдельный, опережающий разработку цикл