Здравствуйте, Pauel, Вы писали:


P>Вот например маленький ресёрч который я делал, длился полгода — закончился тем, что все варианты решения были забракованы. Не сильно ясно, чем здесь помогает скрам.

И, следовательно, скрам не нужен вообще от слова совсем, да?

P>Еще один ресёрч длился два года, и в самом конце я подвис на месяц или два, чуть не поседел. Ну есть у меня подзадачи "написать чтонибудь еще" и "собрать статистику", а дальше то что?

А дальше то, что в любом исследовательском проекте, которым является в том числе разработка нового ПО, нужно в первую очередь идентифицировать и оценить главные риски, которые могут помешать, усложнить, или вообще сделать реализацию невозможной или непрактичной. Бессмысленно проводить бесчисленные совещания о расположении кнопок на пользовательском интерфейсе, если неизвестно, существует ли в принципе подход или алгоритм, который позволит решить задачу.
Вот это и нужно помещать самые первые спринты. Затем, по результатам, принимать решение. Нашли идеальное решение — превосходно, нашли решение, которое работает, но с ограничениями — пингуем проджект овнера и ждем ответа. Напоролись на физическое ограничение, ну что ж, как говорят теоретические физики, "гребаная гравитация".

Ну и в конце такого проекта подвиснуть можно только на деталях. Лечится переключением на другие задачи.

P>С приложением все иначе — сходимость прогозов и результатов рано или позно обеспечивается. А вот с исследованием это не так.

P>Результат по проекту он аддитивный.

Нет.

P>Даже если вы пишете плохо, то все равно доберётесь до конца.

Нет.

Верхние два утверждения лежат в основе водопада, который, как известно, в разработке ПО не работает.

P>По исследованию это мягко говоря не так.

Разработка ПО — это исследовательская деятельность.

Здравствуйте, Pauel, Вы писали:


P>Вот например маленький ресёрч который я делал, длился полгода — закончился тем, что все варианты решения были забракованы. Не сильно ясно, чем здесь помогает скрам.

И, следовательно, скрам не нужен вообще от слова совсем, да?

P>Еще один ресёрч длился два года, и в самом конце я подвис на месяц или два, чуть не поседел. Ну есть у меня подзадачи "написать чтонибудь еще" и "собрать статистику", а дальше то что?

А дальше то, что в любом исследовательском проекте, которым является в том числе разработка нового ПО, нужно в первую очередь идентифицировать и оценить главные риски, которые могут помешать, усложнить, или вообще сделать реализацию невозможной или непрактичной. Бессмысленно проводить бесчисленные совещания о расположении кнопок на пользовательском интерфейсе, если неизвестно, существует ли в принципе подход или алгоритм, который позволит решить задачу.
Вот это и нужно помещать самые первые спринты. Затем, по результатам, принимать решение. Быстро вышли на идеальное решение — превосходно, нашли решение, которое работает, но с ограничениями — пингуем проджект овнера и ждем ответа. Напоролись на принципиальное или физическое ограничение, ну что ж, как говорят теоретические физики из одного анекдота, "гребаная гравитация".

Ну и в конце такого проекта подвиснуть можно только на деталях. Лечится переключением на другие задачи.

P>С приложением все иначе — сходимость прогозов и результатов рано или позно обеспечивается. А вот с исследованием это не так.

P>Результат по проекту он аддитивный.

Нет.

P>Даже если вы пишете плохо, то все равно доберётесь до конца.

Нет.

Верхние два утверждения лежат в основе водопада, который, как известно, в разработке ПО не работает.

P>По исследованию это мягко говоря не так.

Разработка ПО — это исследовательская деятельность.