Рис. 14.1. Два главных измерения изменчивости процесса.

Схема процесса не является реализацией процесса для конкретного проекта с четко определенным рецептом успеха. Во-первых, потребуется рассудительность, а, во-вторых, методы, способы, культура, формализация и организация должны быть адаптированы под конкретную область для достижения такой реализации процесса, которая приведет к успеху. Следующее ниже обсуждение основных различий в процессах выполнения проектов строится вокруг шести параметров процесса: размера проекта и пяти параметров, которые влияют на экспоненту процесса и, следовательно, на экономию при больших масштабах в модели СОСОМО II. Это лишь некоторые из критичных измерений, которые менеджер проекта по созданию ПО должен принимать во внимание при адаптации схемы процесса для его практической реализации.

Рис. 14.2. Приоритеты для адаптации схемы процесса.

14.1.1 Масштаб.

Возможно, наиболее важным фактором при адаптации схемы процесса по созданию ПО к конкретным требованиям проекта является общий масштаб приложения. Существует множество способов измерения масштаба, включая количество строк исходного кода, количество функциональных точек, количество вариантов использования и количество долларов. С точки зрения адаптации процесса самым главным критерием масштаба является размер команды. По мере роста числа разработчиков важность согласованного межличностного взаимодействия становится первостепенной. В противном случае плата за большой масштаб может оказать серьезное влияние на достижение целей проекта.

Мой опыт участия в проектах показал, что оптимальный размер команды разработчиков составляет пять человек. В ходе проведения множества исследований было установлено, что большинство людей способны управлять четырьмя-семью объектами одновременно. При простой экстраполяции этих результатов можно предположить, что необходимы фундаментально различающиеся подходы к управлению при руководстве командой из 1 человека (тривиальной), из 5 человек (маленькой), из 25 человек (средней), из 125 человек (большой), из 625 (гигантской) и т.д. По мере роста величины команды каждый новый уровень управления персоналом достигается при каждой очередной степени 5. Эта модель может использоваться для описания некоторых различий в процессах для проектов разной величины.

Проектам тривиального размера не требуется никакой управленческой надстройки (планирование, взаимодействие, координация, оценка прогресса, проверка, администрирование). Практически отсутствует необходимость в документировании промежуточных рабочих продуктов. Все рабочие процессы состоят из единственного потока. Ход выполнения в большой степени зависит от личных навыков.

Маленький проект (5 человек) требует очень небольшой управленческой надстройки, но наличие руководства, направляющего команду на достижение общей цели, является критичным. Необходимо распространять среди членов команды промежуточные рабочие продукты. Контрольные точки проекта легко поддаются планирЬванию, легко достигаются и изменяются. В проекте существует незначительное число индивидуальных рабочих процессов. Ход выполнения зависит прежде всего от личных навыков. Зрелость процесса относительно не важна. Индивидуальные инструменты могут иметь решающее влияние на ход выполнения.

Проекты среднего размера (25 человек) требуют умеренной управленческой надстройки, включая ответственного менеджера проекта для синхронизации различных рабочих процессов команды и для равномерного распределения ресурсов. В дополнительные обязанности лидеров команд входят проверка, координация и оценка. Существует определенная необходимость в распространении промежуточных рабочих продуктов среди команд. Контрольные точки проекта планируются и достигаются формально, а влияние изменений обычно является доброкачественным. Число параллельных командных рабочих процессов невелико; каждый из них состоит из нескольких индивидуальных рабочих процессов. Ход выполнения сильно зависит от навыков ключевых сотрудников, особенно лидеров команд. Весьма ценной становится зрелость процесса. Существенное влияние на ход работ может оказать среда, однако успех может быть достигнут за счет использования определенных инструментов.

Большие проекты (125 человек) требуют значительной управленческой надстройки, включая ответственного менеджера проекта и нескольких менеджеров более низкого уровня для синхронизации различных рабочих процессов уровня проекта и последующего уровня, а также для равномерного распределения ресурсов. Увеличивается объем дополнительной работы, которая ложится на лидеров команд и которая направлена на распределение, проверку, координацию и оценку. Совершенно очевидной становится необходимость распространения промежуточных рабочих продуктов среди разнообразных команд для согласования результатов разработки. Контрольные точки проекта планируются и достигаются формально, а внесение изменений в планы контрольных точек оказывается очень дорогим. Требуется наличие большого числа параллельных командных рабочих процессов, каждый из которых состоит из множества индивидуальных рабочих процессов. На ход выполнения большое влияние оказывают навыки ключевых сотрудников, особенно менеджеров второго уровня и лидеров команд. Выполнение проекта зависит от средних сотрудников по двум причинам:.

1.

Любой большой проект включает в себя определенный объем рутинного труда, особенно вспомогательные рабочие процессы.

2.

Мала вероятность того, что удастся нанять, содержать и удержать большое число выдающихся работников.

Зрелость процесса становится необходимой; это касается, в частности, аспектов планирования и контроля при управлении проектом, прогресса и ожиданий заинтересованных сторон. Интегрированная среда должна управлять внесением изменений, автоматизировать создание рабочих продуктов и поддерживать согласованность изменяющихся рабочих продуктов.

Гигантские проекты (625 человек) требуют существенной управленческой надстройки, включая нескольких менеджеров проекта по созданию ПО и множество менеджеров более низкого уровня для различных рабочих процессов уровня проекта и последующих уровней, а также для равномерного распределения ресурсов. Возрастают затраты на дополнительную работу для лидеров команд, направленную на распределение, проверку, координацию и оценку. Совершенно очевидной становится необходимость распространения промежуточных рабочих продуктов среди разнообразных команд. Контрольные точки проекта планируются и достигаются весьма формально, а внесение изменений в планы контрольных точек обычно приводит к проблемам и к необходимости повторного планирования. Существует большое число параллс хьных командных рабочих процессов, каждый из которых состоит из множества индивидуальных рабочих процессов. Ход выполнения сильно зависит от навыков ключевых сотрудников, особенно менеджеров второго уровня и лидеров команд, а также от навыков средних сотрудников.

Зрелость процесса создания ПО и наличие опыта в данной области необходимы для исключения рисков и гарантированной синхронизации ожиданий многих заинтересованных сторон. Всем командам разработчиков требуется развитая интегрированная единая среда, позволяющая управлять изменениями, автоматизировать создание рабочих продуктов, поддерживать согласованность изменяющихся рабочих продуктов и увеличивать отдачу от инвестиций с помощью общих процессов, инструментов, нотаций и метрик.

В таблице 14.1 обобщены некоторые существенные различия между составляющими малых и больших проектов.

Таблица 14.1.

Отличительные особенности процессов, определяемые их размерами

Таблица 14.1. (продолжение).

Отличительные особенности процессов, определяемые их размерами

14.1.2 Сотрудничество или соперничество заинтересованных сторон.

Степень сотрудничества и координации между заинтересованными сторонами (покупателями, разработчиками, пользователями, субподрядчиками, осуществляющими сопровождение и др.) может существенно влиять на особенности определения процесса. Взаимоотношения могут меняться от сплоченности до вражды. У сплоченных команд — общие цели, взаимодополняющие навыки и тесные связи. У враждующих команд — противоречивые цели, конкурирующие или неполные навыки и слабое взаимодействие.

Для продукта, который финансируется, разрабатывается, продвигается на рынок и продается в рамках одной и той же организации, может быть сформулирована единая цель (например, получение прибыли). Внутри маленькой, компактной организации может быть установлен такой порядок, при котором существуют единая база навыков и постоянное взаимодействие между членами команды.

Более трудной задачей является организация большой контрактной работы без наличия соперничества между командами. Подрядчик редко обладает всеми необходимыми знаниями в программной или предметной области и зачастую вынужден объединяться с множеством субподрядчиков, которые имеют конкурентные цели по получению прибыли. Ответственные за финансирование и пользователи стремятся минимизировать стоимость, максимизировать набор возможностей и ускорить выход на рынок, в то время как получившие контракт на разработку стремятся максимизировать прибыль. Большие команды практически невозможно правильно расставить, и синхронизация ожиданий заинтересованных сторон является постоянной проблемой. Все эти факторы способствуют деградации сплоченности команды, и с этим приходится постоянно работать.

В таблице 14.2 обобщены различия в составляющих процесса для разных уровней сплоченности заинтересованных сторон.

Таблица 14.2.

Отличительные особенности, проявляющиеся при разной степени сплоченности заинтересованных сторон

14.1.3 Гибкость или жесткость процесса.

Степень жесткости, формализации и простоты внесения изменений, присущая конкретному «соглашению» о проекте (общей концепции, бизнес-плану и плану разработки) оказывает существенное влияние на выполнение проекта. Управление «свободными» контрактами, такими как создание коммерческого продукта внутри структурного подразделения компании, производящей ПО (например, приложения компании Microsoft или инструменты для разработки корпорации Rational Software), имеет минимальную степень сложности. Для процессов разработки такого рода набор функциональных возможностей, время выхода на рынок, бюджет и качество могут быть легко согласованы и изменены с малыми накладными расходами. Например, если компания принимает решение об исключении нескольких возможностей из продукта, находящегося в процессе разработки, для захвата доли рынка за счет ускорения выпуска продукта, вполне допустимым будет принятие решения менее чем за неделю. Все усилия по координации вполне могут ограничиться соглашением по некоторым ключевым вопросам между менеджером по разработке, менеджером по маркетингу и менеджером структурного подразделения.

С другой стороны, в случае жесткого контракта может понадобиться много месяцев на утверждение тех или иных изменений в графике выпуска версий. Например, для того чтобы избежать большого объема разработок на заказ, нужно включить в очередное поколение системы управления воздушным движением некоторый новый коммерческий продукт. Такого рода изменения потребуют согласования с подрядчиком разработки, финансирующим органом, пользователями (возможно, с профсоюзом диспетчеров воздушного сообщения и основными авиакомпаниями), сертифицирующими органами (такими, как Федеральная администрация по авиации), смежными подрядчиками для утверждения интерфейсов взаимодействующих систем и др. Для крупномасштабных, критичных к отказам систем характерны всеобъемлющая жесткость контрактов и использование существенно отличных подходов к управлению. В таблице 14.3 обобщены основные различия в составляющих процесса для разных уровней его гибкости.

Таблица 14.3.

Отличительные особенности, проявляющиеся при различиях в степени гибкости процесса

Таблица 14.3. (продолжение).

Отличительные особенности, проявляющиеся при различиях в степени гибкости процесса

14.1.4 Зрелость процесса.

Уровень зрелости процесса, присущий данной организации-разработчику, как это определено в модели Capability Maturity Model, предложенной Software Engineering Institute [SEI, 1993; 1993b; 1995], является еще одним ключевым фактором, влияющим на сложность управления. Управлять зрелым процессом (уровень 3 или выше) гораздо проще, чем незрелым процессом (уровни 1 и 2). Организации, обладающие зрелым процессом, обычно располагают более высоким уровнем предшествующего опыта в области разработок ПО и высоким уровнем дополнительного обеспечения, которое способствует предсказуемости в планировании и в осуществлении процесса. Такого рода дополнительное обеспечение включает в себя четко определенные методы, инструменты для автоматизации процесса, обученный персонал, метрики планирования, шаблоны рабочих продуктов и рабочих процессов. Адаптация процесса со зрелой организацией под конкретный проект является, вообще говоря, простой задачей. В таблице 14.4 представлены ключевые различия в составляющих процесса для различных уровней его зрелости.

Таблица 14.4.

Отличительные особенности, проявляющиеся при различиях в степени зрелости процесса

Отличительные особенности, проявляющиеся при различиях в степени зрелости процесса

14.1.5 Архитектурный риск.

Степень технической осуществимости, демонстрируемая перед переходом к полномасштабному производству, является важным измерением при определении специфики процесса в данном проекте. Существует много потенциальных источников архитектурного риска. К наиболее важным и повторяющимся относятся работа системы (использование ресурсов, время реакции, пропускная способность, точность), простота внесения изменений (добавление новых возможностей, включение новой технологии, настройка на динамически изменяющиеся условия работы) и надежность системы (предсказуемое поведение, устойчивость к отказам). Та степень, с которой удается избавиться от этих рисков до начала производства, приводит к разительным отличиям в процессе адаптации. В таблице 14.5 приведены ключевые различия в составляющих процесса для разных уровней архитектурного риска.

Таблица 14.5. (продолжение).

Отличительные особенности, проявляющиеся при различиях в степени архитектурного риска

14.1.6 Опыт в предметной области.

Опыт в соответствующей области знаний, которым обладает организация-разработчик, оказывает влияние на способность достижения приемлемой архитектуры за минимальное число итераций. Организация, которая разработала пять поколений коммутаторов, управляющих радарами, в состоянии достичь адекватной базовой архитектуры для нового приложения, связанного с радарами, за две или три итерации по выпуску прототипа. Организации, имеющей большой опыт в создании ПО, но разрабатывающей свое первое приложение, связанное с радарами, может потребоваться четыре или пять версий прототипов, прежде чем она сумеет достичь такого же результата. В таблице 14.6 обобщены ключевые различия в составляющих процесса для разных уровней опыта в предметной области.

Таблица 14.6.

Отличительные особенности, проявляющиеся при различиях в опыте, имеющемся в предметной области

Таблица 14.6. (продолжение).

Отличительные особенности, проявляющиеся при различиях в опыте, имеющемся в предметной области__