Как уже обсуждалось, точно оценить сроки окончания проектов программных проектов (ПО) невозможно по природе вещей, причем типичны ошибки в разы. Тем не менее, сдать проект в срок можно. Одним из условий являются периодические демонстрации заказчику прототипа и уточнение деталей, которые в правильном контракте, вообще не оговариваются.
(Вы можете проиграть видео (щелкните по нему) или прочесть текст под ним)
Прототип, тоже, разумеется, надо представлять в согласованные сроки, но тут мы имеем то преимущество, что небольшие отклонения прототипа от идеала допустимы по определению прототипа.
Таким образом, задача сводится к тому, чтобы свести к минимуму отклонения прототипа от идеала, а это, согласно «Центральной предельной теореме» из статистики можно сделать, если разбить очередную итерацию («спринт» или»Sprint») по изготовлению прототипа на более мелкие функциональности и подзадачи.
Проще всего это проиллюстрировать на стандартном примере подбрасывания монеты. Управлению проектами соответствует в этой игре задача свести проигрыш (отклонение от срока) к минимуму.
Если мы бросаем монету один раз, то мы имеем либо полный провал, либо выигрыш. Это нас, разумеется, не устраивает. Заказчику не очень нужно, чтобы мы сделали прототип быстрее, так как сроки его представления уже согласованны, но заказчику очень не понравится полное отсутствие прототипа к сроку.
Предположим теперь, что мы разобьем наши ставку (время спринта) на 100 частей (подзадач) и будем бросать монету 100 раз. Тогда статистика говорит, что наш проигрыш в среднем не будет превышать SQRT(100)*100%/100 = 10% (SQRT – обозначает квадратный корень). В управлении проектами это соответствует 10% отклонению от времени выполнения, но поскольку все разбито на подзадачи, это означает, что не менее 90% функциональности будет готово к окончанию спринта. Для прототипа это совсем не плохо.
В общем случае формула оценка риска сложна, но грубо, в предположении, что все подзадачи занимают одинаковое время, среднее отклонение от цели в процентах можно оценить как SQRT(N)*100%/N
Таким образом на каждую демонстрацию прототипа, надо договариваться о демонстрации нескольких функциональностей (фич) и сами фичи в ходе спринта должны быть разбиты на несколько задач. Как говорится, «не надо класть все яйца в одну корзину».
Все предыдущие рассуждения подразумевают, что хотя мы и можем ошибиться в сроках отдельной задачи раза в два, усредняя по большому количеству задач, мы оцениваем сроки верно. Как ни странно это требование накладывает ограничения на величину команды, выполняющей проект. Но масштабирование возможно. Об этом в следующих заметках. Так что подписывайтесь на «feed», чтобы не пропустить 
.
0 Response to “Центральна предельная теорема и управление проектами программного обеспечения (ПО)”