Комментарии 16
На это исследование ссылается автор статьи в РБК 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 теперь, оказывается -- работа даже без попытки заранее понять, что мы делаем.
Если спецификацию написать можно -- её надо писать, это очевидно. Если нельзя, надо хоть что-то всё-таки написать, чтобы ну хоть какие-то вещи были продуманы заранее.
Понятно, что Agile -- это группа методологий, ориентированных на работу в изменчивом окружении. Писать полную и детальную спецификацию до работ часто нет смысла. Но если горе-практики поняли это как "тогда мы вообще не будем думать заранее, всё сделаем по месту", то шансов на провал у проекта очень много. Именно из-за таких практиков и формируется подобная прекрасная статистика.
Никогда Agile не запрещал писать спецификации (да, статус спецификации другой -- это не закон, а что-то, что легко можно поменять, в то время как в более старых подходах это бумага, вокруг которой будет идти торг — сделано/не сделано). Agile -- это не хаотическая разработка. И если кто-то подумал, что это способ не продумывать ничего заранее, то так ему и надо. Чем лучше поставлена задача, тем больше шансов на успех, и это не зависит от методологии, это общее правило.
Можно не хотеть расписывать какие-то детали до того, как пощупаешь первый прототип. Но одно дело -- не расписывать "какие-то детали", для которых пока нет видения, а другое -- "ничего продумывать не будем, там разберёмся".
И если хоть каких-то вменяемых описаний желаемого нет (ну, кроме разве что проектов по багфиксингу, там есть баги, есть представления об их срочности и прикидочной трудоемкости -- иди и чини примерно в нужном порядке), это не Agile. Это бардак. Правда, нынче модно называть любой бардак Agile'ом, за что и расплачиваемся.
Исследование показало, Agile-проекты проваливаются на 268% чаще