Как оценить срок выполнения работ?
В одной из статей я поднимал вопрос о том, насколько удобны и необходимы диаграммы Гантта в разработке программ. Использование диаграммы во многом усложняет, а не в самых опытных руках еще и вредит планированию проекта. Какая же методика позволит оценить не хуже, а чаще даже лучше, сроки выполнения проекта и при этом существенно сократить издежрки, связанные с составлением и поддержкой в актуальном состоянии плана проекта?
Описываемая методика заимствована из семейства Agile и не предполагает составления плана в привычном понимании, какой строится при помощи диаграммы Гантта. Методика базируется на двух основных понятиях: однотипность итераций (принцип вчерашней погоды - если погода установилась, то завтра погода будет такая же как и вчера) и скорость команды.
Методика
Суть методики заключается в том, что если на выходе каждой итерации ваша команда имеет работающий продукт (что само по себе является неким мерилом прогресса), то за несколько итераций вы получаете усредненную и довольно точную оценку скорости вашей команды. Скорость можно измерять в количествах реализованных функций (user stories) за итерацию, или за день, или затраченных часов за некоторый период, это второй вопрос.
В нашей системе скорость команды измеряется в количестве выполненной командой работой за день. Это в первую очередь командная характеристика, а не индивидуальная. Данный показатель инкапсулирует фазы разработки, зависимости между задачами, загрузку ресурсов, выходные или незапланированные отсутствия участников и другие риски, в целом все то, что происходило с командой в течение итерации. С большой долей вероятности в течение следующей итерации разработка пойдет примерно с тем же темпом.
По сути вам вообще не нужен план, то есть дерево задач, расписанное по участникам проекта, вам нужен набор функций, которые требуется реализовать, договоренность внутри команды о процессе реализации каждой функции (использовать TDD, использовать автоматизированное тестирование и т.п.) и данные о показателях вашей команды. Все. Теперь вы с высокой точностью определите сроки реализации этих функций.
Остается еще один момент: все функции требуют различной трудоемкости на реализацию. Можно делить их на классы: простые, обычные и сложные. Мы пошли другим путем и оцениваем трудоемкость отдельного пожелания (feature или user story). Здесь возникает погрешность недооценки, поскольку команде, не реализовав и не поняв всех тонкостей реализации пожелания, трудно точно его оценить. С другой стороны команда состоит из людей и пожелание может быть выполнено не с первого раза, что обнаружится по результатам тестирования. Поэтому вводится еще один показатель: процент ошибок.
Результат
Таким образом, срок выполнения некоторого набора пожеланий вашей командой вычисляется по простой формуле: суммарная оценка трудоемкости * погрешность недооценки * процент ошибок / скорость команды.
Существенным преимуществом данной методики является прозрачность оценки - вы видите, что нужно изменить, чтобы добиться поставленной цели. А также независимость от способа оценки трудоемкости пожеланий. Оценивать трудоемкость может лидер команды, тогда он думает только о реализации, а затраты на все остальные фазы описываются погрешностью недооценки. Оценивать трудоемкость может команда, тогда погрешность недооценки будет стремиться к 1.
Вы только подумайте о том, что теперь нет необходимости расписывать задачи на всю команду, указывать исполнителей, расставлять зависимости, выравнивать ресурсы, а главное - переписывать план проект при изменении скоупа, сроков или стоимости. Вы мгновенно узнаете о стомости и сроках некоторого скоупа.
Ограничения
Немного о минусах, они конечно же есть и здесь, но они настолько незначительны, что ими вполне можно пренебречь, либо чуть подкорректировать свой процесс с целью следования принципам Agile.
Методика основывается на предположении, что состав команды не меняется, равно как и возможности ее участников. Зачастую это действительно так в рамках нескольких итераций, а может и релизов. Если вы хотите со своей командой выполнить проект, то она должна быть достаточно сплоченной и устойчивой. Если команда распадается, либо ее участники меняются, то наработанные показатели необходимо рассчитать заново. Хорошая новость в том, что довольно точные показатели вы сможете собрать уже после двух или трех итераций.
Предполагается, что структура работ во всех итерациях примерно одинаковая, то есть какое-то определенное время работает аналитик, затем каждая функция проходит однотипные этапы разработки, тестирования, документирования. По окончании каждой итерации у вас должен быть стабильный продукт, а не так, что в первой итерации занимаемся анализом, во второй - разработкой, в третьей - тестированием.
Предполагается, что работает эффективная команда, которая самостоятельно может обнаружить и разрешить возникающие между задачами зависимости, владеет пониманием процесса изготовления программного продукта.
Если ваша команда разрабатывала Web-приложение, автоматизирующее деятельность магазина, а теперь ей предлагается разработать трейдинговое приложение на C++, то скорее всего показатели команды придется собрать заново. Однако, в любом случае это крайне рискованная затея :) |
Еще интересные статьи на эту тему:
|
