Нашу команду попросили представить наши усилия по разработке в плане проекта. Никто не недоволен нашей работой или не ставит под сомнение нашу способность доставлять, мы просто участвуем в конкурсе ИТ-проектов для планов проектов. Проблема в том, что мы - гибкая команда и не думали о нашей работе с точки зрения формального плана проекта.
Хотя у нас есть общее представление о том, над чем мы работаем дальше, мы не уверены на 100%, пока не планируем итерацию. До сих пор наша команда в основном работала в вакууме, и от нас не требовалось представлять нашу методологию или показатели сторонним организациям. Мы следуем большинству практик, используемых в экстремальном программировании .
Мы проводим ежеквартальные встречи по планированию, чтобы иметь общее представление об историях, над которыми мы будем работать в течение четверти. Тем не менее, наши истории документированы на картах 3х5 и оцениваются только в начале итерации, в которой они будут работать. После оценки мы документируем историю в Team Foundation Sever . Во время итерации мы прикрепляем код к историям и помечаем истории как завершенные после завершения. Из этих данных мы можем генерировать диаграммы выгорания и скорости. Самое главное, что мы знаем нашу среднюю скорость за итерацию, которая не дает нам откусывать больше, чем мы можем пережевывать.
Я не собираюсь изменять способ, которым мы занимаемся разработкой, но хочу представить нашу деятельность по разработке в отчете, который поймет кто-то, только знакомый с водопадом. В книге «Как выглядит план гибкого проекта» Кент Макдональд хорошо разбирает различия между планами гибкого и водопадного проектов. Он указывает на различия в расходных пулях:
- Гибкий план проекта основан на особенностях
- Agile Project Plan организован в итерации
- План Agile Project имеет разные уровни детализации в зависимости от сроков
- Agile Project Plan принадлежит команде
Умение объяснить различия - это здорово, но как лучше представить данные?