Рекомендуемые методики модели процессов MSF
Нижеследующие сопроводительные методики призваны помочь проектным группам в применении модели процессов MSF в их работе.
Стимулируйте изобретательность расширяя функциональность и ограничивая ресурсы
Общий подход Майкрософт к разработке продуктов – это ограничение ресурсов и бюджета разработки. Это стимулирует изобретательность, форсирует принятие решений и оптимизирует сроки выпуска.
Фиксируйте календарный график
Внутренние временные ограничения (известные как “временной ящик” - “time-boxing”) мобилизуют проектную группу и заставляют ее приоритезировать функциональность и деятельность.
Календарное планирование на неопределенное будущее
Добавляйте временной буфер в календарный график проекта, чтобы дать проектной группе возможность отреагировать на неожиданно возникающие проблемы и изменения. Величина этого буфера должна зависеть от уровня проектных рисков. При проведении ранней оценки рисков может быть определено влияние на календарный график наиболее вероятных из них, и это влияние следует компенсировать временным буфером адекватной длины.
Длительность дополнительного временного буфера может рассматриваться в качестве оценки ожидания длительности неизвестных задач и событий. Независимо от опыта сотрудников не все проектные задачи могут быть оценены заранее. Также учитывайте, что некоторые проектные риски воплотятся в реальность, и это повлияет на ход проекта. Необходимые корректирующие меры займут дополнительное время.
|
|
|
При выборе временного буфера рекомендуется учитывать следующее:
Не добавляйте буферы в качестве резерва времени для запланированных задач. Так как работа всегда разрастается на все отведенное ей время (закон Паркинсона), такой буфер будет поглощен этими же самыми запланированными задачами, а не использован для реакции на непредвиденные события.
Буферное время должно выделяться как будто бы под дополнительно существующую задачу. Обычно буфера создаются перед главными вехами, особенно позднейшими из них. Временные буфера всегда должны дополнять критический путь проекта (project’s critical path). Критический путь – это наидлиннейшая цепь зависимых проектных задач, непосредственно определяющая сроки проекта.
Использование буферного времени по ходу проекта должно подвергаться жесткому контролю.
Если потребовалось расширить функциональность решения или уменьшилось количество доступных ресурсов, не компенсируйте это использованием буферного времени. Если вы поступите таким образом, вы ослабите свою возможность адекватного реагирования на риски. Согласовывайте баланс возможностей, ресурсов и сроков при помощи треугольника компромиссов, показанного на рис. 5.
|
|
|
Если буферное время исчерпано, поставьте в известность всю проектную группу о том, что любой сбой или задержка будут ударом по работе над проектом и создадут опасность выхода из временных рамок.
Используйте параллельно работающие компактные команды
с частой синхронизацией усилий.
Даже в больших и сложных проектах проектная группа может быть разделена на меньшие, более эффективные команды, работающие параллельно, - при условии, что эти команды периодически синхронизируют свою деятельность и результаты работы. Такой подход фокусирует внимание сотрудников на общем качестве работы, помогает менеджерам программы контролировать прогресс и упрощает отчетность внутри каждой из команд.
Разбивайте большие проекты на осуществимые части
Фундаментальной стратегией Майкрософт является разбиение больших проектов на многие версионированые выпуски без (или с минимально короткой) отдельной фазы сопровождения.
Извлекайте уроки из пройденных вех
На каждой главной вехе проектная группа, заказчик и другие заинтересованные стороны проводят собрание, посвященное анализу достигнутых на соответствующей фазе результатов и оценке общего прогресса в работе над проектом. В больших проектах подобные собрания проводятся также во время промежуточных вех.
|
|
|
Непосредственно после этих собраний проектная группа проводит внутренний анализ своей деятельности, чтобы оценить ее качество и эффективность. Этот анализ может рассматриваться как часть деятельности по контролю за качеством (quality assurance), которая в определенных ситуациях может активизировать триггер изменения управления проектом.
Часто по ходу работы над проектом персональный состав проектной группы меняется. Непременно получите от покидающих проектную группу сотрудников всю полезную для коллективного извлечения уроков информацию во время главных вех – до того, как эти сотрудники вышли из группы.
Используйте прототипирование
Прототипирование дает возможность до того, как осуществлена разработка, проводить тестирование с точки зрения многих аспектов, в особенности – удобства эксплуатации. Это помогает лучше понять взаимодействие пользователя с решением и усовершенствовать спецификации продукта.
Дата добавления: 2019-01-14; просмотров: 88; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!