Поправка: (Вот более удачная версия статьи) Теория вероятностей в действии 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 позиций меню предесмотрено? Если да, то скролл довольно аккуратно смотрится, да и уже как-то привычнее)
Поправка: (Вот более удачная версия статьи) Теория вероятностей в действии 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 позиций меню предесмотрено? Если да, то скролл довольно аккуратно смотрится, да и уже как-то привычнее)