denis_ulizko Oct 2 at 07:04

Как экономить время на фиче, растянув ее на три спринта

5 min

1.7K

МТС corporate blogPersonnel Management * Development Management * Project management * Product Management *

+25

Comments 6

Delderfield85 Oct 2 at 08:42

Спасибо, Денис, за подробный разбор и практические примеры. Особенно за цифру — сокращение Story Lead Time почти в два раза впечатляет.
Будет интересно посмотреть, как это решение проезжает на других командах и задачах — на одной модели ли стоит остановиться, или будет эволюция.

denis_ulizko Oct 2 at 08:44

Спасибо

Конечно, возможно через какое-то время стоит рассказать как данная модель прошла тестирование временем

Pusk1 Oct 3 at 14:54

Story Lead Time сократился с ~21,5 до ~9,6 дней При разбивке конвейера на 3 спринта меньше 10 дней ну никак не получится.
И зачем вам спринты? Попробуйте "по мере готовности" с той же ритмичностью планирования. Пока активность смотрится как первый шаг в сторону канбан подхода.

denis_ulizko Oct 7 at 09:25

По мере готовности действительно может быть неплохим вариантом, когда есть общий мешок задач и нет необходимости конкретную строю вывести к конкретному периоду.

Но когда есть сроки по выпуску конкретной стори, подобный подход увеличивает вероятность попасть в эти сроки

tentecool Oct 5 at 08:10

И я же правильно понимаю, что это всё верно только в том случае, если разработка сможет фичу, которую описывали до этого БА/СА/ПМ/ДИЗ 4 недели, сделать за 1 неделю, а ещё за 1 неделю отладить вместе c QA?
У вас всех фичи на разработку декомпозируются и режутся по объему до 1 недели оценки разработки?

denis_ulizko Oct 7 at 09:32

Да, все верно

Стори режутся так чтобы быть сделанными за один спринт, а инкременты BA, SA, Arch, Design проходят DoR ровно для того чтобы у разработки было все что ему нужно для быстрой разработки

И конечно же, одновременно у команды в работе несколько сторей, которые сначала проработываются со стороны Discovery а потом реализуются со стороны Delivery.

Так что 4 недели готовится не одна сторя 😊