|
|
|
Ваши замечания и предложения отправляйте редактору По техническим вопросам обращайтесь к вебмастеру Дата публикации: 20.10.03 | |
© Зайцев С.Л.
Вы являетесь руководителем проекта и хотели бы использовать методологию RUP. В Данная статья представляет собой справочное руководство, разъясняющее роль руководителя проекта в разработке ПО с использованием RUP. Здесь вы найдете определение роли руководителя проекта и описание ее взаимодействия с другими ролями. Мы также представим вводную информацию по ключевым артефактам, которые должен разрабатывать и использовать руководитель проекта. В конце мы предоставим обзор некоторых ключевых задач RUP, в решение которых вовлечены руководители проектов.
Существует масса причин, по которым проект может провалиться или привести к неудовлетворительным результатам. Многие из подобных причин могут быть связаны с различными техническими обстоятельствами, что зачастую достаточно быстро и охотно признается; технология является весьма подходящим и безответным козлом отпущения. Но авторы и консультанты, такие как Роджер Прессман (Roger Pressman), принимавшие участие в освидетельствовании многих проектов, утверждают следующее: “Если бы для каждого проекта проводилась посмертная оценка, то весьма вероятно, что обнаружилось бы одно общее обстоятельство: Неэффективное управление проектом”.
“Персонал, продукт, процесс, проект — именно в этом порядке”, - вот как тот же Роджер Прессман определяет функциональные границы управления проектами разработки ПО.
Руководителю программного проекта следует полагаться только на результаты, а не на героические усилия, искренние намерения, использование правильного процесса или же неотступное следование "учебнику". Поэтому на протяжении всего жизненного цикла разработки руководитель проекта должен фокусировать свое внимание на окончательных или на каких-либо промежуточных результатах, приближающих процесс к успешному завершению. Проект RUP является результатом совместных усилий нескольких сторон, среди которых и руководитель проекта. Учитывая динамический контекст итеративной разработки, роль руководителя проекта отражается скорее фразой "направлять и адаптировать", чем "планировать и отслеживать выполнение" (практика, обычно используемая при работе над обычными проектами).
Поэтому роль руководителя проекта сложна и требует многих различных навыков, необходимых для динамического управления и адаптации:
Вероятно, при работе над большими проектами роль руководителя проекта придется выполнять нескольким сотрудникам.
Мы склоняемся к мнению, что на должность руководителя проекта следует назначать одного сотрудника. И в большинстве от малых до средних проектов (от 3 до 15 человек), только один сотрудник будет выполнять эту роль. Но RUP описывает руководителя проекта не как персону, а как роль, которую эта персона будет выполнять, и есть вероятность, что при работе над большими проектами эту роль будут выполнять несколько персон. Тем не менее, разумно существование лишь одного явного лидера проекта, но, управляя проектом, этот сотрудник не должен ощущать потребности в выполнении всех задач RUP.
Прежде всего, может существовать небольшая группа сотрудников, осуществляющая руководство проектом. Один сотрудник может заниматься планированием; другой - иметь дело с некоторыми ключевыми коммуникационными интерфейсами, с менеджерами по продукту или заказчиком; еще один может отслеживать ход внутренних работ. Следует иметь в виду, что некоторые из этих специализаций уже учтены в RUP, где определены более одной роли руководителя; существуют роли руководителей с соответствующей специализацией, например, менеджер по конфигурации, менеджер по развертыванию, менеджер по тестированию и инженер по процессу разработки.
Кроме того, для более крупных организаций-разработчиков ПО, скажем, с коллективом больше 25 сотрудников, общепринятой практикой является разбиение организации на менее крупные группы, с последующим делегированием каждой группе части полномочий роли руководства проектом. Другими словами, руководитель проекта делегирует некоторые из рутинных управленческих задач, приобретая "глаза и уши" на различных участках работ.
В крупных проектах некоторые группы могут быть сформированы для выполнения определенных управленческих задач более формальным образом и для поддержки руководителя проекта:
Эти группы формируются из сотрудников, имеющих соответствующую квалификацию и полномочия, иногда из людей, работающих в режиме полной занятости, и функционируют по мере необходимости, обеспечивая поддержку управленческой группы.
“Управление проектом является результатом приложения знаний, навыков, применения инструментальных средств и техник к проектным задачам с целью достижения соответствия потребностям и ожиданиям лиц, заинтересованных в проекте.”
Достижение и даже превышение результатов, ожидаемых от проекта со стороны заинтересованных лиц, несомненно, включает балансирование между взаимопротивоположными требованиями
Здесь следует сделать важное замечание. Методология RUP сознательно не затрагивает всех аспектов управления проектами, фокусируясь главным образом лишь на технических аспектах.
Несмотря на то, что мы написали выше относительно первого "П", Персонала, процесс управления проектом в RUP не затрагивает многих аспектов, относящихся к управлению сотрудниками в коллективе — всего, что относится к работе с кадрами. Поэтому в RUP вы не найдете указаний, как нанимать, обучать, оплачивать, оценивать или дисциплинировать людей.
Аналогично, RUP не затрагивает никаких финансовых вопросов, таких как бюджет, распределение, учет или составление отчетов. Кроме того, в RUP не рассматриваются юридические или договорные вопросы, приобретение и сбыт, лицензирование и работа с субподрядчиками. Также RUP не имеет дела с некоторыми административными вопросами, связанными с персоналом, финансами и проектами.
Для всех этих тем во всем мире существует широкий диапазон практик, вместе с легко доступной обширной информацией, не связанной конкретно с разработкой ПО.
Одним из наиболее ценных источников информации является Руководство к совокупности знаний по управлению проектами (PMBOK), разработанное с помощью Института управления проектами (PMI) и принятая комитетом IEEE в качестве Стандарта 1490-1998, Адаптация руководства PMI для PMBOK.
Вместе с этим RUP фокусируется на программно-специфических аспектах управления проектами, т.е. на областях, где определяющую роль играет сама природа программного обеспечения. Задачи, не затрагиваемые методологией RUP, отнимают значительное количество усилий и времени и требуют наличия определенных навыков. Поэтому они не должны оставаться не выявленными при назначении управляющих проектом сотрудников.
Довольно трудно сжать управление проектом разработки ПО до набора общеупотребительных рецептов, но выработка общего алгоритма является достаточно хорошей практикой.
Мы считаем, что в настоящее время руководитель проекта должен уделять максимальное внимание следующим направлениям:
В соответствии с этим, ключевой артефакт руководителя проекта будет сфокусирован на Плане разработки продукта, причем этот план является зонтичным артефактом, содержащим много различных планов, каждый из которых предназначен для одной из функций управления:
Для лучшей ясности, визуализации и отчетности План разработки программного обеспечения может быть отнесен к формальным (обязательным) артефактам проекта.
По мере продвижения хода работ эти планы уточняются, корректируются и улучшаются, что и ожидается от процесса итеративной разработки; с целью достижения улучшений создаются другие тактически важные артефакты. Эти артефакты обычно используют мгновенный снимок проекта, на основе которого принимаются некоторые тактические решения:
Одним из важных аспектов SDP является более точное определение процесса, который будет использовать проект: в этом и состоит роль описания процесса разработки проекта. Руководитель проекта также должен установить и поддерживать соответствующую степень формальности, или адекватного для данного проекта “уровня церемониальности”, как называет его Грейди Буч. И это описание процесса разработки также будет эволюционировать с продвижением проекта, основываясь на уроках, полученных при каждой итерации.
Итеративная разработка является лейтмотивом данной статьи, но не помешает сказать об этом еще раз. В итеративной обработке вам не нужно, однажды составив план, затем заниматься лишь мониторингом проекта, пытаясь удержать его в рамках запланированных затрат. Вы планируете и затем перепланируете, делая это снова и снова. Таким образом, вы можете оказаться в ситуации, отличной от той, которая прогнозировалась в первоначальном плане, но вы найдете, что эта ситуация будет не хуже планируемой, или же более скромной, но вместе с тем более реалистичной, что естественно лучше, чем отсутствие каких-либо результатов.
Если вы никогда не руководили итеративным проектом, то вполне вероятно, что первоначально вы будете в замешательстве.
Для реализации эффективного управления итеративной разработкой, второй концепцией для начинающего менеджера RUP является знание и постоянное внимание к наличию риска. В действительности имеется много рисков различной интенсивности и вероятности, которые могут влиять на проект разработки ПО. Управление проектом разработки не является бездумным применением набора рецептов и шаблонов к созданию прекрасных планов, достойных быть высеченными на мраморе, с последующей передачей для выполнения группе разработки. Управление проектом включает постоянное отслеживание и быстрое реагирование на новые риски, новые события, ситуации и изменения, которые могут отрицательно влиять на проект. Преуспевающий руководитель проекта является тем, кто дотошно выясняет у членов группы подробности технологии, спрашивает "почему", "зачем" и снова "зачем" - все это для идентификации новых, неожиданных рисков, и применения соответствующих рецептов для их избежания.
Другим ключевым словом для руководителя проекта RUP являются метрики. Во избежание увода в сторону за счет субъективности или недостатка знаний, руководитель проекта устанавливает некоторые объективные критерии для отслеживания (более или менее автоматического) некоторых аспектов проекта. Эти критерии могут использоваться для сбора таких характеристик, как затраты, уровень завершенности (как много функциональности реализовано), покрытие тестирования (как много протестировано), и дефекты (обнаруженные и исправленные), а также отслеживания изменений этих показателей со временем. Другие полезные метрики предназначены для отслеживания изменений во времени: объемы брака или переработки, или хаотические изменения в требованиях, которые могут отслеживаться с помощью хорошей системы конфигурационного управления. Опытный руководитель проекта захочет максимально автоматизировать сбор подобных метрик, чтобы высвободить больше времени для задач, требующих более интенсивного межличностного общения.
Метрики, собранные для текущего проекта и для предшествующих проектов, являются тем, что сможет помочь группе разработчиков провести оценку, в частности оценку объема работ. Эти оценки лежат в сфере совместной ответственности руководителя проекта и остальной группы разработки. Руководитель проекта не должен устанавливать эти метрики в одностороннем порядке.
Итак, чем же конкретно по методологии RUP занимается руководитель проекта?
В RUP все задачи сгруппированы по темам:
Основываясь на первоначальном документе Концепции системы, руководитель проекта разрабатывает первоначальное экономическое обоснование, сопоставляющее функциональные границы проекта (вместе с ожидаемой продолжительностью и затратами) и потенциальную прибыль. Концепция системы отражает истинный смысл требований: чего именно вы хотите достичь. В Экономическом обосновании формулируются основные причины реализации данного проекта. Прежде чем проект будет инициирован и утвержден, Концепция системы и Экономическое обоснование проекта должно быть пересмотрено много раз. Следует как можно раньше начать идентификацию рисков, т.е. любых событий, которые могут неблагоприятно повлиять на проект или вообще привести к невозможности его завершения. Эти риски будут первостепенными вопросами, решением которых следует заняться на следующей итерации проекта.
В зависимости от функциональных границ и размера проекта, руководитель проекта будет создавать некоторые или же все SDP. Организация может уже иметь разработанные готовые для использования шаблоны, с уже заполненными готовыми сегментами, которые будут более подходящими, чем уже имеющиеся в RUP.
Имеются два важных раздела SDP:
Другие планы описывают конфигурационное управление, документирование, тестирование, инструментальные средства, и т. п. атрибуты разработки.
Руководитель проекта будет проводить более подробное планирование объема работ и целей фаз и итераций, указав критерии успеха, которые будут использованы для оценки работы на соответствующих этапах. Эти задачи потребуют расширенного взаимодействия со всеми членами группы, не могут быть выполнены в башне из слоновой кости. Каждая фаза и итерация потребуют соответствующего комплектования персоналом с последующим распределением задач среди членов группы.
После завершения итерации (или фазы с основными этапами), руководитель проекта получит доступ к результатам итерации или фазы, и сравнит их с ожидаемыми результатами, приведенными в SDP. Расхождения приведут к пересмотру планов или к формированию других функциональных границ проекта. Сам процесс может быть улучшен.
Например, при обзоре предварительно идентифицированных рисков (“Интеграция технологии X со связующим ПО Y”), вы пришли к выводу, что вы действительно успешно интегрировали эту технологию в прототип и протестировали ее, устранив таким образом данный риск.
В качестве непрерывно выполняемой задачи руководитель проекта будет использовать некоторые индикаторы для отслеживания хода проекта и сравнения его с планами. Это может делаться на различных уровнях формальности и использовать комбинацию метрик (такую как обнаружение дефектов и процент их устранения) и рецензий (неформальных и формальных) для оценки соблюдения планов и достижения качества продукта.
Например, если частота обнаружения дефектов значительно падает, это является сигналом о том, что (а) работы по тестированию ведутся неэффективно, (b) что новые сборки системы не привносят какой-либо существенной функциональности, или же (c) продукт просто становится стабильным.
Существует, по крайней мере, одна оценка за итерацию, и кое-что более формальное при закрытии фазы, так как эти главные этапы проекта могут включать некоторые стратегические решения, относящиеся к выполнению проекта. Эти этапы являются моментами, когда могут рассматриваться отмена или значительное изменение функциональных границ проекта.
Для того, что начать работу с RUP, жизненно важно, чтобы руководитель проекта хорошо понимал концепцию итеративной разработки и жизненный цикл RUP (фазы и итерации). Кроме того, существуют некоторые ключевые концепции: управление рисками, качество, метрики, а также то, как описывается процесс (роли, задачи, артефакты). При необходимости обратитесь за определениями в словарь RUP. Если вы хорошо знакомы с тематикой руководства проектами, но незнакомы с итеративными проектами разработки ПО, то основной объем обучения можно получить в области RUP, относящейся к планированию, в частности планированию итеративных проектов.
Вы можете начать знакомство с RUP с раздела Роль: Руководитель проекта и изучить различные задачи, определяющие эту роль. Альтернативно, можно начать с раздела Артефакт: План разработки продукта (его шаблона и некоторых примеров). Отсюда можно перейти к различным задачам, связанным с разработкой этого плана, или, формулируя более точно, к разработке различных планов, которые он содержит. Это приведет вас к более специализированным ролям менеджера по конфигурационному управлению, менеджера по тестированию и т.д.
В небольших проектах или в небольших организациях-разработчиках ПО весьма вероятно, что тот же сотрудник, который выполняет роль руководителя проекта, также будет выполнять обязанности инженера процесса, определяя описание процесса разработки проекта, обеспечивая принятие процесса, и участвуя в работах по улучшению процесса как результата оценки итерации (или проекта). Затем см. раздел Роль: Инженер процесса.
Не следует забывать, что руководитель проекта будет взаимодействовать со многими другими ролями и в той или другой форме принимать участие в решении соответствующих задач. В частности, руководитель проекта практически ежедневно должен будет координировать работу Архитекторов, а также участвовать в составлении различных рецензий.
Следование определенному процессу, такому как экземпляр RUP, ни в коем случае не является для руководителя проекта путем уклонения от ответственности и отказа от чувства здравого смысла. Эта работа не является механической разработкой каких-либо артефактов, описанных в RUP, в надежде на то, что процесс пойдет в правильном направлении. Задача не состоит в распределении всех задач RUP для членов группы с последующим выражением недоумения, "Да я же просто следовал RUP! Совершенно не понимаю, почему проект провалился". Для достижения успеха вам следует выбрать в RUP правильный набор артефактов, правильные методы и техники, и адаптировать их к вашему контексту. Вы должны обладать глубоким пониманием проекта и продукта, и уметь работать с архитектором, аналитиками, разработчиками и тестировщиками.
Вы будете оценивать конкретные результаты, а не то, что вы все делаете в соответствии с правилами. Ваша роль состоит в направлении и постоянной адаптации процесса по мере развития проекта, и в решении, какие артефакты и какие задачи приносят конкретные результаты. Для того, чтобы это выполнить, вы должны быть глубоко вовлечены в жизнь проекта, с технической точки зрения, для быстрого понимания ключевых решений, которые могут быть приняты, для более полного использования доступных возможностей с целью получения более полных результатов, для руководства функциональными границами и "размером" проекта. Эту работу можно эффективно выполнить только в режиме сотрудничества, но не при помощи введения жесткой бюрократии и установки дистанции между руководством проекта и остальной группой.
Также следует помнить о том, что все управленческие задачи, не описанные в RUP, также являются очень важными. Вы управляете не машинами; вы управляете не поведением; вы управляете людьми. Вы не должны ходить вокруг сотрудников и говорить им, что делать, указывая при этом на RUP. Вы устанавливаете цели и создаете культуру разработки ПО, культуру, основанную на сотрудничестве и доверии. Подобного можно достичь лишь при наличии постоянно высокого уровня коммуникации.
Итак, подведем итоги:
За дополнительной информацией обращайтесь в компанию Interface Ltd.
| INTERFACE Ltd. |
| ||||