Водопад или итеративность? (waterfall vs iterative) (обновить)

2013 ИЮЛЬ 19
Решил я в очередной раз повторить теорию и изучить дополнительные материалы по гибким методам разработки. Начнём, как это обычно водится, со сравнения водопадного линейного последовательного и итеративного подходов к разработке.

Водопад:

  1. Начинается с детального подробного планирования и документирования, все задачи определяются максимально чётко, команда принимает участие в оценке сложности и времени. Затем заказчик оценивает документацию и планы, утверждает их. После чего команда начинает создавать продукт проекта. Полностью создаются и тестируются компоненты, затем компоненты интегрируются, тестируется система целиком, а затем передаётся заказчику.
  2. (+) Этот процесс крайне логичен и последователен: сначала хорошенько подумай, запиши, запланируй, следуй плану, не теряй контроль.
  3. (-) Вовлечены люди.
  4. (-) Согласно 1-2 все хорошие идеи, чтобы попасть в план, должны поступить в самом начале. Но так не бывает. При этом подходе хорошая идея в конце проекта — не благо, а угроза.
  5. (?) Основное средство коммуникации важной информации — документация. Зачем? Во-первых, это позволяет массово делиться мыслями. Во-вторых, так люди показывают, что они не просто сидят, а выполняют работу.
  6. (-) Никто не читает большие многостраничные документы (ну, или мало кто).
  7. (-) Если документ текстовый, то он порождает большое количество двусмысленностей и недопонимания.
  8. (-) Не приемлет изменения. Продукт будет хорош настолько, насколько и первоначально задокументированные идеи.
  9. (-) Ситуация «Да, но…» возникающая, когда заказчик в первый раз видит итоговый продукт и придумывает 10 способов, как это можно было сделать по-другому. Например: «Да, это то, что задокументировано, но не то, что нам реально нужно».
  10. (-) Люди плохо предсказывают и планируют будущее. Что вы будете делать и где через 3 месяца?..
  11. (-) Провоцирует соперничество. «Я не буду реализовывать то, что не в ТЗ». «Это уже не моя задача, свою часть я выполнил».
  12. (-) Не очень-то и весело работать с таким подходом. Обычно сотрудники недовольны работой, которая требует от людей исполнительности роботов без свободы для творчества.

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

Comments

comments

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *