Comments 41
Хотел написать несколкьо, но потом понял, что про Waterfall получилось много, и ещё больше народ не осилит :) Другие методологии опишу в другом посте.
Ну да: дефицит внимания, поколение айфонов, фруктовые смузи — вот это всё :) Сам недавно узнал, что тексты размером в средний ЖЖ-пост 2008 года теперь называют лонг-ридами :))
Ну вот нам и ответ почему мрёт хабр. Интресно АЭС и даже простой водопровод долго ещё продержатся? Там же ИНСТРУКЦИИ!!! — тома-талмуды, да ещё предполагающие, что тома учебников давно в голове...
Ну вот заказчик один недавно требовал от нас, интерграторов в энергетике, инструкции на оборудование. На оборудование, к которому есть отличная — подробная, исчерпывающая и понятная — инструкция завода изготовителя на русском. Не, грит, надо покороче, на 2-3 страницы.
На авиафоруме рассказывали как они в Африке сводили в три итерации многокилограммовые инструкции по Ми-24 вначале к брошюре, а потом к буквально колоде карт с комиксами.

Все там будем.
Этот текст не про то, что Waterfall плох. Этот текст про то, что Waterfall плох, если ТЗ составляют плохие аналитики.
Плох тот процесс, который позволяет завалить проект одному "плохому" работнику.
Не одному работнику, а одной фазе. И да, ошибки на этапе анализа — самые дорогие в любой методологии, за сорок лет со времен Фагана ничего не изменилось (на самом деле, еще архитектура может посоревноваться, чтобы быть честными).
ошибки на этапе анализа — самые дорогие в любой методологии

Если бы только ошибки… Оно само по себе часто съедает кучу человеко-часов. В корпоративке (европы если что) частенько бывает примерно вот так (ЧД — человеко-день):

  • есть бюджет у заказчика — 100 ЧД, но надо бы в идеале за 50-75 (оставить на черный день);
  • собственный проект-менеджмент заказчика — 20 ЧД;
  • выяснение "тонкостей" внутри самого заказчика (проект-менеджмент <-> люди которым нужен продукт) — 5 ЧД;
  • собственный аудит заказчика — 10 ЧД;
  • согласование внутри заказчика (все эти вышеуказанные "грантоеды") — 10 ЧД;
  • обсуждение с salesman подрядчика — 5 ЧД;
  • здесь в первый раз проект-менеджер (или в идеале команда разрабов) подрядчика увидели проект — 1 ЧД;
  • написание тех-задания (или переделка-подгонка ТЗ от заказчика) — 10 ЧД;
  • согласование тех-задания проект-менеджер — разработчик — 5 ЧД;
  • согласование тех-задания с заказчиком — подрядчик (глухие телефоны туда-сюда) — 10 ЧД;
  • здесь неоднократный повтор вплоть до аудитора заказчика, а все почему — прямой контакт разраба подрядчика и человека от заказчика, для которого пишем проект, не желателен (а часто просто тупо запрещен);
  • подготовка инфраструктуры, репозитариев, и т.д. — 1 ЧД;

Итог: разработчики только начинают писать, когда осталось 0 ЧД с хвостиком (в идеале).

Про тест, ввод в эксплуатацию, баг-фиксинг, энд-аудит и т.д. и т.п. уже промолчим.
Всё дело в объёме задачи. Если это простая доработка на 50 часов, то waterfall ничего не испортит. Если мы говорим о задаче с фазой разработки на 3 месяца, то тут лучше получать фидбэк как можно раньше. И agile-подход в этом плане сильно снижает риски по «плохим аналитикам», т. к. качество требований и их влияние на следующие фазы видно сразу.
Может тогда разбить большую фазу на несколько мелких и получить себе вполне годный Agile?
Так ведь так оно и получается. Берём большую задачу, разбиваем на понятные более-менее законченные куски, делаем для каждого аналитику и архитектуру, кодим… Опа, а мы уже в agile!
К сожалению, в случае контрактов, которые должны проводиться по конкурсной процедуре, agile не подходит. Ибо в agile клиент платит за процесс разработки. А в ГК — за результат.
Всё немного сложнее. Agile, при всех его преимуществах, не бесплатен: итерации требуют дополнительных ресурсов и дополнительного взаимодействия между людьми, увеличивая время разработки. Я думаю, что не будет преувеличением сказать, что примерно на треть.

С другой стороны, при наличии сильной команды аналитиков waterfall может оказаться намного полезнее, предоставляя меньшие сроки разработки, предсказуемость по срокам и качеству результата. Другой вопрос, что качественное ТЗ — это очень дорогое и еще и небыстрое удовольствие, позволить которое мало кто может. Но кое-где это оправдано.
Да, действительно, agile не бесплатен. Время уходит на ежедневные статусы, ретро и демо. Некоторые спринты вообще выкидываются в мусорку из-за упущений в аналитике и архитектуре. Но я пока не видел ни одной крупной задачи, которую удалось реализовать по waterfall без последующего пересмотра аналитики или архитектуры (я говорю о большой доработке существующей системы, которая развивается больше 10 лет).
Здесь просто пропущена важная фаза — обсуждение требований с Implementation Matter Expert. Когда БА должен взять за шкирку архитектора и разработчиков, посадить в одной комнате и провести проверку требований на реализуемость. Это не серебряная пуля, но иногда позволяет найти болото на "строй площадке" раньше, чем подпишут документ. А там уже пусть ПМ думает что делать — менять границы проекта, или предлагать резать функционал.

Справедливости ради, тут действительно есть косяк: нет снимков местности (требования к окружению).
Человечество печет блины сколько себя помнит, а IT как отрасли от силы 70 лет.
Можно смеяться сколько угодно, но пройдёт ещё столько же времени прежде, чем IT-компании наконец научатся, как это делать.
однако до сих пор не все знают как печь блины. что уж говорить про IT

картинка в тему
image
"Все" — это очень широкая и абстрактная категория, но.

Я уверен, повара точно знают, как печь блины.
А айтишники (в широком смысле) — не всегда знают, как делать IT.

Собственно, в этом вся изюминка ситуации.
Начало похоже на IBM. Только у тех просрочка раз в пять, а в конце оказывается, что условия лицензирования изменились, муку для блинов IBM больше не производит, на другой муке фабрика работать принципиально не может, и блины на построенной фабрике выпекать не получится, так что заказчик может продолжать платить аренду за землю под фабрикой и зарплату нанятому персоналу или сносить её за свой счёт, а блины идёт покупать готовые в супермаркете.
У вас в тексте почему-то waterfall также ассоциируется с плохим ПМ, плохими аналитиками, архитекторами, девелоперами, тестировщиками… в общем все страдают ерундой и делают всё не так. С такими людьми при работе по любому процессу вы сделаете не блины, а черт знает что. И никакой agile тут не поможет.

У каждого SDLC есть свои плюсы и минусы.
У каждого SDLC есть свои плюсы и минусы.

Безусловно. Штука в том, что в реальности очень сложно найти идеального аналитика, архитектора, разработчика и тестировщика. Рискну даже предположить, что их не бывает :) Суть текста в том, что waterfall гораздо менее простительно относится к ошибкам на начальных стадиях, чем тот же agile.
Заказчик сообщает, что хочет блинов. Компания выделяет проджект менеджера, который говорит: «Говно вопрос! Наша компания специализируется по производству блинов! Мы сделаем вам офигенских блинов за две тысячи человеко-часов!»

Мне после этой фразы стало ясно чем всё закончится)
Вот так, братцы, строятся блинные заводы в представлении узбека из «привокзальной рыгаловки», и это во многом подытоживает Agile vs не-Agile дискуссию :)
Впервые столкнулся с этой методикой в этом году… Начинающий разработчик… Опять таки выскажу свое субъективное мнение. Все бы было отлично и на деле, если бы разработчики и менеджеры были роботами а не людьми. Холодный расчет, никаких форсмажоров и тд… Но обычно при разработке ТЗ и всей шелухи, забывают внести во временные риски, человеческий фактор. А именно людям свойственно болеть, увольняться, лениться… А так все работает как часики...
в результате чего фабрика может производить только блины захардкоженной квадратной формы.

В результате, запатентованную сковородку заменяют на обычную Tefal за 150 р. из Ашана.

Они взяли сковородки диаметром в sqrt(2) раз больше?
Надо признать, что это частный пример плохого поста. Но вот что он делает наверху уже два дня — второй вопрос.
Что из этого — хороший пост?

Обзор инфракрасного датчика 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
Не знаю, хорошие они или нет. Мне же они, к счастью, на глаза не попались. То, что я читаю, меня, в целом, устраивает.
Only those users with full accounts are able to leave comments. Log in, please.