Pull to refresh

Comments 23

Вот только пункт 5 вашего плана надо развернуть в еще одну итеративную схему с условием «Удовлетворяет ли созданная система заданным требованиям?»
В моем понимании «до завершения подзадач» означает, что то, что было реализовано практически полностью соответствует спецификациям (иначе зачем мы их писали?). Пока есть значительные отклонения — считаем пункт 5 не завершенным. А вот уже после него действительно может возникнуть вопрос «удовлетворяет ли созданное современным реалиям и требованиям рынка» и придется решать, актуален ли в принципе переход к пункту 1. Чтобы не понести в случае выявления неактуальности серьезных потерь итерации нужно делать как можно меньшими по объему работ, но при этом, чтобы избежать неполноценности в рамках одной итерации, они должны быть максимально концептуально целостными.
Не совсем понимаю чем ваш процесс отличается от Rational Unified Process кроме как используемой терминологией и тем, что на первом шаге уже не идея, а определённая задача, на решению которой было дано добро.
Ну вот, моя корыстная цель написания этого топика достигнута — Вы подсказали мне название метода, чтобы я мог почитать о нем у профессионалов =)
цикл вышел бесконечный. А если все таки какая либо подзадача не реализуемая в силу объективных причин?

и второе — практика разработки показывает, что кривая процесса разработки похожа функцию y=arctan(x), которая показывает, что при x (которое есть время) стремящееся к бесконечности не получит 100% качество продукта.
(переход через x=0 — это качественный скачек от альфа к бета версии продукта)

суть графика заключается в том, что 70-80% продукта делается в очень короткий интервал времени. все остальное время занимает:
a) подготовка к качественному скачку = итерации разработки;
б) подготовка к релизу = итерации доработки.

Вывод из этого всегда прискорбный: сколько продукт не вылизывай, он скорее устареет, чем выловишь все потенциальные ошибки.

поэтому, на мой взгляд, в алгоритме касательно пунктов 5-6 нужно ввести проверку на предмет числа проведенных итерации.

Скорее не числа итераций, а некоторого порогового значения изменений требований, на которые можно закрыть глаза и запустить проект.

P.S. Закон Парето никто не отменял.
возможно, главное чтобы не было вечного цикла (как у Шелдона в алгоритме из книжки «Как подружится»).

Да, я именно про этот закон и имел ввиду. Позабыл, как звали автора. Спасибо что напомнили.
В статье касающейся решения инженерных задач, imho, должны прозвучать следующие аббревиатуры: ТРИЗ (Теория Решения Изобретательских Задач), АРИЗ (Алгоритм Решения Изобретательских Задач)
Когда я впервые услышал о ТРИЗ, у меня прямо сердце учащенно забилось. Как оказалось напрасно…
Почему напрасно?
Понятно, что опыт, интуиция и креативность незаменимы, но чем плох, к примеру, АРИЗ как алгоритм?
ТРИЗ лично для меня оказалась неподъемной. Возможно пока неподъемной. Слишком много аббревиатур… А чтобы начать ей пользоваться — сначала придется решить задачу, формулируемую как «Научиться применять ТРИЗ» =) По мне, так сначала нужно построить пару своих велосипедов, обкатать их, чем сразу садиться за руль тяжеловесного профессионального болида.
Вашу статью, на мой взгляд, корректнее сравнивать с АРИЗ.
Суть вкратце: направленными вопросами решение изобретательской задачи сводится к решению физического противоречия (одного или нескольких) + даются пути/советы по решению физического противоречия.
Поясняющая схема
Однако, знакомая схема… Ну что ж, получается, что я был близок к истине в своих догадках. Спасибо, что ткнули носом, что теперь нужно курить.
Хороший алгоритм для демонстрации алгоритмов при их узучении. Но никакой практической пользы. За использование LibreOffice/OpenOffice.org — 5. За изобретение… за наглядное пособие по алгоритмам тоже 5.
Скажите, а у вас техническое образование?
… И даже успешно оконченное.
Я к тому, что вообще в технических вузах обычно на всех инженерных специальностях (даже программистам) рассказывают, что такое «жизненный цикл изделия» и всякие связанные с ним вещи, и что на все это даже существуют госты.

В свете этого ваша статья — трехколесный велосипед.
Не могли бы Вы немного развить свою мысль, а то я не совсем понимаю, как связаны между собой жизненный цикл «изделия» и подход к созданию этого изделия? Сия статья описывает некоторый психологический костыль, помогающий решать технические задачи, а не методологию создания «изделий» (пользуясь Вашей терминологией).
Проблема в том, что вы описываете именно методологию (правильный порядок действий, в том числе и для преодоления психологических тормозов), а она уже описана и многократна проверена в действии, и у вас нет ничего нового.

А вот подход, некий тип мышления, точки соприкосновения с задачей — это как раз, как уже писали в комментариях выше, тот самый ТРИЗ, например.
Про то, что я не претендую на оригинальность, я указал в тексте топика. Мой метод (методология — слишком сильное слово) родился на практике и не претендует на строгую научность, в отличие от ТРИЗ. Но при этом он более прост в восприятии, и мне бы хотелось надеяться, что он сэкономит время начинающим разработчикам.
Warning: Variable «времени суток» is undefined in the reader's head on line 2.
Sign up to leave a comment.

Articles