Что, если перевернуть аджайл манифест и 12 принципов гибкой разработки ПО?

В некоторых местах не смешно :-)

Анти-аджайл манифест

В процессах разработки ПО для лучшего контроля над программистами руководство считает важным:

Процессы и инструменты важнее людей и их взаимодействия

Исчерпывающая документация важнее работающего продукта

Согласование условий контракта важнее сотрудничества с заказчиком

Следование плану важнее готовности к изменениям

Хотя и можно (под давлением) признать что то, что справа имеет какую-то ценность, мы на самом деле считаем важным только то, что слева.

12 принципов анти-гибкой разработки программного обеспечения

1. Самым главным, наивысшим приоритетом для нас является выполнение всех работ указанных в договоре, в срок, и в рамках бюджета.

2. Изменения требований не приветствуются и предотвращаются настолько, насколько это возможно, для соблюдения изначального плана. Соблюдение ограничений «железного треугольника» важнее, чем развитие конкурентного преимущества продукта.

3. Работающий продукт следует выпускать пореже, с периодичностью
   от пары месяцев до пары лет, более длительные сроки предпочтительны.

4. Разработчикам и представителям бизнеса следует избегать прямого общения. Коммуникацию следует строить через формальную спецификацию и спускаемые требования.

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

6. Лучший способ передачи информации для контроля реализации софтверных проектов — очень подробная документация и непрерывная отчетность о состоянии на всех организационных уровнях.

7. Основным показателем прогресса является процент выполнения задач.

8. Высокий уровень производительности лучше всего достигается за счет установки кратчайших сроков и высочайших приоритетов на всё подряд. Хвалите и вознаграждайте отдельных героев, порицайте и обвиняйте в слабости прочих, исправлять организационные проблемы — не требуется. Темпы разработки программного обеспечения должны определяться требованиями бизнеса, а не способностью разработчиков, спонсоров и пользователей поддерживать этот ритм.

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

10. Простота — искусство минимизации лишней работы — идёт от лени, и противоречит принципу максимизации загруженности сотрудников.

11. Самые лучшие требования, архитектурные и технические решения придумываются старшими инженерами, архитекторами, представителями бизнеса, заранее и издалека предписывающими инженерный подход к проекту.

12. Команды лучше всего работают, следуя строго описанным процессам и процедурам, четким инструкциям, спущенным сверху. Самовольная же корректировка процессов на основе продемонстрированных результатов приводит к потере контроля со стороны руководства.

Ссылки
Перевел с: https://agilecheetah.com/the-anti-agile-manifesto/

Часто поднимаемая тема в 35+

— Я работала по 90 часов в неделю, разрушила свое ментальное здоровье и семью
— Должно быть, теперь ты богата?
— Нет. Но мы успели выпустить важный продукт.
// Reddit

Факторов приводящих к выгоранию целый список.
Рецептов выхода из выгорания написано сто штук, все они по сути одинаковые (несколько полезных ссылок в конце поста).

Важно знать как происходит выход из выгорания.

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

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

Полезно знать так же:

1. Как во время болезни человеку сложно вспомнить, как было хорошо когда он был здоров, так и в состоянии выгорания человеку бывает сложно вспомнить что работа ему нравилась.

2. Выгораете вы скорее всего не один.
   Скорее всего вокруг вас есть сильно задолбавшиеся сотрудники и/или выжатый как лимон шеф, которому тоже не сладко. В какой-то момент может происходить контр-продуктивное взаимодействие, его нужно уметь фильтровать.

3. Задолбавшиеся люди производят посредственные результаты.
   Невозможно пробежать марафон в формате спринта, как и невозможно бежать со сломанными ногами.
   Иногда нужно откладывать дела и переключаться.

Рекомендую две статьи и два видео
https://vc.ru/hr/207775-professionalnoe-vygoranie-chto-delat-i-kak-poborot-sindrom-menedzhera
https://f-ps.ru/stati-psikhologov/tpost/p88r58rmsd-ot-entuziazma-do-depressii-4-stadii-emot
Орлов: https://www.youtube.com/watch?v=45hEPff4loE
Стрелецкая: https://www.youtube.com/watch?v=IHZEqujLtFU

Weighted Shortest Job First. Сначала наивесомейшая кратчайшая работа.

Принцип используется в SAFe 4 как метод приоретизации работы. Смысл в том, чтобы наиболее ценные и быстровыполнимые задачи брать с более высоким приоритетом. Для того, чтобы быстрее наносить максимум пользы конечным пользователям в потоке поставке ценности.

Что глядя на это можно сказать?

• Чем скорее можем поставить большую ценность, тем лучше.
• Чем меньше потратим Cost of Delay, тем лучше.
• Чем менее значима бизнес составляющая, и высока сложность, тем меньше шансов, что до её реализации вообще дойдет :)

Звучит очевидно, да? Но на практике не всегда легко ранжировать.

---

Формула выглядит так:

WSJF = Cost of Delay / Duration

SAFe предлагает Cost of Delay считать как:

Cost of Delay = User-Business Value + Time Criticality + (Risk Reduction or Opportunity Enablement)

• User-Business Value: Насколько громко просят об это пользователи? Как это отразится в деньгах, если эта штука НЕ будет сделана? Какой потенциально негативный эффект будет, если это выполнить позже, а не раньше?

• Time Criticality: Как это влияет на общий поток поставки? Задерживает ли реализацию чего-то еще? Нужно ли это выпустить к определенной дате? Есть ли риск того, что опоздание с этим умножит на ноль весь смысл проделанной работы?

• Risk Reduction: Снижает ли это какие-то риски? Будет ли это позитивно влиять на качество в других областях? Будет ли эффект сиюминутным или долгосрочным?

• Opportunity Enablement: Откроет ли эта штука новые возможности для продукта или всего бизнеса? Поможет ли выйти на новые рынки сбыта/привлечь других клиентов?

Оценки проставляются от 1 до 21 согласно ряду Фиббоначи (1, 3, 5, 8, 13, 21... ), суммируются и делятся на размер работы. Размер работы тоже оценивается числами Фиббоначи, в общем оценкой в скрамовских сторипоинтах.

К примеру, следующий набор Фич для интернет-магазина:

1. Приветственное письмо покупателю, сразу после того, как он получил на руки заказ от курьера
2. Автоматический дозвон до клиента и соединение с оператором коллцентра после того, как клиент оставил заказ в интернет магазине
3. Автоматичесая печать наклеек на пакеты для транспортной компании

Проведем оценку, чтобы было понятно почему такие значения, распишем Business Value и перечень технических задач на реализацию каждой Фичи:

Есть строгие правила проставления оценок:

1. Заполнять по одной колонке за раз, начиная с самой простой Фичи, проставив ей оценку 1, остальные оценивать относительно первой единице
2. Следствие: должна быть минимум одна единица в каждой колонке!
3. Самое большое число по WSJF означает наиболее высокий приоритет
   По мне, очень полезные правила, придерживаться которых следует, чтобы снизить коэффициент «ленинского прищура».

Расставляем веса и смотрим что получилось:

Иногда результаты могут получиться контр-интуитивными. Как видно из формулы, на приоритет Feature можно повлиять с двух сторон: оценка бизнес-важности, так и оценка со стороны сложности реализации. При низкой экспертизе оценщиков или плохой коммуникации между заказчиком и исполнителем, могут быть ошибки, приводящие к тому, что все делается не в оптимальной последовательности.

Самое ценное в этом принципе то, что его использование предполагает диалог между бизнесом и инженерами.

Кстати, если бы среди моих инженеров был тот, кто уже работал как с API CRM так и с API транспортной компании, оценка от технической команды могла быть для Фичи про печать наклеек гораздо меньшей.

А вот мой двухгодичной давности пост о приориетизации http://ashigabutdinov.ru/2016/02/07/1/

Вперед, к причинению пользы! ;-)

Еще по теме:

1. http://www.summa.com/blog/what-is-wsjf-how-to-use-this-agile-concept-to-prioritize-work
2. https://techbeacon.com/prioritize-your-backlog-weighted-shortest-job-first-wsjf-improved-roi
3. https://www.scaledagileframework.com/wsjf/

В августе 2016 года на одном из проектов установили ограничение Work In Progress равное количеству девелоперов работающим над проектом. Т. е. если кто-то заболевал или уходил в отпуск, ограничение Work In Progress уменьшалось на единицу. При добавлении разработчиков, увеличивалось на единицу.

На скриншоте Control Chart в Jira и эффект от внедрения данной практики:

Rolling avarage дней между «взято в разработку» и «готово к релизу» (конкретно на этом проекте даже выкачено на продакшен) снизилось с 7.4 дней до 2.7 дней.

То есть бизнес стал получать свою функциональность в два раза быстрее.

Недавно проводил мастер-класс новой проектной команде по Канбану и WIP:

Смысл в том, что бы браться за новые задачи только после того, как уже взятые в работу полностью готовы.

Частая картина в девелоперских командах:

1. Программист взял Задачу 1 в разработку
2. Отправил Задачу 1 на тестирование
3. Тестер приступил к тестированию через 5 часов
4. Программист пока взял Задачу 2
5. Задача 1 вернулась с багом
6. Программист решает закончить Задачу 2
7. Через 3 часа программист отправляет Задачу 2 на тестирование
8. Программист возвращается к доработке Задачи 1
9. Через час исправляет баг и отправляет Задачу 1 на тестирование
10. Через 2 часа Тестировщик приступает к тестированию Задачи 1
11. Задача 1 отправляется в релиз

Итого время простоя задачи
на пункте 3: 5 часов
на пункте 7: 3 часа
на пункте 10: 2 часа

Проблемы бесконтрольного набора задач:

1. Задача долго отлеживается, перед тем как её возьмут на тестирование, потому что тестировщики заняты тестированием других задач
2. Задача долго отлеживается после возвращения на доработку, потому что программист пока ждет результатов тестирования, взял себе на разработку уже другую задачу, и пока ее не закончит, к доработкам вернувшегося тикета не приступит.

Как итог: куча полуфабрикатов, недоделок, незавершенных задач — одним словом, связанный капитал: время и деньги на разработку потрачены, а результата нет.

Так вот, в моих командах, процесс устроен следующим образом:

Ограничение WIP = кол-во девелоперов на проекте

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

Как только задача готова, тестировщик принимается за ее тестирование.

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

Как только задача возвращается на доработку — берет ее в ту же минуту и быстро исправляет недочеты. Это легко, т. к. программист находится в контексте задачи и прекрасно помнит что именно где править

Как только задача завершена, тестировщик в ту же минуту проводит повторное тестирование, и если все ОК, отправляет в релиз.

Как результат:

1. минимальное время на реализацию задач
2. минимальное количество задач погрязших в болоте доработок
3. у программистов и тестировщиков есть время на саморазвитие
4. бизнес подразделение довольно: новая функциональность начинает приносить деньги сразу же, а не «через 2 недели, когда будет релиз»

+ Полезное из переписки на facebook:

Ицхак Адизес — эксперт в сфере повышения эффективности ведения бизнеса в своей книге «Идеальный руководитель. Почему им нельзя стать и что из этого следует» написал, что для эффективного управления компанией необходимо, чтобы в ней было 4 типа руководителей:

• P. Производитель — нацеленный на краткосрочные результаты
• A. Администратор — нацеленный на процессы и эффективность
• E. Энтерпренер (предприниматель) — нацеленный на долгосрочные результаты и видение перспектив
• I. Интегратор — нацеленный на эффективное взаимодействие людей в компании и блгоприятную психологическую атмосферу

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

Более подробно:
Типы руководителей
Стили управления PAEI
Тест на тип личности по Адизесу
Funky и Sexy менеджеры

Каждые 3-4 недели рекомендуется проводить встречи 1 на 1 с сотрудниками для того, чтобы снять их текущее состояние, выявить проблемы, обсудить какие-то накопившиеся вопросы.

Встречи проводятся для того, чтобы говорил сотрудник, а не менеджер. Обычно провожу диалог со следующим набором вопросов:

1. Интересны ли задачи которые ставятся? Не слишком сложные? Не слишком простые?
2. Есть ли какие-то проблемы, которые ты видишь, которые нужно решить?
3. Есть ли у тебя какие-то идеи как можно улучшить в проекте или команде? Может в компании в целом?
4. В какой области есть желание развиваться?
5. Время от времени люди смотрят вакансии в других компаниях, все ли тебя устраивает?
6. Как тебе взаимодействие с ребятами? Все норм, конфликтов нет? (Поименно) А с Васей? А с Петей? А с Машей?
7. Если есть проблемы: Есть ли у тебя идея, как следует эту проблему решить? Можешь предложить способ решения, который бы всех удовлетворил?
8. Накопились ли какие-то вопросы на которые могу ответить?

Смотреть в глаза, записывать что говорит собеседник.
Основная цель: снять состояние человека, понять что человеку нравится или не нравится, помочь решить какие-то проблемы.

На таких встречах иногда возникают какие-то идеи или принимаются решения что-то сделать, в этом случае

• каждый вопрос нужно доводить до состояния КТО / ЧТО / КОГДА будет делать
• все договоренности записываются
• все договоренности выполняются после встречи 1 на 1
• на следующей встрече подводятся итоги того что было сделано по результатам прошедшей встречи

Для меня эти встречи — инструмент для выявления в каком состоянии находится сотрудник:

Матрица показывает как человек обучается какому-либо навыку и что происходит с его интересом к работе. Например, вы взяли на работу нового сотрудника. Он еще не знаком с особенностями вашего процесса разработки или ведения проектов, может не знать чего-то в вашем бизнес-домене (то есть компетенция у него, относительно вашей сферы деятельности, пока низкая), но при этом ему интересно и «глаза горят» (вы его, скорее всего по этому признаку и отбирали — будущая работа кандидату должна быть интересна: квадрант высокого интереса). Когда человеку интересно то, что он делает, он начинает учится. Его компетенция растет, он остается в правой части матрицы, но сдвигается по ней вверх. Высокий интерес и высокая компетентность.

Отличное состояние. Устойчивое, интересное.

Потом человек делает то, что умеет год или два. Опыт накоплен. Задачи решаются. Но интерес постепенно спадает. Сдвигаемся влево. Человек знает и умеет, возможно, больше всех в команде или компании. От работы немного «укачивает», но авторитет, должность, деньги и зона комфорта могут удерживать человека достаточно прочно.

Последний пустой квадратик «как бы намекает» :) Нет, человек не глупеет, но перестает развиваться, потому что крайне сложно заставить себя учить что-то новое, когда тебе совсем не интересно то, что ты делаешь.

Александр Орлов про формулу работы с людьми

MindMap по Формуле работы с людьми (xmind) — как раз из видео
http://stratoplan.ru/pmf/stratoplan_pmformula.xmind

Что делать если не придумали ничего умнее чем почикать файлы из pg_xlog/

http://dba.stackexchange.com/questions/80317/how-can-i-solve-postgresql-problem-after-deleting-wal-files

Как спать спокойно (про бекапы)

https://simply.name/ru/video-pg-meetup-yandex2015.html

Курс по постгресу, 17 урок про механику физического резервирования в Postgres

https://www.youtube.com/playlist?list=PLaFqU3KCWw6KzGwUubZm-9-vKsi6vh5qC

В общем-то я и прежние годы был под впечатлением и действовал по принципам книги «Цель. Процесс непрерывного совершенствования», которую давно всем рекомендую, но реальный практический тренинг все расставил по полочкам.

Чем собственно отличается процесс SCRUM от KANBAN.

Чем меряют сложность задач в Scrum и Kanban

Три графика, которые помогут измерить эффективность всего процесса (от начала до результата)

Стоимость задержки поставки. Авария, обычная необходимость, жесткий срок, технический долг

Звездная карта. Картотека компетенций команды и точек интереса сотрудников. Полезная вещь, сразу же завел такую у себя.

Бонусом раскрыли тему о том чем коллектив отличается от команды

А это просто доска с результатами игры. Сначала мы шли медленнее остальных, но за счет того, что автоматизировали многие вещи, ограничили WIP и очередь выиграли.

Что еще интересно, и игру закончили мы Э-э-э раньше двух других команд. Но это, по словам тренеров, не релевантно :)

Могу теперь всем говорить, что у нас не чик-чик и в продакшен, а KANBAN. Даже справка есть.

Скопипащу сюда свой собственный мануал для новеньких разработчиков.

Установка git

$ sudo su
$ apt-get install git-core git-gui git-doc

SSH ключи

Шаг 1. Проверяем есть ли у вас уже ключи.

cd ~/.ssh
Если отвечает “No such file or directory“ идем на шаг 3. Иначе идем на шаг 2.

Шаг 2. Бекапим имеющиеся

mkdir key_backup
cp id_rsa* key_backup
rm id_rsa*

Шаг 3. Создаем новый ключ

ssh-keygen -t rsa -C «[email protected]»
[enter]

Шаг 4. Нужно добавить ваш ключ на репозиторий, например gitorius, gitlab, bitbucket

cat id_rsa.pub
ctrl+c ctrl+v в браузер.

Шаг 5. Добавляем персональную информацию

git config —global user.name «Firstname Lastname»
git config —global user.email «[email protected]»

Использование

git init — создать в этой папке git репозиторий
git status — получить информацию на какой ветке мы сейчас находимся, список внесенных изменений
git checkout development — переключиться на основную девелоперскую ветку.
git pull origin development — скачать с серевра самую свежую версию ветки development и залить ее в текущую ветку.
git checkout -b new_branch_name — создать новую ветку из текущей (на которой вы сейчас находитесь).
git reset —hard — отменяет все изменения сделанные до коммита
git commit -a — сохраняет на вашем локальном компе в ветке все изменения, которые вы внесли
git push origin branch_name — закачивает на сервер вашу модифицированную ветку

Для работы в общем-то и этого набора команд достаточно :)

Ништяки

Вывод названия текущей ветки в строку приглашения bash.
Выглядит примерно так: /var/www/site (master) $
Создать в домашней директории файл .gitbranch.sh с правами на исполнение для владельца:

#!/bin/bash
 
GIT_BR=`git symbolic-ref HEAD 2> /dev/null | cut -b 12-`
 
if [ "$GIT_BR" = "" ]; then
    echo -n
else
    echo -n "($GIT_BR)"
fi
</pre>
в файле .bashrc, находящейся в домашней директории найти строку
<pre class="brush:shell">if [ "$color_prompt" = yes ]; then
PS1='...

и заменить ее на

if [ "$color_prompt" = yes ]; then
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\e[1;31m\]:\[\e[01;34m\]\w\[\e[00m\]`~/.gitbranch.sh`\[\e[00m\]\$ '
else
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w`~/.gitbranch.sh`\$ '
fi

так же 10 строками выше можно раскоментировать force_color_prompt=yes

GUI

Многие разработчики в нашей команде используют либо командную строку, либо gtk-шный Git Gui. Я же рекомендую SmartGit, пожалуй это лучший клиент из всех что я видел. Еще весьма неплохо работает с гитом клиент, встроенный в PHP Storm.

Из очень удобных клиентов под Linux я бы еще назвал Gitg. Он особенно полезен для просмотра дерева веток и истории слияний веток между собой. Устанавливается он с полпинка по apt-get install gitg.

Вот забавно, хотел сейчас причитать о том, как жаль, что под Mac нет такого классного инструмента, как оказалось, что Gitg это клон GitX, содранного с маков :)

Под Windows я использую тот же самый SmartGit и консоль (mingw), которая поставилась самим инсталлятором. Скачать git для windows можно на http://git-scm.com/

Ссылки по теме:
Прекрасная книга Pro Git
Магия Git — другая прекрасная книга про гит

Наверное в каждой dev-команде применяющей Agile найдутся люди недовольные постоянными изменениями.

Я хотел бы дать свои комментарии по Agile манифесту.

Люди и взаимодействие важнее процессов и инструментов.
Как известно из законов физики, свободная энергия изолированной системы стремится к минимуму. Для команды это значит, что в отсутсвие жестких регламентов, команда скорее всего самостоятельно выработает оптимальную модель взаимодействия друг с другом и будет тратить меньше времени на то, чтобы следовать инструкциям.

Работающий продукт важнее исчерпывающей документации
Большую инструкцию или пояснения по коду следует писать в свободное время. Минимальные блоки документации, описывающие формат данных и краткое описание функций или сложных моментов должны писаться вместе с кодом. И должны быть частью кода.

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

Готовность к изменениям важнее следования первоначальному плану
Это очень хорошо демонстрирует сущность договора на создание ПО звучит как «сначала вы делаете, потом мы платим». Вообще, это означает, что заказчик и команда должны быть готовы к тому, что могут поменяться требования к проекту в любой момент его реализации, например если:

• в середине процесса создания ПО появилась идея
• изменился/появился какой-то закон
• конкуренты выпустили новую версию своего продукта с фичей которой нет у нас
• сменилось ответственное лицо заказчика
• заказчик вспомнил важную, упущенную во время обсуждений, деталь
• мы нашли еще кого-то кто мог бы купить у нас этот же продукт, но новому заказчику нужна фича
• задача была составлена не верно/команда не верно интерпретировала задачу
• Обнаружилось, что во время сбора требований забыли про какой-то бизнес-процесс :-)
• что-то ещё

А 12 принципов Agile по-моему, настолько очевидны, что комментировать их не имеет смысла.

Про постоянные измения в одних и тех же частях системы, доработки функционала ПО.

Хотел бы привести в пример, как метафору метод прогрессивного JPEG.
В любую секунду проект готов на 100%, хотя проработанность может быть и на 4%.

Получается, что время тратится только на нужную степень прожарки, а общий вид стейка всегда ясен.

Иллюстрация выше — типичный пример методолгии Водопада (слева) и Agile (справа). Собственно, каждая итерация в Agile процессе может прибавлять 5-20% к детализации целой картины продукта. Как показывает практика, обычно продукты шипятся (сдаются в продажу или в использование) не тогда, когда они на 100% завершены, а тогда, когда подошел срок :-)

Методология Водопада — это «сначала много думаем, потом делаем, никому ничего не показываем, потом ноем о том, что этого не было в ТЗ, если стало вдруг нужно прикрутить фишечку, нужно переделывать половину системы, т. к. никто и предположить не мог что что-то придется менять когда-нибудь. Срываем сроки, называм заказчиков тупыми ублюдками, убиваемся об стену, материм манагера.»

В этом случае, на 95% готовая по методологии Agile система будет содержать в себе абсолютно все запланированные фичи работать и удовлетворять почти всем требованиям заказчика, ну и содержать какие-то небольшие недоработки.
В системе готовой на 95%, разрабатываемой по методологии водопада, скорее всего будет просто полностью отсутствовать часть требуемого функционала, а возможно некоторые части системы просто не смогут работать без тех отсутствующих 5%.

Кроме того, изготавливаемый по методолгии водопада продукт, скорее всего будет выпущен морально устаревшим, т. к. мир стремительно меняется, появляются новые технологии и конкурирующие продукты.
Методология водопада хороша там, где требования к продуту не меняются, надежность и качество ценятся вне зависимости от времени разработки и количества денег. Например, в космических программах (NASA до сих пор использует 386 процессоры). Может быть еше в ракетах и в танках.

А в остальных сферах — только Agile и постоянные изменения.