How to become an author
Search
Write a publication
Pull to refresh

Comments 41

Когда начал читать, ожидал что будет несколько методологий.
Total votes 46: ↑44 and ↓2+42
Хотел написать несколкьо, но потом понял, что про Waterfall получилось много, и ещё больше народ не осилит :) Другие методологии опишу в другом посте.
Total votes 49: ↑17 and ↓32-15
6-7 экранов текста на телефоне — это много?
Total votes 16: ↑12 and ↓4+8
Ну да: дефицит внимания, поколение айфонов, фруктовые смузи — вот это всё :) Сам недавно узнал, что тексты размером в средний ЖЖ-пост 2008 года теперь называют лонг-ридами :))
Total votes 26: ↑21 and ↓5+16
Ну вот нам и ответ почему мрёт хабр. Интресно АЭС и даже простой водопровод долго ещё продержатся? Там же ИНСТРУКЦИИ!!! — тома-талмуды, да ещё предполагающие, что тома учебников давно в голове...
Total votes 7: ↑7 and ↓0+7
Ну вот заказчик один недавно требовал от нас, интерграторов в энергетике, инструкции на оборудование. На оборудование, к которому есть отличная — подробная, исчерпывающая и понятная — инструкция завода изготовителя на русском. Не, грит, надо покороче, на 2-3 страницы.
Total votes 5: ↑5 and ↓0+5
На авиафоруме рассказывали как они в Африке сводили в три итерации многокилограммовые инструкции по Ми-24 вначале к брошюре, а потом к буквально колоде карт с комиксами.

Все там будем.
Total votes 8: ↑8 and ↓0+8
Этот текст не про то, что Waterfall плох. Этот текст про то, что Waterfall плох, если ТЗ составляют плохие аналитики.
Total votes 2: ↑1 and ↓10
Плох тот процесс, который позволяет завалить проект одному "плохому" работнику.
Total votes 18: ↑18 and ↓0+18
Не одному работнику, а одной фазе. И да, ошибки на этапе анализа — самые дорогие в любой методологии, за сорок лет со времен Фагана ничего не изменилось (на самом деле, еще архитектура может посоревноваться, чтобы быть честными).
Total votes 3: ↑3 and ↓0+3
ошибки на этапе анализа — самые дорогие в любой методологии

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

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

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

Про тест, ввод в эксплуатацию, баг-фиксинг, энд-аудит и т.д. и т.п. уже промолчим.
Total votes 4: ↑4 and ↓0+4
Всё дело в объёме задачи. Если это простая доработка на 50 часов, то waterfall ничего не испортит. Если мы говорим о задаче с фазой разработки на 3 месяца, то тут лучше получать фидбэк как можно раньше. И agile-подход в этом плане сильно снижает риски по «плохим аналитикам», т. к. качество требований и их влияние на следующие фазы видно сразу.
Total votes 2: ↑2 and ↓0+2
Может тогда разбить большую фазу на несколько мелких и получить себе вполне годный Agile?
This comment wasn’t rated yet0
Так ведь так оно и получается. Берём большую задачу, разбиваем на понятные более-менее законченные куски, делаем для каждого аналитику и архитектуру, кодим… Опа, а мы уже в agile!
Total votes 1: ↑1 and ↓0+1
К сожалению, в случае контрактов, которые должны проводиться по конкурсной процедуре, agile не подходит. Ибо в agile клиент платит за процесс разработки. А в ГК — за результат.
Total votes 1: ↑1 and ↓0+1
Всё немного сложнее. Agile, при всех его преимуществах, не бесплатен: итерации требуют дополнительных ресурсов и дополнительного взаимодействия между людьми, увеличивая время разработки. Я думаю, что не будет преувеличением сказать, что примерно на треть.

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

Справедливости ради, тут действительно есть косяк: нет снимков местности (требования к окружению).
Total votes 1: ↑1 and ↓0+1
Кстати, да.

Хотелось бы видеть завершенную статью. Тема интересная.
This comment wasn’t rated yet0
Человечество печет блины сколько себя помнит, а IT как отрасли от силы 70 лет.
Можно смеяться сколько угодно, но пройдёт ещё столько же времени прежде, чем IT-компании наконец научатся, как это делать.
Total votes 5: ↑3 and ↓2+1
однако до сих пор не все знают как печь блины. что уж говорить про IT

картинка в тему
image
Total votes 4: ↑4 and ↓0+4
"Все" — это очень широкая и абстрактная категория, но.

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

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

У каждого SDLC есть свои плюсы и минусы.
This comment wasn’t rated yet0
У каждого SDLC есть свои плюсы и минусы.

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

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

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

Они взяли сковородки диаметром в sqrt(2) раз больше?
Total votes 1: ↑1 and ↓0+1
Что, кто там утверждал, что Хабр не умер?…
Total votes 15: ↑8 and ↓7+1
Надо признать, что это частный пример плохого поста. Но вот что он делает наверху уже два дня — второй вопрос.
Total votes 1: ↑1 and ↓0+1
Что из этого — хороший пост?

Обзор инфракрасного датчика 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
This comment wasn’t rated yet0
Не знаю, хорошие они или нет. Мне же они, к счастью, на глаза не попались. То, что я читаю, меня, в целом, устраивает.
This comment wasn’t rated yet0
Ну это сегодняшний топ.
This comment wasn’t rated yet0
Sign up to leave a comment.

Articles

Your account

Sections

Information

Services

Support
© 2006–2024, Habr