» » » История одного факапа или почему итеративность — это необходимое, но не достаточное условие для Agile

 

История одного факапа или почему итеративность — это необходимое, но не достаточное условие для Agile

Автор: admin от 15-07-2015, 17:57, посмотрело: 520

В данной статье идет речь о итерациях, которые включают в себя все этапы разработки ПО, от зарождения идеи до выпуска релиза. Не путать с итерациями, которые используются на этапе реализации в каскадо-водопаде, план таких итераций строится на основании уже хорошо проработанного ТЗ и архитектуры, а в конце каждой итерации нет сбора обратной связи и изменения требований.

Небольшой экскурс: молодая и небольшая компания, успешно применяющая Agile-подходы и Scrum в частности, вела всю разработку ПО одним отделом, разбитым на несколько Scrum-команд. Каждая Scrum-команда разрабатывала свой продукт и всё было хорошо.

Угроза пришла откуда не ждали. Параллельно с разработкой ПО сформировался и развивался отдел аналитики. Первое время аналитики были заняты методологическими документами и на разработку ПО почти не имели никакого влияния. Методологические документы разрабатывались по заказу одной крупной софтверной компании. Разработка с ними велась настолько плотно, что наши аналитики и руководство нашей компании не могли не прознать про то, как у них всё устроено. А было всё устроено по классическому каскадо-водопаду. Софтверная компания была настолько крупной и авторитетной, что руководство нашей компании приняло всё на веру и решило обязательно внедрить их подход к разработке в нашей компании.

Поначалу, возможно, не понимая для чего, а впоследствии объяснив это необходимостью заказной разработки, руководством компании был принят опасный коктейль следующих решений:

  • Вместо роли Product Owner нам нужен Главный аналитик;

  • Командам разработчиков строго запрещено напрямую взаимодействовать с заказчиком. Только аналитики имеют на это право;

  • Команда разработчиков должна получать все задачи от команды аналитиков. Результаты выполнения этих задач должны сдаваться им же;

  • Раз разработчикам так нужен Agile, то пусть используют Agile у себя внутри, мы даже оставим итерации и аналитики будут передавать разработчикам не всё ТЗ целиком, а небольшие порции требований, скорректированные с учетом последней демонстрации тестовой версии программы заказчику;

  • Наш девиз: «Мы решаем сложные задачи!».


Всё это привело к тому, что два проекта, которые можно было сделать за квартал (максимум пол года), делались целый год и так и не дошли до первого релиза на продакшен. Это произошло из-за того, что:

  • От итерации к итерации приходилось менять архитектурные решения, что иногда приводило к очень большим рефакторингам и выбрасываниям в корзину больших кусков кода. Разработчики не видели всю картину в целом, они были оторваны от заказчика, не участвовали в процессе аналитики и не видели ТЗ целиком. Аналитики, не зная реализации, также не могли предвидеть изменения в архитектурных решениях;

  • Часто простые вещи аналитики делали невероятно сложными, отчасти из-за малого опыта в разработке, а отчасти из-за нового девиза компании “Мы решаем сложные задачи!”;

  • Главный аналитик стал мега звездой и требовал особого подхода к своей персоне;

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

  • Были большие проблемы с управляемостью проекта. Никто не хотел брать на себя полную ответственность за проект в целом (в том числе и менеджер проекта).


Наличие итеративности не спасло эти проекты, а только усугубило ситуацию. Как известно итеративная разработка позволяет своевременно менять направление развития продукта. Это достигается за счет выпуска релиза в конце каждой итерации, а также сбора и анализа обратной связи. Смена направления в итеративной разработке достаточно частое явление, поэтому нет смысла писать детальное ТЗ, оно будет устаревать быстрее чем писаться. Отсутствие ТЗ компенсируется единым информационным пространством команды, в котором небольшими порциями накапливаются знания, благодаря совместным усилиям всей команды. Таким образом, итеративность это необходимое, но не достаточное условие для Agile разработки, как минимум ещё должна быть единая команда разработчиков!

Итог


Каскадо-водопад и Agile сами по себе прекрасные методологии разработки ПО. Каждая из них имеет свои плюсы и минусы, по набору которых можно совершить правильный выбор в пользу одной из них для каждого проекта. Если у вас фиксированный бюджет, сроки и требования, то используйте каскадо-водопад. Если у вас нет сроков (продукт развивается непрерывно на протяжении всего жизненного цикла) и нет необходимости в жесткой фиксации требований, то используйте Agile. Но не в коем случае не смешивайте эти два подхода!

Источник: Хабрахабр

Категория: Программирование » Веб-разработка

Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

Добавление комментария

Имя:*
E-Mail:
Комментарий:
Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
Введите два слова, показанных на изображении: *