Комментарии 23
Вот только пункт 5 вашего плана надо развернуть в еще одну итеративную схему с условием «Удовлетворяет ли созданная система заданным требованиям?»
+1
В моем понимании «до завершения подзадач» означает, что то, что было реализовано практически полностью соответствует спецификациям (иначе зачем мы их писали?). Пока есть значительные отклонения — считаем пункт 5 не завершенным. А вот уже после него действительно может возникнуть вопрос «удовлетворяет ли созданное современным реалиям и требованиям рынка» и придется решать, актуален ли в принципе переход к пункту 1. Чтобы не понести в случае выявления неактуальности серьезных потерь итерации нужно делать как можно меньшими по объему работ, но при этом, чтобы избежать неполноценности в рамках одной итерации, они должны быть максимально концептуально целостными.
+1
Не совсем понимаю чем ваш процесс отличается от Rational Unified Process кроме как используемой терминологией и тем, что на первом шаге уже не идея, а определённая задача, на решению которой было дано добро.
+4
цикл вышел бесконечный. А если все таки какая либо подзадача не реализуемая в силу объективных причин?
и второе — практика разработки показывает, что кривая процесса разработки похожа функцию y=arctan(x), которая показывает, что при x (которое есть время) стремящееся к бесконечности не получит 100% качество продукта.
(переход через x=0 — это качественный скачек от альфа к бета версии продукта)
суть графика заключается в том, что 70-80% продукта делается в очень короткий интервал времени. все остальное время занимает:
a) подготовка к качественному скачку = итерации разработки;
б) подготовка к релизу = итерации доработки.
Вывод из этого всегда прискорбный: сколько продукт не вылизывай, он скорее устареет, чем выловишь все потенциальные ошибки.
поэтому, на мой взгляд, в алгоритме касательно пунктов 5-6 нужно ввести проверку на предмет числа проведенных итерации.
и второе — практика разработки показывает, что кривая процесса разработки похожа функцию y=arctan(x), которая показывает, что при x (которое есть время) стремящееся к бесконечности не получит 100% качество продукта.
(переход через x=0 — это качественный скачек от альфа к бета версии продукта)
суть графика заключается в том, что 70-80% продукта делается в очень короткий интервал времени. все остальное время занимает:
a) подготовка к качественному скачку = итерации разработки;
б) подготовка к релизу = итерации доработки.
Вывод из этого всегда прискорбный: сколько продукт не вылизывай, он скорее устареет, чем выловишь все потенциальные ошибки.
поэтому, на мой взгляд, в алгоритме касательно пунктов 5-6 нужно ввести проверку на предмет числа проведенных итерации.
+2
Скорее не числа итераций, а некоторого порогового значения изменений требований, на которые можно закрыть глаза и запустить проект.
P.S. Закон Парето никто не отменял.
P.S. Закон Парето никто не отменял.
+1
Когда я впервые услышал о ТРИЗ, у меня прямо сердце учащенно забилось. Как оказалось напрасно…
0
Почему напрасно?
Понятно, что опыт, интуиция и креативность незаменимы, но чем плох, к примеру, АРИЗ как алгоритм?
Понятно, что опыт, интуиция и креативность незаменимы, но чем плох, к примеру, АРИЗ как алгоритм?
+2
ТРИЗ лично для меня оказалась неподъемной. Возможно пока неподъемной. Слишком много аббревиатур… А чтобы начать ей пользоваться — сначала придется решить задачу, формулируемую как «Научиться применять ТРИЗ» =) По мне, так сначала нужно построить пару своих велосипедов, обкатать их, чем сразу садиться за руль тяжеловесного профессионального болида.
+2
Вашу статью, на мой взгляд, корректнее сравнивать с АРИЗ.
Суть вкратце: направленными вопросами решение изобретательской задачи сводится к решению физического противоречия (одного или нескольких) + даются пути/советы по решению физического противоречия.
Поясняющая схема
Суть вкратце: направленными вопросами решение изобретательской задачи сводится к решению физического противоречия (одного или нескольких) + даются пути/советы по решению физического противоречия.
Поясняющая схема
+1
Хороший алгоритм для демонстрации алгоритмов при их узучении. Но никакой практической пользы. За использование LibreOffice/OpenOffice.org — 5. За изобретение… за наглядное пособие по алгоритмам тоже 5.
+1
Скажите, а у вас техническое образование?
0
… И даже успешно оконченное.
0
Я к тому, что вообще в технических вузах обычно на всех инженерных специальностях (даже программистам) рассказывают, что такое «жизненный цикл изделия» и всякие связанные с ним вещи, и что на все это даже существуют госты.
В свете этого ваша статья — трехколесный велосипед.
В свете этого ваша статья — трехколесный велосипед.
0
Не могли бы Вы немного развить свою мысль, а то я не совсем понимаю, как связаны между собой жизненный цикл «изделия» и подход к созданию этого изделия? Сия статья описывает некоторый психологический костыль, помогающий решать технические задачи, а не методологию создания «изделий» (пользуясь Вашей терминологией).
0
Проблема в том, что вы описываете именно методологию (правильный порядок действий, в том числе и для преодоления психологических тормозов), а она уже описана и многократна проверена в действии, и у вас нет ничего нового.
А вот подход, некий тип мышления, точки соприкосновения с задачей — это как раз, как уже писали в комментариях выше, тот самый ТРИЗ, например.
А вот подход, некий тип мышления, точки соприкосновения с задачей — это как раз, как уже писали в комментариях выше, тот самый ТРИЗ, например.
0
Про то, что я не претендую на оригинальность, я указал в тексте топика. Мой метод (методология — слишком сильное слово) родился на практике и не претендует на строгую научность, в отличие от ТРИЗ. Но при этом он более прост в восприятии, и мне бы хотелось надеяться, что он сэкономит время начинающим разработчикам.
0
Warning: Variable «времени суток» is undefined in the reader's head on line 2.
+1
итеративный подход в реальной жизни:
![image](https://habrastorage.org/r/w1560/getpro/megamozg/comment_images/05a/72a/eee/05a72aeee235f12581a51bab18ecab56.png)
![image](https://habrastorage.org/getpro/megamozg/comment_images/05a/72a/eee/05a72aeee235f12581a51bab18ecab56.png)
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Итеративный подход к решению инженерных задач