Как можно измерить (оценить) выгоду от перехода с Waterfall на SCRUM?

Question

[IndexIsOutOfRange]

В нашей компании вся разработка ведется по классическому Waterfall - проектные команды, диаграммы Ганта, оценка задач в человекоднях, документация перед стартом девелопмента и т.д. и т.п. Задач множество, каких-то типовых нет. Есть сильное желание перевести разработку на SCRUM, для чего запускаем пилотный проект на данном фреймворке, для пробы как пойдет. Нужно понять, как мы сможем оценить результат и презентовать менеджменту. Менеджмент организации согласует переход всей разработки на SCRUM, только после того , как мы сможем на цифрах показать выгоду - сокращение затрат, за счет увеличения скорости разработки или чего то еще. Важный момент - сделать это нужно обязательно в сравнении с существующим на данный момент процессом. Вот как это сделать, не совсем понятно - что и как измерять? Буду признателен, если кто сможет поделиться опытом или подскажет что почитать.

Answer 1

[⚡ Kotobotov ⚡]

>Задач множество, каких-то типовых нет.
если задачи уникальные, то все ваши планы по разработке - очковтирательство.

>переход всей разработки на SCRUM, только после того , как мы сможем на цифрах показать выгоду
ваше мышление еще не готово переходить на гибкие методологии.
Многие вещи в цифрах не считаются.
Вам предлагают посчитать в цифрах следующее: идти в магазин ориентируясь на местности или идти в магазин с закрытыми глазами по карте которую вы нарисовали у себя дома, при этом вы никогда не ходили до этого в магазин и вообще не знаете есть ли он там.
По плану и там и там одинаково эффективно вы должны дойти, а в реальности с закрытыми глазами вас через 15 минут пути машина собьет, или вы просто шею сломаете зайдя не туда.
========
Суть в том чтоб за 2 года запланированной разработки, не прийти в помойную яму вместо магазина.
Попытаться все спланировать и посчитать итог работ - это опять из ватерфола, вы живете в недетерминированном мире в котором вы НЕ можете все вокруг посчитать и проконтролировать, вы либо это принимаете и начинаете по другому мыслить и действовать (на основе обратной связи) , либо дальше занимаетесь очковтирательством.
П. С.
бизнес не любит неопределенности, любят гарантии и точные ответы - поэтому заказчик будет все равно ТРЕБОВАТЬ чтоб ему в очки втирали дичь, по поводу обьемов работ и сроков, это основная проблема внедрения гибких методологий, привычка и не желание людей по другому мыслить.

Comments

[IndexIsOutOfRange]

> если задачи уникальные, то все ваши планы по разработке - очковтирательство.

Мы с нашими очковтирательскими планами много лет успешно работаем и успешно завершили десятки проектов.

Вот за что я не люблю российские форумы, вместо нормальных ответов, какой-то поток сознания. Я прекрасно знаю как работает SCRUM, Сазерленда могу сам наизусть цитировать и сам же мог прекрасно рассказывать про идеологию, лежащую за ним, про то что нужно изменить сознание и пр. Вопрос был про то, как продать идею менеджменту, которому нужно на цифрах показать, что стало лучше. Еще раз - идеологию продать не удастся, многие годы успешно пользуем waterfall, нужно будет после пилота показать в чем профит (да и для самих себя убедиться, что он таки есть). А то бывают и вот такие мнения - https://medium.com/@ard_adam/why-scrum-is-the-wron...

[⚡ Kotobotov ⚡]

IndexIsOutOfRange,
на вопрос: Как продать "отказ от долгосрочного планирования", на основе оценок из долгосрочного планирования?
нормальный ответ: Никак.
=====
Если вы успешно с ватерфолом работаете (с ваших же слов), то о чем ВООБЩЕ РЕЧЬ? зачем вообще вам это все?
поражаюсь что за люди пошли, хочу то сам не знаю что и вообще зачем, но убедите меня и моих клиентов в том что мне это надо.

[IndexIsOutOfRange]

⚡Дима Кубитский ⚡, меня убеждать не нужно. И зачем мне это я знаю. Еще раз - задача - продать идею менеджменту. Без обоснования измеримого профита это не получится. То что мы сейчас успешно работаем, не означает что мы не можем работать еще более успешно.

[⚡ Kotobotov ⚡]

IndexIsOutOfRange, вы правда считаете что кому-то из управляющих у которых есть налаженный рабочий бизнес, у которых все успешно и без гимороя работает - можно продать тему типа "а давайте теперь ВСЕ ПЕРЕДЕЛАЕМ", возьмем на себя риск развалить бизнес, за то чтоб бы у нас МОЖЕТ БЫТЬ что-то стало еще более успешным?

Только под угрозой страха, и необходимостью выживания на рынке можно заставить изменить схемы работы (и это должно быть очевидно для управляющих). Просто так пытаться выводить людей из зоны комфорта, за какие-то эфимерные улучшения черевато только одним -> все ваши улучшения будут саботировать, а затем и вас и всех кто вас поддержит просто выдавят из этой компании.
П. С.
Все эти ваши "рассчитать измеряемый профит на калькуляторе" никого не интересуют, решения так не принимаются, решение или принимается и ПОТОМ под него подгоняется эта калькуляция, или не принимается, а просьба сделать калькуляцию, лишь способ уже вам очки втирать успешно саботируя это решение, тоесть ваше предложение уже отвергли, можете расслабиться.
Вот когда у вас изза ватерфола случится полная жопа в работе, тогда возвращайтесь к этому предложению, не надо впереди паровоза бежать

[IndexIsOutOfRange]

⚡Дима Кубитский ⚡, вот, уже ближе. Но домысливать за меня всякое, в том числе и что я считаю, не нужно, спасибо. Во-первых - никакого риска развалить бизнес нет, для тестирования запускается отдельный стрим разработки по scrum, остальное все в это время будет разрабатываться другими людьми ровно также, как и до этого. Еще раз - задач много, проектов - много. Во-вторых, цель как раз понять - будут ли реальные улучшения или эфемерные (то есть, их не будет). Т.е., при условии что мы получим нужный нам результат используя scrum, нужно понять - что мы собственно выиграли и выиграли ли что то вообще - сократили ли мы costs или duration, можем ли мы теперь поставлять больше меньшими затратами. В третьих - не нужно придумывать кто кого и куда вышвырнет, если у вас был подобный опыт, не стоит его реплицировать на всех.

[⚡ Kotobotov ⚡]

IndexIsOutOfRange, вы на калькуляторе разницы не увидите.
С обоими подходами - ОДИНАКОВЫЕ обьемы работ по времени (например несколько месяцев работ одними и темеже разработчиками), в обоих подходах себестоимость работ одинаковая.
Только в одном случае результатом будет считаться хотя бы формальное выполнение ТЗ, в другом случае будет сделан больше упор на обратную связь и корректировку задач.

Answer 2

[Владимир]

Когда работает скрам -
1) Ранняя выкатка прототипа (MVP)
2) Частые релизы (частенько спринт длится две недели и в конце - релиз) - это дает возможность рано получить фидбек и прекратить разработку ненужных фич, или быстро изменить направление, если требования для фичи поменялись.
3) За счет двух недельного пульса, разработчики могут меньше стрессовать и эффективнее работать, но это индивидуально.

Посмотрите и посчитайте выкидывали ли в корзину работу изза измененных требований, факапили сроки изза этого или нет, какое было влияние на смежные команды, и сможете определить профит.

Иногда до выкатки Пруф оф Концепт, тяжело определиться, что выкатывать в релиз, и тогда на первом этапе Скрам заменяют на Канбан.

Answer 3

[Василий Мажекин]

Сначала наймите или обучите своего профессионального скрам-мастера. Без него вы вряд ли получите выгоду. Обрывочные знания в скраме и отсутствие человека его хорошо знающего, только усугубят проблемы. Если вы задаете такой вопрос, то скорее всего такого человека у вас нет, и ваш скрам усохнет и ограничится формально лишь доской спринта и ежедневными перекличками, эффективного управления там даже близко не будет.

Скрам - это сфера гораздо сложнее чем программирование, там несколько уровней сертификации https://www.scrum.org/.

Я бы провел аналогию так, программирование - это шахматы - игра с полной информацией, от вас требуется база знаний по предмету и логика.
То скрам - это покер - игра с неполной информацией, где к знаниям по предмету и логике еще добавятся теория вероятностей и психология.