Не мучайтесь сами и не мучайтесь команду. Откажитесь от спринтов, они, в том виде как вы их используете, не несут вам пользы. Ну или изучите скрам, сходите на тренинг и наладьте процесс со спринтами.
Нет смысла засчитывать часть задачи в выполненные sp, вы таким образом лишает себя возможности корректно определить ёмкость спринта. В велосити засчитываются только завершенные задачи. Незаконченные возвращаются в бэклог и проходят цикл оценки и планирования по новой.
Успешный спринт это не когда все задачи завершены, а когда достигнута цель спринта и есть готовый к поставке инкремент.
Спринт это командная работа, если разработчик утащил задачку в норку и там её в одиночку грызёт, если у вас внутри задачи микроводопад, с последовательно анализом, разработкой, тестированием, вы что-то делаете не правильно. Если у вас большинство задач планируются к завершению в конце спринта, неудивительно, что часто не успеваете. Вы описываете причины, по которым не успеваете. Но скрам предлагает решения этих проблем. И это не те, которые описываете вы.
У вас не работает одна из вырванных из скрама практик. Ровно потому, что все остальные остались за бортом.
Друзья, описываемые вами проблемы не от того, что "скрам, канбан и другие", а от того, что вы не понимаете и не знаете не первого, не второго не другого. Большая часть ваших "решений" проистекает оттуда же и ничего не решает.
Такое количество абсолютно неверных утверждений даже не позволяет ответить конструктивно, объём ответа будет сравним со статьёй.
Абсолютной точности не достичь, конечно, но приемлимая вполне достижима. Как минимум, методом Монте Карло можно получить дату, раньше которой точно не надо ждать завершения. Волшебным образом она чаще всего гораздо позже, чем хотелось бы.
Хаосрепорт такой как раз потому, что люди пытаются угадать будущее, а не спрогнозировать на основе знаний о прошлом. Было бы меньше фантазий, больше расчётов, глядишь, и репорт был бы другим.
Ну и конечно, никак не спрогнозировать в сложном домене, когда мы не знаем предстоящего объёма работ.
методу на вход надо давать некоторые числовые значения, которые как-то характеризуют разимер и сложность задачи
Нет, не надо. Практика показывает, что никакой корреляции между размером/сложностью и сроками завершения нет. Ладно, иногда слабая корреляция есть, у очень продвинутых команд с хорошо стабилизированным процессом. Эти выводы мы делаем на основании большого массива накопленных данных.
Как раз имеют, причем связь обычно близка к линейной
Данные покажете? Мы то собирали и проверяли эту корреляцию. (Не мы одни, конечно).
В случае, если команда бежит спринтами, вообще все сводится чуть ли не к тупой формуле , в которую входят:
производительности команды за спринт
обьем бэклога
Ой, вы описали подход, лежащий в основе метода, только упустили, что производительность команды за спринт не константа, она "плавает". И метод Монте Карло это как раз позволяет учесть и дать вероятности того или иного исхода. Справедливости ради, для очень многих случаев точность такого прогноза не сильно отличается от МК.
На практике, даже с учётом нестабильности, метод зачастую оказывается не хуже, чем экспертные прогнозы. При этом на порядки дешевле по трудозатратам.
В худшем случае, он даёт оценку снизу, "раньше чем Ч не сделаем точно", что уже очень ценный результат, позволяющий запустить полезные дискуссии о скоупе работ, ресурсах и, таки, сроках.
А где вы смотрели результаты? Они таки есть. И у Дорофеева и у других.
Во-первых, Дорофеев описывал не Монте-Карло, а более простой способ расчёта, тоже на исторических данных, но без учёта распределения. И даже он даёт достаточно неплохие результаты.
Вы что-то путаете. Метод Монте-Карло не даёт никаких оценок ни в каких попугаях. Он отвечает на один из двух вопросов: а) с какой вероятностью к какой дате будут сделаны вот эти N задач?
б) Сколько и с какой вероятность задач мы сделаем за период?
Ни в одном из этих случаев попугаи не фигурируют. Тратить время на попытки экспертно предсказать будущее тоже не нужно.
Если у вас эксперты хорошо умеют давать такие предсказания и трудозатраты на этот процесс вас устраивает, вам не нужен Монте-Карло, смело проходите мимо. Но почему-то в подавляющем большинстве случаев оценки попугаев, да хоть трудозатрат в человеко-часах, не имеют никакой корреляции с длительностью работы и, соответственно, на вопрос "Когда?" ответить не помогают. Хотите проверим на ваших данных? :)
Для применения метода Монте-Карло не нужны оценки длительности отдельных задач.
Конечно, применять его лучше для той же команды, для которой у нас есть данные.
Всё, что вы описали, расчёт назад от "когда надо", расстановка и контроль промежуточных точек, имеет место, конечно. Но разве это отменяет другие методы?
В чём посыл вашего комментария? Метод не рабочий? Это не так. Метод не надо применять? Не применяйте. Для нас он работает и результат лучше, чем экспертные оценки "да, вот это мы сделаем тогда-то". Что их не отменяет, но методом они прекрасно проверяются на адекватность.
Я не понимаю только одного — а зачем в компании с такой культурой работать? При существующем дефиците на программистов, не должно быть проблемой найти нормальное место. При должной квалификации инженера, конечно.
Не совсем так, никаких не несущих ценности работ в проекте нет, конечно.
Здесь речь о том, что отслеживать метрики и здоровье проекта имеет смысл на уровне того, что в методе называют customer recognizable work items, а не технических задач в командах. CFD в таком случае показывает именно здоровье проекта, в отличие от CFD на уровне задач, которая, конечно, показывает поток, только пользы в нём гораздо меньше. И хорошая СFD на уровне технических задач команды очень мало говорит о здоровье поставки ценности клиенту сервиса.
Оптимизация на уровне команды, отдельных задач, это локальная оптимизация. А Канбан-метод (и не только он) учит нас, что локальная оптимизация чаще всего не приносит пользы для цепочки поставки ценности. Канбан систему имеет смысл строить end2end и смотреть на систему и поток в целом.
Видео хорошее для общего понимания. Чтобы научиться видеть паттерны на диаграмме, придётся потренироваться.
подход с двумя досками, который вы описываете, в методе называется «двухуровневая визуализация». Может быть полезной, но с ней довольно тяжело работать, в большинстве инструментов синхронизировать придётся вручную.
В слаке можно настроить автоответ на ключевые слова. Но, кажется, не получится его научить просто «Привет» от «Привет, <тут содержательная часть>». Возможно, можно написать бота. Нам, пожалуй, не актуально.
Не мучайтесь сами и не мучайтесь команду. Откажитесь от спринтов, они, в том виде как вы их используете, не несут вам пользы. Ну или изучите скрам, сходите на тренинг и наладьте процесс со спринтами.
Нет смысла засчитывать часть задачи в выполненные sp, вы таким образом лишает себя возможности корректно определить ёмкость спринта. В велосити засчитываются только завершенные задачи. Незаконченные возвращаются в бэклог и проходят цикл оценки и планирования по новой.
Успешный спринт это не когда все задачи завершены, а когда достигнута цель спринта и есть готовый к поставке инкремент.
Спринт это командная работа, если разработчик утащил задачку в норку и там её в одиночку грызёт, если у вас внутри задачи микроводопад, с последовательно анализом, разработкой, тестированием, вы что-то делаете не правильно. Если у вас большинство задач планируются к завершению в конце спринта, неудивительно, что часто не успеваете. Вы описываете причины, по которым не успеваете. Но скрам предлагает решения этих проблем. И это не те, которые описываете вы.
У вас не работает одна из вырванных из скрама практик. Ровно потому, что все остальные остались за бортом.
Друзья, описываемые вами проблемы не от того, что "скрам, канбан и другие", а от того, что вы не понимаете и не знаете не первого, не второго не другого. Большая часть ваших "решений" проистекает оттуда же и ничего не решает.
Такое количество абсолютно неверных утверждений даже не позволяет ответить конструктивно, объём ответа будет сравним со статьёй.
И по мелким задачам мы умеем давать прогноз неплохо обычно. Проблемы начинаются когда начинаем прогнозировать проекты или большие фичи :)
А посчитайте коэффициент корреляции между оценкой и фактом. Визуально на втором графике корреляция в лучшем случае очень слабая.
Может добавить прямо в статью эту ссылку?
Так и есть. Модели помогают экспертам, не заменяют их.
Абсолютной точности не достичь, конечно, но приемлимая вполне достижима. Как минимум, методом Монте Карло можно получить дату, раньше которой точно не надо ждать завершения. Волшебным образом она чаще всего гораздо позже, чем хотелось бы.
Хаосрепорт такой как раз потому, что люди пытаются угадать будущее, а не спрогнозировать на основе знаний о прошлом. Было бы меньше фантазий, больше расчётов, глядишь, и репорт был бы другим.
Ну и конечно, никак не спрогнозировать в сложном домене, когда мы не знаем предстоящего объёма работ.
Какого результата нет, простите?
Нет, не надо. Практика показывает, что никакой корреляции между размером/сложностью и сроками завершения нет. Ладно, иногда слабая корреляция есть, у очень продвинутых команд с хорошо стабилизированным процессом. Эти выводы мы делаем на основании большого массива накопленных данных.
Данные покажете? Мы то собирали и проверяли эту корреляцию. (Не мы одни, конечно).
Ой, вы описали подход, лежащий в основе метода, только упустили, что производительность команды за спринт не константа, она "плавает". И метод Монте Карло это как раз позволяет учесть и дать вероятности того или иного исхода. Справедливости ради, для очень многих случаев точность такого прогноза не сильно отличается от МК.
Спасибо за конструктивный комментарий!
На практике, даже с учётом нестабильности, метод зачастую оказывается не хуже, чем экспертные прогнозы. При этом на порядки дешевле по трудозатратам.
В худшем случае, он даёт оценку снизу, "раньше чем Ч не сделаем точно", что уже очень ценный результат, позволяющий запустить полезные дискуссии о скоупе работ, ресурсах и, таки, сроках.
Вы делаете утверждение, можете его подкрепить чем-то?
Когда к вам приходит сейлз с уже сгоревшими сроками, ему вообще оценки нужны? Если ему эксперт скажет "не успеем", что скажет ему в ответ сейлз?
А где вы смотрели результаты? Они таки есть. И у Дорофеева и у других.
Во-первых, Дорофеев описывал не Монте-Карло, а более простой способ расчёта, тоже на исторических данных, но без учёта распределения. И даже он даёт достаточно неплохие результаты.
Во-вторых, сравнение результатов прогнозов его методом и методом Монте-Карло, на реальных данных и проектах, он как раз проводил https://youtu.be/xt27W5WhMrs?list=PLm6zCN_KJCrXXiDWoIczR7B9n73wPX2wn
Целиком плейлист тут https://www.youtube.com/playlist?list=PLm6zCN_KJCrXXiDWoIczR7B9n73wPX2wn
И не он один, конечно, сверял результаты прогноза МК с реальностью. Так же как и результаты прогноза экспертов :)
Вы что-то путаете. Метод Монте-Карло не даёт никаких оценок ни в каких попугаях. Он отвечает на один из двух вопросов:
а) с какой вероятностью к какой дате будут сделаны вот эти N задач?
б) Сколько и с какой вероятность задач мы сделаем за период?
Ни в одном из этих случаев попугаи не фигурируют. Тратить время на попытки экспертно предсказать будущее тоже не нужно.
Если у вас эксперты хорошо умеют давать такие предсказания и трудозатраты на этот процесс вас устраивает, вам не нужен Монте-Карло, смело проходите мимо. Но почему-то в подавляющем большинстве случаев оценки попугаев, да хоть трудозатрат в человеко-часах, не имеют никакой корреляции с длительностью работы и, соответственно, на вопрос "Когда?" ответить не помогают. Хотите проверим на ваших данных? :)
Для применения метода Монте-Карло не нужны оценки длительности отдельных задач.
Конечно, применять его лучше для той же команды, для которой у нас есть данные.
Всё, что вы описали, расчёт назад от "когда надо", расстановка и контроль промежуточных точек, имеет место, конечно. Но разве это отменяет другие методы?
В чём посыл вашего комментария? Метод не рабочий? Это не так.
Метод не надо применять? Не применяйте. Для нас он работает и результат лучше, чем экспертные оценки "да, вот это мы сделаем тогда-то". Что их не отменяет, но методом они прекрасно проверяются на адекватность.
Нельзя садиться в обе стороны. И взлёт и посадка всегда осуществляются в направлении хода корабля, да ещё и хода на приличной скорости.
Здесь речь о том, что отслеживать метрики и здоровье проекта имеет смысл на уровне того, что в методе называют customer recognizable work items, а не технических задач в командах. CFD в таком случае показывает именно здоровье проекта, в отличие от CFD на уровне задач, которая, конечно, показывает поток, только пользы в нём гораздо меньше. И хорошая СFD на уровне технических задач команды очень мало говорит о здоровье поставки ценности клиенту сервиса.
Оптимизация на уровне команды, отдельных задач, это локальная оптимизация. А Канбан-метод (и не только он) учит нас, что локальная оптимизация чаще всего не приносит пользы для цепочки поставки ценности. Канбан систему имеет смысл строить end2end и смотреть на систему и поток в целом.
Видео хорошее для общего понимания. Чтобы научиться видеть паттерны на диаграмме, придётся потренироваться.
подход с двумя досками, который вы описываете, в методе называется «двухуровневая визуализация». Может быть полезной, но с ней довольно тяжело работать, в большинстве инструментов синхронизировать придётся вручную.