Планирование

1. Мы исходим из того, что контракт спринта носит безусловный характер, после того как он согласован с командами.

   • Это важный принцип, который требуется для того, чтобы мы могли управлять ожиданиями друг друга.
   • Иное можно считать исключением, но не правилом.

2. Приоритеты в рамках спринта

   1. Релиз — 50% планируемого времени.
   2. Баги и другие непредвиденные задачи — от 30 до 50% времени спринта, которые не распределяется на конкретные задачи.
   3. Груминги, декомпозиция, все что касается подготовки задач к реализации в будущем спринте — 20% планируемого времени

3. Баги и проблемы системы становятся безусловным приоритетом №1 в случае, если это блокирует работу системы или ведут к неминуемым прямым убыткам

4. Любое изменение контракта спринта происходит через продакта или ****проджекта спринта.

   1. Если любая задача затянулась (разработка фичи, работа над багом, декомпозиция и т.д.), т.е. в процессе или фактически (по результату дня) сдвигает сроки других задач, которые аффектят работу коллег — об этом необходимо сообщить
   2. Если выполнены все задачи спринта. Новые задачи берутся из согласованного беклога с уведомлением продакта или проджекта спринта. А если такого списка нет, прямо запрашиваем его

5. Инструмент ‣ и ежедневные планерки требуется для того

   1. Чтобы смежные команды, проджект и продакт видели и были в курсе задач с которыми работают члены команды. И могли исходя из этого планировать свою работу
   2. Чтобы сам исполнитель на ежедневной основе оценивал план-факт движения по задачам. А в случае системного нарушения этого, мог калибровать свою работу или обратиться за помощью к коллегам за помощью в решении проблемы.

6. Все задачи после их грумминга

   1. Должны быть декомпозированы разработчиком
   2. Должны иметь плановую оценку
   3. В процессе реализации должны трекать фактические времязатраты

   Этот важный ритуал, который позволяет проводить план-факт оценку и ретроспективу процесса реализации задач, корректировать и улучшать ее.

Релиз задачи

<aside> ☝ У любой фичи должен быть выпускащий разработчик. По-умолчанию, ответственный за доведение фичи в релиз является член команды, который ее и декомпозировал.

</aside>

1. Сначала задача уходит на отдельную ветку
2. Задача не мержется в основную ветку пока не прошла тестирование и не получен апрув от ответственного продакта/проджекта.
3. Мержинг задачи в основную ветку букально означает, что это пойдет в ближайший релиз.
4. Исключения из данного правила они оговариваются в явном виде на этапе планирования спринта

Фактирование

• В трекере обязательно фиксируем фактическое время потраченное на разработку задачи, тестирование задачи