Comments 12
Не помешало бы добавить в конце ссылки которые подтверждают или на которые опирается написаное.
Например нагуглил для такую:
Royce, Winston (1970), «Managing the Development of Large Software Systems», Proceedings of IEEE WESCON 26 (August): 1–9
www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
Например нагуглил для такую:
Royce, Winston (1970), «Managing the Development of Large Software Systems», Proceedings of IEEE WESCON 26 (August): 1–9
www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
Спасибо, кэп. Это есть во всех учебниках.
«В таком случае остается вопросом, почему методология в широких кругах разработчиков и тестировщиков воспринимается ошибочно, как отображено на первом рисунке…»
Для меня больший вопрос почему вы считаете что в широких кругах разработчиков и тестировщиков waterfall воспринимается ошибочно??
А если выразить моё мнение, то я и вовсе не понимаю о чём статья, 2 скриншота вырванных из книги это всё равно что кровь из пальца высасывать. Даже в том отрывке что вы привели в качестве первоисточника, достаточно подробно описаны все нюансы и расписаны частично шаги.
Для меня больший вопрос почему вы считаете что в широких кругах разработчиков и тестировщиков waterfall воспринимается ошибочно??
А если выразить моё мнение, то я и вовсе не понимаю о чём статья, 2 скриншота вырванных из книги это всё равно что кровь из пальца высасывать. Даже в том отрывке что вы привели в качестве первоисточника, достаточно подробно описаны все нюансы и расписаны частично шаги.
Ответ на главный вопрос уже есть — youtu.be/X1c2--sP3o0
Водопад не любят не из-за того, что не понимают, его не любят из-за того, что он плохо подходит для сложных программных систем. Причин 2:
1. В современных условиях заказчик сам не знает и не может объяснить, чего же он в итоге хочет («чтоб было круто» — это не желание, это ощущение);
2. из-за п.1 бегать вверх-вниз по ступенькам водопада можно до бесконечности, как только проект переваливает определенную сложность (у нас в команде буквально за неделю аж 3 таких проекта появилось, притом так, что мы даже пока не знаем, в каких сроки и стоимость это получится уложить)
То, что вы озвучили в конце — это не разновидность водопада, это скорее спираль
1. В современных условиях заказчик сам не знает и не может объяснить, чего же он в итоге хочет («чтоб было круто» — это не желание, это ощущение);
2. из-за п.1 бегать вверх-вниз по ступенькам водопада можно до бесконечности, как только проект переваливает определенную сложность (у нас в команде буквально за неделю аж 3 таких проекта появилось, притом так, что мы даже пока не знаем, в каких сроки и стоимость это получится уложить)
То, что вы озвучили в конце — это не разновидность водопада, это скорее спираль
Проблема каскадной модели второго типа в том, что если нам внезапно сообщили, что требования ошибочны, а мы уже на этапе тестирования, то необходимо будет вернуться назад к первому шагу, а затем снова бежать по водопаду вниз.
а как иначе?
Смена требований ведь влияет на все последующие этапы…
Сменили/добавили требования — нужен анализ, нужны правки в дизайне, нужно кодирование, нужно тестирование…
Смена требований ведь влияет на все последующие этапы…
Сменили/добавили требования — нужен анализ, нужны правки в дизайне, нужно кодирование, нужно тестирование…
Иначе — agile methods, при всех своих недостатках. В конце концов, все апологеты agile methods как раз отталкиваются в своих работах от недостатков водопада.
Одна фирма говорит: «ну а как иначе? сменили требования, дайте ещё год на работу».
А другая: «гм, ну что ж, мы были к этому готовы, дайте ещё месяц».
Подумайте, к кому заказчики пойдут :)
Одна фирма говорит: «ну а как иначе? сменили требования, дайте ещё год на работу».
А другая: «гм, ну что ж, мы были к этому готовы, дайте ещё месяц».
Подумайте, к кому заказчики пойдут :)
По-этому нужно говорить не про то, что водопад — устаревшая утопия, а Agile — панацея, а о том, что эти методологии применимы для разных проектов.
При чем здесь мы говорим о размере проекта (Agile ведь говорит о проекта численостью 7+-2 человека), о его тематике (как подметил товарищ Greesha в своей статье, сложно представить проект по мед. или косм. программам бегущий на Agile) и конечно же желании/готовности кастомера (толи он хочет конкретный ф-л и у него есть требования, толи он подписывает контрак на год разработки и все время вам заказывает новые фичи).
При чем здесь мы говорим о размере проекта (Agile ведь говорит о проекта численостью 7+-2 человека), о его тематике (как подметил товарищ Greesha в своей статье, сложно представить проект по мед. или косм. программам бегущий на Agile) и конечно же желании/готовности кастомера (толи он хочет конкретный ф-л и у него есть требования, толи он подписывает контрак на год разработки и все время вам заказывает новые фичи).
сложно представить проект по мед. или косм. программам бегущий на AgileСложно представить проект по мед. или косм. программам, в котором "заказчик сам не знает и не может объяснить, чего же он в итоге хочет" ;-)…
В полку выбравших красную таблетку не ленящихся читать первоисточники прибыло. :)
Что интересно, когда я сделал для себя это открытие и решил поведать о нём миру, я вырезал из статьи те же самые картинки.
Что интересно, когда я сделал для себя это открытие и решил поведать о нём миру, я вырезал из статьи те же самые картинки.
Sign up to leave a comment.
Waterfall — итеративная методология разработки