Типа waterfall или WaterfallButt

Как вас всех, наверное, достали те разработчики, которые безосновательно считают, что у них Agile. Мы такой процесс называли "типа Agile". Спросишь у них "вы как работаете?" - а они в ответ "ну у нас типа Agile" и скромненько так ручкой махнут.
Я ваше негодование полностью разделяю и поддерживаю. Как так можно? Во-первых, на святое, а во-вторых, они же примазываются. А потом будут кричать везде "ваш Agile фигня".

Ken Schwaber, автор Scrum, называет такой процесс Scrum Butt. Например, "we have scrum, but...(no iterations)". Dan Rawsthorne даже нотацию придумал:

• Scrum (but) no Product Owner
• Scrum (but) no self-organization
• Scrum (but) shitty code

Но я хотел написать совсем не об этом. Видимо, начинаю писать про "типа Agile" и остановится не могу, ну вы меня понимаете.

Так вот, я про waterfall хотел написать. Мне кажется, что настоящие "водопадники" (если бы такие водились) точно также должны были бы обижаться на тех, кто примазывается к их "настоящему водопаду". Такие, я подозреваю, не водятся, поэтому я выступлю в несвойственной для себя роли защитника водопада.

Будем называть такой процесс "типа водопад" или "waterfall butt".

Во-первых, господа "водопадники", вас все критикуют за Big Design Up Front. Вы понимаете, что это должно означать? Как минимум, это:

Design есть. И он создается в начале проекта.

Причем первая часть важнее. Так вот, страшная тайна в том, что дизайн и спецификации - это не требования к системе, то есть не Use Cases! Это описание архитектуры, дизайн компонентов на уровне диаграмм классов, различные sequence diagrams и прочие ужасы дорвавшегося до власти сумасшедшего проектировщика.

Я вам страшную историю расскажу. Прихожу я как-то в одну очень серьезную "водопадную" компанию. Они мне показывают очень многостраничные документы спецификаций. Я прямо за голову хватаюсь, надо же, первый раз настолько серьезную контору вижу. Ну и потом разговорились. Главный программер и говорит: "Ну мы сначала пишем код, а потом пишем к нему спецификации". Нет, вы представляете? Big Design Up Front, my ass!

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

Ну а как? Ведь время от времени прибегает заказчик и что-то еще просовывает, какие там уж планы. Такие запросы получают статус JFDI (Just Fucking Do It) и выполняются в обход всех планов и процедур.

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

Я сказал чуть выше слово Use Cases? Я погорячился! Какие там Use Cases!
Хотите анекдот? Я его сам придумал:

- Ты знаешь як москали наши Requirements Specifications называют?
- Як?
- Тэзэ. Поубывав бы!

Простите мой украинский, я знаю, что он не идеален.

Так вот, ТЗ (техническое задание) это такой длинный слабо-структурированный текст, где фичи перемешаны с описанием того, как система должна работать. Туда еще понапиханы прототипы экранных форм и все это без указаний приоритетов. Действительно, зачем приоритеты? У нас все важно!

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

А приемка результатов? У кого есть согласованные с заказчиком приемочные тесты и процедуры приемки? Я таких не видел: у нас другие методы подписания актов приемки. К системе они никакого отношения они не имеют. Зато включают много других интересных телодвижений, которыми вообще-то прокуратура должна интересоваться.

Так что не примазывайтесь. У вас не водопад, а "типа водопад", или, если хотите, "waterfall butt".

Я по простому скажу: никакого watefall в России нет, и слава богу. Без waterfall'а проживем.

Так что покайтесь, и давайте внедрять Agile :-)