ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March"

^ ГЛАВА 5. ПРОЦЕССЫ

Если вы запомните хотя бы одно слово из данной главы (либо вообщем из всей книжки), то эти словом должна быть приоритетность (triage). Исходя из наименования главы, вы сможете поразмыслить, что речь в главном ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" пойдет о таких знакомых методологиях, как структурный анализ, либо формальных дисциплинах наподобие SEI Capability Maturity Model (CMM), либо разных подходах к разработке ПО под общим заглавием RAD (Rapid Application Development ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March"). Все это принципиальные и нужные вещи, но самое главное состоит в том, что в безвыходном проекте вам не хватит времени на то, чтоб удовлетворить все потребности юзера. Если вы будете строить ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" все свои процессы и способы, исходя из этого непререкаемого факта, то у вас появятся шансы на фуррор; если же вы начнете проект, будучи уверенными, что к кодированию нельзя приступать до того времени, пока ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" все диаграммы потоков данных, приобретенные в итоге структурного анализа, не будут утверждены юзером, то вы точно потерпите беду.

Это не значит, что нам следует игнорировать все методологии и стратегии, связанные с процессами ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" (я поговорю о их позднее в этой главе); но моя идея, как вы сможете убедиться, состоит в том, что они, непременно, должны быть частью общей корпоративной стратегии, но их не следует ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" навязывать команде безвыходного проекта в отчаянных попытках избежать его провала. В данной ситуации применима концепция приоритетности - испытывая нехватку времени и ресурсов, команда безвыходного проекта откажется от тех способов, которые она сочтет никчемными ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" либо несущественными (к примеру, детальные мини-спецификации в структурном анализе), и воспримет на вооружение только самые полезные для нее способы. Аналогично, менеджер проекта, располагающий очень малым временем для чтения данной главы, предпочтет прочитать более ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" важную информацию и пропустить остальное; я выстроил обсуждение в данной главе, исходя конкретно из этих суждений.

^ 5.1 Концепция «triage»

Слово «triage» происходит от старенького французского «trier», что значит «сортировать, классифицировать». American Heritage Dictionary (3-е ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" издание) определяет его последующим образом:


triage - существительное


  1. Процесс рассредотачивания покалеченых по группам зависимо от их потребности в оказании незамедлительной мед помощи. Применяется на поле боя, в местах катастроф и лазаретах в ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" критериях ограниченных мед ресурсов.

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


Большая часть из нас знакомы с мед трактовкой этого термина ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", но для безвыходных проектов более подходящим является 2-ое определение: рассредотачивание дефицитных ресурсов (самым дефицитным из которых обычно является время) таким макаром, чтоб извлечь из этого самую большую выгоду. Либо, как отметил Stephen Covey ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" в [1], «главное - это быть уверенным в том, что главное - это главное». (По правде, можно будет достигнуть еще наилучших результатов в проекте, если каждый участник команды заместо увесистого тома методологии разработки ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" ПО получит экземпляр восхитительной книжки Covey!)

Большая часть подходов, связанных с прототипированием и RAD, полностью смешиваются с данной концепцией, а некие даже очевидно на нее ссылаются. Но, большая часть подходов RAD делают акцент ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" лишь на резвом получении некого - какого угодно! - результата (работающего приложения), который можно показать юзеру с целью (а) показать, как ощутим достигнутый прогресс, и (б) получить замечания, касающиеся функциональности системы и (в большей степени ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March") пользовательского интерфейса. Все это очень полезно, но если проектная команда будет расходовать свои ресурсы на проектирование исходных прототипов с снаружи симпатичными, но несущественными способностями, то как команда, так и юзер ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" будут напрасно терять время.

Большая часть методологий разработки ПО, независимо от того, базируются ли они на традиционной «каскадной» модели актуального цикла, либо на более современной «спиральной» модели и прототипировании, имеют неприметное на 1-ый взор ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", но достаточно каверзное свойство. Оно выражается последующей фразой: «неважно как, но ко времени окончания проекта мы создадим все». Может быть, причина этого состоит в том, что в детстве предки ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" воспрещали нам выходить из-за обеденного стола, пока мы не оставим пустые тарелки; в любом случае, невысказанный лозунг многих проектных команд - «мы не оставим невыполненным ни 1-го требования».

Очевидно, это добросовестный лозунг, но в безвыходных ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" проектах он практически всегда невыполним. Как я уже отмечал в главе 1, в большинстве безвыходных проектов «официально утвержденные» требования превосходят ресурсы проектной команды - в особенности, людские и временные ресурсы - на 50-100 процентов ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March". В этой ситуации неопытная команда уповает, что, работая сверхурочно в два раза больше, она сумеет как-нибудь покрыть этот недостаток; а меркантильная команда «самоубийственного» проекта подразумевает, что их проект все равно затянется на 50-100 процентов ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" по сопоставлению с начальным планом, как и хоть какой другой проект. Но даже если меркантильная команда ошибается в этом, она все равно подразумевает, что ранее либо позднее (обычно еще позднее ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March"!) она в конце концов реализует все функции, которые требовались юзеру.

Один из главных моментов в безвыходных проектах заключается в том, что некие требования не просто останутся невыполненными до официального срока окончания проекта, да ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" и не будут выполнены никогда. Если представить, что известное правило «80-20» справедливо, то проектная команда сумеет достигнуть 80 процентов «эффекта» от разработанной системы, реализовав 20 процентов требований к ней - при условии правильного выбора ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" этих 20 процентов. И, так как юзеру, обычно, не терпится получить работающую систему за длительное время до того срока, который проектная команда считает разумным, то он может взять эти готовые 20 процентов, приступить к ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" их использованию и навечно позабыть об оставшихся 80 процентах функций системы.

Это, естественно, очень облегченный подход, но, все же, практически во всех безвыходных проектах, в каких я учавствовал, приходилось устанавливать ценности, разделяя все требования ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" к системе на три категории: «необходимо выполнить», «следует выполнить» и «можно выполнить». Смысл этих категорий очевиден, и тот факт, что их всего три, предупреждает любые никчемные дискуссии на тему о ценностях, к ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" примеру, какой ценность присвоить определенному требованию - 6-ой либо седьмой. При таковой расстановке ценностей в проекте тривиальная стратегия будет заключаться в последующем: сначала сосредоточиться на требованиях, которые нужно выполнить; потом, если остается ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" время, сосредоточиться на требованиях, которые следует выполнить; и в конце концов, если произойдет волшебство, заняться требованиями, которые можно выполнить.

Если не следовать таковой стратегии с самого начала проекта, то к концу он окажется ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" в очень противной кризисной ситуации. Чтоб осознать, почему это происходит, разглядим обычный график проекта, изображенный на рис. 5.1:





Начало проекта Середина проекта Кризис Окончание


Рис. 5.1 График проекта


Когда проект начинается, никто и слушать не ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" вожделеет, что его сроки нереальны - в особенности все юзеры и высшее управление. У менеджера проекта и участников команды может появиться противное чувство, что им предстоит делать «самоубийственную» цель, но если они - оптимисты, то могут ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" поверить, что проект будет иметь нрав «невыполнимой миссии» и потом какое-нибудь волшебство придет им на помощь. В этот момент важнейшим будет то, что конечный срок еще довольно далековато (через 6 месяцев либо год ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March"), и никто не желает серьезно думать о невыполнимости намеченных целей.

По правде, политическое давление и неопытность проектной команды могут привести к тому, что даже посреди проекта он не будет подвергнут ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" никакой переоценке. Как не забавно это звучит, но неувязка возможно окажется еще больше сложной, если проектная команда употребляет какую-либо разновидность RAD-подхода, так как они, возможно, уже показали юзеру один либо ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" более прототипов системы и тем поддержали у него иллюзию, что все будет изготовлено впору. Но, к этому моменту проектная команда вероятнее всего начнет осознавать, что они пробуют прыгнуть выше головы, и ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" если для менеджера этот безвыходный проект - 1-ый, он будет наивно веровать, что высшее управление и юзеры тоже в конце концов их усвоют.

Как досадно бы это не звучало, но обычно этого не происходит ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March". В конце концов наступает кризис, когда юзеры и/либо высшее управление оказываются обязаны поглядеть в лицо действительности: невзирая на их требования и искренние заверения менеджера проекта, система не будет готова в срок ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March". Как правило это случается в месяц до окончания проекта, время от времени за неделю, а время от времени и через один день после официального окончания! Последствия могут быть разными: это находится в зависимости ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" от степени напряженности политических баталий к этому моменту, также от степени изнуренности и разочарованности менеджера проекта. Все же, при всем этом, обычно, происходит последующее: высшее управление приходит к выводу, что во всем ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" повинет менеджер проекта, и в конечном итоге злосчастного увольняют (если только он сам уже не уволился!) и ставят нового с требованием «ликвидировать весь этот бардак и сдать систему вовремя».

Новый менеджер может ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" быть как закаленным ветераном из самой организации, так и посторонним консультантом. Время от времени бывает так, что он по правде обнаруживает ряд грубых ошибок, изготовленных его предшественником (к примеру, отсутствие планирования вообщем ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" либо отсутствие рабочих графиков); время от времени новый менеджер приходит к выводу, что его предшественник в главном делал все верно, но не сумел избежать участи козла отпущения, когда высшее управление в конце ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" концов удостоверилось, что их начальные требования неосуществимы.

Но, независимо от его оценки, практически не подлежит сомнению, что новый менеджер должен быть готов к последующему: все проектные требования в полном объеме ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" не получится воплотить в согласовании с сначало установленным сроком – если б это было не так, то предшествующего менеджера навряд ли бы уволили. Итак, что все-таки следует сделать новенькому менеджеру? Две более тривиальные способности ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" заключаются в последующем:

(Консультант John Boddie предлагает еще одну возможность: менеджер проекта может стать одним из числа тех, кто добьется официального прекращения ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" проекта, если его вправду нереально спасти. Новенькому менеджеру сделать такое еще проще, чем его предшественнику, так как тот вложил в проект столько личных усилий и чувств, что ему тяжело представить для себя ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", как вообщем можно закончить проект. Boddie дает несколько не плохих советов относительно политически применимых методов прекращения проекта в собственной статье «Calling Doctor Kevorkian», размещенной в журнальчике American Programmer, February 1997.)

1-ая возможность в принципе ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" полностью допустима, но в безвыходном проекте фактически нереальна. По правде, ведь основной предпосылкой, побудившей юзеров настаивать на таких мистических планах, является неотложная потребность в системе, которая позволила бы им совладать со ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" своими неуввязками в бизнесе. Так как новый менеджер приходит в проект тогда, когда уже близок сначало установленный срок окончания, высока возможность того, что юзеры уже строят планы эксплуатации новейшей системы. Последнее, что им хотелось бы ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" слышать – это то, что проект продлится еще 6-12 месяцев.

Потому более нередко – и удачно – используемый прием заключается в определении ценностей для начальных требований. Отметим, что при всем этом новый менеджер говорит с ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" позиции силы – это не его вина, что проект оказался в таком плачевном состоянии; при всем этом не высказывается вслух, но предполагается, что управление и юзеры сначала были так неумны, что позволили загнать ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" себя в таковой тупик. Новый менеджер может даже поставить свое согласие на роль в проекте в зависимость от удачного окончания переговоров – к примеру, заявив: «Если вы желаете, чтоб я вынул вас из этой ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" ямы, то должны принять как факт, что мы сможем воплотить в срок только маленький процент сначало данных функций. Таково реальное положение вещей, согласны вы с ним либо нет».

Такое заявление будет прямым ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" и добросовестным, хотя и обескураживающим. Но при всем этом уместно задать вопрос: что все-таки делать со всем тем, что было наработано до пришествия кризиса и прихода нового менеджера? Ведь команда ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", возможно, уже успела много напрограммировать и оттестировать, и может быть, даже успела создать некую документацию и проектные модели. Что все-таки делать со всей этой отчасти выполненной работой. Более разумный ответ: огромную ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" часть придется выкинуть.

Такое утверждение может показаться очень пессимистичным. По правде, почему бы просто не отложить всю отчасти выполненную работу в сторону и возвратиться к ней позже? В наилучшем из ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" миров так оно и происходит; но это может быть при наличии надежных средств и процессов контроля версий, конфигурационного управления, контроля начального кода и т.д. – всего того, что отвергается в пылу схватки, когда все ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" усилия команды сосредоточены на получении как можно огромных результатов.

Настоящая причина, по которой вся эта отчасти выполненная работа преобразуется в напрасный труд, заключается в последующем: ни у кого не найдется ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" времени, чтоб опять к ней возвратиться. Представим, что участники проектной команды (сейчас уже под управлением нового менеджера, к которому они могут относиться с почтением либо нет) способны воплотить только самый минимум нужных функций, при ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" этом работа над проектом обычно доводит их до такового истощения, что половина из их уходит. Не считая того, проект уже так опротивел юзерам, что они не будут приставать с вопросами ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" относительно функций, оставшихся нереализованными; либо же, напротив, они будут так довольны наименьшим набором функций, что также никогда не потребуют доделать систему до конца. Даже если они это сделают, и даже если проектная команда все еще ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" будет существовать в начальном составе, высока возможность, что в попытках воплотить «скелет» системы в нее будет внесено настолько не мало строительных конфигураций, что наполовину законченные составляющие системы (надлежащие второстепенным функциям ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March") никогда больше не будут употребляться.

Заметьте, что мы в данном обсуждении еще никогда не задели таких тем, как структурный анализ, SEI-CMM либо любые другие «книжные» методологии и процессы сотворения ПО. Все ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", что говорилось по поводу приоритетности, продиктовано только здравым смыслом, что для безвыходных проектов является критически принципиальным. Чтоб эта концепция работала, все акционеры и заинтригованные лица должны принять согласованное решение, какие требования ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" следует отнести к категории «необходимо выполнить», какие к «следует выполнить» и какие к «можно выполнить». Очевидно, если обладатель проекта категорически настаивает на том, чтоб все требования были непременно выполнены, все предстоящее обсуждение будет ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" пустой растратой времени. (По сути, я бы посоветовал менеджеру проекта и его команде использовать такое обсуждение в самом начале проекта как лакмусовую бумажку. Если юзеры, обладатель проекта, высшее управление, акционеры и заинтригованные ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" лица не хотят принимать таковой подход к расстановке ценностей требований, то более разумным ответным шагом будет выйти из проекта, пока не поздно. В качестве дополнительной лакмусовой бумажки следует предложить юзерам поделить ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" все требования на три равные группы в согласовании с вышеуказанными категориями. Это может уберечь от того, чтоб 90 процентов требований были объявлены критичными.) Если разные акционеры и заинтригованные лица никак не могут достигнуть ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" консенсуса по поводу отнесения требований к той либо другой категории, то проектная команда, пытаясь удовлетворить всех, в итоге окажется парализованной из-за отсутствия нужных ресурсов.

К огорчению, «суровая реальность» такая, что большая часть организаций ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" не обладает нужной дисциплиной, опытом и политической силой, чтоб найти ценность требований в самом начале проекта. Все, что я обрисовал в прошлых абзацах, совсем не является кое-чем заумным, и даже самый технологически ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" необразованный менеджер либо юзер в состоянии это осознать; по правде, этот подход идиентично отлично подходит для всех проектов с ограниченными ресурсами и недочетом времени. Но, даже если все отлично ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" понимают, о чем речь идет, политические баталии вокруг безвыходного проекта в состоянии сделать практически неосуществимым достижение консенсуса по применимым для всех ценностям. Только когда в проекте наступит кризис, тогда, в конце концов, противоборствующие ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" стороны придут к соглашению, которое им было надо бы достигнуть в самом начале проекта.

Из таких сумрачных прогнозов можно сделать одно исключение: оно касается организаций, для которых безвыходные проекты являются образом жизни. Очевидно, юзеры ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" и высшее управление не дурачины, и они обычно извлекают уроки из собственного опыта, даже если для их усвоения будет нужно три либо четыре проваленных проекта. Как было отмечено выше, первого менеджера ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" безвыходного проекта обычно гробит неспособность расставить ценности сначала проекта, в то время как выжившие равномерно ранее доходят. Я еще вернусь к этим вопросам в главе 7.

^ 5.2 Значимость управления требованиями

Все вышеупомянутое подразумевает, что ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" в безвыходном проекте нужно уделить повышенное внимание такому относительно новенькому нюансу актуального цикла разработки ПО, как требованиям. Почему я употребил определение «новому»? В конце концов, каждый проект содержит требования, и нельзя ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" сказать, чтоб разработчики были совершенно уж незнакомы с этим понятием.

Классические методологии сотворения ПО - включая разные «структурные» и «объектно-ориентированные» методологии, разработкой которых некие мои коллеги и я занимались более 20 последних ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" лет - сосредоточены на моделировании требований, обычно при помощи таких графических средств, как диаграммы потоков данных либо диаграммы «сущность-связь». Но я в данной главе говорю конкретно об управлении требованиями в той лихорадочной обстановке ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", которая присуща безвыходному проекту.

Эти два понятия - моделирование и управление - не являются противоречивыми либо несопоставимыми. Можно издержать время и силы как на одно, так и на другое; если команда безвыходного проекта считает, что ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" для наилучшего осознания требований к системе полезно выстроить объектно-ориентированную модель, у меня нет никаких возражений. Я только желал бы предостеречь проектную команду, чтоб она делала то, что конкретно она ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" сама считает принципиальным и полезным, а не то, что считают «правильным» блюстители чистоты методологии (тут отчасти затрагиваются вопросы «наилучшей» практики, которые будут дискуссироваться ниже).

Мой опыт гласит о том, что в большинстве безвыходных проектов ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" не употребляются формальные способы моделирования, такие, как SA/SD либо OOA/OOD. Частично это из-за того, что эти методологии кажутся проектной команде очень массивными и бюрократическими; частично из-за того, что CASE ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March"-средства, поддерживающие эти методологии, кажутся очень неловкими для использования; и, обычно, из-за того, что они не лицезреют, каким образом можно конвертировать приобретенные в итоге анализа модели в работающий код - единственное, что ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" в конечном счете необходимо юзеру. (В «нормальном» проекте, напротив, SA/OOA-модели сами по для себя воспринимаются, как очень полезные. Юзеры и спецы, определяющие бизнес-политику организации, будут толпиться вокруг диаграмм ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" потоков данных и тихо бурчать друг дружке: «Так вот в чем заключается наш бизнес! Может быть, имеет смысл провести реинжиниринг бизнес-процессов и поменять все это перед тем, как создавать ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" новейшую автоматическую систему».)

По правде, в экстремальной ситуации проектная команда даже не будет документировать ни одно из пользовательских требований; в свое оправдание (которое наверное слышал каждый менеджер проекта!) они молвят, что это просит очень ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" много времени, требования очень нередко изменяются и, не считая того, юзеры сами не знают, что им необходимо. Таким макаром, команда обычно полагается на способы и средства прототипирования, при помощи которых можно наглядно показать ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" всю важную проектную работу, также выявить реальные требования к системе.

Исходя из убеждений «приоритетности», о которой шла речь в разд. 5.1, все это порождает одну главную делему: невозможность сколько-либо организованным методом управлять ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" требованиями. Как можно в хоть какой момент времени сказать, какие требования «необходимо выполнить», какие «следует выполнить» и какие «можно выполнить»? Любопытно отметить, что методологии SA/SD и OOA/OOD ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" также не дают ответа на этот вопрос. Можно, естественно, определять ценности, раскрашивая кружочки на диаграммах потоков данных, но они вначале предусмотрены совсем не для этого. Методологии SA/SD и OOA/OOD предусмотрены ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" сначала для осознания и разъяснения требований, а не для управления ими в динамике.

Конкретно динамическая составляющая управления требованиями обычно вызывает самые большие трудности. Если б вам в самом начале проекта удалось уверить всех ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" акционеров и заинтересованных лиц согласиться с приоритетностью требований, и если б эти ценности никогда не изменялись в течение проекта ... ну что ж, если вы по правде в это верите, то вы, наверняка ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", также верите в фей и чернокнижников. В реальных же безвыходных проектах обычно появляются в разных вариантах последующие проблемы:

Этот список ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" можно продолжать далее, но думаю, что вывод ясен: управление ценностью требований является критически принципиальной частью «процесса» безвыходных проектов. Естественно, если безвыходный проект содержит всего дюжину требований, то управлять ими будет совершенно ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" нетрудно; можно нацарапать их на картонной салфетке и просто пересматривать при необходимости. Но, большая часть проектов включает сотки требований, а многие - даже тыщи; проект самолета Боинг-777 (который полностью можно считать мешком программ с крыльями) включал ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", по слухам, 300.000 требований. Но это еще не все, ведь требования обычно не являются независящими; некие требования зависят от других требований, а некие в свою очередь порождают другие требования.

Все это предполагает ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" необходимость в способах, процессах и средствах для описания зависимостей меж требованиями и управления огромным количеством таких зависимостей. В решении данной препядствия могут, естественно, посодействовать такие известные способы, как структурный анализ и объектно-ориентированный ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" анализ, но, к огорчению, до сего времени эти способы обычно игнорировали атрибуты требований, такие, как ценность, цена, риск, план, обладатель и разработчик, который занимается его реализацией. В итоге проектным ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" командам, испытывающим потребность в управлении требованиями, приходилось использовать доморощенные средства, базирующиеся на электрических таблицах, текстовых микропроцессорах либо наскоро сделанных приложениях, чтоб обеспечить хотя бы некую степень автоматической поддержки.

К счастью, в текущее время появилось новое ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" поколение средств, обеспечивающих более всеохватывающую и сложную поддержку управления требованиями. Вот некие из доступных на сегодня средств: Requisite (Requisite, Inc.), DOORS (Zycad Corp.), RTM (Marconi Systems). Так как данная глава ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" посвящена в главном процессам, а не средствам, я не буду вдаваться в детали этих 3-х товаров; но так как средства оказывают влияние на процессы, принципиально знать хотя бы о их существовании (ветераны-разработчики ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" ПО вспомнят старенькую поговорку: «Если единственным вашим инвентарем является молоток, то все ваши препядствия смотрятся как гвозди»).

Существует один нюанс в композиции процессов и средств, который следует особо отметить. Как ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" было сказано выше, многие команды безвыходных проектов отрешаются от использования формальных методологий SA/SD либо OOA/OOD, так как они смотрятся очень массивными и бюрократическими. Что любопытно, акционеры и заинтригованные лица рассуждают точно ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" так же. Если предоставить им выбор, то они предпочли бы, чтоб их не заставляли учить, как читать диаграммы потоков данных; по правде, руководители и конечные юзеры высочайшего уровня иерархии сетуют, что ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" они ничего не понимают во всех этих «технических» диаграммах. У их также не хватает терпения продираться через сотки страничек с диаграммами и маленькими деталями описаний частей данных либо спецификаций процессов. Естественно, если времени и ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" терпения довольно, то проектная команда в состоянии преодолеть сопротивление и уверить конечных юзеров в том, что кропотливо разработанные модели по сути приносят огромную пользу - но в безвыходных проектах вечно не хватает ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" ни времени, ни терпения.

Что юзеры в состоянии осознавать - так это их свой родной язык, к примеру, британский для большинства североамериканских проектов. И что большая часть из их предпочитают читать - это маленький документ из ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" 10-20 страничек, суммирующий все требования к системе. Требования в таком документе могут называться «характеристиками», а сам документ в целом - «Требования к системе» («Product Requirements Document» - PRD) либо «спецификация высочайшего уровня» либо еще ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" какой-либо подходящей фразой. Главное, что этот документ маленькой и на британском языке. Он не должен содержать маркетинговой «шелухи», также непонятной терминологии либо обозначений, заставляющих юзеров думать, что бы это значило. В ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" безупречном случае каждый абзац либо даже каждое отдельное предложение должны соответствовать определенному требованию, чтоб и юзеры, и участники проектной команды могли использовать их в качестве отправной точки для собственной предстоящей работы.

Во всем ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" этом есть один увлекательный момент - он состоит в том, что у нас уже одно знакомое всем средство для сотворения таких документов; оно именуется «текстовый процессор». По правде, исходная версия такового ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" документа обычно исходит от юзеров - к примеру, в виде записки от вице-президента по маркетингу к исполнительному директору по поводу появившейся потребности в новеньком восхитительном продукте со качествами X, Y и Z, который мог ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" бы конкурировать с продуктом соперника - даже когда департамент информационных технологий еще ничего об этом не знает. На этой ранешней стадии юзеры рассматривают текстовый микропроцессор как свое средство, а записку ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" службы маркетинга – как собственный документ; в итоге они проявляют еще огромную готовность участвовать в следующих обсуждениях по поводу приоритетности требований, если при всем этом продолжают употребляться подобные средства и документы. Таким макаром, мы ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" смотрим тенденцию, ведомую к документо-центричному управлению требованиями, когда средства, применяемые спецами по ИТ (к примеру, Requisite, DOORS либо RTM), тесновато интегрируются с текстовыми микропроцессорами и документами, в каких юзеры отлично разбираются ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" (я должен честно признаться, что это в некий степени маркетинговый трюк, так как такая интеграция является одним из главных параметров Requisite, и я был одним из членов правления компании Requisite, когда писал ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" эту книжку. Но так как я играю роль беспристрастного создателя, я от всей души рекомендую вам познакомиться со всеми 3-мя перечисленными тут продуктами.)

Очередное последнее суждение: очень принципиально, чтоб все акционеры и заинтригованные лица ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" участвовали в процессе выработки исходных требований, их документирования и определения ценностей. Очевидно, это касается всех проектов, но нехватка времени и политические баталии, присущие обреченным проектам, часто соблазняют менеджера проекта ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" рассуждать последующим образом: «Ладно, мы будем двигаться далее и обойдемся без этого кретина Мелвина из департамента маркетинга; все, на что он способен – это не соглашаться никогда и ни с чем». При всем этом ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" может появиться последующая неувязка: Мелвин, получив суровую «политическую» пощечину и чувствуя, что его игнорируют (и что менеджер проекта считает его кретином!), вероятнее всего отыщет метод саботировать проект.

На теоретическом уровне каждый соображает и соглашается ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" с таковой точкой зрения, но на практике просто умопомрачительно следить, как безвыходные проекты потихоньку зарастают все новыми и новыми требованиями. Дополнительные требования, модификации имеющихся требований и недвусмысленные предложения игнорировать некие требования - все ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" это сваливается на проектную команду в виде телефонных звонков, посланий по электрической почте и дискуссий с глазу на глаз с менеджером проекта. Многие из этих предложений предваряются такими успокаивающими ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" фразами, как «извини, что я запамятовал об этом сказать на нашем последнем совещании, но ... » либо «я рассчитывал, что у нашей группы управления будет время совладать с этой неувязкой, но ... ».

Существует ли у ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" менеджера проекта такая формальная группа управления - т.е., группа, состоящая из акционеров и заинтересованных лиц, которая оценивает приобретенные в проекте результаты и воспринимает определенные решения относительно приоритетности требований - либо нет, в этом случае не ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" имеет значения; это находится в зависимости от того стиля управления и организации проектов, который сложился в каждой организации. Но что вправду имеет значение для удачного окончания безвыходного проекта - это тщательное ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" документирование каждой модификации, вносимой в начальные требования, и уведомление о ней всех акционеров и заинтересованных лиц. Если вице-президент по финансам желает потихоньку воткнуть в проект очередное приоритетное требование, это замечательно; но при всем этом ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" менеджер проекта должен позаботиться, чтоб об этом узнали вице-президент по маркетингу и исполнительный директор.

^ 5.3 SEI, ISO-9000. Формальные процессы против неформальных

Некие менеджеры, прочтя предшествующий раздел данной главы, могут ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" высказать недовольство: «Вот здорово! Это смотрится еще более формальным, чем все, что мы когда-либо делали!» Когда мне приходилось сталкиваться с таковой реакцией в неких консалтинговых проектах, это просто ставило меня в ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" тупик. С одной стороны, я уверен, что документирование, определение ценностей и управление требованиями просто нужны (независимо от того, какие средства и способы для этого употребляются); с другой стороны, я опасаюсь последующего: когда проектной команде ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", и без того заваленной работой выше головы, напрашивается совсем новый и незнакомый процесс, то этот процесс - к примеру, управление требованиями - возможно окажется последней каплей, переполнившей чашу терпения.

По правде, у меня нет ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" для этой проблемы другого решения, не считая как надежды, что проектная команда все таки сумеет совладать с одной новейшей мыслью посреди иных собственных средств и процессов. Но, меня обхватывает еще ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" большее беспокойство, когда я вижу команды, которые решают собственный 1-ый безвыходный проект с решением (либо, что более возможно, с указанием, навязанным им блюстителями методологии), обязывающим их использовать формальные процессы, к примеру, те, которые регламентируются SEI ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March"-CMM либо ISO-9000. Формальные процессы - это величавая вещь, если вы отлично понимаете, что делаете, и если вы уже использовали их до этого. Но, действительность такая, что такие формальные процессы, обычно, ранее вообщем ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" не использовались в организации, и безвыходный проект представляет собой пилотный проект для апробации структурного анализа либо ISO-9000.

Какое безумие! Это вправду последняя капля, которая переполнит чашу терпения; в конце концов обычный безвыходный ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" проект пробует выполнить то, что ранее никогда не делалось, и (невзирая на мои предостережения в главе 4) команда часто состоит из людей, которые никогда ранее не работали совместно. Так не достаточно ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" того, они еще обязаны осваивать внедрение незнакомой методологии либо процесса, не будучи уверенными в том, что это им нужно сначала, и, напротив, будучи убежденными, что это только затормозит их работу. Чему же ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" тогда удивляются блюстители методологии, когда они в схожих обстоятельствах сталкиваются с сопротивлением? Консультант Doug Scott не так давно привел мне пример таковой ситуации:


В одном проекте, как мне понятно, потребовался диаграммер ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" для ERD, и они заполучили Excelerator. Найдя, что он поддерживает методологию SSADM, они ввели ее без какого-нибудь обучения персонала, после этого нашли, что темп работы на проектом существенно снизился (практически, работа просто тормознула), в ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" то время как каждый был занят чтением руководств, освоением средств и решением трудности, что делать далее (либо переделывать то, что было изготовлено в «неправильном» порядке). Практически безупречный сценарий для тех ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", кто следит за безвыходными проектами.


Чтоб достигнуть фуррора, проектная команда должна прийти к соглашению, какие процессы будут формализованы - к примеру, контроль начального кода, управление переменами и (неплохо бы) управление требованиями - и ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" какие будут производиться на стопроцентно неформальной базе (к примеру, проектирование пользовательского интерфейса). Глупо навязывать какой-нибудь процесс в неотклонимом порядке, если никто не собирается ему следовать. Блюстители методологии просто напрасно теряют время, пытаясь сделать это ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", а в итоге, что еще ужаснее, может зря утратить время проектная команда (в почти всех случаях эти деятели не совершают ничего полезного, не считая суеты вокруг департамента информационных технологий и надоедания и ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" без того вялой от всего проектной команде).

Это значит, что менеджер безвыходного проекта должен неоспоримо настаивать на процессах, которые он считает принципно необходимыми - к примеру: «Каждый, кто посмеет внести ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" конфигурации в начальный код, минуя процесс управления переменами, будет немедля уволен!» Либо проектная команда должна сама сознательно пойти на внедрение процесса, понимая, что это позволит уменьшить издержки. Такое может быстрее произойти в ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" этом случае, если участники команды ранее уже работали вкупе и заполучили общий опыт использования разных процессов сотворения ПО; и напротив, это маловероятно, если только один из участников команды встанет и произнесет: «Я глубоко уверен ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", что структурный анализ является критически принципиальным для фуррора нашего проекта», в то время как другие и понятия не имеют, о чем это он гласит. Очередное утверждение, последующее из этого правила: попытка ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" ввести в безвыходном проекте новый, незнакомый процесс может окончиться чертовски, даже если команда верует, что он может посодействовать в работе. Препядствия с освоением, неминуемая неурядица и споры по поводу деталей процесса ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" обычно сводят на нет все выгоды.

Это значит, что такие формальные подходы, как SEI-CMM, ISO-9000 либо внедрение новых методологий анализа/проектирования обязаны иметь место где-нибудь за пределами безвыходного проекта. Внедрение таких ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" процессов имеет смысл как часть длительной корпоративной стратегии, и должно начинаться с выполнения пилотного проекта (который не должен быть обреченным проектом), сопровождаясь организацией нужного обучения.

Если все это уже изготовлено, и если все ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" другие разработки ПО в организации уже производятся на 3-ем уровне SEI-CMM, то любопытно узнать, следует ли также использовать такие процессы в безвыходном проекте. Как в один прекрасный момент увидел Watts Humprey на ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" конференции в докладе по поводу SEI-CMM: «Если процесс нельзя использовать в критичных критериях, его вообщем не следует использовать».

Я не уверен, что многие согласятся с этим утверждением, в особенности ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" если безвыходный проект рассматривать как единственное в жизни исключение из правил. Если это по правде так, то, может быть, имеет смысл отрешиться от формальных процессов и предоставить проектной команде возможность использовать ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" любые способы, которые она сочтет применимыми. Но не запамятовывайте при всем этом мое утверждение, высказанное в главе 1: безвыходные проекты становятся нормой, а не исключением. Если это так, то официально принятые в организации процессы следует ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", по мере надобности, усовершенствовать, чтоб сделать их применимыми для использования в безвыходном проекте. И тогда только тогда утверждение Humprey будет иметь смысл.

Меж иным, если вы по правде столкнулись с потребностью ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" усовершенствовать сложившуюся практику работы команды безвыходного проекта, я рекомендую обратиться к методологии PSP (Personal Software Process), создателем которой является Watts Humprey. Ее главные положения изложены в моей книжке «Rise and Resurrection of ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" the American Programmer. Можно также прочитать книжку [2], хотя я честно предупреждаю: в ней 789 страничек.

^ 5.4 «Достаточно хорошее» программное обеспечение

Определение ценностей требований, обсуждавшееся выше, может быть одним из методов, помогающих безвыходному проекту двигаться ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" в «разумном» направлении. Для заслуги фуррора совсем не непременно реализовывать все требования; будет «достаточно хорошо», если мы сможем воплотить требования, которые «необходимо выполнить», и применимое количество требований, которые «следует выполнить».

Существует ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", но, очередной нюанс в разработке ПО, порождающий трудности в безвыходных проектах: неявно подразумеваемое требование заслуги безупречного свойства. Обычно оно выражается в определениях количества изъянов (ошибок), но может быть также выражено в определениях ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" переносимости, независимости от платформы, гибкости, сопровождаемости и других «стей». Даже в «нормальных» проектах довольно тяжело удовлетворить всем этим требованиям, а в безвыходных проектах сделать это просто нереально. Заместо этого проектная команда должна прийти ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" к решению - и по способности согласовать его с акционерами и заинтересованными лицами - относительно того, какое качество является довольно неплохим.

Значимость такового решения разъясняется тем, что достижение абсолютного свойства съедает все ресурсы проекта - в ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" особенности время. Если вы желаете создать сертифицированную, не содержащую ошибок программку и математически обосновать ее правильность, на это будет нужно время. Это может также востребовать более высочайшего уровня таланта и ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" возможностей, чем те, которыми располагает проектная команда. Не считая того, одному либо более участникам команды придется расходовать дополнительную энергию, как следует, они не сумеют работать над другими задачками. Короче говоря, выполнение таких требований ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", как надежность, переносимость и сопровождаемость, нереально без компромиссов, и это нужно учесть в процессе определения ценностей требований.

Командам безвыходных проектов приходится сталкиваться с таковой противной реальностью лицом к лицу, так как кандидатура - «совершенное» ПО ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", которое не будет готово даже тогда, когда пройдут все мыслимые сроки. Идеальнее всего, когда команда с самого начала проекта настроена прагматично на создание довольно неплохого ПО, но, мой опыт, к огорчению ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", гласит о том, что многие обыденные разработчики ПО соглашаются с понятием довольно неплохого ПО только тогда, когда упираются в тупик - к примеру, когда оказываются в кризисном положении в месяц либо два до окончания ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" проекта.

Прямо до этого момента времени они выражают свое недовольство: «Как вам понравится, если мы будем использовать ваш «достаточно хороший» подход применительно к ПО ядерного реактора либо системы управления ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" воздушным движением?» Очевидно, я отвечу, что мне это совершенно не нравится; и, если кто-либо вздумает затеять безвыходный проект для сотворения такового рода высоконадежных приложений, тогда я просто перестану летать на самолетах и ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" буду держаться как можно далее от компаний с атомными реакторами. С другой стороны, нам обычно и не приходится сталкиваться с безвыходными проектами такового рода; быстрее, это может быть кадровая система на ядерном предприятии ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" либо система резервирования авиабилетов. Это, естественно, не значит, что кадровые системы и системы резервирования авиабилетов должны работать со сбоями, но все таки конкретные последствия этих сбоев будут не настолько серьезны.

В ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" любом случае, совершенная надежность, сопровождаемость, переносимость и т.д. не являются необходимыми, удобными либо даже предпочтительными в большинстве безвыходных проектов. По правде, достигнуть такового совершенства нереально даже в «нормальных» проектах, хотя ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" в данном случае мы можем позволить для себя установить планку собственных эталонов еще выше, так как не связаны такими жесткими ограничениями на время, бюджет и человеческие ресурсы. Что все-таки касается безвыходных ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" проектов, то юзерам в реальности нужна система, которая довольно дешева, довольно производительна, обладает достаточными способностями, довольно устойчива и будет готова довольно скоро - вот в чем заключается их определение «достаточно хорошего» ПО.

Почему же нам ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" не удается сделать «достаточно хорошее» ПО? Это обычно разъясняется совокупой последующих обстоятельств:

Каким же образом мы сможем сделать «достаточно хорошее» ПО? Как отмечает James Bach [3], для этого требуется несколько вещей:



^ 5.5 Лучшая практика и наихудшая практика

Не один раз уже ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" в этой книжке я предупреждал об опасностях, связанных с вмешательством блюстителей методологии и попытками против воли ввести в практику проектной команды лишенные гибкости методологии либо процессы сотворения ПО. То же самое касается ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" наружных консультантов, гуру, знахарей, целителей, заклинателей змей и книжек. Даже этой книжки: если то, что я рекомендую, не находит подабающего осознания, и проектная команда не испытывает по этому поводу особенного интереса, то ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" такую рекомендацию лучше проигнорировать!

Но это в особенности справедливо по отношению к методологиям и процессам сотворения ПО. Заместо того, чтоб следовать рекомендуемой кем-либо практике – либо, что еще ужаснее, практике, навязываемой сверху ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" управлением и комитетами по методологии, которые обычно сами не знают то, о чем они молвят – еще лучше следовать практике, которую сама команда считает «наилучшей» в данных обстоятельствах. В этом заключается существо ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" подхода «наилучшей практики», который стал пользующимся популярностью в последние несколько лет: основного подхода, принятого на вооружение организациями-разработчиками ПО, признанного удачным реальными разработчиками.

К огорчению, у команд безвыходных проектов практика такового рода часто отсутствует ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", так как их проект, обычно, рассматривается как 1-ый проект такового рода в организации. Если он даже не 1-ый, то все равно рассматривается как исключение – потому никто не побеспокоился заблаговременно составить список отлично и ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" плохо зарекомендовавших себя способов. Что еще ужаснее, большой процент безвыходных проектов завершается провалом (по другому они не назывались бы «смертельными маршами»!). Таким макаром, люди, которые могли бы посодействовать полезными советами ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" в следующих безвыходных проектах, уже ушли, были уволены, покончили жизнь самоубийством, заработали нервное расстройство либо перевоплотился в застарелых циников.

Если вы по правде начинаете 1-ый в организации безвыходный проект, то, возможно ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", самое наилучшее, что вы сможете сделать – это документально фиксировать все реально работающие процессы, которые могли бы понадобиться в следующих безвыходных проектах. Один из методов сделать это – провести «ревизию» в самом конце проекта. Все ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" же, это делается изредка, и результаты обычно так неинтересны, что никому неохота их читать. Предпосылки этого явны: как было отмечено выше, проектная команда к концу проекта находится в таком измочаленном и затрепанном состоянии, что ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" предложение документально обрисовать их опыт будет вероятнее всего встречено градом насмешек; не считая того, многие из числа тех, кто занес больший вклад в работу, к концу проекта уже издавна пропали.

Таким ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" макаром, кандидатурой может быть серия «мини-ревизий» в течение всего проекта. Если ваша работа состоит из мини-этапов, таких, как передача новейшей версии макета юзеру, запланируйте полдня на проведение мини ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March"-ревизии сходу после окончания шага. Решите, что в практике работы было неплохим, а что оказалось негожим; что заслуживает особенного внимания на последующем шаге, а от чего следует отрешиться. Необходимо подчеркнуть, что такового рода ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" «самокопание» полезно для всей проектной команды, и тот факт, что их опыт будет полезен для будущих команд безвыходных проектов, может подсластить таблетку. Не считая того, такое подведение итогов в конце шага обычно поднимает ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" дух команды, их суждения становятся более уникальными, искренними и не такими меркантильными.

Что все-таки касается организаций, которым недоступен положительный опыт других команд, то я бы посоветовал несколько источников. Эта тема затронута ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" в одной из глав моей книжки Rise and Resurrection of the American Programmer; другие материалы, касающиеся лучшей практики, можно отыскать на веб-сайте консультанта Кристины Комафорд http://www.christine.com ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March". Может быть, более принципиальным проектом, находящимся в текущее время в процессе разработки, является проект министерства обороны США, информацию о котором можно отыскать на веб-сайте http://spmn.com.

Ниже перечислены «наилучшие практики ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March"», рекомендуемые в этом проекте (не запамятовывайте данный мною ранее совет о том, что не следует принимать эту информацию практически как «заповедь», которой нужно следовать; напротив, она может служить полезной отправной точкой для ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" ваших собственных мыслях относительно лучшей практики):

Одно из более значимых достижений данного проекта министерства обороны – это понятие ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" наихудшей практики; в особенности отлично оно применимо к обреченным проектам, где часто бывает более принципиально предотвращать катастрофы, а не заниматься поисками лучшего решения заморочек. Перечень таких практик приведен ниже:

В течение прошедшего года на собственных семинарах в различных концах света я задал нескольким соткам менеджеров проектов два вопроса: «Если ваш сотрудник решает собственный ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" 1-ый безвыходный проект, какой единственный совет для заслуги фуррора вы могли бы ему дать? И что единственное вы бы порекомендовали ему не делать?» Я был очень заинтригован, найдя, что никто даже не ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" упомянул средства либо технологии в качестве «одной важнейшей вещи»; не были также упомянуты и формальные методологии и способы, такие, как структурный анализ либо объектно-ориентированное проектирование. Некие рекомендовали стратегии управления человечьими ресурсами ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" (к примеру, «наймите добротных исполнителей» и «добейтесь, чтоб команда была вправду нацелена на успех»), но практически все советы были ориентированы на проведение переговоров, контроль за выполненным объемом работ (которому отлично содействует обсуждавшееся ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" ранее определение ценностей требований) и управление рисками (о котором пойдет речь ниже).

Очередной последний подход, взятый из упоминавшегося проекта министерства обороны, возможно окажется полезным для безвыходных проектов, хотя он ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" в основном предназначен для менеджеров за пределами проекта, чем для менеджера самого проекта и участников его команды. Он именуется «тест на алкоголь»: какие вопросы следует задать команде безвыходного проекта, чтоб стремительно найти ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", не утратили ли они чувство действительности до таковой степени, что проект пора прекращать? Вопросы такового рода нередко задаются консультантами, которых высшее управление уполномочило проанализировать состояние проекта. Я сам был в таком положении ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", и я обычно могу заключить, что проект находится в плачевном положении, когда вижу остекленевший взор менеджера проекта, который припоминает взор лани, застигнутой светом фар приближающегося автомобиля.

Время от времени безопасный вопрос типа «знаете ли вы ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", кто является вашим заказчиком?» приводит всех в полное замешательство, и в гробовом молчании каждый озадаченно глядит на собственного соседа, а позже все пристально вглядываются в пол. Если вас заинтересовывают некие ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" другие вопросы «теста на алкоголь», ниже приведен их перечень:

Как было отмечено выше, «тест на алкоголь» проводится в этом случае ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", когда кто-нибудь в организации – обычно, не менеджер проекта, а кто-нибудь, стоящий на значительно более высочайшем уровне иерархии – ощутит, что проект идет не так, как следует. Для того, чтоб выжить в ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" политических схватках, менеджеру проекта и всей команде временами следует задавать друг дружке подобные вопросы. Менеджеру проекта вообщем всегда следует быть бдительным по отношению к другим признакам, говорящим о тревожном состоянии проекта, даже если ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" в согласовании с официальным графиком PERT все смотрится как положено. Такими признаками могут быть:



^ 5.6 Принцип «ежедневной сборки проекта»

В дискуссии по поводу прототипирования, контрольных точек и мини-этапов неявно предполагалось, что очередные результаты, получаемые проектной командой, возникают через ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" интервалы, измеряемые месяцами либо неделями. К этому приучил большая часть из нас прежний опыт «нормальных» проектов, и это согласуется с обыденным темпом деловой жизни – к примеру, еженедельными совещаниями персонала, каждомесячными отчетами о состоянии работ ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", ежеквартальными презентациями для высшего управления и т.д.

Но, безвыходные проекты, как мы могли убедиться в данной книжке, обычно нуждаются в другом подходе. Когда таковой проект приходит к прототипированию и пошаговой ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" разработке, обычно имеет смысл организовать всю работу над проектом на базе принципа «ежедневной сборки проекта». Под этим я понимаю последующее: компиляция, сборка, установка и тестирование всей совокупы разработанного командой кода должны производиться ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" каждый денек, как если б сей день был последним перед окончанием проекта, и на последующее утро было бы нужно сдать законченную систему юзерам.

Очевидно, реалии таковы, что приступить к каждодневной сборке проекта с самого ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" первого денька нереально. Правда, уже на 2-ой денек проекта можно написать подпрограмму типа «Hello, World», и тяжело сейчас изумить кого-либо совсем новыми технологиями (а именно, многие из проектов, использующих Java ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", во время написания этой книжки уже находились в процессе разработки). Но, есть определенные требования, которым должна удовлетворять версия макета системы при первой «официальной» демонстрации: кроме того, что она включает нужную совокупа компонент ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", процедур либо модулей и, по последней мере, несколько сотен, а может быть и тыщ строк кода, она должна делать реальный ввод данных, создавать реальную обработку либо вычисления и сформировывать реальный выход. Конкретно отныне ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" следует начинать каждодневную сборку проекта и сформировывать каждый денек новейшую (лучше усовершенствованную) версию системы.

Почему это так принципиально? Как любит гласить Jim McCarthy, менеджер продукта Microsoft Visual C++ и создатель книжки ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" ^ Dynamics of Software Development [4]: «Ежедневная сборка - это биение сердца проекта. Она дает знать, что жизнь продолжается». Такая стратегия может быть ценностью номер один для менеджера проекта. Если в течение недели каждый ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" крутит свою прялку, и никто не соберется с духом, чтоб сказать менеджеру проекта, что разрабатываемое ими клиент-серверное приложение никак не желает верно вести взаимодействие с новейшей восхитительной объектно-ориентированной базой данных ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", то в итоге проект может безвыходно отстать от графика. До того времени, пока менеджер судит о состоянии проекта по устным отчетам, запискам либо диаграммам потоков данных, будет очень просто спутать движение с прогрессом ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" и усилия с плодами. Но, если менеджер проекта настаивает на каждодневной физической демонстрации результатов, будет еще сложнее скрыть какие-либо трудности, которые в конечном счете могут содействовать провалу проекта.

Некие ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" менеджеры проекта будут кивать головами и подтверждать, что они всегда конкретно так и поступают, но большая часть согласится, что они наслаждаются еженедельным, каждомесячным либо полугодовым контролем реализации системы. В то время как ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" навряд ли кто-либо вправе претендовать на «изобретение» данного подхода, многие знают, что он в первый раз стал пользующимся популярностью во время разработки операционной системы Windows NT (увлекательную дискуссию на данную тему можно найти в ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" описании данного проекта, приведенном в [5]). Интересно также отметить, что при разработке Windows 95 также употреблялся принцип каждодневной сборки проекта; заключительная бета-версия перед выпуском конечного продукта была реализована в августе 1995 года и ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" называлась «Проект 951».

Принципиально обдумывать, что схожий подход становится неотъемлемой составляющей процесса разработки системы, которому следует проектная команда. Представьте для себя, каково быть участником команды, которая должна показывать работающую версию программного обеспечения ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" 951 денек попорядку! (Правда, если быть добросовестным, я не уверен, что команда Microsoft вправду свято соблюдала таковой порядок каждый денек. Может быть также, что формирование более чем одной версии укладывалось в 24-часовой просвет, и ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" может быть, команда могла денек либо два отдохнуть в этом марафоне.) Не считая того, чтоб быть действенным, процесс каждодневного окончания проекта должен быть автоматическим и должен производиться ночкой без чьего-либо роли, когда ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" все программеры направились домой спать (либо влезли на свои рабочие столы и забрались в спальные мешки!). Таковой подход предполагает наличие автоматического управления конфигурацией ПО и устройств контроля начальных кодов ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", также различных «скриптов» для выполнения компиляции и сборки приложений. Но что еще больше принципиально, он предполагает наличие системы автоматического тестирования, которая может работать всю ночь, выполняя гору тестов для проверки работоспособности системы. Таким ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" макаром, чтоб воплотить на практике принцип каждодневной сборки проекта, нужно иметь в собственном распоряжении адекватный набор средств и технологий; мы еще вернемся к этому вопросу в главе 6.

Действие данного принципа может также ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" дополнительно усилить ряд последующих мер:



^ 5.7 Управление рисками

Если управление требованиями - в особенности определение ценностей требований - является в безвыходном проекте более принципиальным процессом, то вторым важным процессом является управление ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" рисками. Если б понятие «риска» не было настолько критичным, тогда мы не употребляли бы по отношению к проекту определение «безнадежный». Любопытно отметить, что один из вопросов «теста на алкоголь» связан с идентификацией проектных рисков ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", и если ответом на таковой вопрос со стороны менеджера «нормального» проекта может быть ошеломленный взор (даже если проект оказался в плачевном состоянии), то менеджер безвыходного проекта вероятнее всего даст на ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" таковой вопрос точный и ясный ответ. Менеджер был бы просто болваном, если б он приступил к безвыходному проекту, не имея какого-нибудь сурового представления об главных рисках и о том, как с ними ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" биться.

Как досадно бы это не звучало, но в процессе проекта ситуация может выйти из-под контроля. Это происходит поэтому, что управление рисками строится в главном на чувствах и инстинктах, а не на формальных ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" процессах, и менеджер часто может просто не увидеть впору возникновение новых рисков в процессе проекта. В наилучшем случае будут устраняться опасности, которые являются явными в самом начале проекта; в обычной ситуации они ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" будут поводом для беспокойства в течение всего проекта (к примеру, риск ухода главного разработчика). Но, могут внезапно появиться совсем новые опасности, которых никто не ждал, и так как команда обычно ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" обладает очень малым припасом прочности (в определениях плана, бюджета и ресурсов), эти опасности возможно окажутся для проекта убийственными.

Если вся эта дискуссия относительно рисков разработки ПО кажется вам очень раздутой либо ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" вообщем не относящейся к делу, сможете смело перебегать к последующей главе. Меня больше всего заботит менеджер проекта, который удачно окончил несколько «нормальных» проектов, справляясь с рисками на интуитивном уровне; таковой подход в ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" безвыходном проекте обычно не работает. По сути, есть действенные формальные процессы управления рисками, дозволяющие решать безвыходные проекты, которые в неприятном случае наверное стали бы самоубийственными.

На тему об управлении рисками написана масса ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" книжек, их обзор не является предметом данной книжки. Всю нужную вам детализированную информацию вы сможете получить из первоисточников [4, 5, 6, 7], хотя принципиально остерегаться, чтоб «служба управления рисками» не погребла проект под формами, отчетами и другими ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" бюрократическими штуковинами. К примеру, некие менеджеры безвыходных проектов следуют очень обычный практике идентификации и мониторинга 10 главных рисков проекта; их можно отпечатать на одной страничке и раз в неделю делать оперативный анализ их ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" состояния.

Естественно, можно более удачно использовать и другие подходы, но самое главное - обеспечить, чтоб проектная команда их понимала, воспринимала и следовала им, так как рядовые сотрудники на самом нижнем уровне иерархии обычно первыми замечают ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" возникновение новых рисков. В безвыходном проекте некогда ожидать, пока информация доберется до управления по безвыходно устаревшим каналам; на делему необходимо навалиться всей командой и совладать с ней, пока она не вышла ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" из-под контроля.

Слово «контроль» в этом случае является принципиальным, так как проектная команда должна различать оценку риска, контроль риска и ликвидацию риска. В худшем случае проектная команда реагирует на риск ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" только по мере его появления - к примеру, выделяя дополнительные ресурсы для проведения дополнительного тестирования, чтоб смягчить последствия ошибки. Таковой подход, когда дилемме уделяется внимание только после ее проявления, нередко приводит к авральной работе ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" в стиле «тушения пожара», которая, в свою очередь, возможно окажется для проектной команды просто катастрофой. Еще лучше предупреждать риск заблаговременно, и это значит, что команда согласна соблюдать выполнение формальных процессов оценки и контроля ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" с целью предотвращения возможных рисков.

Управление рисками в более профилактической форме ориентировано на устранение самих обстоятельств, приводящих к риску и бедам; оно часто является центральным звеном всех начинаний, связанных с ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" управлением качеством в организации. При таком подходе проявляется тенденция к значительному расширению границ оценки рисков и возникновению способности их предотвращения; это может привести к очень брутальному стилю управления, основанному на полном контроле над ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" степенью риска в согласовании с его допустимостью для организации. Я всецело делю таковой подход, но эта неувязка в основном стратегическая, она должна дискуссироваться и реализовываться за пределами безвыходного проекта. Команда безвыходного ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" проекта преследует в главном тактические цели; она не пробует поменять культуру организации, а всего только выжить и нормально окончить проект.

Все же, могут появиться некие трудности, связанные с культурой организации, в особенности в этом ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" случае, если существует мировоззрение, что в других проектах риск отсутствует, и данный проект - это 1-ый, последний и единственный безвыходный проект, когда-либо имевший место в организации. Неувязка состоит в ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" том, что проектная команда не находится на необитаемом полуострове; если б это было так, то можно было бы решить все вопросы, «ликвидировав вестника», который докладывает о дилеммах управлению.

С другой стороны, как отмечает Rob ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" Charette [8], главные предпосылки провалов проектов часто кроются в окружающей проект среде (среде самой организации и/либо наружной среде), как показано на рис. 5.2. Эта среда практически всегда находится вне пределов досягаемости ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" менеджера проекта, и что более принципиально, менеджер проекта может и не подозревать о наличии этих «внешних» рисков, пока они не обвалятся на проект.

Очевидно, правильно и оборотное: проект порождает опасности, которые могут повлиять на ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" среду организации и внешнюю среду, и об этом знает каждый. По правде, менеджер проекта не должен забывать, что его безвыходный проект может подвергнуть угрозы всю компанию - если не цивилизацию и всю ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" вселенную! Те менеджеры, которые плачутся и сетуют, что их команда трудится над окончанием проекта всего только 127 часов в неделю, часто находятся в блаженном незнании относительно происходящего у их под носом, что может привести ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" к крушению проекта.





Рис. 5.2 Область деяния проектных рисков


Потому настолько принципиально использовать формальные процессы управления рисками, при помощи которых можно оценить проектные опасности по разным нюансам деятельности организации и попробовать найти разумный ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" баланс меж ними; в конце концов то, что кажется риском проектировщику и разработчику ПО, может рассматриваться департаментом маркетинга как подходящая возможность. Таковой подход к «глобальному» управлению рисками очень важен, но мне приходилось встречаться с ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" ним в безвыходных проектах совершенно не так нередко, как хотелось бы. Как было отмечено выше, у проектной команды нет времени, энергии либо политического воздействия, чтоб пробовать поменять культуру организации ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" при помощи внедрения глобального процесса управления рисками. Как следует, отсутствие такового процесса в организации само по себе становится риском, который команда должна оценить.

Оценка риска производится обычно методом оценки трудности разрабатываемой системы либо ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" продукта, также оценки клиентской среды и среды проектной команды. Сложность продукта можно оценить в определениях объема (к примеру, количества многофункциональных точек), ограничений производительности, технической трудности и т.д. Риск, связанный с клиентской средой ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", определяется в главном такими факторами, как количество юзеров, вовлеченных в проект, уровень квалификации юзеров, значение разработки для пользовательского бизнеса, возможность того, что внедрение новейшей системы (если оно произойдет) приведет к реорганизации либо даунсайзингу ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" и т.д. В конце концов, риск, связанный со средой проектной команды, находится в зависимости от ее возможностей, опыта, морального состояния и физического/чувственного здоровья.

Обычно, довольно полная модель риска может ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" включать 100 либо более причин риска; как отмечено ранее, некие проектные команды сознательно ограничиваются рассмотрением 10 более существенных рисков. Некие из рисков можно оценить количественно - к примеру, требования к производительности (быстроты реакции системы ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March") либо объем системы, выраженный в количестве многофункциональных точек. Другие причины - к примеру, степень дружелюбности либо враждебности юзеров - могут быть оценены только отменно. Такие причины принято охарактеризовывать значениями «высокий», «низкий» либо «средний».

После того ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", как опасности подверглись идентификации и оценке, менеджер и команда могут попробовать избрать подходящую стратегию минимизации либо исключения по способности большего количества рисков. Эта деятельность носит, естественно, общий нрав, но не ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" стоит забывать, что сама природа безвыходного проекта такая, что количество рисков превосходит обыденное, они более серьезны, и от их нельзя просто так избавиться. С другой стороны, если опасности являются экстраординарными, то и решения ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" должны быть адекватными: в то время как проектная команда «нормального» проекта может никогда не набраться смелости, чтоб обратиться к исполнительному директору либо первому вице-президенту с просьбой уменьшить риск методом существенного ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" роста бюджета либо снятия суровых бюрократических ограничений, будет полностью разумным обратиться с таковой просьбой в безвыходном проекте. Если вы этого не сделаете - а для этого может потребоваться пройти по иерархической лестнице и обойти несколько ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" уровней тупых начальников - то вы так никогда и не узнаете, удалось бы вам решить ваши препядствия либо нет.

В любом случае, если есть суровые причины риска, воздействие которых исключить нереально – а в безвыходных ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" проектах практически всегда так оно и есть – их следует зафиксировать в особом документе, идентифицировав для каждого риска вероятные последствия и разработав план действий в неожиданных ситуациях. Это не будет ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" чисто политическим «прикрытием задницы», так как в этом случае, если риск материализуется и повлечет за собой провал проекта, то последствия, обычно, будут грустными для всех, имеющих отношение к проекту; в конце концов, таковы реалии ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" безвыходных проектов. Все же, отрицание действительности - также достаточно распространенное явление в безвыходных проектах. Как участники проектной команды, так и юзеры и руководители разных уровней часто мучаются близорукостью и напрочь игнорируют существование ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" суровых проектных рисков. Полностью можно ждать, что менеджер проекта и участники команды будут с усердием обращать внимание «внутренним» рискам; но, как было отмечено выше, участники команды часто оставляют без внимания «внешние ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March"» опасности, так как они связаны с неуввязками организации и бизнеса, неподвластными команде. Таким макаром, документирование рисков является принципиальной практической деятельностью, подталкивающей юзеров и управление к осознанию того, что они предпочитали не замечать ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" и игнорировать.

5.8 Заключение

Достаточно просто бросить за бортом многие из числа тех мыслях, которые дискуссировались в этой главе, и оказаться потом в плену пустопорожней бюрократии. Но, как отмечает Stephen Nesbit (я получил его ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" сообщение именно в этот момент, когда добрался до конца этой главы и не знал толком, как ее окончить):


Отсутствие эталонов и методологии само по себе может перевоплотить проект в безвыходный. К ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" примеру, в моем последнем проекте сжатый и мистический план был применен в качестве предлога для того, чтоб отрешиться от последующего:

1) Использования системы конфигурационного управления для контроля проектного начального кода, сосредоточенного в 3-х разных ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" компьютерных системах, расположенных в 2-ух территориально удаленных местах. В итоге существенное время было потеряно впустую в попытках:

а) выполнить сборку программного обеспечения;

б) найти, кому какая версия ПО принадлежит;

в) найти, почему ПО ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" работает на одной системе и не работает на другой.

2) Регистрации узеньких мест и изъянов при помощи системы конфигурационного управления. В итоге стало совсем нереально оперативно узнать, какие ошибки устраняются, а ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" какие проигнорированы; какие составляющие окончены и могут тестироваться.

3) Документальной фиксации главных требований, проектных решений и вариантов, узловых точек в процессе разработки и применяемых тестов. В итоге участникам проектной команды оказалось очень тяжело достигнуть взаимопонимания не ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" только лишь относительно текущего состояния проекта, но также и относительно главных решений, принятых в самом начале проекта.


Итак, пожалуйста, не нужно принимать эту главу как предлог для отказа от каких-то процессов ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", методологий либо способов вообщем; по правде, это может убить безвыходный проект. Фокус состоит в том, чтоб найти те процессы, методологии либо способы, которые вправду работают, и которым команда будет ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" следовать естественным образом и безотчетно. Последнее в особенности принципиально: команда испытывает таковой стресс и давление, что должна делать многие вещи чисто подсознательно. Если взгромоздить на команду бремя новых, незнакомых процессов, которые так сложны ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", что они обязаны будут каждые 5 минут останавливаться и заглядывать в управление, чтоб найти, что делать далее, то все пропадет впустую. Потому нужно поступать проще – и если команда может уяснить только одно ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" слово, этим словом должно быть приоритетность.


Литература к главе:


  1. Stephen R. Covey, Roger A. Merill, Rebecca R. Merill. First Things First. New York: Simon & Schuster, 1994.

  2. Watts Humphrey. A Discipline of Software Engineering. Reading, MA ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March": Addison-Wesley, 1995.

  3. James Bach. The Challenge of ‘Good Enough’ Software. American Programmer, October 1995.

  4. Jim McCarthy. Dynamics of Software Development. Redmond, WA: Microsoft Press, 1995.

  5. G. Pascal Zachary. Show-Stopper! New York ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March": Free Press, 1994.

  6. Rob Thomsett. The Indiana Jones School of Risk Management. American Programmer, September 1992.

  7. Capers Jones. Assessment and Control of Software Risks. Englewood Cliffs, NJ: Prentice Hall, 1994.

  8. Rob Charette. Building Bridges over Intellectual Rivers ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March". American Programmer, September 1992.


Дополнительная литература:


  1. 1. Alan M. Davis. Software Requirements: Objects, Functions, and States. Englewood Cliffs, NJ: Prentice Hall, 1993.

  2. Mark C. Paulk, Charles V. Weber, Bill Curtis, Mary Beth Chrises ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March", et al. The Capability Maturity Model: Guidelines for Improving the Software Process. Reading, MA: Addison-Wesley, 1995.

  3. Robert N. Charette. Application Strategies for Risk Analysis. New York: McGraw-Hill, 1990.

  4. Robert N. Charette. Software Engineering ГЛАВА 5. ПРОЦЕССЫ - Edward Yourdon "Death March" Risk Analysis and Management. New York: McGraw-Hill, 1989.





glava-5-sanitarno-epidemiologicheskie-trebovaniya-k-usloviyam-obucheniya-i-proizvodstvennoj-praktike.html
glava-5-sejsmicheskoe-mikrorajonirovanie-v-usloviyah-severnogo-kavkaza-otchet-o-vipolnenii-1-etapa-gosudarstvennogo-kontrakta-.html
glava-5-sfera-vospominanij.html