Комментарии 3
Очень много вопросов к статье, никогда в жизни не видел проекта у которого беклог бы не рос значительным образом. Приведу две cumulative flow диаграммы реальных проектов, один это конечный продукт который после релиза и тюнинга не требует развития, второй это сервисный проект обрабатывающий заявки.
Я напрочь вообще не представляю никакого реального продукта, в котором все задачи были бы проставлены сначала. Так или иначе, но во время выполнения одних задач, ставятся новые, ставятся задачи в техдолг. На каждом демо появляются новые задачи, уж не говоря о релизе, каждый релиз производит аналитику, новые ab тесты и новые задачи. Продукт в котором не растёт беклог это продукт без обратной связи.
Тут же кстати видно интересную штуку, далеко не все поставленные задачи на самом деле требуется доделать к релизу, и после релиза останется ворох ненужных задач которые потеряли актуальность, их проще закрыть если проект будет дальше завиваться, или оставить висеть если проект завершён, нет никакого смысла разгребать остатки.
P.S. кто увидел что на сервисном проекте растёт количество принятых задач (accepted) которые ждут очереди на выполнение, тот молодец, да, такова жизнь, не всё нужное успевается.
Приветствую. Конечно вы абсолютно правы, что в жизни задачи появляются по мере того как ты двигаешься. Тут скорее для примера приведены графики и возможны в ситуации "Идеального проекта", когда задачи четко продуманы наперед.
Мне кажется первое что стоит усвоить начинающему менеджеру проектов (а для кого ещё вы рассказываете про cumulative flow) что идеальных проектов не бывает не потому что что-то помешало, а потому что так не бывает в принципе, работа менеджера состоит именно том чтобы вести продукт к своим целям в постоянно меняющемся мире, при постоянных изменениях требований, доступных ресурсов и команды. Не надо пытаться построить идеальный flow и требовать от команды работы по нему.
Все проблемы проекта в одной диаграмме: как с помощью Kaiten построить диаграмму потока