Я делаю проект, который позволяет скорректировать прогноз планирования релиза/фичи на основании опыта предыдущих ошибок планирования. Данная версия исключительно для оффлайн (LocalStorage). Использую Веб-воркеры для разгрузки основного потока (летает как самолет).
Реализовано:
Создание задач с возможностью указать время старта, время прогноза, время фактического финиша, "субъективную сложность" фичи, назначенный исполнитель;
Задача, имеющая прогноз (при наличии завершенных задач конкретной сложности, назначенных на конкретного исполнителя) будет иметь прогрессбары для рассчитанного с использованием теории вероятностей "ощущаемого" и самого худшего сценариев;
Можно настроить варианты рабочих графиков для расчета рабочих часов на выполнение задачи (я использую для анализа эффективности промежутков работы между прерываниями на созвоны и коммуникации);
Для задачи можно назначить задачу-родителя (я использую для построения дерева задач);
Пока в работе, позже планирую добавить фичи:
Подключить сокет в отдельном потоке (поэкспериментировать с обратной связью от пользователя);
Функция "Поделиться ссылкой на дерево проектов" - Серверный кэш для хранения временных данных;
Я пришел к выводу, что "Менеджеры вынуждены контролировать работу специалистов", т.к. не знают их работу (как неспециалист не знает работу специалиста), и это единственный их вариант получить иллюзию ежедневного контроля. Управленцев, которые не знают матчасть сейчас сильно больше и на них идёт давление таких же менеджеров со стороны заказчика.
Поправка: (Вот более удачная версия статьи) Теория вероятностей в действии 2.0 (суть алгоритма корректировки прогнозов разработчиков) https://habr.com/p/874226/
Решаю практически эту же задачу длительное время. Думаю, финалом будет алгоритм, который распознает твою комфортную скорость работы. Подробнее описал здесь.
Но любую фичу разные люди делают за разное время. И оценивают по разному - для кого-то фича простая, для другого - несколько сложнее. Команда также может менять состав с течением времени. Как быть с этими фактами? Общая статистика здесь не прокатит, кмк
Интересная точка зрения. Согласен почти со всем кроме некоторых моментов:
Абсолютные оценки в часах не работают
Но постойте, как же Принцип Доказательного Планирования от Joel Spolsky? Я думаю, оценивать в реальных часах конкретными людьми для последующего анализа - это нормально. Подробнее изложил здесь, если интересно - там есть идеи как вычислить, насколько обманет конкретный разраб, который сказал "Это на пару часов".
С этим тоже не могу согласиться:
если за последние три месяца 80% задач размера M выполнялись в течение 5–7 дней, то с высокой вероятностью новая задача аналогичного размера займет примерно столько же времени.
А если процессы совершенствуются с течением времени? Мой контраргумент коротко: разные люди работают с разной комфортной скоростью, в любой момент времени статистика конкретного исполнителя может удивить - люди развиваются и деградируют, и это надо иметь ввиду.
Согласен с тем, что необходимо вводить абстрактные критерии оценки сложности фичи (попугаи, пятибалльная система, футболки и т.д.) - зачастую сложность определяет комфортную скорость работы.
Существует такое понятие как функция распределения вероятностей(в приложении он также строится под названием "Timing distribution according to previous experience") - так вот, в точке x на графике изменение скорости ("Δ" в контексте статьи) стремится к нулю - про расчет этой наиболее вероятной скорости реализации фичи идёт речь в статье. А ту статистику про которую говорите Вы - можно собрать самому, используя этот расчет.
Но спасибо за фидбек, я добавлю пояснения в статью.
В поисках баланса между "изложить полезное и интересное", "поменьше текста" и "хотя бы немного кода" пришел к результату в виде коммента на который сейчас отвечаю. Спасибо за фидбек ) периодически возвращаюсь к редактированию.
Вот предыдущий вариант статьи. В этот раз думал сделать компактнее (изучаю метрику читателей для корректировок)
Изучал эту проблему, поделюсь мнением. На мой взгляд в текущий момент, лучшая ретроспектива - это переиспользование ошибок планирования сроков на фичи по методике EBS, Вы удивитесь, но на ретроспективу не потребуется специально отведенное дополнительное время (она должна быть автоматизирована, как вариант). В сухом остатке, это должно быть не более чем неявное переиспользование опыта работы с коллегами, которое предложил Joel Spolsky.
+1 Если мы говорим про место на экране телефона, то экономия на спичках здесь, прям, мастхэв, что очевидно же) Насчет полноценного бокового меню - нуу фиг знает, стоит ли его применять для любого кейса (может, это действительно только для 7+-2 позиций меню предесмотрено? Если да, то скролл довольно аккуратно смотрится, да и уже как-то привычнее)
Я делаю проект, который позволяет скорректировать прогноз планирования релиза/фичи на основании опыта предыдущих ошибок планирования. Данная версия исключительно для оффлайн (LocalStorage). Использую Веб-воркеры для разгрузки основного потока (летает как самолет).
Реализовано:
Создание задач с возможностью указать время старта, время прогноза, время фактического финиша, "субъективную сложность" фичи, назначенный исполнитель;
Задача, имеющая прогноз (при наличии завершенных задач конкретной сложности, назначенных на конкретного исполнителя) будет иметь прогрессбары для рассчитанного с использованием теории вероятностей "ощущаемого" и самого худшего сценариев;
Можно настроить варианты рабочих графиков для расчета рабочих часов на выполнение задачи (я использую для анализа эффективности промежутков работы между прерываниями на созвоны и коммуникации);
Для задачи можно назначить задачу-родителя (я использую для построения дерева задач);
Пока в работе, позже планирую добавить фичи:
Подключить сокет в отдельном потоке (поэкспериментировать с обратной связью от пользователя);
Функция "Поделиться ссылкой на дерево проектов" - Серверный кэш для хранения временных данных;
Возможно что-то ещё...
https://pravosleva.pro/dist.estimate-corrector-2024
Проект живой (сам использую в работе), здесь пишу новости по обновлениям: https://t.me/bash_exp_ru/607
Я пришел к выводу, что "Менеджеры вынуждены контролировать работу специалистов", т.к. не знают их работу (как неспециалист не знает работу специалиста), и это единственный их вариант получить иллюзию ежедневного контроля. Управленцев, которые не знают матчасть сейчас сильно больше и на них идёт давление таких же менеджеров со стороны заказчика.
Поправка: (Вот более удачная версия статьи) Теория вероятностей в действии 2.0 (суть алгоритма корректировки прогнозов разработчиков) https://habr.com/p/874226/
А все потому что надо научиться отключать уведомления по умолчанию.
Вот же глюк... И не отредактировать уже, соррямба. https://habr.com/p/874226/
Решаю практически эту же задачу длительное время. Думаю, финалом будет алгоритм, который распознает твою комфортную скорость работы. Подробнее описал здесь.
И конечно же, многозадачность - вселенское зло )
Hours ∝ Story Points
Правильно, "живые" либы должны постоянно ломаться и ремонтироваться, как традиционные Жигули )
Но любую фичу разные люди делают за разное время. И оценивают по разному - для кого-то фича простая, для другого - несколько сложнее. Команда также может менять состав с течением времени. Как быть с этими фактами? Общая статистика здесь не прокатит, кмк
Интересная точка зрения. Согласен почти со всем кроме некоторых моментов:
Но постойте, как же Принцип Доказательного Планирования от Joel Spolsky? Я думаю, оценивать в реальных часах конкретными людьми для последующего анализа - это нормально. Подробнее изложил здесь, если интересно - там есть идеи как вычислить, насколько обманет конкретный разраб, который сказал "Это на пару часов".
С этим тоже не могу согласиться:
А если процессы совершенствуются с течением времени? Мой контраргумент коротко: разные люди работают с разной комфортной скоростью, в любой момент времени статистика конкретного исполнителя может удивить - люди развиваются и деградируют, и это надо иметь ввиду.
Согласен с тем, что необходимо вводить абстрактные критерии оценки сложности фичи (попугаи, пятибалльная система, футболки и т.д.) - зачастую сложность определяет комфортную скорость работы.
Попробую объяснить проще:
Существует такое понятие как функция распределения вероятностей (в приложении он также строится под названием "Timing distribution according to previous experience") - так вот, в точке x на графике изменение скорости ("Δ" в контексте статьи) стремится к нулю - про расчет этой наиболее вероятной скорости реализации фичи идёт речь в статье. А ту статистику про которую говорите Вы - можно собрать самому, используя этот расчет.
Но спасибо за фидбек, я добавлю пояснения в статью.
В поисках баланса между "изложить полезное и интересное", "поменьше текста" и "хотя бы немного кода" пришел к результату в виде коммента на который сейчас отвечаю. Спасибо за фидбек ) периодически возвращаюсь к редактированию.
Вот предыдущий вариант статьи. В этот раз думал сделать компактнее (изучаю метрику читателей для корректировок)
Check it out =)
Изучал эту проблему, поделюсь мнением. На мой взгляд в текущий момент, лучшая ретроспектива - это переиспользование ошибок планирования сроков на фичи по методике EBS, Вы удивитесь, но на ретроспективу не потребуется специально отведенное дополнительное время (она должна быть автоматизирована, как вариант). В сухом остатке, это должно быть не более чем неявное переиспользование опыта работы с коллегами, которое предложил Joel Spolsky.
Мои научные изыскания пока что привели к этому. Ваше мнение? )
+1
Если мы говорим про место на экране телефона, то экономия на спичках здесь, прям, мастхэв, что очевидно же) Насчет полноценного бокового меню - нуу фиг знает, стоит ли его применять для любого кейса (может, это действительно только для 7+-2 позиций меню предесмотрено? Если да, то скролл довольно аккуратно смотрится, да и уже как-то привычнее)