Оценивает задачу тот, кто будет её выполнять, с запасом, как ему комфортно, менеджер дополнительно прибавляет процент на риски (исходя из истории и опыта), и резервирует время и бюджет у заказчика.
Если не получается, чтобы задачу взял тот, кто оценил, тогда особенно важно, чтобы оценка была с запасом. Особенно если задача ушла неопытному разработчику - он её может выполнять вдвое-втрое дольше.
Разработчики записывают всё время по задаче, как им удобно, в свободной форме, но с привязкой к задаче. Это может быть непосредственно разработка, поддержка, аналитика, консультации - любая полезная деятельность должна быть оплачена.
Записывают как и когда им удобно, но заранее предупреждаются о сроке закрытия спринта/сделки, чтобы успели проставить время.
От закрытого времени напрямую зависит их (и не только их) доход, так что если что-то не записали - значит работали бесплатно, мотивация трекать более часто. Опять же нужна прозрачность, чтобы разработчики понимали, что от их записей зависит и их доход и фирмы.
Систем трекинга много, всяких.
Но это разработчики - так что в ходу много кастомных, внутренних, даже частных трекеров, которые сливают записи по api в кастомный корпоративный трекер.
Есть всевозможные клиенты для корпоративного трекера, в т.ч. веб-морда и mobile apps. Разрабатываем сами, кому как удобно, что-то приживается, что-то отмирает - живая экосистема.
Корпоративный трекер в свою очередь можно синхронизировать с редмайнами. Некоторые клиенты умеют заливать и в трекер и в редмайны, т.к. хранят данные в универсальном формате.
Оценка по комфортному времени позволяет разработчикам чаще укладываться в оценку, чем не укладываться. Поэтому почти с каждой задачи остаётся какой-то процент неиспользованного времени. Плюс оценка на риски менеджера.
В конце спринта все неиспользованные часы складываются, и из них покрывается овертайм.
Овертайм бывает на небольшом проценте задач, но иногда значительный: 200-300%. Не всё можно предусмотреть.
Почти всегда суммарного запаса часов хватает: например в спринте 10 задач, разработчики оценили их по 5ч каждую, менеджер заложил ещё 5ч на риски, итого 10ч каждая - зарезервировано 100ч на спринт, по итогу 2 задачи уши в большой овертайм, и скушали 30ч, 3 задачи ушли в овертайм, но уложились в риски - ещё 30ч, зато оставшиеся 5 задач уложились в оценку (без рисков), и на них ушло по 5ч - итого зарезервировано 100ч, затрачено 85ч(30+30+5*5), в оценку уложились, заказчик доволен.
Но так плохо редко бывает, в основном, т.к. разработчики оценивают комфортное время, реально уходит меньше оценки, т.е. оценили в 5ч, сделали за 3-4ч.
А те часы, что остались после покрытия овертайма, в счёт не выставляются, так что работа обходится как правило дешевле договоренностей. Небольшой приятный бонус для заказчика. Можно смело присваивать эти лишние часы, но долгосрочные отношения на обмане не построить, так что нафиг.
В случае совсем форс-мажоров, когда выходим за все риски - обсуждаем с заказчиком возможные варианты. Обычно заказчики идут на встречу, и выделяют дополнительные ресурсы.
Плюсы подхода: почти всегда укладываемся в бюджет, часто обходимся дешевле договоренностей, хорошие отношения с заказчиками.
Минус подобного подхода - приходится часть бюджета резервировать на риски, эта часть бюджета замораживается на два спринта, и может быть влита в 3й.
Как итог заказчику приходится закладывать бюджет чуть больше необходимого, но за счёт этого получаем намного более предсказуемое и стабильное планирование, к тому же в большинстве случаев этот небольшой переизбыток бюджета остаётся неиспользованным, и в среднем это бесплатно: то, что заморожено в текущем спринте, будет разморожено в следующем, и через спринт может быть пущено в дело.
