Постом Agile: использование time boxing мы открыли серию заметок по использованию Agile практик в разработке программного обеспечения и применению их в системе управления процессом разработки DEVPROM.
Другим важным параметром процесса в Agile является скорость команды (velocity), который представляет из себя вычисляемый коэффициент позволяющий получать довольно точную оценку продолжительности итерации или релиза, исходя только из оценки, которую дает команда.
При классическом подходе к планированию разработки некоторого функционала от менеджера проекта требуется составить детальный план работ, включающий как разработку функционала, так и прохождение всех этапов процесса: анализ, проектирование, тестирование, документирование, стабилизацию и т.п. Опыт показывает, что составление таких планов не то чтобы бесполезное занятие, а зачастую даже вредное для проекта. Вот лишь несколько причин:
- водопадный процесс - для составления адекватного плана работ хотя бы на пару месяцев необходимо полностью представлять, чем будет заниматься команда, заранее провести полную функциональную декомпозицию, расписать роли и загрузку участников. Звучит замечательно, однако, в реальности сделать это практически невозможно, приходится учитывать и обосновывать риски, но разве вы сможете все учесть? Такой план становится уже неактуальным при первой незначительной пробуксовке в проекте.
- плохая измеряемость - одним из важных моментов в планировании процесса разработки является возможность измерить параметры процесса, чтобы понимать слабые места команды и с легкостью адаптировать план под изменяющиеся условия проекта. Вы можете измерять процесс задачами, трудоемкостями, количеством пожеланий или еще чем-либо, однако в случае такого плана работ у вас не будет удобных коэффициентов для определения продолжительности разработки.
- плохая адаптируемость - разработка ПО всегда связана с изменением функционального скоупа, при этом вам приходится перекраивать план по несколько раз на дню и отвлекать команду на оценку или переоценку задач. И ни в коем случае нельзя ошибиться :)
Забудьте про этот кошмар и научитесь пользоваться интегральными параметрами процесса, такими как, скорость команды (velocity).
Скорость (velocity) - это отношение трудозатрат команды на выполнение некоторого скоупа к продолжительности работы команды над этим скоупом. Вот некоторые замечательные возможности, которые дает вам данный параметр:
- трудозатраты команды покрывают все особенности вашего текущего процесса, не нужно задумываться обо всех деталях, кто чем занимается, просто дайте команде работать. Оценка трудозатрат может осуществляться хоть в попугаях, идеальных часах или реальных часах, которые дает технический или тест-лидер.
- все технические, технологические и ресурсные риски уже учтены в фактической продолжительности работы команды, вам больше не пригдятся жуткие зависимости между задачами, из-за которых образуется клубок запутанных связей.
- измерив данный параметр один раз, вы получаете способ быстро оценить сроки реализации изменившегося или дополнительного скоупа и определить реальные сроки завершения очередного этапа работ.
Для получения достаточно точного значения скорости команды вам необходимо выполнить всего лишь несколько итераций.
|
