1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom

Оценка трудоемкости создания программного обеспечения 471

В идеальной ситуации итерация длится от двух до шести не­ дель, хотя в действительности это зависит от характера проекта и размера организации-разработчика. Приведем несколько приме­ ров.

•Группа из пяти человек может выполнить некоторое плани­ рование в понедельник утром, наблюдать за ходом проекта и перераспределять задания во время ежедневных совместных обедов, начать конструирование во вторник, а завершить итерацию в пятницу вечером.

•Если попытаться применить этот сценарий для фуппы из 20 человек, то это окажется затруднительным. Распределение работы, синхронизация подгрупп и интеграция будут зани­ мать больше времени. В этом случае итерация может занять три—четыре недели.

•Если же фуппа будет состоять из 40 человек, то только неде­ ля уйдет на прохождение указаний от руководства к исполни­ телям. Нужны промежуточные уровни управления; кроме то­ го, достижение общего понимания целей потребует большей формальности и документирования. В этом случае разумной продолжительностью итерации будет уже три месяца.

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

После того как определена приемлемая длительность итера­ ции, следует определить число итераций на каждой стадии.

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

только с планированием и маркетингом. Одна итерация все же может потребоваться для создания прототипа, предназначенного смягчить последствия от реализации основных технических ре­ шений.

На стадии разработки нужна, как минимум, одна итерация. Если отсутствует начальная архитектура и нужно адаптироваться к новым инструментальным средствам, технологиям, платформе или языку профаммирования, то следует планировать две—три итерации. Возможно, потребуется продемонстрировать прототип заказчику или конечным пользователям, чтобы уточнить требо­ вания. Кроме того, дополнительная итерация может потребо­ ваться для исправления ошибок, допуш^енных при разработке ар­ хитектуры.

На стадии конструирования также нужно запланировать не менее одной итерации, при этом количество итераций зависит в основном от реализуемой функциональности (количества вари­ антов использования).

На стадии ввода в действие нужна, как минимум, одна итера­ ция, например, для выпуска окончательной версии после бетаверсии.

В итоге можно определить три уровня проведения полного цикла разработки (табл. 6.21).

Таким образом, можно принять в качестве эмпирического правила, что средний итерационный проект включает 6 ± 3 ите­ рации.

! Следует запомнить

1.Оценка трудоемкости создания ПО является одним из наи­ более важных видов деятельности в процессе создания ПО.

Оценка трудоемкости создания программного обеспечения 473

2.Модели и методы оценки трудоемкости необходимы для разработки бюджета проекта, анализа степени риска и вы­ бора компромиссного решения, планирования и управле­ ния проектом, анализа затрат на улучшение качества ПО.

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

^ Основные понятия

Функциональный тип, функциональная точка.

?Вопросы для самоконтроля

1.К каким последствиям могут привести недооценка и пере­ оценка стоимости, времени и ресурсов, требуемых для соз­ дания ПО?

2.На какой стадии проекта и с какой точностью может вы­ полняться оценка трудоемкости создания ПО?

3.Охарактеризуйте и сравните методы оценки трудоемкости создания ПО.

4.Что означает хорошая оценка трудоемкости?

5.В каких единицах измеряется размер ПО?

6.Какие факторы наиболее значительно влияют на трудоем­ кость создания ПО?

ШГЛАВА-Т;

ОСОБЕННОСТИ СОВРЕМЕННЫХ ПРОЕКТОВ

Прочитав эту главу, вы узнаете:

•В каких условиях выполняется большинство современных проек­ тов создания ПО.

•Какую роль играет человеческий фактор в «безнадежных» проек тах.

•Какие процессы, средства и технологии являются предпочти­ тельными в «безнадежных» проектах.

В последнее время множество проектов создания ПО выпол­ няется в экстремальных условиях. Независимо от причин такие «смертельные марши» (по определению Эдварда Йордона, одно­ го из ведущих мировых консультантов), или «безнадежные» про­ екты, предъявляют особые требования к используемым методам управления, технологиям и средствам. Эти требования наиболее полно (и не без юмора) изложены в книге Эдварда Йордона «Death March»^ выпущенной издательством Prentice-Hall в 1997 г и в 2003 г (второе издание).

7 . 1 . КАТЕГОРИИ «БЕЗНАДЕЖНЫХ» ПРОЕКТОВ

Далеко не все «безнадежные» проекты одинаковы; помимо ог­ раничений в планах, штатах, бюджете и функциональности, они могут иметь различные масштабы, формы и другие особенности.

Наиболее важной отличительной характеристикой «безна­ дежного» проекта является его масштаб. В зависимости от масш­ таба можно выделить четыре категории проектов:

^ Йордон Эд. Путь камикадзе: Пер. с англ. — М.: ЛОРИ, 2001 (в настоя­ щее время готовится перевод второго издания).

• небольшие проекты — проектная команда включает менее 10 человек, работает в исключительно неблагоприятных ус­ ловиях и должна завершить проект в срок от 3 до 6 месяцев;

•средние проекты — проектная команда включает от 20 до 30 человек, протяженность проекта составляет 1—2 года;

•крупномасштабные проекты — проектная команда включа­ ет от 100 до 300 человек, протяженность проекта составляет 3-5 лет;

•гигантские проекты — в проекте участвует армия разработ­

чиков от 1000 до 2000 человек и более (включающая, как правило, консультантов и соисполнителей), протяженность проекта составляет 7—10 лет.

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

До сих пор остались без ответа вопросы, почему вполне ра­ зумные организации предпринимают подобные проекты и поче­ му разумные менеджеры и технические специалисты соглашают­ ся в них участвовать. Эти вопросы будут рассмотрены ниже.

7.2. ПРИЧИНЫ, ПОРОЖДАЮЩИЕ «БЕЗНАДЕЖНЫЕ» ПРОЕКТЫ

Такие проекты порождаются самыми различными причинами:

•высокая конкуренция, вызванная появлением новых ком­ паний на рынке или новых технологий;

•сильное воздействие неожиданных правительственных ре­ шений;

•неожиданный и (или) незапланированный кризис;

•политические «игры» высшего руководства;

•наивный оптимизм и менталитет первопроходцев у неопыт­ ных разработчиков.

Многие «безнадежные» проекты связаны с применением в первый раз новых технологий. Достаточно вспомнить первые проекты, связанные с объектно-ориентированной технологией, технологией «клиент-сервер», реляционными базами данных или Internet. Некоторые из них носили экспериментальный характер и имели целью извлечение потенциальных выгод из новой техно­ логии, однако другие, вероятно, были ответом конкурентам, внедрившим такую же технологию. В последнем случае такие проекты могут быть непомерно большими, а также отягощенны­ ми чрезвычайно агрессивными планами и бюджетами.

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

Наиболее распространенные причины, побуждающие разра­ ботчиков участвовать в «безнадежных» проектах, можно охарак­ теризовать следующим образом:

•высокое вознаграждение;

•синдром покорителей Эвереста;

•наивность и оптимизм молодости;

•угроза безработицы;

•возможность будущей карьеры;

•возможность победить бюрократию.

Наилучший пример данной ситуации — это работа в начина­ ющей компании. Если заверить участников проекта, что его ус­ пех принесет компании всеобщую известность, а им поможет стать миллионерами, то они с радостью будут работать до изне­ можения. Конечно, они могут отдавать себе отчет в рискованнос­ ти этой затеи, но, поскольку многие верят, что они всемогущи и бессмертны, они не обратят особого внимания на риск.

Разумеется, самоуверенность участников проекта выручает в ситуациях, когда обычные проектные команды терпят пораже­ ние. Тот факт, что наиболее успешные продукты - от Lotus 1-2-3 до Netscape Navigator - были разработаны небольшими команда­ ми в условиях, неприемлемых для нормальных людей, уже стал фольклором в индустрии ПО. Такие проекты, заканчиваясь ус­ пешно, приносят проектной команде известность и славу; даже

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

Важно отметить, что наивность и оптимизм молодости обыч­ но сочетаются с офомной энергией, целеустремленностью и от­ сутствием таких помех, как семейные отношения. Гораздо чаще можно встретить 22-летнего программиста, который готов и жаждет участвовать в «безнадежном» проекте со 100-часовой ра­ бочей неделей в течение года или двух, чем 35-летнего женатого программиста с двумя детьми и весьма умеренной склонностью к покорению горных вершин. Молодой программист, желающий участвовать в «безнадежном» проекте, а также относительно мо­ лодой менеджер проекта, дающий оптимистические обещания начальству, как бы утверждают: «Разумеется, мы обеспечим успех этого проекта и сокрушим все препятствия на своем пути!»

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

Технические специалисты и менеджеры проектов часто жалу­ ются, что их корпоративные бюрократы мешают продуктивно ра­ ботать и задерживают разработки ПО. Чем крупнее организация, тем сильнее бюрократия, особенно в тех организациях, где служ­ ба стандартов требует строгого соблюдения требований SEIСММ или ISO-9000. Аналогично департамент по управлению персоналом может использовать процедуры скрупулезной про­ верки каждого вновь принимаемого на работу сотрудника или стороннего разработчика, привлекаемого к участию в проекте.

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

ловиях требуются в полном объеме. Не менее важно и то, что ме­ неджер проекта получает большую свободу действий в подборе участников проектной команды, чем в обычных условиях.

Следует отметить, что некоторые аналитики смотрят на проб­ лему оптимистично; они полагают, что количество «безнадеж­ ных» проектов в последующие годы будет уменьшаться. Причи­ ны такого уменьшения: а) рост корпоративной культуры 1Т-ком- паний; б) обучение разработчиков различным методам обеспече­ ния качества в сочетании с «быстрой» разработкой ПО.

7.3. ПРИЧИНЫ РАЗНОГЛАСИЙ МЕЖДУ УЧАСТНИКАМИ ПРОЕКТА

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

В условиях «безнадежного» проекта наиболее очевидным ис­ точником политических споров и дискуссий являются времен­ ные, бюджетные и ресурсные ограничения. Если бы с ресурсами было все в порядке, то не было бы и предмета для обсуждения.

Однако существуют и другие источники разногласий. Неко­ торые из них очевидны для любых разработчиков, например спо­ ры по поводу спецификации требований: она действительно от­ ражает реальные требования пользователей или является неадек­ ватной и неполной. Это особенно актуально для «безнадежных» проектов, поскольку не хватает времени на интервьюирование конечных пользователей, формальное документирование, согла­ сование и утверждение их требований. Большинство профессио­ налов понимает, что это может стать серьезной проблемой и в нормальном проекте, поэтому растет интерес к прототипированию, итерационной разработке и другим подобным методам.

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

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

Кроме этих проблем существует еще один источник полити­ ческих дебатов: разногласия по поводу статуса проекта, вероятнос­ ти его успешного завершения и действий, которые необходимо предпринять, если проект выбьется из графика и/или бюджета.

В любом случае политические разногласия могут привести к существенным задержкам в проекте, что само по себе является серьезной проблемой цдя «безнадежного» проекта. Одним из воз­ можных решений особенно в случае разногласий относительно функциональности и других требований к системе является про­ ведение JAD-сессий (JAD — Joint Application Development), в ко­ торых участвуют все заинтересованные лица, пытаясь выработать общее решение в серии коротких, но интенсивных совещаний.

Если это невозможно, менеджеру проекта следует добиться согласия основных заинтересованных лиц на то, что все реше­ ния, требующие их согласования или утверждения, будут рас­ сматриваться в течение 24 часов. Хорошим примером такой стра­ тегии является обсуждение «экстремальное» программирование.

7.4. ПЕРЕГОВОРЫ В «БЕЗНАДЕЖНОМ» ПРОЕКТЕ

Предположим, что проектная команда подготовила «разум­ ную» оценку плана, бюджета и персонала, требуемых для «безна­ дежного» проекта, и руководство готово пойти на переговоры перед тем, как принять окончательное решение. Наиболее веро­ ятно, что руководство объявит первоначальную оценку «непри-

480 Глава 7

емлемой» и выдвинет свои требования, которые окажутся более жесткими. Как в этом случае поступить менеджеру проекта?

Если контрпредложение со стороны высшего руководства или заказчика содержит только одну «переменную», менеджер проекта может оценить влияние остальных переменных. Напри­ мер, если первоначальная оценка менеджера проекта заключает­ ся в том, что проект потребует 12 месяцев на реализацию, трех разработчиков и бюджет $200 000, вполне вероятно, что первой реакцией руководства будет: «Вздор! Нам нужно, чтобы система была готова и работала через шесть месяцев!» На первый взгляд, очевидный способ сделать это заключается в увеличении штата и/или бюджета (например, увеличить зарплату, чтобы привлечь более продуктивных программистов).

С другой стороны, Фредерик Брукс уже более 30 лет назад от­ мечал, что зависимость между количеством разработчиков и вре­ менем разработки носит нелинейный характер, поэтому термин «человеко-месяц» был объявлен мифом. Практически все зави­ симости между основными переменными проекта являются не­ линейными и зависящими от времени. Вследствие эффекта «об­ ратной связи», возникающего в результате многих решений руко­ водства, изменение одной переменной (например, увеличение штата) повлияет со временем не только на другие переменные (продуктивность), но и на собственное первоначальное значение. Например, увеличение штата может отрицательно сказаться на моральном состоянии команды, что повлечет за собой текучесть кадров. В результате уменьшится численность персонала.

Переговоры — это игра, которая имеет место во всех проектах. Переговоры в «безнадежных» проектах характеризуются тем, что ставки гораздо выше, эмоции перехлестывают через край, а зап­ росы противоположной стороны (в терминах плана, бюджета и т.д.) обычно доходят до такой крайности, что могут превысить любой «запас прочности». В обычном проекте самый очевидный запас прочности — это сверхурочная работа. Даже если менеджер проекта оказался вынужден принять под давлением жесткий гра­ фик и урезанный бюджет, успеха все равно можно будет добить­ ся. Для этого надо уговорить проектную команду работать сверхурочно от 10 до 20 ч. в неделю в течение нескольких заклю­ чительных месяцев проекта. Эти дополнительные усилия никак не отражаются в официальной статистике, поскольку програм­ мисты ничего не получают за сверхурочную работу, поэтому в конце проекта менеджер выглядит героем.