(См. также https://zen.yandex.ru/media/id/5dca6a6713aa6c3a6247ec12/o-vrede-agile-5de7c283fbe6e700b04a7103)
В последние годы много говориться о революции в управлении разработкой ИТ Систем на основе Agile методологий. Считается, что причастность той или иной методологии к Agile определяется соответствием основным принципам Agile, изложенным в манифесте (12 пунктов, см. https://ru.wikipedia.org/wiki/Agile_Manifesto).
Изложенные принципы слишком общи и подходят, в принципе, к любым методологиям разработки информационных систем, даже к тем, с которыми часто борются приверженцы Agile.
Вскоре после публикации манифеста Agile начали появляться методологии, претендующие на Agile. К примеру, новая/старая XP (Extreme Programming), Scrum и Kanban «всплыли» из далекого прошлого.
Почему-то, появившееся методологии приверженцами и апологетами начали часто называть проектными. Наверное «проект» – модное и распространенное слово, огромное поле деятельности для различных методологий, которые необходимо «занять».
Термин Agile стал модным, приверженность Agile стало правилом «хорошего» тона. О необходимости использования Agile методик заговорили на «высоком» государственном уровне (правда не ИТ специалисты).
Если исходить из определения проекта – уникальный продукт на выходе, ограниченность по времени, ресурсам ( https://ru.wikipedia.org/wiki/Проект_(в_управленческой_деятельности)).
Появившиеся методологии как правило не говорят ничего определенного об уникальном продукте на выходе, кроме того, что понимание продукта будет формироваться в процессе разработки и периодических демонстраций Заказчику.
По поводу ресурсов – ничего определенного. В процессе разработки будем уточнять.
По поводу временных ресурсов – никаких временных рамок.
Все это означает что методологии по любым определениям понятия «проект» не являются проектными.
Заказчика по проектам (если это не «свои» люди) это касается очень существенно.
Заказчик хочет иметь не отдаленное представление по следующим вопросам:
• Что он получит?
• Когда он это получит?
• Сколько это будет стоить?
При серьезном подходе Заказчик, разумеется, «отметет» подобного рода Agile технологии.
Если Extreme Programming предполагает непрерывную разработку и непрерывное неформальное взаимодействие программистов (2х) с Заказчиком (включая демонстрации, тестирование), то Scrum и Kanban предполагают частые итерации, в которых участвует условный заказчик (Product Owner – может бизнес аналитик, может системный аналитик, может архитектор, может проектировщик, …) и разработчики (как правило программисты). Количество итераций не оценивается, в каком порядке будут имплементироваться требования заказчика (BackLog), как быть с общесистемными требованиями (способность расширению возможностей систем, развитию программной и аппаратной составляющей, сопровождаемость, масштабируемость, устойчивость к сбоям, обеспечение непрерывности бизнеса, …) – остается в «воздухе».
К проектным методологиям можно отнести масштабируемый Scrum-Kanban – методология SAFe ( https://habr.com/ru/post/433934/). Отношусь к этой методологии симпатией, но необходимо учесть следующие особенности:
• Методология не получила широкого распространения;
• Методология ничем не отличается от типовых проектных методологий, относящихся апологетами Agile к не Agile методологиям.

Основа большинства Agile методологий – итеративная разработка (если не считать пример с Extreme Programming с практически непрерывными итерациями).
Обычно Agile лекторы (коучеры – новое «крутое» слово) начинают с того, что все прежние проектные методологии устарели так как основываются на водопадной модели: без итераций и предоставления заказчику промежуточных версий, с последовательными этапами – бизнес анализ, анализ требований, архитектура, дизайн, программирование, тестирование, развертывание, внедрение.
На вопрос – какие методологии Вы имеете в виду – ответа нет. Знания в области технологических процессов ИТ у коучеров (по крайней мере у тех которых встречал) очень неглубокие – в основном только то что преподают.
Даже если сделать краткий обзор предшествующих методологий (например, https://habr.com/ru/post/244003/), то получается, что все они были итеративными, предполагали демонстрацию промежуточных версий систем Заказчику, внесение корректив в дальнейшие планы по проекту. В чистом виде «водопадных» фактически не было. В отличии от типовых Agile, они, как правило, охватывают все процессы (области знаний) связанные с разработкой программно-аппаратных систем, начиная с управления проектами, включая бизнес и системный анализ, архитектуру, дизайн, программирование, тестирование, развертывание, внедрение, управление конфигурацией и изменениями, ….
Примеры методик:
• публикация доктора Уинстона У. Ройса «Managing the development of large software systems» 1970г. (управление разработкой крупных программных приложений) – часто называют основой «водопадной» модели, но в доработанной им же версии методология приобрела черты итерационой.
• Rapid Application Development (1991г) – итерационная методология.
• MSF начало 1993 (Microsoft Solution Framework) - итерационная методология
• Dynamic Systems Development Method (1994) - итерационная методология.
• Oracle CDM/PJM (1990е)
• RUP 2001 (Rational Unified Process, IBM) - итерационная методология.
• PRINCE2 (PRojects IN Controlled Environments – Стандарт управления проектами в Великобритании с 2013г.) - итерационная методология.
• ITIL (библиотека инфраструктуры информационных технологий - 5 томов) – охватывает все аспекты ИТ с ориентацией на сервисный подход к ИТ, в том числе и управлению проектами.
Сбором и обобщением информацией об ИТ проектам занимается PMI (Американский институт по изучению вопросов и проблем управления проектами). Это огромное количество публикаций, связанных с управлением проектами. Наиболее известная – PMBOOK (база знаний по управлению проектами), которая периодически обновляется, SEBoK (база знаний по системной инженерии).
Что дает нам Agile взамен? Это несколько страниц описания процесса SCRUM или Kanban, или XP (c SAFe сложнее).
Но ведь это «здорово». Коучер дает нам понять, что «предки» теперь не нужны. Они накопили огромные знания и опыт как в области управления проектами, так и в других сложных отраслях знаний – бизнес и системный анализ, архитектура, проектирование, программирование, тестирование, развертывание (deployment), …. Догнать их в знаниях и опыте очень трудно и долго. Но есть простое решение – Agile – 3 странички текста, и вы на «вершине». Соблюдайте ежедневные и еже итерационные ритуалы и все будет отлично.
Agile – значит «живая» методология – быстрая и эффективная. Автоматически подразумевается, что все остальные просто не нужны.
Проблема в том, что знания, в области управления проектами, также как и в других областях ИТ отражают объективные аспекты ИТ. Это значит, что эти ИТ аспекты существуют вне зависимости от того знаем мы их или нет. Так же как законы физики (например, закон сохранения энергии, закон Ома, законы термодинамики, …).
Примеры критических аспектов по управлению проектами (PMBOOK, CMM):
• Управление рисками;
• Управление областью охвата;
• Управление временем;
• Управление ресурсами;
• Управление качеством (см. также CMMI);
• Управление коммуникациями;
• Управление закупками.
Все это критически важные аспекты управления проектами, требующие больших специальных знаний.
В Бизнес и системном анализе (BABOOK):
• Коммуникация с Заказчиком;
• Выявление заинтересованных участников;
• Анализ бизнес-потребностей и проблем;
• Выявление бизнес требований;
• Моделирование бизнес-процессов;
• Проектирование системных требований с учетом как функциональных требований, так и нефункциональных требований, архитектурных, нормативных, организационных и других ограничений.
• Обеспечение качества системных требований (непротиворечивость, не содержать реализацию, функциональная полнота, проверяемость, …).
• Управление требованиями (хранение, версионирование, атрибуты требований, поиск, управление целостностью требований, …);
Архитектура (много публикаций и фреймворков, например TOGAF – международный архитектурный стандарт, SEBoK, RUP, …):
• Архитектурные шаблоны;
• Архитектурные фреймворки и технологии;
• Методики проектирования: структурные, объектные, компонентные, аспектные;
• Методики максимизации повторного использования компонент;
• Моделирование архитектурных представлений;
• Архитектурный репозиторий (база данных и управление модельными объектами);
• Организация процессов разработки «от архитектуры» (architecture driven development).
• Проектирование реализации функциональных и нефункциональных требований – решения по разработке гибких, легко модифицируемых систем, масштабируемых систем (по пользователям и нагрузке), устойчивых к сбоям, обеспечивающих гарантированную непрерывность работы, ….
Много по тестированию:
• Проектирование тестовых кейсов;
• Организация регрессионного тестирования;
• Организация многоуровневого процесса тестирования в релизах: модульное-функциональное, интеграционное, системное.
Много по развертыванию:
• миграция данных,
• организация развертывания систем
• Установка версий и патчей;
• Проведение тестов;
• Обработка запросов от Заказчика (дефекты, запросы на изменения)
• Обучение
• И многое другое
Конфигурация и изменения:
• Управление изменениями;
• Хранение версий и релизов системы;
• …

Коучеры Agile обычно игнорируют эти аспекты. Мое впечатление – они просто ничего этого не знают.
Ничего против предлагаемых Agile методик, в принципе, не вижу. Они просто предлагают решение очень узкого круга задач в рамках типового проектов – организация микро-релизов группами программистов (это максимум 10% всех аспектов разработки систем, скорее существенно меньше). Это типично в следующих случаях:
• Сопровождение уже существующих систем – периодическое устранение дефектов и мелкие доработки;
• Организация работ групп программистов на различных стадиях проекта по реализации подготовленных на итерации требований и архитектурных решений.
Другой аспект Agile методик – это ритуалы. Типичные ритуалы – доски со стикерами, ежедневные собрания, собрания по результатам итераций.
Не думаю, что это «гениальные» изобретения. Все комплексные методики предполагают организацию процессов в итерациях. Обычно они дают множество рекомендаций на основе большого опыта проектной деятельности. На основе этого опыта подбираются оптимальные методики проведения итераций с учетом свойств проектов (включая масштаб, критичность, …) внутренней культуры организации, развитостью ИТ (см CMMI). В RUP, например, для этого есть роль Process Engineer.
Теперь – мой личный опыт.
Существенные проекты, которые реализовывались по Agile методологиям в крупных, значимых организациях – это провал!
Основные проблемы:
• Быстрое программирование без мало-мальски уточненных, качественных с точки зрения системного и бизнес анализа (как области знаний) приводит к большому объему изменений, как следствие общая продолжительность разработки не сокращается, а увеличивается. Тут важно понимать существенный факт – стоимость разработки требований и архитектуры существенно ниже стоимости разработки. Ошибка в требованиях приводит к существенному увеличению стоимости разработки – это закономерность, аналогичная законам физики. Отсутствие серьезного, методичного отношения к бизнес и системному анализу, архитектуре приводит к удлинению по времени, повышению стоимости разработки, существенному увеличению проектных рисков.
• Архитектура в принципе плохо развиваема, не гибка (для большинства изменений необходимы «заплатки»), мало или нет повторно используемых компонент (существенно удорожает разработку), плохо масштабируется, плохо с устойчивостью, непрерывностью бизнес-процессов, плохо с информационной безопасностью. Насмотрелся архитектурных «ужасов» в системах большой государственной важности.
• Архитектура систем понятна только разработчикам, причем разным разработчикам по разным аспектам. Низкая взаимозаменяемость. Со временем (причем очень скоро) разработчики сами перестают контролировать архитектуру. Отсюда большие затраты на сопровождение, модификацию, развитие, большие риски сбоев после внесения изменений.
В дополнение – мой опыт работы в Германии в компании Telesens AG (Кельн 1999-2000г). Сначала работал программистом в группе (C++ Sun Solaris, Oracle) в проекте по разработке биллинговой системы для Deutche Telecom. Потом назначили руководителем группы программистов. Были распространены 2-а типа команд:
• В команде – все программисты, включая руководителя;
• В команде – 1-2 проектировщика программных компонент (использовали UML Rational Rose).
Как результат в командах с проектировщиками – скорость разработки выше, выше качество (меньше дефектов, гибкость, повторная используемость кода, …), лучше сопровождаемость (есть документация, есть знание программиста и проектировщика).
Иногда удивлялись – почему скорость разработки выше, ведь «чистых» программистов меньше?
Трудно ответить, наверное это объективный закон, я думаю мы все его знаем – закон Адама Смита – разделение труда (мануфактура в которой работали 10 человек и производили булавки, причем каждый делал булавки целиком, в другой команде работу разбили на 10 отдельных операций, которые выполняло такое же количество людей (каждый только свою операцию), как результат производительность повысилась в разы).
Разделение труда, как горизонтальное (разработчики разбиваются по подсистемам), так и вертикальное (специализация – управление проектами, бизнес и системные аналитики, архитекторы, проектировщики, тестировщики, специалисты по развертыванию) обязательно должно привести к росту эффективности ИТ. Важно учесть, что каждая из специализаций требует больших знаний и профессионализма. Полагаться, на то, что «его величество» программист решит все проблемы, на мой взгляд, наивно. Кстати к программистам отношусь очень уважительно. Непрерывно работал программистом более 10 лет (на большинстве распространённых языках программирования, на многих технологических средах), считаю себя таковым и сейчас (как и десантников – программистов «бывших» не бывает).
Выводы: выводов Нет. Остается вопрос - Agile – Зачем?