Комментарии 19
Чем большее количество спринтов участвует в подсчете, тем более усредненной и точной будет рассчитанная скорость.
На самом деле нет. Разработка это не как станок, это как футбол. То что ваши спортсмены в прошлом квартале забили 5 мячей и пропустили 2, ровным счетом ни чего не говорит о том, сколько они забьют или пропустят в следующем году. Можно устраивать тотализатор и принимать ставки.
В абстрактно-математическом смысле, расчет статистической вероятности выпадания орла или решки подразумевает, что вы кидаете одну и ту же абстрактную монетку, одним и тем же абстрактнвм способом в одних и тех же абстрактных условиях. Но для реальных данных, будь то ретроспективные, или прогнозируемые - контекст все время разный. Поэтому отклонения будут непременно. Раз так, то ключевой момент здесь это не точность прогнозов, а интерпретация отклонений, с пользой для себя дела. Все что нужно - это внедрить подходящий ментальный фреймворк (ну или миф).
Договорились с ними на оценку по ретроспективе? - отлично! Теперь у вас есть моральное право митинговать риски, делегируя последствия за факапы либо в никуда, либо в внутрь них же самих. Все же верят трем видам лжи статистике? Ну дескать вот раньше все успевали, а тут не успели, видимо не доработали, расслабились - значит сами виноваты. На такие ритуалы и в самом деле нет смысла тратить кучу ресурсов - меньше времени на раздумья, больше времени мячи гонять. Ну, а заказчику регулярно напоминать: estimates are NOT commitment.
Интересная тема, на какой вид спорта похож процесс разработки:)) Думаю, зависит от уровня специалистов в команде. Иногда на наш футбол, где все мало предсказуемо, а иногда на синхронное плавание:) Я согласна, что любые прогнозы - это всегда не 100% вероятность, поэтому жалко тратить время синхронистов на уборку бассейна:)))
поэтому жалко тратить время синхронистов на уборку бассейна:)))
Классная метафора. :) Просто так не бывает. Бывает так, что у вас нет отдельного вечно-бесплатного ресурса ни на уборку, ни на ремонт бассейна. Все сами. Сами все делаем, сами выступаем, сами иногда обделываемся (физиология, пресловутый человеческий фактор) и сами же потом чиним и убираем. Ну или откладываем уборку с починкой в беклог задач за которые нам ни кто ни когда не заплатит. А пока пытаемся производить на публику тот же эффект, делая те же фигуры, но уже в немножко мутной и слегка попахивающей воде, под чуть-чуть протекающей крышей. Публика негодует и отказывается платить. Мы признаем ошибки на ретро и обещаем в следующем спринте показать ещё больше трюков, занырнув вообще на самую глубину)).
Разработка ещё похожа на дженгу, только наоборот: мы строим башню, добавляя кубики разного размера (M, L, XXL, вот это вот все) до тех пор, пока она не развалится. Ну и если на начальных этапах стройка идёт быстро потому, что кубики, даже самые огромные, встают просто на ровный стол, то дальше у них появляются зависимости, когда их приходится ставить уже друг на дружку. Маленькие на большие, большие на маленькие. Хорошо если у всех был четкий план и кубики на нижних ярусах стоят ровно и надёжно. Но нередко бывает, что кто-то поспешил все успеть и поставил свой маленький кубик немножко криво, или не убрал за собой лишнее. Таким образом у новой смены прибавляется немножко работы и эстимации даже для самых простых задач начинают плыть в далёкие края.
А бывают моменты, что очередной точно такой же кубик нужно запихнуть в середину. Ну вот так получилось. То есть для этого надо теперь или пересобрать половину башни, или нагородить каких-то ацких подпорок. И тогда объем работы увеличивается уже не на немножко, а может и ни в какой бюджет.
В общем, я это к чему. Планы ни что, планирование - все. И сокращать на это время - правильно. Но кажущиеся на первый взгляд размеры кубиков это лишь пол беды. Многое зависит от архитектуры и согласованности работы команд. Если пытаться заменить всем этим планированием и проектирование, то вы просто сократите время до катастрофы).
Если требуется оценить выполнение задач одним специалистом, проще применить алгоритм абсолютной оценки: спросить, сколько времени он потратит на решение каждой задачи, и подсчитать сумму.
Как все просто и предсказуемо.
Еще в книге Чистый Agile описывалось, как они оценивали трудоемкость.
Брали первую задачу, она к примеру занимала 3 часа. А потом оценивали сложность задачи относительно первой голосованием. Собирали всю команду и спрашивали во сколько по вашему эта задача тяжелее эталонной (первой). Они на бумажке писали числа и потом их ответы усредняли. По-моему еще откидывали самый маленький результат и самый большой. В итоге получали оценку команды, во сколько данная задача сложнее первой и получали ее трудоемкость.
Похоже на покер планирования! Думаю, если небольшая команда - очень применимо! А на удаленке - особенно!)) Как говорится, совместить приятное общение с полезным процессом оценки) А вы пробовали?
В Essential Kanban есть раздел про прогнозирование, а в красной(синей) книге про канбан метод использование оценок, полученных от экспертов, рассматривается как ненадёжный, подрывающий основы SLA механизм.
Не пробовали опираться на подобные инструменты?
Спасибо за ссылку на книгу! Именно такую не читала, с удовольствием посмотрю)
По поводу вероятностного прозгнозирования - мне оно близко, потому что это объяснимая заказчику математика. Но считаю, что в жизни метод Монте-Карло и пр применимы только если на входе разделять user-story по объему и сложности + собирать данные для похожих user-story + именно на основе этих данных строить вероятностные прогнозы.
Даже в примере из Essential Kanban прогноз звучит как: с 50% вероятностью - 06.05, с 85% вероятностью - 20.05, с 95% вероятностью - 27.06. Разброс дат - 2 месяца, причем, если внимательно посмотреть на график попаданий, то там не 95%, а, скорее, 5%:)
А вот если на входе поделить user-story по размеру и сложности. Например, 1) есть класс user-story, который содержит 1-3 простые понятные задачи 2) есть класс user-story, который содержит 3-10 простые понятные задачи и тд...то для каждого класса user-story диапазон вероятностных дат поставки будет намного уже, при этом он будет таким же правдивым. И так как этот класс надо определять на входе, это снова похоже на относительные оценки - только не задач, а user-story.
Очень интересный вопрос, как раз хочу в него зайти, но не с целью прогнозирования сроков, а поисследовать скорость команды.
Результатами обязательно поделюсь)
Предлагаю перед изучением скорости команды, всё таки сходить к Андерсену в синюю(красную) книгу. Там путёво рассказано, как всё таки мерить пропускную способность команды. Эта метрика покажет как следить за скоростью и прогнозировать.
Эту книгу я как раз читала) Интересно, а в работу вашей команде все user-story одинакового размера поступают? Так бывает?)
Считаю, если пропускную способность оторвать от размера и сложности задач, На графике увидеть ускорение или замедление не получится. В один период реализовано 4 объемных user-story, в следующий - 4 мелкие, а остальное время команда учились, например. Вот на графике без привязки к размеру и в том, и в другом случае будет 4 user-story.
Спасибо за ваши комментарии!
Хороший подход к оценкам, интересно увидеть продолжение, как на основе этих оценок рождаются сроки и как несколько сторей вводятся на ПРОД
Кажется вы забыли сделать финальное упраженение - сравнить фактическое выполнение ваших задач с изначально оценённым. На моей практике задачи, изначально оценённые командой в М по факту часто оказываются S, L или даже XL. Понимание частотности этих отклонений и их причин позволит вам оперировать не одним сроком, в который легко не попасть, а комбинацией оптимистичного/реалистичного и пессимистичного срока.
Для тех, кто посматривает на относительные оценки, но не решается их внедрить