5.8 Заключение
Довольно легко оставить за бортом многие из тех идей, которые обсуждались в этой главе, и оказаться впоследствии в плену пустопорожней бюрократии. Однако, как отмечает Stephen Nesbit (я получил его сообщение как раз тогда, когда добрался до конца этой главы и не знал толком, как её закончить):
Отсутствие стандартов и методологии само по себе может превратить проект в безнадёжный. Например, в моем последнем проекте сжатый и нереальный план был использован в качестве предлога для того, чтобы отказаться от следующего:
1) Использования системы конфигурационного управления для контроля проектного исходного кода, сосредоточенного в трех различных компьютерных системах, расположенных в двух территориально удалённых местах. В результате значительное время было потеряно впустую в попытках:
а) осуществить сборку программного обеспечения;
б) определить, кому какая версия ПО принадлежит;
в) определить, почему ПО работает на одной системе и не работает на другой.
2) Регистрации узких мест и дефектов с помощью системы конфигурационного управления. В результате стало совершенно невозможно оперативно выяснить, какие ошибки устраняются, а какие проигнорированы; какие компоненты закончены и могут тестироваться.
3) Документальной фиксации основных требований, проектных решений и вариантов, узловых точек в процессе разработки и используемых тестов. В результате участникам проектной команды оказалось чрезвычайно трудно добиться взаимопонимания не только относительно текущего состояния проекта, но также и относительно основных решений, принятых в самом начале проекта.
Итак, пожалуйста, не надо воспринимать эту главу как предлог для отказа от каких-либо процессов, методологий или методов вообще; в самом деле, это может погубить безнадёжный проект. Фокус заключается в том, чтобы отыскать те процессы, методологии или методы, которые действительно работают, и которым команда будет следовать естественным образом и бессознательно. Последнее особенно важно: команда испытывает такой стресс и давление, что должна делать многие вещи чисто инстинктивно. Если взвалить на команду бремя новых, незнакомых процессов, которые настолько сложны, что они вынуждены будут каждые пять минут останавливаться и заглядывать в руководство, чтобы определить, что делать дальше, то все пропадёт впустую. Поэтому надо поступать проще – и если команда может запомнить только одно слово, этим словом должно быть приоритетность.
Литература к главе:
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: 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: 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. 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, 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 Risk Analysis and Management. New York: McGraw-Hill, 1989.
Отсутствие стандартов и методологии само по себе может превратить проект в безнадёжный. Например, в моем последнем проекте сжатый и нереальный план был использован в качестве предлога для того, чтобы отказаться от следующего:
1) Использования системы конфигурационного управления для контроля проектного исходного кода, сосредоточенного в трех различных компьютерных системах, расположенных в двух территориально удалённых местах. В результате значительное время было потеряно впустую в попытках:
а) осуществить сборку программного обеспечения;
б) определить, кому какая версия ПО принадлежит;
в) определить, почему ПО работает на одной системе и не работает на другой.
2) Регистрации узких мест и дефектов с помощью системы конфигурационного управления. В результате стало совершенно невозможно оперативно выяснить, какие ошибки устраняются, а какие проигнорированы; какие компоненты закончены и могут тестироваться.
3) Документальной фиксации основных требований, проектных решений и вариантов, узловых точек в процессе разработки и используемых тестов. В результате участникам проектной команды оказалось чрезвычайно трудно добиться взаимопонимания не только относительно текущего состояния проекта, но также и относительно основных решений, принятых в самом начале проекта.
Итак, пожалуйста, не надо воспринимать эту главу как предлог для отказа от каких-либо процессов, методологий или методов вообще; в самом деле, это может погубить безнадёжный проект. Фокус заключается в том, чтобы отыскать те процессы, методологии или методы, которые действительно работают, и которым команда будет следовать естественным образом и бессознательно. Последнее особенно важно: команда испытывает такой стресс и давление, что должна делать многие вещи чисто инстинктивно. Если взвалить на команду бремя новых, незнакомых процессов, которые настолько сложны, что они вынуждены будут каждые пять минут останавливаться и заглядывать в руководство, чтобы определить, что делать дальше, то все пропадёт впустую. Поэтому надо поступать проще – и если команда может запомнить только одно слово, этим словом должно быть приоритетность.
Литература к главе:
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: 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: 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. 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, 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 Risk Analysis and Management. New York: McGraw-Hill, 1989.
ГЛАВА 6.
ТЕХНОЛОГИЯ И СРЕДСТВА
Летом 1992 года мне довелось обедать с дружной группой менеджеров среднего уровня Microsoft. Во время завязавшейся беседы я спросил, является ли для проектных команд Microsoft обычным делом использование таких методологий, как структурный анализ или объектно-ориентированное проектирование. Ответы были примерно следующими: «иногда», «хммм, вроде бы да», «от случая к случаю» и «а что это такое?». Когда же я спросил их относительно использования CASE-средств (которые в то время все ещё были довольно популярными в индустрии ПО), то из их ответов понял, в чем заключается общее мнение майкрософтовцев: такие средства годятся для «людей с улицы». С таким выражением я ещё не встречался, его можно грубо интерпретировать как «невежественные дикари, которые только что вылезли из своего первобытного леса и начали обучаться программированию, в отличие от настоящих программистов, которые не нуждаются во всяких финтифлюшках».
Будучи слегка уязвлённым, я поинтересовался, используют ли их проектные команды хоть какие-нибудь средства, и в ответ услышал, что каждая команда Microsoft может выбрать любые средства, которые сочтёт подходящими для своего проекта. Ухватившись за такой ответ, я спросил, какое средство считает наиболее важным типичная проектная команда?
«На днях я задал одной из проектных команд такой же вопрос», – ответил один из менеджеров. «Как вы думаете, что они ответили?»
«Какой-нибудь высокопроизводительный компилятор С++?», – спросил я. «Ассемблер? Или мощное средство отладки для устранения множества ошибок в их коде (хи-хи-хи) ?»
«Ничего подобного», – ответил менеджер, игнорируя моё гнусное хихиканье. «Они ответили: электронная почта. Средний разработчик Microsoft получает сотню сообщений в день; он живёт в электронной почте. Уберите электронную почту, и проект умрёт».
Рассказывая этот анекдотический случай, я неспроста в самом начале упомянул 1992 год: эти события происходили до начала эры Internet и World Wide Web. Сотня почтовых сообщений в день потрясла моё воображение; в 1992 году я был безумно счастлив, если получал два или три сообщения в день. Однако можно представить себе, что если бы такой же вопрос о «наиболее важном средстве» был задан в 1996 году, ответом могло быть «World Wide Web»; по аналогии, «факс» в 1987, «ПК» в 1983, «онлайновый терминал» в 1976 и «мой собственный телефон на рабочем столе» в 1964 году, когда я только начинал свою карьеру программиста.
Очевидно, не следует ожидать, что команда безнадёжного проекта сможет ограничиться только одним средством. Большинство команд – даже в «нормальных» проектах – пользуются в своей повседневной работе самыми разнообразными средствами и технологиями. Правда, иногда количество средств становится чересчур большим, технологии – слишком новыми, а иногда нежелательные средства навязываются им некомпетентными менеджерами.
Если вас встревожили эти обстоятельства, позвольте мне уверить вас, что я вовсе не собираюсь агитировать за использование экзотических, суперсовременных средств, которые, телепатически взаимодействуя с программистом, получают из его беспорядочных мыслей хорошо структурированный код. Напротив, я хочу обсудить понятие «минимально необходимого набора средств» для безнадёжных проектов. Я хочу также обратить особое внимание на критически важные взаимосвязи между средствами и процессами, особенно поскольку процессы в безнадёжном проекте, скорее всего, отличаются от тех, которые используются в организации. И, наконец, я хочу предостеречь от использования в безнадёжном проекте совершенно новых средств.
Будучи слегка уязвлённым, я поинтересовался, используют ли их проектные команды хоть какие-нибудь средства, и в ответ услышал, что каждая команда Microsoft может выбрать любые средства, которые сочтёт подходящими для своего проекта. Ухватившись за такой ответ, я спросил, какое средство считает наиболее важным типичная проектная команда?
«На днях я задал одной из проектных команд такой же вопрос», – ответил один из менеджеров. «Как вы думаете, что они ответили?»
«Какой-нибудь высокопроизводительный компилятор С++?», – спросил я. «Ассемблер? Или мощное средство отладки для устранения множества ошибок в их коде (хи-хи-хи) ?»
«Ничего подобного», – ответил менеджер, игнорируя моё гнусное хихиканье. «Они ответили: электронная почта. Средний разработчик Microsoft получает сотню сообщений в день; он живёт в электронной почте. Уберите электронную почту, и проект умрёт».
Рассказывая этот анекдотический случай, я неспроста в самом начале упомянул 1992 год: эти события происходили до начала эры Internet и World Wide Web. Сотня почтовых сообщений в день потрясла моё воображение; в 1992 году я был безумно счастлив, если получал два или три сообщения в день. Однако можно представить себе, что если бы такой же вопрос о «наиболее важном средстве» был задан в 1996 году, ответом могло быть «World Wide Web»; по аналогии, «факс» в 1987, «ПК» в 1983, «онлайновый терминал» в 1976 и «мой собственный телефон на рабочем столе» в 1964 году, когда я только начинал свою карьеру программиста.
Очевидно, не следует ожидать, что команда безнадёжного проекта сможет ограничиться только одним средством. Большинство команд – даже в «нормальных» проектах – пользуются в своей повседневной работе самыми разнообразными средствами и технологиями. Правда, иногда количество средств становится чересчур большим, технологии – слишком новыми, а иногда нежелательные средства навязываются им некомпетентными менеджерами.
Если вас встревожили эти обстоятельства, позвольте мне уверить вас, что я вовсе не собираюсь агитировать за использование экзотических, суперсовременных средств, которые, телепатически взаимодействуя с программистом, получают из его беспорядочных мыслей хорошо структурированный код. Напротив, я хочу обсудить понятие «минимально необходимого набора средств» для безнадёжных проектов. Я хочу также обратить особое внимание на критически важные взаимосвязи между средствами и процессами, особенно поскольку процессы в безнадёжном проекте, скорее всего, отличаются от тех, которые используются в организации. И, наконец, я хочу предостеречь от использования в безнадёжном проекте совершенно новых средств.
6.1 Минимально необходимый набор средств
В предыдущей главе я настоятельно рекомендовал устанавливать приоритеты для пользовательских требований. Такой же подход можно использовать по отношению к средствам и технологии: существуют средства, которые «необходимо использовать», «следует использовать», и огромное разнообразие средств, которые «можно использовать». Этот подход разумно применить в самом начале проекта, и тому есть ряд причин.
Наиболее очевидная причина лежит в плоскости экономики. Даже если средства хорошо работают и все знакомы с ними, их приобретение может стоить слишком дорого. Кроме того, на их получение может уйти слишком много времени – процесс приобретения в условиях обычной корпоративной бюрократии может завершиться уже после окончания проекта. Для большинства безнадёжных проектов следует сосредоточиться на небольшом количестве критически важных средств, и затем убедить высшее руководство (или соответствующую службу) в необходимости их приобретения.
С другой стороны, предположим, что команда работает в крупной корпорации, имеющей в своём распоряжении сотни различных средств, приобретавшихся в течение целого ряда лет. Следует ли их все использовать? Конечно, нет! Даже если все они работают, те умственные усилия, которые необходимо приложить, чтобы запомнить, как ими пользоваться, а также дополнительные усилия для обеспечения их совместной работы обычно сводят на нет всю выгоду. Можно провести аналогию с командой альпинистов, которые собираются штурмовать вершину и пытаются решить, какое снаряжение им использовать. Существуют вещи, которые необходимы (палатки, питьевая вода и т.д.) ; и, если маршрут не слишком сложный, можно взять с собой некоторые новомодные приспособления, о которых они прочли в своём любимом альпинистском журнале. Однако, если они собираются штурмовать Эверест, им не обойтись без помощи ослов-носильщиков или местных жителей, иначе они будут не в состоянии тащить на спине по 300 фунтов снаряжения на человека.
Команда безнадёжного проекта должна самостоятельно, независимо от принятых в организации стандартов, решить, какие средства являются необходимыми, а без каких можно обойтись. Меня очень удивил подход ряда организаций, в которых я побывал, к безнадёжным проектам, когда менеджер проекта с грустью говорил, что все проекты заставляют разрабатывать на КОБОЛе (или, в других организациях, в таком качестве может фигурировать Visual Basic или Oracle или что-нибудь ещё …), даже если эта технология совершенно не подходит для его проекта. Чепуха! Пошлите их подальше! Используйте те средства и технологии, в которых есть смысл! В противном случае это можно сравнить с ситуацией, когда кто-либо говорит руководителю команды альпинистов, собирающейся штурмовать Эверест: «Наш комитет решил, что ваша проектная команда должна взять подробную схему Нью-Йоркского метро, поскольку в большинстве проектов её сочли очень полезной». (Иногда в это дело вмешивается своими грязными руками политика. В прошлом году мне приходилось видеть несчастных сотрудников IBM, вынужденных использовать Lotus Freelance вместо PowerPoint и Lotus 1-2-3 вместо Excel, поскольку у них не было никакого желания ввязываться в противном случае в политические баталии. Аналогично, я не уверен, что хотел бы оказаться в проектной команде Microsoft, которая решила бы примерно в августе 1996 года использовать Netscape Navigator вместо Internet Explorer.)
Я думаю, очень важно, чтобы участники команды пришли к единому мнению относительно используемых в проекте средств, иначе наступит хаос. Разумеется, это утверждение не следует понимать слишком буквально; оно не означает, что все участники команды должны обязательно использовать один и тот же текстовый процессор для подготовки своих документов, однако, скорее всего, важно использовать один и тот же компилятор С++. Одна из проблем, связанных с безнадёжными проектами, заключается в том, что разработчики ПО считают допустимой полную анархию на индивидуальном уровне (например, если им хочется использовать никому не известный компилятор С++, который они переписали с университетского Web-сайта, то они считают, что это их неотъемлемое право). Это совсем не так: неотъемлемым правом обладает команда, и менеджер проекта должен неуклонно проводить его в жизнь во всех ситуациях, когда несовместимые средства могут привести к значительным разногласиям.
Это означает, что, пока участники команды не поработают вместе на нескольких безнадёжных проектах, они не придут к единому мнению относительно «минимального» набора средств. После того, как достигнут консенсус по поводу набора средств, команда может обсудить средства, которыми «следует» пользоваться, при этом проблемы заключаются в том, чтобы добиться согласия в команде и получить разрешение руководства на приобретение новых средств. Если после этого ещё останется время и желание, то можно обсудить качества неопределённого количества средств, которые «можно использовать» и в которых заинтересованы различные участники команды.
Выше я высказал мысль, что менеджер проекта должен быть готов к тому, чтобы настаивать на достижении консенсуса; в самом деле, это может быть одним из критериев, используемых менеджером для выбора потенциальных участников команды. Отметим, что то же самое можно сказать относительно процессов, которые мы обсуждали в главе 5. И, как мы увидим далее, это имеет ещё большее значение, поскольку средства и процессы тесно связаны друг с другом.
Помня обо всех высказанных предостережениях, практически невозможно для такого «дилетанта», как я, с ходу перечислить все средства, рекомендуемые для безнадёжного проекта. Когда задают такой вопрос, мой ответ – «это зависит от … » – обычен для присущего консультантам и приводящего к замешательству стремления уходить от прямого ответа на любой вопрос. Итак, поскольку вы крепко запомнили мои предыдущие советы, далее приводится перечень средств, которые мне хотелось бы видеть в безнадёжных проектах:
1) Электронная почта, ПО для групповой работы, средстваInternet/Web – так же, как и в эпизоде с Microsoft, эти средства находятся в начале моего списка. Причина заключается в следующем: электронные средства общения и взаимодействия являются не только гораздо более эффективным средством коммуникации, чем записки и факсы, но они также способствуют координации и сотрудничеству. Лично мне безразлично, какие именно средства использовать: Microsoft Mail, cc:Mail, Netscape Collabra или Lotus Notes; важно только, чтобы вся команда работала в сети хранила общие проектные данные также в сети. Помимо этого, существуют и другие хорошие новые средства, но они скорее относятся к категории «следует использовать», а не «необходимо использовать».
2) Средства прототипирования/быстрой разработки приложений (RAD) – как отмечалось ранее, почти все безнадёжные проекты используют в той или иной степени прототипирование и пошаговую разработку; следовательно, им необходимы соответствующие инструментальные средства. Сегодня не так просто отыскать популярную среду разработки приложений, которая заявляла бы о себе иначе, чем среда RAD, и большинство таких средств обладают визуальным пользовательским интерфейсом, выполненным в стиле «drag and drop», облегчающим и ускоряющим процесс разработки. Я не берусь давать общие рекомендации, какие средства лучше использовать – Delphi, C++, Visual Basic или Smalltalk (или множество других). Существенно важно только одно: чтобы вся команда использовала один и тот же набор средств от одного и того же поставщика. Если одна часть команды использует VisualWorks (ParkPlace Digitalk), а другая – VisualAge for Smalltalk (IBM), то это явно глупо, хотя и допустимо с точки зрения технологии.
3) Средства управления конфигурацией (CM) /контроля версий – некоторые из моих коллег полагают, что они должны быть на первом месте в списке. John Boddie, автор Crunch Mode, высказал такое мнение:
Я хотел бы отметить, что средства управления конфигурацией действительно «необходимо использовать». По мере разработки будет возникать множество нестыковок между отдельными частями проекта, поэтому менеджер и команда нуждаются в средствах, позволяющих фиксировать и отслеживать версии системы по мере продвижения к завершению проекта.
4) Очевидно, использование средств CM может принести гораздо больше пользы, если они будут интегрированы со средствами разработки приложений. Например, SourceSafe (Microsoft) может быть, а может и не быть самым лучшим средством контроля версий ПО, однако тот факт, что оно тесно интегрировано с Visual Basic, является весомым аргументом в его пользу. Аналогично, многие другие средства разработки приложений интегрированы с PVCS (InterSolv), ENY/Developer (IBM) или другими подобными средствами CM.
5) Средства тестирования и отладки – многие из нас автоматически включают эти средства в «базовый» набор средств разработки приложений, позволяющих создавать, компилировать и выполнять код. Однако, когда мы перешли от онлайновых приложений на мэйнфреймах к клиент-серверным системам с графическим пользовательским интерфейсом, то постепенно поняли, что необходим совершенно новый набор средств тестирования; в то же время средства таких поставщиков, как SQA и Mercury Interactive, ещё не получили достаточного распространения в тех организациях, где мне удалось побывать. Аналогично, проектные команды, разрабатывающие приложения в среде Internet, скорее всего нуждаются в полностью новых средствах тестирования и отладки.
6) Средства управления проектом (оценка, планирование,PERT/GANTTи т.д.) – обычно их считают средствами менеджера проекта и, наверное, так оно и есть; возможно, только менеджеру проекта приходится каждый день пересчитывать «критический путь». Однако, к той же категории следует отнести такие средства оценки, как ESTIMACS (Computer Associates, автор – Howard Rubin), CHECKPOINT (Software Productivity Research) и SLIM (Quantitative Software Management). Эти средства, по моему мнению, являются достаточно важными, поскольку они позволяют в ходе выполнения проекта динамически пересматривать планы и сроки.
7) Наборы повторно используемых компонент – если проектная команда знакома с концепцией повторного использования ПО, и если она рассматривает её как стратегическое оружие, позволяющее достичь высокого уровня продуктивности разработки, то набор повторно используемых компонент должен быть в списке тех средств, которые «необходимо использовать». Это может быть набор компонент VBX для Visual Basic, библиотека классов ParkPlace Digitalk Smalltalk или библиотека классов MFC для C++ (Microsoft) ; разумеется, можно также использовать компоненты, разработанные другими проектными командами в организации. Выбор компонент обычно зависит от используемого языка программирования, и это ещё одна проблема, нуждающаяся в выработке единого подхода со стороны проектной команды.
8) CASE—средства для анализа/проектирования – некоторые проектные команды рассматривают CASE-средства как «костыли» для новичков, а другие считают их не менее важными, чем текстовые процессоры. Я сам отдаю предпочтение простым, недорогим и гибким CASE-средствам; кроме того, я избегаю рекомендовать какой-либо конкретный продукт или поставщика, поскольку самым разумным ответом на вопрос, какие CASE-средства использовать, будет «это зависит от …». В самом деле, как заметил Doug Scott, может вообще не понадобиться никакой технологии:
Наиболее очевидная причина лежит в плоскости экономики. Даже если средства хорошо работают и все знакомы с ними, их приобретение может стоить слишком дорого. Кроме того, на их получение может уйти слишком много времени – процесс приобретения в условиях обычной корпоративной бюрократии может завершиться уже после окончания проекта. Для большинства безнадёжных проектов следует сосредоточиться на небольшом количестве критически важных средств, и затем убедить высшее руководство (или соответствующую службу) в необходимости их приобретения.
С другой стороны, предположим, что команда работает в крупной корпорации, имеющей в своём распоряжении сотни различных средств, приобретавшихся в течение целого ряда лет. Следует ли их все использовать? Конечно, нет! Даже если все они работают, те умственные усилия, которые необходимо приложить, чтобы запомнить, как ими пользоваться, а также дополнительные усилия для обеспечения их совместной работы обычно сводят на нет всю выгоду. Можно провести аналогию с командой альпинистов, которые собираются штурмовать вершину и пытаются решить, какое снаряжение им использовать. Существуют вещи, которые необходимы (палатки, питьевая вода и т.д.) ; и, если маршрут не слишком сложный, можно взять с собой некоторые новомодные приспособления, о которых они прочли в своём любимом альпинистском журнале. Однако, если они собираются штурмовать Эверест, им не обойтись без помощи ослов-носильщиков или местных жителей, иначе они будут не в состоянии тащить на спине по 300 фунтов снаряжения на человека.
Команда безнадёжного проекта должна самостоятельно, независимо от принятых в организации стандартов, решить, какие средства являются необходимыми, а без каких можно обойтись. Меня очень удивил подход ряда организаций, в которых я побывал, к безнадёжным проектам, когда менеджер проекта с грустью говорил, что все проекты заставляют разрабатывать на КОБОЛе (или, в других организациях, в таком качестве может фигурировать Visual Basic или Oracle или что-нибудь ещё …), даже если эта технология совершенно не подходит для его проекта. Чепуха! Пошлите их подальше! Используйте те средства и технологии, в которых есть смысл! В противном случае это можно сравнить с ситуацией, когда кто-либо говорит руководителю команды альпинистов, собирающейся штурмовать Эверест: «Наш комитет решил, что ваша проектная команда должна взять подробную схему Нью-Йоркского метро, поскольку в большинстве проектов её сочли очень полезной». (Иногда в это дело вмешивается своими грязными руками политика. В прошлом году мне приходилось видеть несчастных сотрудников IBM, вынужденных использовать Lotus Freelance вместо PowerPoint и Lotus 1-2-3 вместо Excel, поскольку у них не было никакого желания ввязываться в противном случае в политические баталии. Аналогично, я не уверен, что хотел бы оказаться в проектной команде Microsoft, которая решила бы примерно в августе 1996 года использовать Netscape Navigator вместо Internet Explorer.)
Я думаю, очень важно, чтобы участники команды пришли к единому мнению относительно используемых в проекте средств, иначе наступит хаос. Разумеется, это утверждение не следует понимать слишком буквально; оно не означает, что все участники команды должны обязательно использовать один и тот же текстовый процессор для подготовки своих документов, однако, скорее всего, важно использовать один и тот же компилятор С++. Одна из проблем, связанных с безнадёжными проектами, заключается в том, что разработчики ПО считают допустимой полную анархию на индивидуальном уровне (например, если им хочется использовать никому не известный компилятор С++, который они переписали с университетского Web-сайта, то они считают, что это их неотъемлемое право). Это совсем не так: неотъемлемым правом обладает команда, и менеджер проекта должен неуклонно проводить его в жизнь во всех ситуациях, когда несовместимые средства могут привести к значительным разногласиям.
Это означает, что, пока участники команды не поработают вместе на нескольких безнадёжных проектах, они не придут к единому мнению относительно «минимального» набора средств. После того, как достигнут консенсус по поводу набора средств, команда может обсудить средства, которыми «следует» пользоваться, при этом проблемы заключаются в том, чтобы добиться согласия в команде и получить разрешение руководства на приобретение новых средств. Если после этого ещё останется время и желание, то можно обсудить качества неопределённого количества средств, которые «можно использовать» и в которых заинтересованы различные участники команды.
Выше я высказал мысль, что менеджер проекта должен быть готов к тому, чтобы настаивать на достижении консенсуса; в самом деле, это может быть одним из критериев, используемых менеджером для выбора потенциальных участников команды. Отметим, что то же самое можно сказать относительно процессов, которые мы обсуждали в главе 5. И, как мы увидим далее, это имеет ещё большее значение, поскольку средства и процессы тесно связаны друг с другом.
Помня обо всех высказанных предостережениях, практически невозможно для такого «дилетанта», как я, с ходу перечислить все средства, рекомендуемые для безнадёжного проекта. Когда задают такой вопрос, мой ответ – «это зависит от … » – обычен для присущего консультантам и приводящего к замешательству стремления уходить от прямого ответа на любой вопрос. Итак, поскольку вы крепко запомнили мои предыдущие советы, далее приводится перечень средств, которые мне хотелось бы видеть в безнадёжных проектах:
1) Электронная почта, ПО для групповой работы, средстваInternet/Web – так же, как и в эпизоде с Microsoft, эти средства находятся в начале моего списка. Причина заключается в следующем: электронные средства общения и взаимодействия являются не только гораздо более эффективным средством коммуникации, чем записки и факсы, но они также способствуют координации и сотрудничеству. Лично мне безразлично, какие именно средства использовать: Microsoft Mail, cc:Mail, Netscape Collabra или Lotus Notes; важно только, чтобы вся команда работала в сети хранила общие проектные данные также в сети. Помимо этого, существуют и другие хорошие новые средства, но они скорее относятся к категории «следует использовать», а не «необходимо использовать».
2) Средства прототипирования/быстрой разработки приложений (RAD) – как отмечалось ранее, почти все безнадёжные проекты используют в той или иной степени прототипирование и пошаговую разработку; следовательно, им необходимы соответствующие инструментальные средства. Сегодня не так просто отыскать популярную среду разработки приложений, которая заявляла бы о себе иначе, чем среда RAD, и большинство таких средств обладают визуальным пользовательским интерфейсом, выполненным в стиле «drag and drop», облегчающим и ускоряющим процесс разработки. Я не берусь давать общие рекомендации, какие средства лучше использовать – Delphi, C++, Visual Basic или Smalltalk (или множество других). Существенно важно только одно: чтобы вся команда использовала один и тот же набор средств от одного и того же поставщика. Если одна часть команды использует VisualWorks (ParkPlace Digitalk), а другая – VisualAge for Smalltalk (IBM), то это явно глупо, хотя и допустимо с точки зрения технологии.
3) Средства управления конфигурацией (CM) /контроля версий – некоторые из моих коллег полагают, что они должны быть на первом месте в списке. John Boddie, автор Crunch Mode, высказал такое мнение:
Я хотел бы отметить, что средства управления конфигурацией действительно «необходимо использовать». По мере разработки будет возникать множество нестыковок между отдельными частями проекта, поэтому менеджер и команда нуждаются в средствах, позволяющих фиксировать и отслеживать версии системы по мере продвижения к завершению проекта.
4) Очевидно, использование средств CM может принести гораздо больше пользы, если они будут интегрированы со средствами разработки приложений. Например, SourceSafe (Microsoft) может быть, а может и не быть самым лучшим средством контроля версий ПО, однако тот факт, что оно тесно интегрировано с Visual Basic, является весомым аргументом в его пользу. Аналогично, многие другие средства разработки приложений интегрированы с PVCS (InterSolv), ENY/Developer (IBM) или другими подобными средствами CM.
5) Средства тестирования и отладки – многие из нас автоматически включают эти средства в «базовый» набор средств разработки приложений, позволяющих создавать, компилировать и выполнять код. Однако, когда мы перешли от онлайновых приложений на мэйнфреймах к клиент-серверным системам с графическим пользовательским интерфейсом, то постепенно поняли, что необходим совершенно новый набор средств тестирования; в то же время средства таких поставщиков, как SQA и Mercury Interactive, ещё не получили достаточного распространения в тех организациях, где мне удалось побывать. Аналогично, проектные команды, разрабатывающие приложения в среде Internet, скорее всего нуждаются в полностью новых средствах тестирования и отладки.
6) Средства управления проектом (оценка, планирование,PERT/GANTTи т.д.) – обычно их считают средствами менеджера проекта и, наверное, так оно и есть; возможно, только менеджеру проекта приходится каждый день пересчитывать «критический путь». Однако, к той же категории следует отнести такие средства оценки, как ESTIMACS (Computer Associates, автор – Howard Rubin), CHECKPOINT (Software Productivity Research) и SLIM (Quantitative Software Management). Эти средства, по моему мнению, являются достаточно важными, поскольку они позволяют в ходе выполнения проекта динамически пересматривать планы и сроки.
7) Наборы повторно используемых компонент – если проектная команда знакома с концепцией повторного использования ПО, и если она рассматривает её как стратегическое оружие, позволяющее достичь высокого уровня продуктивности разработки, то набор повторно используемых компонент должен быть в списке тех средств, которые «необходимо использовать». Это может быть набор компонент VBX для Visual Basic, библиотека классов ParkPlace Digitalk Smalltalk или библиотека классов MFC для C++ (Microsoft) ; разумеется, можно также использовать компоненты, разработанные другими проектными командами в организации. Выбор компонент обычно зависит от используемого языка программирования, и это ещё одна проблема, нуждающаяся в выработке единого подхода со стороны проектной команды.
8) CASE—средства для анализа/проектирования – некоторые проектные команды рассматривают CASE-средства как «костыли» для новичков, а другие считают их не менее важными, чем текстовые процессоры. Я сам отдаю предпочтение простым, недорогим и гибким CASE-средствам; кроме того, я избегаю рекомендовать какой-либо конкретный продукт или поставщика, поскольку самым разумным ответом на вопрос, какие CASE-средства использовать, будет «это зависит от …». В самом деле, как заметил Doug Scott, может вообще не понадобиться никакой технологии:
Самое лучшее средство – это большая диаграмма, приколотая к стене. Она может содержать (частично полные) E/R-диаграамы, или потоки данных, или что-нибудь другое. Важно то, что она служит отправной точкой для обсуждения проектных решений и почти не требует затрат.Как я говорил ранее, самая большая проблема, связанная с CASE-средствами, заключается в том, что они поддерживают (а иногда навязывают) определённую методологию, которую проектная команда не понимает и не желает использовать.
6.2 Средства и процессы
Упомянутая выше проблема CASE-средств, вероятно, представляет собой наиболее очевидный пример трюизма: средства и процессы связаны друг с другом достаточно сложным образом. Бессмысленно браться за CASE-средство, поддерживающее структурный анализ, если вы никогда не слышали сокращений DFD и ERD. Использование такого CASE-средства будет не только бесполезным, но и чрезвычайно обременительным, если проектная команда искренне полагает, что DFD и ERD представляют собой лишённые смысла формы бюрократических документов, преследующие единственную цель: чтобы блюстители методологии могли прикрыть свои задницы.
Но ситуация не всегда бывает такой черно-белой. Например, проектная команда может считать, что диаграммы потоков данных полезны, но только как «неформальное» средство моделирования. Таким образом, «гибкое» CASE-средство может рассматриваться как нужное и полезное, в то время как «жёсткое» CASE-средство может быть отвергнуто. Можно провести очевидную аналогию с текстовым процессором: мы все способны оценить достоинства проверки орфографии, но не хотим, чтобы нас заставляли её использовать, и вполне вероятно, что мы её никогда не использовали, поскольку проверка орфографии слишком медленна и неудобна (по крайней мере, именно под таким предлогом я не использую её в Microsoft Word!). Мы будем ещё больше раздражаться, если текстовый процессор будет настойчиво отвергать слово «ain’t» как ошибочное, или требовать, чтобы любые фразы, содержащие утверждения расистского или женоненавистнического характера, утверждались специальным комитетом. Нескольких таких «замечательных» свойств может оказаться достаточно, чтобы вынудить нас вернуться к бумаге и карандашу.
Все это означает, что команда безнадёжного проекта должна в первую очередь нормально воспринимать те процессы и методологии, которым она собирается следовать; кроме того, она должна решить, каким из этих процессов следовать беспрекословно, а каким – следовать духу, но не букве закона. После принятия такого решения можно соответственно выбрать (или отвергнуть!) средства и технологию. Таким же образом менеджер проекта может решить использовать какое-либо средство для усиления процесса, необходимость которого все понимают, но на практике следуют ему достаточно небрежно; хорошие примеры таких процессов – контроль версий и управление конфигурацией.
Один из величайших мифов, касающихся использования инструментальных средств в любых проектах (и особенно опасных в безнадёжных проектах) заключается в отношении к средству как к «серебряной пуле», которая позволит творить чудеса. Разумеется, поиском чудес занимается в основном высшее руководство, однако даже менеджера проекта могут соблазнить рекламные заявления поставщика, уверяющего, что с помощью его гениальных средств можно в десять раз повысить производительность программирования, тестирования или какой-нибудь другой деятельности.
Помимо проблемы, заключающейся в новизне таких средств и в том, что никто не знает, как их использовать (о чем будет говориться ниже), существует более важный момент: средство может стать подобным «серебряной пуле» только в том случае, если оно будет позволять или заставлять разработчиков изменять свои процессы. Например, если я пишу программу, а затем компилирую её, я делаю это в соответствии с определённым процессом. При этом программированию может предшествовать процесс сквозного контроля или тщательного, формального проектирования. Теперь, если вы дадите мне компилятор, который работает на 10% быстрее, чем предыдущий, это облегчит мою работу и сделает её несколько более эффективной; может быть, незначительно возрастёт продуктивность всего проекта в целом.Но мне не придётся менять свой процесс.
С другой стороны, если мне дадут компилятор, который работает в десять раз быстрее, то он изменит мой процесс. Так произошло, когда мы перешли в 70-е годы от ночной пакетной компиляции к онлайновой компиляции, затем к компиляции на собственных ПК и рабочих станциях в 1980-е годы, и затем к различным сочетаниям пошаговой компиляции (а ля Delphi) и интерпретации (а ля Visual Basic). Вследствие этого многие разработчики отказались от тщательного проектирования, предшествующего кодированию, из тех соображений, что они смогут писать программы на ходу и импровизировать в процессе кодирования; во многих проектах отказались также от практики сквозного кодирования, полагая, что программист и так сможет быстро обнаружить и исправить свои ошибки.
Едва ли кто-нибудь станет возражать против использования усовершенствованных технологий, позволяющих избавляться от рутинных и утомительных процессов. Гораздо труднее внедрить новую технологию, требующую введения новых процессов или модификации существующих процессов, к которым мы привыкли. Хорошим примером служит процесс повторного использования и связанная с ним технология библиотек повторно используемых компонент, броузеров и других средств. Проектные команды, использующие эту технологию, могут повысить уровень повторного использования кода приблизительно от 20 процентов (уровень, который я называю «случайным») до 60 процентов и более; разумеется, если технология используется в масштабе всей организации, то уровень повторного использования может достигать 80-90 процентов и более.
Разница между 20-процентным и 80-процентным уровнем повторного использования эквивалентна четырехкратному повышению производительности. Как отмечено в [2], постепенное последовательное повышение уровня повторного использования приносит больше выгод, чем можно было бы ожидать. Если уровень повторного использования возрастает с 80 до 90 процентов, это означает, что вместо разработки «с нуля» 20 процентов кода проектной команде придётся разрабатывать только 10 процентов. Таким образом, их загрузка снизится вдвое.
Все это замечательно – и вполне достойно называться «серебряной пулей» – но совершенно бесполезно, если проектная команда (и в конечном счёте вся организация) окажется неспособной или не пожелает менять свои процессы в соответствиями с требованиями технологии повторного использования. Ирония заключается в том, большинство организаций поставят в вину самой технологии свои собственные провалы: они приобретут дорогостоящую библиотеку классов или поменяют свою старую методологию разработки ПО на объектно-ориентированную методологию, исходя из предположения, что объекты и повторное использование – это одно и то же; когда они в конечном счёте обнаружат, что не добились сколько-нибудь ощутимых результатов, то будут винить во всем объектную технологию, библиотеку классов, поставщика и др. Между тем, все процессы остались в точности такими же, какими были до внедрения новой технологии. Культура такой организации может быть выражена следующей фразой: «Только бездари пользуются чужим кодом; настоящие программисты, черт возьми, пишут свой!»
Но ситуация не всегда бывает такой черно-белой. Например, проектная команда может считать, что диаграммы потоков данных полезны, но только как «неформальное» средство моделирования. Таким образом, «гибкое» CASE-средство может рассматриваться как нужное и полезное, в то время как «жёсткое» CASE-средство может быть отвергнуто. Можно провести очевидную аналогию с текстовым процессором: мы все способны оценить достоинства проверки орфографии, но не хотим, чтобы нас заставляли её использовать, и вполне вероятно, что мы её никогда не использовали, поскольку проверка орфографии слишком медленна и неудобна (по крайней мере, именно под таким предлогом я не использую её в Microsoft Word!). Мы будем ещё больше раздражаться, если текстовый процессор будет настойчиво отвергать слово «ain’t» как ошибочное, или требовать, чтобы любые фразы, содержащие утверждения расистского или женоненавистнического характера, утверждались специальным комитетом. Нескольких таких «замечательных» свойств может оказаться достаточно, чтобы вынудить нас вернуться к бумаге и карандашу.
Все это означает, что команда безнадёжного проекта должна в первую очередь нормально воспринимать те процессы и методологии, которым она собирается следовать; кроме того, она должна решить, каким из этих процессов следовать беспрекословно, а каким – следовать духу, но не букве закона. После принятия такого решения можно соответственно выбрать (или отвергнуть!) средства и технологию. Таким же образом менеджер проекта может решить использовать какое-либо средство для усиления процесса, необходимость которого все понимают, но на практике следуют ему достаточно небрежно; хорошие примеры таких процессов – контроль версий и управление конфигурацией.
Один из величайших мифов, касающихся использования инструментальных средств в любых проектах (и особенно опасных в безнадёжных проектах) заключается в отношении к средству как к «серебряной пуле», которая позволит творить чудеса. Разумеется, поиском чудес занимается в основном высшее руководство, однако даже менеджера проекта могут соблазнить рекламные заявления поставщика, уверяющего, что с помощью его гениальных средств можно в десять раз повысить производительность программирования, тестирования или какой-нибудь другой деятельности.
Помимо проблемы, заключающейся в новизне таких средств и в том, что никто не знает, как их использовать (о чем будет говориться ниже), существует более важный момент: средство может стать подобным «серебряной пуле» только в том случае, если оно будет позволять или заставлять разработчиков изменять свои процессы. Например, если я пишу программу, а затем компилирую её, я делаю это в соответствии с определённым процессом. При этом программированию может предшествовать процесс сквозного контроля или тщательного, формального проектирования. Теперь, если вы дадите мне компилятор, который работает на 10% быстрее, чем предыдущий, это облегчит мою работу и сделает её несколько более эффективной; может быть, незначительно возрастёт продуктивность всего проекта в целом.Но мне не придётся менять свой процесс.
С другой стороны, если мне дадут компилятор, который работает в десять раз быстрее, то он изменит мой процесс. Так произошло, когда мы перешли в 70-е годы от ночной пакетной компиляции к онлайновой компиляции, затем к компиляции на собственных ПК и рабочих станциях в 1980-е годы, и затем к различным сочетаниям пошаговой компиляции (а ля Delphi) и интерпретации (а ля Visual Basic). Вследствие этого многие разработчики отказались от тщательного проектирования, предшествующего кодированию, из тех соображений, что они смогут писать программы на ходу и импровизировать в процессе кодирования; во многих проектах отказались также от практики сквозного кодирования, полагая, что программист и так сможет быстро обнаружить и исправить свои ошибки.
Едва ли кто-нибудь станет возражать против использования усовершенствованных технологий, позволяющих избавляться от рутинных и утомительных процессов. Гораздо труднее внедрить новую технологию, требующую введения новых процессов или модификации существующих процессов, к которым мы привыкли. Хорошим примером служит процесс повторного использования и связанная с ним технология библиотек повторно используемых компонент, броузеров и других средств. Проектные команды, использующие эту технологию, могут повысить уровень повторного использования кода приблизительно от 20 процентов (уровень, который я называю «случайным») до 60 процентов и более; разумеется, если технология используется в масштабе всей организации, то уровень повторного использования может достигать 80-90 процентов и более.
Разница между 20-процентным и 80-процентным уровнем повторного использования эквивалентна четырехкратному повышению производительности. Как отмечено в [2], постепенное последовательное повышение уровня повторного использования приносит больше выгод, чем можно было бы ожидать. Если уровень повторного использования возрастает с 80 до 90 процентов, это означает, что вместо разработки «с нуля» 20 процентов кода проектной команде придётся разрабатывать только 10 процентов. Таким образом, их загрузка снизится вдвое.
Все это замечательно – и вполне достойно называться «серебряной пулей» – но совершенно бесполезно, если проектная команда (и в конечном счёте вся организация) окажется неспособной или не пожелает менять свои процессы в соответствиями с требованиями технологии повторного использования. Ирония заключается в том, большинство организаций поставят в вину самой технологии свои собственные провалы: они приобретут дорогостоящую библиотеку классов или поменяют свою старую методологию разработки ПО на объектно-ориентированную методологию, исходя из предположения, что объекты и повторное использование – это одно и то же; когда они в конечном счёте обнаружат, что не добились сколько-нибудь ощутимых результатов, то будут винить во всем объектную технологию, библиотеку классов, поставщика и др. Между тем, все процессы остались в точности такими же, какими были до внедрения новой технологии. Культура такой организации может быть выражена следующей фразой: «Только бездари пользуются чужим кодом; настоящие программисты, черт возьми, пишут свой!»