Post #471

Как выглядит на практике работа с Enhanced Burndown Chart. Попросили меня посмотреть, что с проектом. А то заказчик говорит — уже почти два месяца прошло, а ничего не движется. Первичная диагностика: смотрим, что там "не движется" (картинка 1). Видим, что с 1 по 5 итерации разработка действительно не очень сильно напрягалась, но, тем не менее, выполнила все первоначальные задачи. Видим резкие скачки на 3 и на 7 итерации — заказчик накинул новые требования, которых не было в самом начале. В принципе, для agile это нормально, но конкретно на этом проекте ситуация с поставкой ценности не очень — заказчик до сих пор не может ничего использовать — нет законченных целостных сценариев (это проблема планирования спринтов, явная ошибка). Ну и первоначально выявленные требования очевидно не полны — можно увидеть, как заказчик смотрит на промежуточный результат, и только в этот момент понимает, что ему нужно (3 итерация). Это бы не было проблемой, если бы с ожиданиями заказчика заранее поработали, и если бы хотя бы раз в месяц ему выдавали полезные результаты. В принципе, тогда бы и вопроса про сходимость проекта не возникло. Реальные продукты, которые развиваются, могут вообще не сходиться — у них нет финальной точки, после которой разработка останавливается. Но можно выделить промежуточные крупные этапы, сходимость к которым можно оценить. Команда понимает недовольство заказчика, и пытается решить это, как умеет — сделать побольше задач, возможно — с переработками. Это дает мощный 7 спринт, да и 6 тоже был производительный. Однако в ожидания вновь не очень попали: заказчик в 7 опять накидал новых задач. Ясно, что команда в таком же авральном режиме долго работать не сможет. Теперь нужно решить, что делать дальше. Варианты (на картинках — прогноз числа задач по спринтам): * объявить фича-фриз, то есть перестать принимать новые задачи на какое-то время, и закончить те сценарии, которые уже в работе. Заказчику не понравится, но будет хоть какое-то законченное изделие к 11 итерации; * посмотреть на тренд 7 и 8 итерации, и предположить, что команда уже достаточно выявила потребности заказчика, и дальнейших рывков вниз не будет. Поэтому можем не морозить скоуп, а заодно можем ещё раз напрячься, как мы уже делали на 6-ой итерации. Тогда можем успеть к 12 итерации, но есть значимая вероятность, что проект уедет правее; * если не напрягаться, но предположить, что новых требований не будет, то мы уезжаем куда-то вдаль, и конца проекту не видно; * наконец, если совместим фича-фриз и напряжемся, то можем выиграть одну итерацию (11 вместо 12). Вот такой диагноз и такие варианты действий. Как вы думаете, какой вариант был выбран в реальности?