Comments 12
Как же все любят гнобить «Водопад» по отрывочным знаниям о нем…
К слову исторически считается, что термин «водопад» впервые ввёл Winston W. Royce в своей работе “Managing the development of large software systems” (1970) и он же там и написал «I believe in this concept, but the implementation described above is risky and invites failure.». После чего еще несколько страниц описывает как бороться с возможными рисками «Водопада».
Опять же, не нужно совать Agile куда угодно. Подход «сделали, не понравилось, переделали! Как же гибко!» очень хорошо работает там, где стоимость исправления и повторной итерации мала.
А теперь давайте строить с помощью Agile гидроэлектростанцию.
1. О, гидроэлектростанция! Не надо никаких долгих проектов. Берем моторчик, опускаем в воду — электричество!
2. Теперь нам надо 100 моторчиков! Заливай дамбу!
3. Хм… 100 моторчиков ведут себя странно…
4. Ломай дамбу!
У каждой методологии есть свои сильные и слабые стороны, как и у инструментов, и некоторые люди (ошибочно видимо) считают, что нужно просто их знать и уметь выбирать нужный… А то очень напоминает холивар виндузятников и линуксоидов. Человек впервые проникшийся линуксом/фреймворком/языком начинает пристраивать его везде)
«Водопад» был признан рискованным вариантом еще его автором в 70-м, но тем не менее он успешно применяется и работает во многих отраслях, особенно в тех, где есть наработанные методы и цена неудачной «итерации» очень высока. Опять же автор рисовал его не как водопад в привычном смысле слова с невозвратным путем вниз
а всячески настаивал на обратных стрелках между соседними этапами
Ну и напоследок, давал несколько советов по сглаживанию «водопадных недостатков».
Ничего не напоминает пункт 5? =)
P.S. Прошу прощения за картинки, в другом варианте у меня выдержек нет.
P.P.S. Внезапно нашел PDF Managing the development of large software systems Очень рекомендую ознакомиться)
К слову исторически считается, что термин «водопад» впервые ввёл Winston W. Royce в своей работе “Managing the development of large software systems” (1970) и он же там и написал «I believe in this concept, but the implementation described above is risky and invites failure.». После чего еще несколько страниц описывает как бороться с возможными рисками «Водопада».
Опять же, не нужно совать Agile куда угодно. Подход «сделали, не понравилось, переделали! Как же гибко!» очень хорошо работает там, где стоимость исправления и повторной итерации мала.
А теперь давайте строить с помощью Agile гидроэлектростанцию.
1. О, гидроэлектростанция! Не надо никаких долгих проектов. Берем моторчик, опускаем в воду — электричество!
2. Теперь нам надо 100 моторчиков! Заливай дамбу!
3. Хм… 100 моторчиков ведут себя странно…
4. Ломай дамбу!
У каждой методологии есть свои сильные и слабые стороны, как и у инструментов, и некоторые люди (ошибочно видимо) считают, что нужно просто их знать и уметь выбирать нужный… А то очень напоминает холивар виндузятников и линуксоидов. Человек впервые проникшийся линуксом/фреймворком/языком начинает пристраивать его везде)
«Водопад» был признан рискованным вариантом еще его автором в 70-м, но тем не менее он успешно применяется и работает во многих отраслях, особенно в тех, где есть наработанные методы и цена неудачной «итерации» очень высока. Опять же автор рисовал его не как водопад в привычном смысле слова с невозвратным путем вниз
Традиционное понимание водопада
а всячески настаивал на обратных стрелках между соседними этапами
Вариант решения проблем
Ну и напоследок, давал несколько советов по сглаживанию «водопадных недостатков».
Вариант решения проблем
Ничего не напоминает пункт 5? =)
P.S. Прошу прощения за картинки, в другом варианте у меня выдержек нет.
P.P.S. Внезапно нашел PDF Managing the development of large software systems Очень рекомендую ознакомиться)
Спасибо за информацию!
Везде, где есть последовательность действий, проявляется эффект, озвученный господином Элияху. Даже если добавить стрелочки в обратную сторону и привлечь заинтересованных лиц к определению требований.
«Водопад умрёт» — это, конечно, фантазия. Есть области применения и для классической каскадной модели.
Возможно причина эмоционального заголовка заключается в том, что я сейчас работаю с очень инертными организациями, которые используют «водопад» по привычке, а не потому что это необходимо. И терпят существенные потери и в цене и в сроках.
Везде, где есть последовательность действий, проявляется эффект, озвученный господином Элияху. Даже если добавить стрелочки в обратную сторону и привлечь заинтересованных лиц к определению требований.
«Водопад умрёт» — это, конечно, фантазия. Есть области применения и для классической каскадной модели.
Возможно причина эмоционального заголовка заключается в том, что я сейчас работаю с очень инертными организациями, которые используют «водопад» по привычке, а не потому что это необходимо. И терпят существенные потери и в цене и в сроках.
И еще в добавок к вашему каменту,
прежде чем говорить что водопад плох, сначала разберитесь в каких условиях работал он и как. Свое начало waterfall берет а в 1956, во времена компьютеров с перфокартами. Задачи были в основном научного характера, никакой прикладной разработки не было. Для того, чтобы упорядочить хаус, Ройс, чтобы хоть как-то упорядочить разработку формализовал процесс, RUP потом описал этот процесс фазами и так или иначе в рамках одной или группы задач все эти фазы есть.
Сравнивать waterfall и текущую разработку, все равно что сравнивать двигатели начала 20века и современные, с фазовращателями, гидротолкателями непосредственным впрыском, инжектором и т.д. А потом с умным видом говорить:«Да, двигатели начала века были совсем плохие и насегоднячний день они не годятся», конечно не годятся, потому, что тогда и средства были другие и задачи были другие и оккружение было другое.
Опять такинатягиать сову на глобус привносить теорию ограничений, в разработку софта, примерно тоже самое, что давайте на заводе по производству окон применим космические технологические процессы.
На реальном производстве, брак одной небольшой детали, может затормозить вообще все изделие целиком. Из реального примера: топливный корпус на ракету имеет очень сложный высокоточный тех. процесс, если запороть этот корпус на финальной стадии, то чтобы получить новый — придется подождать. Пока его отольют, обработают, протестируют. В процесс вовлечено огромное количество людей и цехов. Если деталь новая, то там вообще пол завода работает (конструкторы, испытатели, инструментальщики, технологи, литейщики). Зависимость между этапами очень высокая.
В софте цикличность и гибкость на порядок выше. Фичу не успеваем — двинем срок, нужно точно в срок — выкинули пару фичей. Постоянно работающих людей над единой частью продукта обычно человек 10 от силы, по факту человек 5-6.
Вся эта беготня вокруг Lean, Aglie, Canban и т.д. сводится к тому, что манагеры/процессно ориентированные граждане, хотят поднять свою важность. Вместо того, чтобы просто договориться как работать и делать дело.
Не следует понимать что я отказываюсь от проектирования, прототипирования, требований и т.д. Но в софте все сильно проще, фича не заработала, в крайнем случае вернули предыдущую версию и все, единица продкта в утиль не идет. В ракете ошибка, которая проводит к падению пораждает очень большой гемморой, потому, что «фарш обратно не провернуть», нельзя откатить на предыдущую версию и успешно запустить ракету, уже все упало и сгорело.
По этому учитесь общаться, договариваться, вырабатывать какие-то процессы взаимодействия и поменьше онанируйте на воплощение теоретического процесса на практике.
прежде чем говорить что водопад плох, сначала разберитесь в каких условиях работал он и как. Свое начало waterfall берет а в 1956, во времена компьютеров с перфокартами. Задачи были в основном научного характера, никакой прикладной разработки не было. Для того, чтобы упорядочить хаус, Ройс, чтобы хоть как-то упорядочить разработку формализовал процесс, RUP потом описал этот процесс фазами и так или иначе в рамках одной или группы задач все эти фазы есть.
Сравнивать waterfall и текущую разработку, все равно что сравнивать двигатели начала 20века и современные, с фазовращателями, гидротолкателями непосредственным впрыском, инжектором и т.д. А потом с умным видом говорить:«Да, двигатели начала века были совсем плохие и насегоднячний день они не годятся», конечно не годятся, потому, что тогда и средства были другие и задачи были другие и оккружение было другое.
Опять таки
На реальном производстве, брак одной небольшой детали, может затормозить вообще все изделие целиком. Из реального примера: топливный корпус на ракету имеет очень сложный высокоточный тех. процесс, если запороть этот корпус на финальной стадии, то чтобы получить новый — придется подождать. Пока его отольют, обработают, протестируют. В процесс вовлечено огромное количество людей и цехов. Если деталь новая, то там вообще пол завода работает (конструкторы, испытатели, инструментальщики, технологи, литейщики). Зависимость между этапами очень высокая.
В софте цикличность и гибкость на порядок выше. Фичу не успеваем — двинем срок, нужно точно в срок — выкинули пару фичей. Постоянно работающих людей над единой частью продукта обычно человек 10 от силы, по факту человек 5-6.
Вся эта беготня вокруг Lean, Aglie, Canban и т.д. сводится к тому, что манагеры/процессно ориентированные граждане, хотят поднять свою важность. Вместо того, чтобы просто договориться как работать и делать дело.
Не следует понимать что я отказываюсь от проектирования, прототипирования, требований и т.д. Но в софте все сильно проще, фича не заработала, в крайнем случае вернули предыдущую версию и все, единица продкта в утиль не идет. В ракете ошибка, которая проводит к падению пораждает очень большой гемморой, потому, что «фарш обратно не провернуть», нельзя откатить на предыдущую версию и успешно запустить ракету, уже все упало и сгорело.
По этому учитесь общаться, договариваться, вырабатывать какие-то процессы взаимодействия и поменьше онанируйте на воплощение теоретического процесса на практике.
Я не понял чему конкретно вы возражаете. Вы говорите, что водопад это что-то из далекого прошлого и практически не применим к текущим реалиям. И я про то же.
Вы говорите, что теория ограничений не применима в разработке, но простите, разве в разработке нет последовательности связанных событий?
Про брак совсем не в тему написали. То что в разработке с браком проще — никто не спорит. Никто ничего по браку не утверждал.
На нюанс надо обратить внимание: тот кто просто договаривается и затем просто работает как договорился оказывается на обочине. Потому что договариваться надо постоянно и постоянно адаптироваться т.к. разработка ПО гораздо более динамичная область нежели производство, скажем, автомобилей, где раз «договорившись», можно 5 лет спокойно работать производя одну и ту же деталь. Но это тоже не по теме статьи.
Что в итоге хотели сказать-то?
Вы говорите, что теория ограничений не применима в разработке, но простите, разве в разработке нет последовательности связанных событий?
Про брак совсем не в тему написали. То что в разработке с браком проще — никто не спорит. Никто ничего по браку не утверждал.
Вместо того, чтобы просто договориться как работать и делать дело
На нюанс надо обратить внимание: тот кто просто договаривается и затем просто работает как договорился оказывается на обочине. Потому что договариваться надо постоянно и постоянно адаптироваться т.к. разработка ПО гораздо более динамичная область нежели производство, скажем, автомобилей, где раз «договорившись», можно 5 лет спокойно работать производя одну и ту же деталь. Но это тоже не по теме статьи.
Что в итоге хотели сказать-то?
Зависимые события и статистические флуктуации или почему «водопад» умретне надо трогать водопад, сравнение с водопадом — друной тон.
Если коротко, то применение/адаптирование заводских процессов производства в IT лютый оверхед.
Вы говорите, что теория ограничений не применима в разработке, но простите, разве в разработке нет последовательности связанных событий?По сравнению с производством — они ничтожны.
Да, похоже, сравнение с водопадом это действительно моветон. Учту.
Кстати, я не предлагал использовать «заводские процессы». Наоборот, вполне такие IT-шные предлагаю использовать.
А вот с ничтожностью проявления теории ограничений совсем не соглашусь. Там где «водопад» живее всех живых, столкнулся с вполне таки катастрофическим проявлением: пол года на сбор требований (тут серьезно просрочили), еще 4 месяца на разработку, еще 3 месяца на внедрение. И есть отличный потенциал для дальнейшего ухудшения ситуации т.к. сейчас все еще идет процесс сбора требований. Есть конечно и плюс — пришло понимание необходимости разрабатывать небольшими кусками.
Кстати, я не предлагал использовать «заводские процессы». Наоборот, вполне такие IT-шные предлагаю использовать.
А вот с ничтожностью проявления теории ограничений совсем не соглашусь. Там где «водопад» живее всех живых, столкнулся с вполне таки катастрофическим проявлением: пол года на сбор требований (тут серьезно просрочили), еще 4 месяца на разработку, еще 3 месяца на внедрение. И есть отличный потенциал для дальнейшего ухудшения ситуации т.к. сейчас все еще идет процесс сбора требований. Есть конечно и плюс — пришло понимание необходимости разрабатывать небольшими кусками.
пол года на сбор требований (тут серьезно просрочили)Тут конечно может все «очень зависеть», но в общем случае за сравнительно небольшой бюджет лучше сделать какой-то готовый кусок функционала.
Прелесть IT в том, что цена ошибки, это время на переделку только этой ошибки, ну и может чего-то рядом с ней. А вот в инженерии не так, простой косяк — губит все изделе и отозвать или обновить версию тоже не очень просто :)
В IT проще что-то сделать, словить кучу шишок, их устранить, чем старательно защищаться от этих шишек.
Если кто-то попробовал поиграть в эту игру — напишите, пожалуйста, за сколько ходов какое количество спичек удалось отправить в релиз.
#!/usr/bin/env python2.7
from random import randint
total_items = 100
players = 10
pools = [total_items] + players * [0]
steps = 0
while pools[-1] < total_items:
steps += 1
for idx in xrange(players):
amount = min(randint(1, 6), pools[idx])
pools[idx+1] += amount
pools[idx] -= amount
print pools
print "Steps: %d" % stepsДля 10 игроков обычно выходит 38-48 шагов.
Ну вот… Такой живописный эпизод хорошей книги так исковеркать, что аж вспоминается анекдот про "мне Мойша напел".
- Начнем с того, что шли они не в шеренгу, а в колонну.
- Кусок с походом полностью вырван из контекста. В оригинальной книге это был один из ключевых моментов изобретения техники "буфер-барабан-веревка". Почему шли, почему это важно, как реагировали дети на предложения — всё это и есть контекст.
- Применять "Цель" впрямую к разработке — достаточно спорно и сложно, это сто раз обсуждено и много лет назад написаны "Цель-3", "Критическая цепь" и "Синдром стога сена". Более того идеи КЦ уже проникли и в PMBoK.
И еще момент. При чтении "Целей" надо понимать, что это очень-очень хороший рекламный материал к консалтингу, обучению Голдратта и к другим более сложным материалам. То, что они хорошо написаны — не отменяет их назначение (в корп. блогах на хабре тоже есть хорошие статьи)
Sign up to leave a comment.
Зависимые события и статистические флуктуации или почему «водопад» умрет