Comments 15
На это исследование ссылается автор статьи в РБК PRO "Стыд и скрам. Почему компании массово отказываются от хваленого эджайла"
Я пошел в первоисточник и решил перевести это "исследование". На мой взгляд, его выводы выеденного яйца не стоят.
Сегодня или завтра опубликую ещё пару постов с переводом критики первоначального исследования и собственными заметками относительно опуса в РБК.
Спойлер: учёный изнасиловал журналиста.
Однако новое исследование показало, что проекты, в которых перед началом разработки были определены спецификации или задокументированы требования, имели на 50 % больше шансов на успех, чем проекты, в которых этого не было, проекты, в которых перед началом разработки были четко определены требования, имели на 97 % больше шансов на успех, а проекты, в которых не требовалось вносить существенные изменения в требования на поздних этапах разработки, имели на 7 % больше шансов на успех.
Ну и дела, кто бы мог подумать...
Один только нюанс: сначала появились заказчики, у которых 7 пятниц на неделе, а потом появились гибкие методологии, чтобы с этим хоть как-то работать.
А проекты, в которых используется подход "Impact Engineering", описанный в книге, изданной сегодня, завершаются неудачей только в 10% случаев.
Предполагается дать ее почитать заказчикам, чтобы они перестали быть мудаками? Или она достаточно увесистая, чтобы дать леща?
Тут ещё такой момент что конкуренция на рынке никуда не денется. И если все заказчики вдруг перестанут быть мудаками и все команды станут работать с этим вот "Impact Engineering", то количество проваленных проектов особо не изменится.
Всё так, только у кого деньги тот девушку и танцует.
Думаю, авторы книги просто решили ее прорекламировать таким образом
Думаю, это ошибка выжившего. Давайте подождём 30 лет, чтобы в Impact Engineering даже в последней деревне начали пытаться - и потом сравним цифры. Пока что это как утверждать, что новая модель машины ломается реже старой. Хотя старой версии выпущено сто тыщ мильонов и у них такой же проблем, а новые тачки ещё даже до конца гарантии не дошли.
Подозреваю, дело в том, что такой подход применим только для проектов, где на протяжении реализации ничего не меняется: ни технологии, ни рынок, ни сам бизнес заказчика. Наверное, там и заказчики себя по-другому ведут.
И да, в такой среде в сроки попасть должно быть проще, чем с каким-нибудь интернет-магазином, где всё бурлит и надо рисовать семь красных линий. Может быть, тут и методологии ни при чём окажутся
В первые вижу настолько странную рекламу новой книги.
На это исследование ссылается автор статьи в РБК PRO "Стыд и скрам. Почему компании массово отказываются от хваленого эджайла"
Я пошел в первоисточник и решил перевести это "исследование". На мой взгляд, его выводы выеденного яйца не стоят.
Сегодня или завтра опубликую ещё пару постов с переводом критики первоначального исследования и собственными заметками относительно опуса в РБК.
Спойлер: учёный изнасиловал журналиста.
Вопрос ещё насколько честно все оценивают внедрён ли в проект Agile. Ибо Agile это про гибкую разработку, а не про гибкое внесение изменений в требований вплоть до последнего дня спринта. Многие понимают Agile именно так, но сама методология этого не предусматривает.
Три из четырех принципов, перечисленных в Agile-манифесте, – это «Работающий продукт важнее исчерпывающей документации», «Сотрудничество с заказчиком важнее согласования условий контракта» и «Готовность к изменениям важнее следования первоначальному плану». Однако новое исследование показало, что проекты, в которых перед началом разработки были определены спецификации или задокументированы требования, имели на 50 % больше шансов на успех, чем проекты, в которых этого не было, проекты, в которых перед началом разработки были четко определены требования, имели на 97 % больше шансов на успех, а проекты, в которых не требовалось вносить существенные изменения в требования на поздних этапах разработки, имели на 7 % больше шансов на успех.
Здесь про приоритеты, но это не значит, что в Agile нет требований или что ими можно вертеть как хочешь. Их можно менять, изменять приоритеты в разработке продукта, но делать это нужно разумно.
Просто сначала проекты не следуют методологии, а потом удивляются почему всё плохо.
>проекты, в которых применяются методы Agile Manifesto
Я думал проекты делают при помощи PMBOK'a. В принципе можно было дальше не читать- очередное агенство придумало свою серебрянную пулю и заказало ангажированное иследование чтобы эту пулю продать.
Есть такая "Модель Кеневин", которая позволяет исходя из вашей системы выбрать фреймворк. Фреймворки Agile в основном применяются для ПРОДУКТОВОЙ разработки, где у вас есть клиенты и много неопределенностей.
И если вы условно натягиваете Скрам на типичный enterprise проект- то не над удивляться, что что-то не работает. Не нужно забивать гвозди микроскопом и ныть что неудобно.
Так что в следующий раз, когда увидите в одном предложении слова "Проект" и "Agile/Scrum/Kanban" - плюньте в автора.
"мы стартовали 3 проекта по новой технологии и два успешны. А 100500 проектов по эджайлу как шли по своему среднему проценту стартов/стопов, так и идут. Покупайте книгу о 100% успехе для всех проектов!"
УЧЕНЫЕ выяснили, охотники, использующие ружье и капкан получают травмы чаще, чем охотники, использующие сачок. На медведя с сачком иди, или все таки неизвестные переменные забыли исключить?
Исследование показало, Agile-проекты проваливаются на 268% чаще