Минимально необходимый набор средств

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

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

С другой стороны, предположим, что команда работает в крупной корпорации, имеющей в своем распоряжении сотни различных средств приобретавшихся в течение целого ряда лет. Следует ли их все использовать? Конечно, нет! Даже если все они работают, те умственные усилия, которые необходимо приложить, чтобы запомнить, как ими пользоваться, а также дополнительные усилия для обеспечения их совместной работы обычно сводят на нет всю выгоду. Можно провести аналогию с командой альпинистов, которые собираются штурмовать вершину и пытаются решить, какое снаряжение им использовать. Существуют вещи которые необходимы (палатки, питьевая вода и т.д.). И если маршрут не слишком сложный, можно взять с собой некоторые новомодные приспособления, о которых они прочли в своем любимом альпинистском журнале. Однако, если они собираются штурмовать Эверест, им обойтись без помощи ослов-носильщиков или местных жителей, иначе они будут не в состоянии тащить на спине по 300 фунтов снаряжения на человека.

Команда экстремального проекта должна самостоятельно, независимо от принятых в организации стандартов, решить, какие средства являются необходимыми, а без каких можно обойтись. Удивителен подход ряда организаций к экстремальным проектам, когда все проекты заставляют разрабатывать на Коболе (в других организациях в таком качестве может фигурировать Visual Basic или Oracle, или что-нибудь еще...), даже если эта технология совершенно не подходит для конкретного проекта. Это можно сравнить с ситуацией, когда кто-либо говорит руководителю команды альпинистов, собирающейся штурмовать Эверест: "Наш комитет решил, что ваша проектная команда должна взять подробную схему Нью-Йоркского метро, поскольку в большинстве проектов ее сочли очень полезной".

Очень важно, чтобы участники команды пришли к единому мнению относительно используемых в проекте средств, иначе наступит хаос. Разумеется, это утверждение не следует понимать слишком буквально.

Оно не означает, что все участники команды должны обязательно использовать один и тот же текстовый процессор для подготовки своих документов, однако, скорее всего, важно использовать один и тот же компилятор C++. Одна из проблем, связанных с экстремальными проектами, заключается в том, что разработчики ПО считают допустимой полную анархию на индивидуальном уровне (например, если им хочется использовать никому не известный компилятор C++, который они переписали с университетского Web-сайта, то они считают, что это их неотъемлемое право). Это совсем не так: неотъемлемым правом обладает команда, и менеджер проекта должен неуклонно проводить его в жизнь во всех ситуациях, когда несовместимые средства могут привести к значительным разногласиям.

Это означает, что, пока участники команды не поработают вместе на нескольких экстремальных проектах, они не придут к единому мнению относительно "минимального" набора средств. После того как достигнут консенсус по поводу набора средств, команда может обсудить средства, которыми "следует" пользоваться, при этом проблемы заключаются в том, чтобы добиться согласия в команде и получить разрешение руководства на приобретение новых средств. Если после этого еще останется время и желание, то можно обсудить качества неопределенного количества средств, которые "можно использовать" и в которых заинтересованы различные участники команды.

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

Практически невозможно сразу перечислить все средства, рекомендуемые для экстремального проекта. Когда задают такой вопрос, обычный ответ: "это зависит от...". Тем не менее далее приводится перечень средств, которые, по мнению Йордана, хотелось бы видеть в экстремальных проектах:

• Электронная почта, ПО для групповой работы, средства Internet/ Web. Так же, как и в эпизоде с Microsoft, эти средства находятся в начале списка. Причина заключается в следующем: электронные средства общения и взаимодействия являются не только гораздо более эффективным средством коммуникации, чем записки и факсы, но они также способствуют координации и сотрудничеству. Не столь важно, какие именно средства использовать: Microsoft Mail, cc:Mail, Netscape Collabra или Lotus Notes. Важно только, чтобы вся команда работала в сети и хранила общие проектные данные также в сети. Помимо этого, существуют и другие хорошие новые средства, но они скорее относятся к категории "следует использовать", а не "необходимо использовать".

• Средства прототипирования/быстрой разработки приложений (RAD). Почти все экстремальные проекты используют в той или иной степени прототипирование и пошаговую разработку, следовательно, им необходимы соответствующие инструментальные средства. Сегодня не так просто отыскать популярную среду разработки приложений, которая заявляла бы о себе иначе, чем среда RAD, и большинство таких средств обладают визуальным пользовательским интерфейсом, выполненным в стиле "drag and drop", облегчающим и ускоряющим процесс разработки. Не стоит давать общие рекомендации, какие средства лучше использовать - Delphi, C++, Visual Basic или Smalltalk (или множество других). Существенно важно только одно: чтобы вся команда использовала один и тот же набор средств от одного и того же поставщика. Если одна часть команды использует VisualWorks (ParkPlace Digitalk), а другая — VisualAge for Smalltalk (IBM), то это явно глупо, хотя и допустимо технологически.

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

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

• Средства управления проектом (оценка, планирование, PERT/ GANTT и т.д.). Обычно их считают средствами менеджера проекта, и, наверное, так оно и есть. Возможно, только менеджеру проекта приходится каждый день пересчитывать "критический путь". Однако к той же категории следует отнести такие средства оценки, как ESTIMACS (Computer Associates, автор Howard Rubin), CHECKPOINT (Software Productivity Research) и SLIM (Quantitative Software Management). Эти средства являются достаточно важными, поскольку они позволяют в ходе выполнения проекта динамически пересматривать планы и сроки. • Наборы повторно используемых компонентов. Если проектная команда знакома с концепцией повторного использования ПО и если она рассматривает ее как стратегическое оружие, позволяющее достичь высокого уровня продуктивности разработки, то набор повторно используемых компонентов должен быть в списке тех средств, которые "необходимо использовать". Это может быть набор компонентов VBX для Visual Basic, библиотека классов ParkPlace Digitalk Smalltalk или библиотека классов MFC (Microsoft Foundation Classes) для C++ (Microsoft). Разумеется, можно также использовать компоненты, разработанные другими проектными командами в организации. Выбор компонентов обычно зависит от используемого языка программирования, и это еще одна проблема, нуждающаяся в выработке единого подхода со стороны проектной команды.

• CASE-средства для анализа/проектирования. Некоторые проектные команды рассматривают CASE-средства как "костыли" для новичков, а другие считают их не менее важными, чем текстовые процессоры. Предпочтение следует отдать простым, недорогим и гибким CASE-средствам. Кроме того, лучше не рекомендовать какой-либо конкретный продукт или поставщика, поскольку самым разумным ответом на вопрос, какие CASE-средства использовать, будет: "это зависит от...".

Самая большая проблема, связанная с CASE-средствами, заключается в том, что они поддерживают (а иногда навязывают) определенные методы, которые проектная команда не понимает и не желает использовать.