Диаграмма сгорания Scrum Sprint — каждая картинка рассказывает историю

Мы используем гибкие методы разработки программного обеспечения, и Scrum — наш предпочтительный метод управления проектами. Наша команда разработчиков находится за границей, и заставить Agile работать в разрозненной команде сложно, но это выполнимо (и может быть весело!). Итак, я подумал, что расскажу вам историю об одном из наших настоящих спринтов, как это показано в Scrum Burndown Chart. Почему? Ну, потому что я думаю, что мы можем многому научиться из диаграмм выгорания, и у каждого есть своя история, которую можно рассказать. Вот наш:

Чтобы подготовить почву, моя команда Scrum собралась (почти естественно), чтобы спланировать следующую итерацию нашей работы по разработке системы обработки заказов на заказ для крупной британской коммунальной компании. Мы знали, какие пользовательские истории нужны владельцу продукта в этом спринте, поэтому мы сели, перечислили задачи, которые требовались для создания пользовательских историй, и оценили в часах, сколько времени займет каждая из них. Эта первая оценка вышла через 90 часов.

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

Все началось хорошо, прогресс был успешным, даже с опережением графика. Затем, через несколько дней, один из сотрудников понял, что для завершения одной из пользовательских историй требуется еще одна задача — поэтому она была задокументирована, оценена и добавлена ​​в список невыполненных работ. Это добавило еще 16 часов к расчетным оставшимся часам, и поэтому диаграмма выгорания сместилась на север.

Еще один неожиданный инцидент произошел через несколько дней. Правительство Великобритании объявило о снижении ставки налога с продаж, и поскольку система, которую мы создали для нашего клиента, представляет собой систему обработки заказов, которая включает в себя расчеты цен и счетов, мы знали, что это законодательное изменение необходимо учитывать, когда это первоочередная задача. Теперь мы небольшая команда (которая не является Agile-командой), и мы быстро поняли, что все текущие работы по разработке должны быть приостановлены, чтобы внести это критическое изменение.

Поэтому мы отложили этот спринт и работали в течение недели и выходных, чтобы успешно внести изменение НДС в дату реализации через неделю после того, как правительство объявило об этом. В результате наша диаграмма выгорания в течение недели оставалась неизменной. Итак, мы поняли, что это повлияет на нашу ожидаемую дату поставки, и поэтому мы начали рассматривать пересмотренное окно завершения для этого спринта.

Однако прежде, чем мы смогли завершить это, перед нами возникла следующая преграда. Разработчик, взявшийся за новую задачу, обнаружил, что она сложнее, чем мы думали изначально; В результате оставшиеся усилия увеличились еще на 36 часов, что привело к еще одному росту в нашем графике и, конечно, еще одной задержке в завершении этого спринта. Опять же, основываясь на скорости работы команды, мы сделали переоценку и опубликовали исправленное закрывающее окно.

Теперь я уже слышу, как некоторые из вас кричат ​​на меня, эксперты по Скраму. Разве нужно было сократить время итерации, а не увеличивать его? Когда мы добавили новое задание, может быть, нам стоило обратиться к Владельцу продукта, чтобы удалить что-то в качестве компенсации за доставку в рамках Спринта? И все это правда — в идеальном мире Scrum мы бы так и поступили. Но мы хорошо знаем наших клиентов, у нас прекрасные отношения с ними, и мы знали, насколько важно для них внедрить эту функцию до Нового года. Поэтому я скорректировал правила Scrum в соответствии с их потребностями. Прежде чем меня вытеснят из банды Скрама, мы не должны упускать из виду ценности Скрама:

* Будьте готовы посвятить себя цели.
* Делай свою работу. Сосредоточьте все свои усилия и навыки на той работе, которой вы привержены.
* Не беспокойтесь ни о чем другом.
* Scrum делает все, что касается проекта, видимым для всех.
* Имейте смелость участвовать, действовать, быть открытыми и ожидать уважения.

Что ж, я согласен с тем, что мы немного изменили правила итераций, но для этого были веские причины. В ходе спринта произошли неожиданные изменения. Но мы были открыты и честны с заказчиком и смогли использовать диаграмму выгорания спринта, чтобы быстро показать владельцу продукта влияние изменения и получить его одобрение для продолжения.

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

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Сожалеем, что вы поставили низкую оценку!

Позвольте нам стать лучше!

Расскажите, как нам стать лучше?

Автор записи: admin

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *