Waterfall
Заказчик сообщает, что хочет блинов. Компания выделяет проджект менеджера, который говорит: «Говно вопрос! Наша компания специализируется по производству блинов! Мы сделаем вам офигенских блинов за две тысячи человеко-часов!»
Далее начинается аналитическая фаза. Бизнес-аналитик берет эксперта, и они денно и нощно заседают в офисе заказчика, потребляют халявный кофе и пончики, а также тщательно записывают бизнес-требования вплоть до толщины блинной корочки с точностью до микрона. Документы записываются на фирменных бланках компании, после чего заверяются подписью директора компании-заказчика, директора компании-исполнителя, стороннего консультанта по блинному производству, а также печатью Папы Римского. После окончания аналитической фазы на проект остается 1000 часов.
Далее начинается фаза архитектуры. Для такой задачи выделяют ведущего архитектора, который детально расписывает архитектурное решение по постройке блинной фабрики на 2000 гектар. В состав фабрики должны войти: цех просеивания муки; цех выращивания кур; цех сбора и сортировки яиц; цех отжима подсолнечного масла; цех замеса теста; система управления кулинарными рецептами; цех выпекания; система контроля толщины корочки (мы же помним про бизнес-требования). При этом, печи в цехе выпекания должны работать на холодном термоядерном синтезе, а продукция между цехами должна перемещаться по универсальному конвейеру-шине, который должен гарантировать доставку продуктов потребителю в нужном порядке. После окончания архитектурной фазы на проект остается 100 часов.
Далее проект передается в разработку. Разработчики приезжают на площадку, выделенную для строительства фабрики, и обнаруживают там болото. Тимлид заводит баг на архитектора со словами: «Если строить фабрику на болоте, она утонет к хренам». Через неделю архитектор возвращает баг с комментарием: «Так осушите болото!» Тимлид сообщает проджект менеджеру, что осушение займет десять тысяч часов. ПМ отвечает, что это слишком много, и надо строить прямо в болоте. Возможно, в следующем релизе у задачи появится второй этап, и мы придумаем специальный насос, который высосет болото из-под фабрики и закачает туда цемент. А пока укомплектуем фабрику эксплуатационным инструментом в виде сотни домкратов. К этому моменту на проект осталось 0 часов.
Пока разработчики возводят завод на болоте и костях своих коллег, умерших от малярии, из проекта одна за одной удаляются фичи. Первым уходит термоядерный реактор, который заменяют на печку-буржуйку. Потом уходит система управления рецептами, в результате чего фабрика может производить только блины захардкоженной квадратной формы. Архитектор до последнего защищает систему контроля толщины корочки, но спустя 1000 часов, на которые уже просрочен проект, отказываются и от нее.
После завершения фазы разработки на площадку запускают тестировщиков. Вместо фабрики они обнаруживают дощатый сарай, а также одинокого специалиста внедрения, который бегает от домкрата к домкрату и удерживает сарай от погружения в болото. В углу сарая стоит печка-буржуйка с unibody-алюминиевой сковородкой, запатентованной у Apple. В другом углу свалены мешки с мукой, коробки с яйцами и подсолнечным маслом. От мешков к буржуйке тянется универсальный конвейер-шина, очередность продуктов на котором гарантирует все тот же специалист внедрения.
Тестировщики удивляются, и заводят 500 багов на разработку, т. к. никто не отразил в документации ни одного компромисса, который был принят во время строительства. Ситуация осложняется тем, что регрессионная модель требует проверки базового функционала: возможности горения дров в присутствии кислорода; невозможности горения дров в отсутствии кислорода; возможности человека войти в дверь фабрики и т. д. Когда проект просрочен на 2000 часов, тестирование только начинает проверять температуру поверхности сковородки. Все бегают, кричат и паникуют, ПМ решает сдавать задачу с незавершенным тестированием.
На приемке заказчику в качестве бонуса дают разогретых блинов из привокзальной рыгаловки и договариваются принимать задачу с ограничениями. Даже с ограничениями заказчик находит проблему: после зажарки блин невозможно отделить от unibody-алюминиевой сковордки, запатентованной у Apple. Приемка откладывается, а разработчики бегут исправлять критичный баг. В результате, запатентованную сковородку заменяют на обычную Tefal за 150 р. из Ашана. Из первоначальной архитектуры остается только универсальный конвейер-шина, на котором так и не смогли обеспечить гарантию очередности продуктов. После 5000 часов, потраченных на задачу, заказчик, скрепя сердце, принимает фабрику и согласует второй этап задачи в следующем релизе. Изрядно поседевший ПМ говорит: «Говно вопрос! ...»
Далее начинается аналитическая фаза.
[ Продолжение следует ]
Комментарии (41)
Scf
03.03.2016 10:58Этот текст не про то, что Waterfall плох. Этот текст про то, что Waterfall плох, если ТЗ составляют плохие аналитики.
vintage
03.03.2016 11:03+18Плох тот процесс, который позволяет завалить проект одному "плохому" работнику.
lair
03.03.2016 11:44+3Не одному работнику, а одной фазе. И да, ошибки на этапе анализа — самые дорогие в любой методологии, за сорок лет со времен Фагана ничего не изменилось (на самом деле, еще архитектура может посоревноваться, чтобы быть честными).
sebres
04.03.2016 00:11+4ошибки на этапе анализа — самые дорогие в любой методологии
Если бы только ошибки… Оно само по себе часто съедает кучу человеко-часов. В корпоративке (европы если что) частенько бывает примерно вот так (ЧД — человеко-день):
- есть бюджет у заказчика — 100 ЧД, но надо бы в идеале за 50-75 (оставить на черный день);
- собственный проект-менеджмент заказчика — 20 ЧД;
- выяснение "тонкостей" внутри самого заказчика (проект-менеджмент <-> люди которым нужен продукт) — 5 ЧД;
- собственный аудит заказчика — 10 ЧД;
- согласование внутри заказчика (все эти вышеуказанные "грантоеды") — 10 ЧД;
- обсуждение с salesman подрядчика — 5 ЧД;
- здесь в первый раз проект-менеджер (или в идеале команда разрабов) подрядчика увидели проект — 1 ЧД;
- написание тех-задания (или переделка-подгонка ТЗ от заказчика) — 10 ЧД;
- согласование тех-задания проект-менеджер — разработчик — 5 ЧД;
- согласование тех-задания с заказчиком — подрядчик (глухие телефоны туда-сюда) — 10 ЧД;
- здесь неоднократный повтор вплоть до аудитора заказчика, а все почему — прямой контакт разраба подрядчика и человека от заказчика, для которого пишем проект, не желателен (а часто просто тупо запрещен);
- подготовка инфраструктуры, репозитариев, и т.д. — 1 ЧД;
Итог: разработчики только начинают писать, когда осталось 0 ЧД с хвостиком (в идеале).
Про тест, ввод в эксплуатацию, баг-фиксинг, энд-аудит и т.д. и т.п. уже промолчим.
ThePretender
03.03.2016 12:25+2Всё дело в объёме задачи. Если это простая доработка на 50 часов, то waterfall ничего не испортит. Если мы говорим о задаче с фазой разработки на 3 месяца, то тут лучше получать фидбэк как можно раньше. И agile-подход в этом плане сильно снижает риски по «плохим аналитикам», т. к. качество требований и их влияние на следующие фазы видно сразу.
Gorthauer87
03.03.2016 12:27Может тогда разбить большую фазу на несколько мелких и получить себе вполне годный Agile?
ThePretender
03.03.2016 12:30+1Так ведь так оно и получается. Берём большую задачу, разбиваем на понятные более-менее законченные куски, делаем для каждого аналитику и архитектуру, кодим… Опа, а мы уже в agile!
NortaBirdo
03.03.2016 12:40+1К сожалению, в случае контрактов, которые должны проводиться по конкурсной процедуре, agile не подходит. Ибо в agile клиент платит за процесс разработки. А в ГК — за результат.
Scf
03.03.2016 12:58+1Всё немного сложнее. Agile, при всех его преимуществах, не бесплатен: итерации требуют дополнительных ресурсов и дополнительного взаимодействия между людьми, увеличивая время разработки. Я думаю, что не будет преувеличением сказать, что примерно на треть.
С другой стороны, при наличии сильной команды аналитиков waterfall может оказаться намного полезнее, предоставляя меньшие сроки разработки, предсказуемость по срокам и качеству результата. Другой вопрос, что качественное ТЗ — это очень дорогое и еще и небыстрое удовольствие, позволить которое мало кто может. Но кое-где это оправдано.ThePretender
03.03.2016 13:18+1Да, действительно, agile не бесплатен. Время уходит на ежедневные статусы, ретро и демо. Некоторые спринты вообще выкидываются в мусорку из-за упущений в аналитике и архитектуре. Но я пока не видел ни одной крупной задачи, которую удалось реализовать по waterfall без последующего пересмотра аналитики или архитектуры (я говорю о большой доработке существующей системы, которая развивается больше 10 лет).
NortaBirdo
03.03.2016 12:37+1Здесь просто пропущена важная фаза — обсуждение требований с Implementation Matter Expert. Когда БА должен взять за шкирку архитектора и разработчиков, посадить в одной комнате и провести проверку требований на реализуемость. Это не серебряная пуля, но иногда позволяет найти болото на "строй площадке" раньше, чем подпишут документ. А там уже пусть ПМ думает что делать — менять границы проекта, или предлагать резать функционал.
Справедливости ради, тут действительно есть косяк: нет снимков местности (требования к окружению).
zip_zero
03.03.2016 12:04+1Человечество печет блины сколько себя помнит, а IT как отрасли от силы 70 лет.
Можно смеяться сколько угодно, но пройдёт ещё столько же времени прежде, чем IT-компании наконец научатся, как это делать.
ghost404
03.03.2016 12:35+4однако до сих пор не все знают как печь блины. что уж говорить про IT
картинка в тему
zip_zero
03.03.2016 13:18+3"Все" — это очень широкая и абстрактная категория, но.
Я уверен, повара точно знают, как печь блины.
А айтишники (в широком смысле) — не всегда знают, как делать IT.
Собственно, в этом вся изюминка ситуации.
Goodkat
03.03.2016 12:24+1Начало похоже на IBM. Только у тех просрочка раз в пять, а в конце оказывается, что условия лицензирования изменились, муку для блинов IBM больше не производит, на другой муке фабрика работать принципиально не может, и блины на построенной фабрике выпекать не получится, так что заказчик может продолжать платить аренду за землю под фабрикой и зарплату нанятому персоналу или сносить её за свой счёт, а блины идёт покупать готовые в супермаркете.
Segun92
03.03.2016 12:25У вас в тексте почему-то waterfall также ассоциируется с плохим ПМ, плохими аналитиками, архитекторами, девелоперами, тестировщиками… в общем все страдают ерундой и делают всё не так. С такими людьми при работе по любому процессу вы сделаете не блины, а черт знает что. И никакой agile тут не поможет.
У каждого SDLC есть свои плюсы и минусы.ThePretender
03.03.2016 12:28+1У каждого SDLC есть свои плюсы и минусы.
Безусловно. Штука в том, что в реальности очень сложно найти идеального аналитика, архитектора, разработчика и тестировщика. Рискну даже предположить, что их не бывает :) Суть текста в том, что waterfall гораздо менее простительно относится к ошибкам на начальных стадиях, чем тот же agile.Segun92
03.03.2016 12:30+1Заказчик сообщает, что хочет блинов. Компания выделяет проджект менеджера, который говорит: «Говно вопрос! Наша компания специализируется по производству блинов! Мы сделаем вам офигенских блинов за две тысячи человеко-часов!»
Мне после этой фразы стало ясно чем всё закончится)
Gorthauer87
03.03.2016 12:29+3Без методологии получается ненамного хуже.
https://xakep.ru/2001/06/19/12860/
Rumega
03.03.2016 12:40+2Вот так, братцы, строятся блинные заводы в представлении узбека из «привокзальной рыгаловки», и это во многом подытоживает Agile vs не-Agile дискуссию :)
siemdi
03.03.2016 12:51+1Впервые столкнулся с этой методикой в этом году… Начинающий разработчик… Опять таки выскажу свое субъективное мнение. Все бы было отлично и на деле, если бы разработчики и менеджеры были роботами а не людьми. Холодный расчет, никаких форсмажоров и тд… Но обычно при разработке ТЗ и всей шелухи, забывают внести во временные риски, человеческий фактор. А именно людям свойственно болеть, увольняться, лениться… А так все работает как часики...
spmbt
03.03.2016 14:01+1в результате чего фабрика может производить только блины захардкоженной квадратной формы.
В результате, запатентованную сковородку заменяют на обычную Tefal за 150 р. из Ашана.
Они взяли сковородки диаметром в sqrt(2) раз больше?
forgotten
03.03.2016 15:44+1Что, кто там утверждал, что Хабр не умер?…
Milfgard
04.03.2016 08:50+1Надо признать, что это частный пример плохого поста. Но вот что он делает наверху уже два дня — второй вопрос.
forgotten
04.03.2016 08:57Что из этого — хороший пост?
Обзор инфракрасного датчика CO2 MH-Z19 5
Видеоаналитика 2.0 или при чём тут оставленные предметы. Часть 1 0
Порог вхождения в Angular 2 — теория и практика 22
(La)TeX на Хабрахабре 16
Тестирование JS. Кармический Webpack 0
Фильм о победителях Google Lunar XPRIZE появится на YouTube 17 марта 1
BMW Australia отказывается соблюдать условия лицензии GPL 20
Обзор и сравнительное тестирование ПЭВМ «Эльбрус 401?PC». Дополнение — вопросы и ответы 23
Астронавт Скотт Келли за год в космосе вырос на 5 см 18
Векторная графика бесплатно — подборка сайтов 2
Labutin
03.03.2016 22:35Waterfall, Agile и т.п. — это и хорошо и плохо.
Но в большинстве случаев как бывает? https://youtu.be/ir5rj2yYH_8
Sevlyar
Когда начал читать, ожидал что будет несколько методологий.
ThePretender
Хотел написать несколкьо, но потом понял, что про Waterfall получилось много, и ещё больше народ не осилит :) Другие методологии опишу в другом посте.
dom1n1k
6-7 экранов текста на телефоне — это много?
Newbilius
2 страницы! 2 страницы, Карл! Серьёзно? Не осилят?!
ThePretender
Ну да: дефицит внимания, поколение айфонов, фруктовые смузи — вот это всё :) Сам недавно узнал, что тексты размером в средний ЖЖ-пост 2008 года теперь называют лонг-ридами :))
impetus
Ну вот нам и ответ почему мрёт хабр. Интресно АЭС и даже простой водопровод долго ещё продержатся? Там же ИНСТРУКЦИИ!!! — тома-талмуды, да ещё предполагающие, что тома учебников давно в голове...
Iceg
Ну вот заказчик один недавно требовал от нас, интерграторов в энергетике, инструкции на оборудование. На оборудование, к которому есть отличная — подробная, исчерпывающая и понятная — инструкция завода изготовителя на русском. Не, грит, надо покороче, на 2-3 страницы.
impetus
На авиафоруме рассказывали как они в Африке сводили в три итерации многокилограммовые инструкции по Ми-24 вначале к брошюре, а потом к буквально колоде карт с комиксами.
Все там будем.