В данной статье идет речь об итерации, которая включает в себя все этапы разработки ПО, от зарождения идеи до выпуска релиза. Не путать с итерациями, которые используются на этапе реализации в каскадо-водопаде, план таких итераций строится на основании уже хорошо проработанного ТЗ и архитектуры, а в конце каждой итерации нет сбора обратной связи и изменения требований.
Небольшой экскурс: молодая и небольшая компания, успешно применяющая Agile-подходы и Scrum в частности, вела всю разработку ПО одним отделом, разбитым на несколько Scrum-команд. Каждая Scrum-команда разрабатывала свой продукт и всё было хорошо.
Угроза пришла откуда не ждали. Параллельно с разработкой ПО сформировался и развивался отдел аналитики. Первое время аналитики были заняты методологическими документами и на разработку ПО почти не имели никакого влияния. Методологические документы разрабатывались по заказу одной крупной софтверной компании. Разработка с ними велась настолько плотно, что наши аналитики и руководство нашей компании не могли не прознать про то, как у них всё устроено. А было всё устроено по классическому каскадо-водопаду. Софтверная компания была настолько крупной и авторитетной, что руководство нашей компании приняло всё на веру и решило обязательно внедрить их подход к разработке.
Поначалу, возможно, не понимая для чего, а впоследствии объяснив это необходимостью заказной разработки, руководством компании был принят опасный коктейль следующих решений:
Всё это привело к тому, что два проекта, которые можно было сделать за квартал, делались почти год и так и не дошли до первого релиза на продакшен. Это произошло из-за того, что:
Наличие итеративности не спасло эти проекты, а только усугубило ситуацию. Как известно итерационная разработка позволяет своевременно менять направление развития продукта. Это достигается за счет выпуска релиза в конце каждой итерации, а также сбора и анализа обратной связи. Смена направления в итерационной разработке достаточно частое явление, поэтому нет смысла писать детальное ТЗ, оно будет устаревать быстрее чем писаться. Отсутствие ТЗ компенсируется единым информационным пространством команды, в котором небольшими порциями накапливаются знания, благодаря совместным усилиям всей команды. Таким образом, итеративность это необходимое, но не достаточное условие для Agile разработки, как минимум ещё должна быть единая команда разработчиков (системные аналитики, дизайнеры, архитекторы, программисты, тестировщики)!
Каскадо-водопад и Agile сами по себе прекрасные методологии разработки ПО. Каждая из них имеет свои плюсы и минусы, по набору которых можно совершить правильный выбор в пользу одной из них для каждого проекта. Если у вас фиксированный бюджет, сроки и требования, то используйте каскадо-водопад. Если у вас нет сроков (продукт развивается непрерывно на протяжении всего жизненного цикла) и нет необходимости в жесткой фиксации требований, то используйте Agile. Но не в коем случае не смешивайте эти два подхода!
Небольшой экскурс: молодая и небольшая компания, успешно применяющая Agile-подходы и Scrum в частности, вела всю разработку ПО одним отделом, разбитым на несколько Scrum-команд. Каждая Scrum-команда разрабатывала свой продукт и всё было хорошо.
Угроза пришла откуда не ждали. Параллельно с разработкой ПО сформировался и развивался отдел аналитики. Первое время аналитики были заняты методологическими документами и на разработку ПО почти не имели никакого влияния. Методологические документы разрабатывались по заказу одной крупной софтверной компании. Разработка с ними велась настолько плотно, что наши аналитики и руководство нашей компании не могли не прознать про то, как у них всё устроено. А было всё устроено по классическому каскадо-водопаду. Софтверная компания была настолько крупной и авторитетной, что руководство нашей компании приняло всё на веру и решило обязательно внедрить их подход к разработке.
Поначалу, возможно, не понимая для чего, а впоследствии объяснив это необходимостью заказной разработки, руководством компании был принят опасный коктейль следующих решений:
- Вместо роли Product Owner нам нужен Главный аналитик;
- Командам разработчиков строго запрещено напрямую взаимодействовать с заказчиком. Только аналитики имеют на это право;
- Команда разработчиков должна получать все задачи от команды аналитиков. Результаты выполнения этих задач должны сдаваться им же;
- Раз разработчикам так нужен Agile, то пусть используют Agile у себя внутри, мы даже оставим итерации и аналитики будут передавать разработчикам не всё ТЗ целиком, а небольшие порции требований, скорректированные с учетом последней демонстрации тестовой версии программы заказчику;
- Проектированием бизнес-процессов, модели предметной области и пользовательского интерфейса занимаются аналитики. Они делают это итерациями. При передаче каждой порции требований разработчикам, также передается соответствующая им документация.
Всё это привело к тому, что два проекта, которые можно было сделать за квартал, делались почти год и так и не дошли до первого релиза на продакшен. Это произошло из-за того, что:
- От итерации к итерации приходилось менять архитектурные решения, что иногда приводило к очень большим рефакторингам и выбрасываниям в корзину больших кусков кода. Разработчики не видели всю картину в целом, они были оторваны от заказчика, не участвовали в процессе аналитики и не видели ТЗ целиком. Аналитики, не зная реализации, также не могли предвидеть изменения в архитектурных решениях;
- Часто простые вещи аналитики делали невероятно сложными, отчасти из-за малого опыта в разработке, а отчасти из-за нового девиза компании “Мы решаем сложные задачи!”;
- Главный аналитик стал мега звездой и требовал особого подхода к своей персоне;
- Разработчики и как не странно аналитики были демотивированы. Часто вспыхивали конфликты. Например, аналитики начали жаловаться на то, что разработчики задают много вопросов и это сильно отвлекает их от текущих задач. После того как главный аналитик пожаловался начальству, было принято решение, что программисты могут задавать вопросы только в процессе передачи задачи, после того как задача принята, вопросы задавать нельзя!
- Были большие проблемы с управляемостью проекта. Никто не хотел брать на себя полную ответственность за проект в целом (в том числе и менеджер проекта).
Итог
Наличие итеративности не спасло эти проекты, а только усугубило ситуацию. Как известно итерационная разработка позволяет своевременно менять направление развития продукта. Это достигается за счет выпуска релиза в конце каждой итерации, а также сбора и анализа обратной связи. Смена направления в итерационной разработке достаточно частое явление, поэтому нет смысла писать детальное ТЗ, оно будет устаревать быстрее чем писаться. Отсутствие ТЗ компенсируется единым информационным пространством команды, в котором небольшими порциями накапливаются знания, благодаря совместным усилиям всей команды. Таким образом, итеративность это необходимое, но не достаточное условие для Agile разработки, как минимум ещё должна быть единая команда разработчиков (системные аналитики, дизайнеры, архитекторы, программисты, тестировщики)!
Каскадо-водопад и Agile сами по себе прекрасные методологии разработки ПО. Каждая из них имеет свои плюсы и минусы, по набору которых можно совершить правильный выбор в пользу одной из них для каждого проекта. Если у вас фиксированный бюджет, сроки и требования, то используйте каскадо-водопад. Если у вас нет сроков (продукт развивается непрерывно на протяжении всего жизненного цикла) и нет необходимости в жесткой фиксации требований, то используйте Agile. Но не в коем случае не смешивайте эти два подхода!
