Разработка программ: Передовые методы управления разработкой

Процессы

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

• Итеративная разработка;
• Контрольные точки (вехи) с учетом рисков;
• Адаптация процесса;
• Непрерывное совершенствование;
• Встроенное соответствие стандартам.

Итеративная разработка

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

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

Преимущества итеративной разработки

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

1. Деление проекта на временные промежутки способствует быстрому принятию решений и фиксации внимания на самых важных моментах. Если срок сдачи проекта истекает через два года, вы меньше чувствуете безотлагательность сдачи и необходимость принятия решений, чем в том случае, если этот срок составляет четыре недели;
2. Регулярная поставка работающего программного обеспечения повышает возможности использования обратной связи. Периодически сдавая прошедшие тестирование программы, вы получаете неоценимую обратную связь в процессе компиляции, интеграции, использования различных инструментов тестирования, а также от основных заинтересованных лиц, что способствует созданию работающего программного кода. Такая обратная связь помогает выявить проблемы на ранних этапах разработки, то есть тогда, когда их можно исправить с наименьшими затратами. Если ошибки исправляются тогда, когда для этого есть и время, и возможность, экономическая эффективность проекта будет гораздо выше;
3. Управление на основе фактов. Нравится нам это или нет, но большая часть дискуссий, происходящих в первые две трети жизненного цикла проекта, субъективна: "Я изучил архитектурное решение: по-моему, в нем есть несколько крупных недостатков". При помощи итеративной разработки мы переходим от этих субъективных дискуссий к объективным, основанным на фактах: "Я ознакомился с результатами тестирования производительности: они подтверждают мою точку зрения - эта архитектура не обеспечит работу системы при требуемой нагрузке";
4. Итеративный подход к разработке повышает шанс создать систему, которая будет удовлетворять реальным потребностям заинтересованных лиц. С экономической точки зрения итеративная разработка способствует формированию более благоприятной кривой выполнения работ: тестирование в этом случае происходит быстрее, потому что на протяжении всей разработки вносятся небольшие корректировки, в отличие от системы, которая разрабатывалась без тестирования на протяжении многих месяцев или даже лет. Благодаря итеративной разработке получаются системы, которые больше соответствуют стратегической задаче, чем исходная (и изобилующая недостатками) подробная спецификация требований.

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

Необходимость изменений

При переходе на итеративную разработку необходимо продумать следующие моменты:

• Обучение и наставничество. Для того, чтобы итеративный подход обеспечил успех разработки, необходимы инвестиции в переподготовку и развитие механизма наставничества. Специалистам по информационным технологиям с традиционными взглядами придется избавиться от ложного чувства большей надежности, обеспечиваемой при продумывании всего проекта заранее. Кроме того, всем специалистам необходимо получить знания и навыки, не относящиеся к их основной специальности, чтобы они с большей легкостью могли переходить от одной деятельности к другой в рамках проекта. Руководству подразделений информационных технологий и заинтересованным деловым кругам необходимо понимать, какие входные и промежуточные продукты в какие сроки ожидать. Обучение и наставничество могут осуществляться постепенно;
• Изменение требований к квалификации каждого специалиста. Для итеративной разработки необходим совсем другой объем квалификации и другой набор ролей. Традиционное управление проектом требовало, чтобы члены рабочей группы были узкими специалистами; а итеративная разработка будет более эффективной, если специалисты будут иметь более широкую квалификацию. Например, если раньше члены рабочей группы были либо разработчиками, либо специалистами по реализации, то теперь они должны заниматься одновременно разработкой проекта и реализацией. У некоторых специалистов переход к итеративным принципам разработки может вызвать определенные трудности;
• Изменение ресурсов проекта. Итеративные методы требуют перераспределения персонала при возникновении необходимости в специалистах определенной квалификации. Например, тестировщики становятся востребованными на более ранних этапах жизненного цикла, поскольку тестирование осуществляется на всем протяжении разработки, а не только ближе к ее завершению. Аналогично, архитекторы необходимы и на более поздних этапах жизненного цикла проекта, потому что архитектурные задачи, поставленные ранее ¹ , продолжают решаться на протяжении всего проекта. Это требует переподготовки и перераспределения рабочей силы;
• Управление проектом требует большей степени вовлеченности. Для руководителей проекта итеративная разработка более сложна, особенно в первые три четверти жизненного цикла проекта. Причина заключается в том, что итерационный подход к разработке вынуждает принимать сложные решения на ранних этапах; кроме того, в проекте больше подвижных компонентов. Вместо того чтобы, как раньше, все члены рабочей группы в течение трех месяцев занимались сбором и анализом требований, теперь в каждой итерации будут в уменьшенном объеме присутствовать все этапы жизненного цикла: сбор и анализ требований, построение архитектурного решения, разработка, реализация и тестирование. Это имеет определенные преимущества: вы сможете избежать болезненных разочарований и непростого отказа от ожиданий на поздних стадиях проекта. Способность приверженца итерационного подхода разрекламировать новые методики управления проектами руководителям проекта и руководителям среднего звена очень важна для успешного внедрения методов итеративной разработки.

Антишаблоны

Следующие антишаблоны показывают, что итерационный подход к разработке применяется неправильно:

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

Типовые рекомендации

Для начала мы рекомендуем использовать итерации длительностью в четыре недели. ² Как только вы поймете, что в вашем контексте больше подойдет другая продолжительность итерации, измените ее. Стремитесь использовать самые короткие итерации, возможные в вашей среде. Между итерациями не должно быть перерывов.

Контрольные точки (вехи) с учетом рисков

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

Движение в сторону понижения риска уменьшает неопределенность в выборе технологии, в том числе готовых решений (COTS, commercial off-the-shelf selections), и стабильности архитектуры, а также нашего представления об эффективности рабочей группы. Это снижение неопределенности также уменьшает расхождение в оценках, поскольку существует прямая зависимость между этими факторами и возможностью формировать обоснованные оценки.

Поскольку снижение риска и создание ценности на ранних стадиях проекта являются основополагающими для успешной реализации проекта (см. рисунок 2), важно правильно расставить контрольные точки. Именно поэтому все четыре фазы процесса RUP оканчиваются контрольной точкой, требующей оценки промежуточных продуктов проекта, чтобы показать адекватное понижение риска и оценку создания ценности. Например, в конце фазы Elaboration (Уточнение) вам нужно управлять максимально возможным объемом технических рисков и создать стабильную архитектуру. Члены рабочей группы должны показать, что у них есть выполнимая архитектура с несколькими готовыми к выполнению сценариями и со списком рисков, в котором отражено уменьшение многих ключевых технических и прочих рисков. Необходимо найти правильное соотношение между понижением рисков, значимостью созданного на данном этапе кода и ценностью решений, принятых на ранних стадиях. Соотношение этих факторов, правильное для одного проекта, может оказаться неподходящим для другого.

Рисунок 2: Понижение риска (светлая кривая) и ценность (фиолетовая кривая) на протяжении жизненного цикла проекта.

Преимущества контрольных точек с учетом риска

Контрольные точки с учетом риска имеют следующие преимущества:

• Взгляд заинтересованных лиц. Контрольные точки позволяют заинтересованным лицам тщательно рассмотреть проект и внести в него свежую струю. Взгляд на проект заинтересованных лиц обеспечивает руководство или реакцию на события и обстоятельства, которые не видны рабочей группе проекта;
• Создание ценности на ранних этапах. Наибольшая ценность создается благодаря принятию жестких решений и подтверждению правильности этих решений. В этом отражается природа систем как проявление творческого потенциала человека. Кроме того, это означает, что большинство инноваций вносится на ранних фазах проекта, как показано на рисунке 3;
• Предотвращение потерь на ранних стадиях. Некоторые проекты строятся на неправильных предположениях и обречены на неудачу с самого начала. Хотя такие проекты явно неудачны, неплохо бы избежать слишком больших денежных расходов до того, как это станет очевидным. Итерации, основанные на учете рисков, выявляют неудачные проекты на самых ранних стадиях жизненного цикла;
• Повышение производительности. Если избавиться от технических рисков еще на ранних стадиях, архитектура сможет обрести стабильность гораздо быстрее. Это обеспечит большую рентабельность исполнения, потому что на поздних этапах проекта вы меньше будете сталкиваться с непредвиденными техническими неизвестными;
• Сокращение вариаций в оценках. Оценки всегда имеют вариации, и их разброс пропорционален количеству неизвестных или рисков. Следовательно, понижение рисков на ранних этапах означает более быстрое уменьшение вариаций оценок.

Рисунок 3: Создание ценности на ранних этапах означает, что большая часть инноваций появляется на ранних этапах проекта, тогда как риск постепенно понижается на протяжении всего жизненного цикла.

Необходимость изменений

При переходе на использование контрольных точек (вех) с учетом рисков необходимо продумать следующие моменты:

• Новая парадигма планирования. Смягчение рисков работает в том случае, если вы меняете вашу тактику, учитывая риски, с которыми сталкиваетесь. Поэтому контрольные точки с учетом рисков требуют адаптивного процесса планирования, при котором планы приспосабливаются к реальным условиям. Вспомните утверждение Эйзенхауэра: " Планы - ничто, планирование - все. " Если вы не готовы принять эволюционирующие планы, то контрольные точки с учетом рисков - не для вас;
• Адаптивный процесс. Наряду с адаптацией планирования необходимо адаптировать процесс разработки. Если ваш процесс слишком директивен, он не обеспечит рабочую группу гибкостью, необходимой для достижения успеха, особенно на стадиях инноваций (Innovation), показанных на рисунке 3. Большее количество процессов редко приводит к появлению большего количества инноваций. Далее, на этапах эффективной стоимости (Cost Efficient) вам понадобятся менее гибкие процессы.

Антишаблоны

С контрольными точками с учетом рисков ассоциируются следующие антишаблоны:

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

Типовые рекомендации

Мы рекомендуем использовать контрольные точки, описанные в процессе RUP: Inception (Обследование), Elaboration (Проработка проекта), Construction (Построение системы) и Transition (Передача), которые четко определены и сосредоточены на смягчении рисков.

Адаптация процесса

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

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

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

В-третьих, организация должна стремиться к непрерывному улучшению процесса . Выполняйте в конце каждой итерации и в конце проекта анализ выполненных работ, чтобы зафиксировать полученный опыт и использовать эти знания для улучшения процесса. Дайте указание всем членам рабочей группы постоянно искать возможности для улучшения и передавайте такие улучшения организациям, финансирующим улучшения процесса, например, группе разработки программного обеспечения и процессов (Software Engineering and Process Group, SEPG) вашей компании. На эти действия необходимо специально выделять время и деньги.

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

Рисунок 4: Факторы, определяющие необходимый объем структуризации процесса. Необходимая именно вам степень структурирования процесса определяется многими факторами - размером проекта, распределенностью рабочей группы, сложностью технологии, количеством заинтересованных лиц, требованиями соответствия стандартам, конкретной фазой проекта.

Преимущества

Адаптация процесса дает некоторые преимущества:

• Повышение производительности. Процесс, адаптированный к потребностям проекта, может повысить, вопреки препятствиям, производительность проекта за счет предоставления объединяющей команду силы, благодаря чему больше усилий тратится на производительную деятельность. Кроме того, он может повысить производительность отдельных членов рабочей группы благодаря предлагаемым шаблонам, примерам и рекомендациям;
• Воспроизводимость результатов. Адаптируемый процесс позволяет рабочей группе приспособиться к тактическим потребностям проекта. Благодаря этому рабочая группа получает поддержку и гибкость, которые необходимы ей для получения воспроизводимых результатов. Однако во многих случаях воспроизводимые результаты требуют некоторой адаптируемости в процессе, чтобы обеспечить соответствие тактическим требованиям; "воспроизводимость" в данном случае не может означать просто 100-процентно идентичное воспроизведение процесса, а, скорее, воспроизводимость фаз процесса, каждая из которых проходит через известный ряд шагов, результатов и показателей;
• Создание ценности на ранних этапах и понижение рисков. Возможность внесения инноваций обеспечивается за счет адаптации и снижения формальности процесса в соответствии со степенью неопределенности проекта. На ранних фазах проекта может быть создано больше ценности, кроме того, это позволяет понизить риски;
• Совместное использование полученного опыта между рабочими группами и проектами. Адаптируя процесс на основе выводов по предыдущим проектам, вы эффективно делитесь полученными знаниями с другими рабочими группами.

Необходимость изменений

С адаптацией процесса ассоциируются следующие компромиссы:

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

Антишаблоны

С адаптацией процесса ассоциируются следующие антишаблоны:

• Чем больше процессов - тем лучше. Всегда считать, что лучше иметь больше процессов, больше документации и больше детализированного предварительного планирования, в том числе настаивать на раннем прогнозировании и следовании этим прогнозам;
• Согласованный и воспроизводимый процесс. Используются всегда одинаковые процессы, независимо от того, о чем идет речь. (Фактически, целью должно стать разрешение вариаций, чтобы каждый проект мог стать успешным. Следовательно, постоянное использование одного и того же процесса и тот же объем процесса на протяжении всего проекта - это антишаблон, который приведет к провалу. Реальная задача - согласованность и воспроизводимость результатов.);
• Специализированный процесс. Вы либо создаете процесс по мере того, как двигаетесь вперед, либо адаптируете его каждый раз до такой степени, что процесс из одного проекта невозможно узнать в следующем проекте. (Если не определено ни одного процесса, то невозможно ожидать предсказуемых результатов, риски не будут выявлены и смягчены, не состоится обмен опытом между рабочими группами.)

Типовые рекомендации

Мы рекомендуем использовать инфраструктуру процесса RUP, настроив готовые процессы разработки с учетом потребностей проекта.

Непрерывное улучшение

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

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

Существует несколько способов идентифицировать потенциальные улучшения процесса разработки ПО в процессе выполнения проекта программного обеспечения:

1. Неформальные семинары по улучшению. Регулярно собирайте вашу рабочую группу, возможно, ключевых заинтересованных лиц проекта, и просто просите их поговорить о том, что делается правильно, что неправильно, и каковы возможные способы улучшить совместную работу;
2. Ретроспективы. Ретроспектива ⁴ - это встреча группы, на которой задаются четыре вопроса: Что из сделанного нами хорошо мы могли бы забыть, если бы не обсудили? Чему мы научились? Что мы должны в следующий раз сделать иначе? Что до сих пор является для нас загадкой? Цель таких ретроспектив, которые могут проводиться в любой момент на протяжении жизненного цикла- это идентификация потенциальных областей улучшения;
3. Ящик для предложений. Иногда самый простой способ идентифицировать потенциальные способы улучшения каких-либо моментов - это предоставить сотрудникам возможность анонимно подавать свои предложения в любое время. Ящики для предложений могут быть обычными ящиками, но теперь гораздо чаще используются их электронные аналоги;
4. Личное обсуждение. Хорошо бы выработать у ваших сотрудников привычку иногда уделять время обдумыванию своей работы: насколько хорошо они работают, взаимодействуют с другими, выполняют свои задачи. Такое размышление часто приводит к выработке личной стратегии улучшения, но может также порождать предложения по общему улучшению процесса;
5. Редактируемый процесс. Предоставьте рабочей группе базовый процесс, но также предоставьте им право и инструменты, такие как Wiki, для изменения этого процесса согласно их пониманию.

Преимущества

Эта методика имеет ряд преимуществ:

• Вы учитесь в процессе работы. Рабочие группы могут сразу начать использовать новый взгляд на вещи вместо того, чтобы ждать следующего процесса, на котором можно будет испытать улучшения. Это приводит к более быстрому повышению производительности. Методика особенно эффективна в сочетании с описанной ранее методикой "Итеративная разработка", поскольку опыт, полученный в процессе одной итерации, может быть сразу же использован в другой итерации;
• Рабочая группа четко контролирует ход событий. Эта методика фактически разрешает рабочим группам вносить свои усовершенствования в процесс и позволяет им более эффективно организовать свою работу. (В Части III, которая выйдет в следующем месяце, будет описан метод "Самоорганизация рабочей группы" с дополнительными подробностями этой концепции.)

Необходимость изменений

С этой методикой ассоциируются следующие моменты:

• Она требует инвестиций. Вам придется выделить время сверх расписания вашего проекта, чтобы инвестировать в деятельности усовершенствования процесса;
• Вам придется действовать. Не существует моментов, в которых можно идентифицировать возможности для улучшения, если вы реально с ними не работаете;
• Нужно быть честным с самим собой.. Многие проблемы, с которыми сталкиваются рабочие группы, сосредоточены вокруг отдельных лиц и способов, которыми они взаимодействуют с другими. Людям, работающим над проектом, необходимо чувствовать себя достаточно защищенными, чтобы указывать на проблемы и потенциальные решения, даже если эти решения идут вразрез с тем, как хотели бы работать другие сотрудники;
• Возможно, вам потребуется использовать в проекте управление конфигурацией и изменениями. Некоторым проектным группам будет необходимо соответствовать стандартам, например, ISO 900X или FDA 21 CFR Part 11, которые требуют, чтобы процесс рабочей группы был определен, причем рабочая группа должна предоставить доказательства, что следует этому процессу. Смысл в том, что для соответствия этим стандартам, возможно, придется отслеживать все изменения вашего процесса, основания, по которым вы внесли любое из изменений и дату изменения.

Антишаблоны

К усовершенствованию процесса разработки ПО имеют отношение следующие антишаблоны:

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

Типовые рекомендации

Мы рекомендуем уделить два часа в конце каждой итерации тому, чтобы провести неформальную встречу по усовершенствованию процесса или ретроспективу.

Встроенное соответствие стандартам

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

Большая часть этой "тяжелой работы" по обеспечению соответствия стандартам может быть автоматизирована при помощи соответствующего инструментария. Например, закон Сарбейнса-Оксли (Sarbanes-Oxley act, SOX) определяет строгие директивы для извлечения, доступа и изменения финансовой информации. Большая часть отслеживания, необходимого по SOX, может быть автоматизирована через продукты, построенные на базе IBM® Tivoli®, например, Tivoli Access Manager и Tivoli Storage Manager. Аналогично, директивы Администрации по контролю за продуктами питания и лекарствами (Food and Drug Administration), а также рекомендации интегрированной модели технологической зрелости организации (Capability Maturity Model Integrated, CMMI) требуют отслеживания требований к контрольным примерам при разработке кода. Комбинация из таких инструментов, как IBM Rational RequisitePro®, IBM Rational Software Architect и IBM Rational ClearQuest®поможет автоматизировать большую часть работы по отслеживанию посредством интеграции определения требований, моделирования проекта и функций отслеживания дефектов.

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

Преимущества

Встроенное соответствие стандартам обладает рядом преимуществ:

1. Преимущества соответствия стандартам. Обычные преимущества использования соответствия стандартам очевидны: это сохранение работоспособности предприятия и возможность подать маркетинговую заявку о соответствии вашей организации ISO-900X, CMMI и т. д. Кроме того, большая часть усилий по обеспечению соответствия стандартам ведет к повышению операционной эффективности;
2. Более низкая стоимость. Встраивая соответствие стандартам в ваши инструменты и процессы, вы уменьшаете издержки на достижение такого соответствия. Ручные подходы к обеспечению соответствия стандартам - трудоемкое внешнее документирование и тщательные пересмотры - оказываются на практике очень затратными и не очень эффективными, потому что люди часто не выполняют сложных работ по обеспечению соответствия стандартам;
3. Меньше противодействия со стороны рабочих групп. Большинство специалистов по информационным технологиям вообще не в восторге от бюрократических методов, особенно, если они являются результатом требований соответствия стандартам. Встроенное соответствие стандартам помогает людям, насколько это возможно, делать все правильно;
4. Более высокая степень соответствия стандартам. Если большинство требований соответствия стандартам или даже все требования автоматизированы, то у проектной группы гораздо больше шансов добиться соответствия и создать необходимую документацию для доказательства этого факта. Например, если ваша система управления версиями требует, чтобы сотрудник, сдающий рабочий продукт, указал требование или дефект, с которым он работает, то отслеживаемость требований была бы значительно усовершенствована: десять секунд рабочего времени при каждой сдаче рабочего продукта могут сэкономить недели трудоемкой и подверженной ошибкам работы в конце работы над проектом. Напротив, если соответствие стандартам обеспечивается вручную, то эта работа обычно откладывается на последнюю минуту и выполняется спустя рукава.

Необходимость изменений

С встроенным обеспечением соответствия стандартам ассоциируются следующие моменты:

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

Антишаблоны

С обеспечением соответствия стандартам связаны следующие антишаблоны:

• Избыток документации. Требованиям обеспечения соответствия стандартам присваивается более высокий приоритет, чем вашей повседневной работе, и организация начинает тонуть в ненужной бумажной работе. Ваша цель - минимизировать необходимый объем работы так, чтобы не нарушались требования обеспечения соответствия стандартам, а еще лучше, чтобы обеспечение совместимости считалось двигателем бизнеса, а не непроизводительными расходами;
• Соответствие стандартам из страха перед законом. Организации зачастую вкладывают слишком много денег в решение по обеспечению соответствия стандартам. Большинство законодательных норм предусматривают определенную свободу действий, признавая, что организации имеют разные цели, требующие разных уровней соответствия стандартам. Одна из распространенных ошибок - не включать специалистов-практиков в определение работ по обеспечению совместимости, тем самым значительно понижаются шансы определить практический подход к новому поручению.

Типовые рекомендации

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

Показатели

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

• Простые и значимые показатели;
• Непрерывный мониторинг проекта.

Простые и значимые показатели

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

• Показатели должны быть простыми. Большая часть организаций либо совсем не используют системы показателей, то есть действуют вслепую, либо слишком усердствуют в этом отношении. Простые показатели, как, например, сумма израсходованных денег или количество дефектов, ожидающих обработки на данный момент, имеют два ключевых атрибута. Во-первых, их просто собирать, и, в идеале, автоматизировать, ведь сбор показателей вручную часто неэффективен и подвержен ошибкам. Во-вторых, они должны быть простыми для понимания и толкования, чтобы можно было принять меры, если произойдет какая-либо ошибка;
• Показатели должны быть общими. Показатели должны быть общими и использоваться во всей организации. Если каждый проект будет иметь собственный набор показателей и свое толкование этих показателей, то контроль со стороны руководства станет невозможным. Рабочие группы могут утвердить некоторые дополнительные показатели, значимые для их проекта, и это хорошо до тех пор, пока основная, организационная система показателей также поддерживается в актуальном состоянии;
• Показатели должны быть значимыми. Многие организации, занимающиеся сбором показателей, выполняют слишком мало действий, основанных на их оценке. Причина заключается в том, что эти показатели недостаточно значимы. Для каждого показателя следует определить действие, которое должно быть выполнено по достижении им определенного порогового значения. Если вы не можете определить, какое действие надо выполнить, то зачем нужен такой показатель? Кроме того, следует иметь минимум необходимых показателей, поскольку нужно сосредоточиться на основных моментах, а не отслеживать незначительные события и реагировать на них.

Преимущества простых и значимых показателей

При правильном подходе принятие системы простых и значимых показателей имеет ряд преимуществ:

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

Необходимость изменений

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

• Количество показателей. После того, как вы начнете собирать показатели, у вас появится искушение собирать много разных типов показателей. Это кажется более точным, и кто знает, возможно, лишний показатель окажется когда-нибудь действительно полезным. Тем не менее, мы настоятельно рекомендуем вам начать с самого маленького количества показателей, которое только возможно, а затем, если будет нужно, добавить еще. Мы рекомендуем использовать совсем немного показателей: чем меньше, тем лучше. После принятия новых показателей старые необходимо удалить; иначе сложность и стоимость сбора показателей будет возрастать с убывающими возвратами в предоставляемых ими значениях. Если вы не собираетесь использовать показатель в дальнейшем, тогда зачем он нужен?
• Возмущение спокойствия. Сбор показателей может обнаружить некоторые истины, которые сотрудники организации предпочли бы скрыть. Без показателей вы практически двигались наугад. Представьте себе, что это происходит на протяжении десяти месяцев жизненного цикла проекта. Это кажется удобным, вы думаете, что все идет как надо. Но что произойдет, если в самом конце проекта вы поймете, что он обречен на неудачу? Вы вынуждены искать причины - возможно даже, вы их представляете - того, почему проект изначально не мог быть успешным. Поскольку у вас нет показателей, которые можно проанализировать, вы будете искать оправдания, вроде "клиенты постоянно меняют свои мнения", "непредвиденные технические проблемы" и "техническая несовместимость". Напротив, имея показатели, вы, по меньшей мере, имеете объективное представление о том, что пошло не так. Наиболее вероятно, что причин окажется несколько, в том числе определенные проблемы, которые необходимо решить в вашей организации;
• Инвестиции. Показатели нельзя получить бесплатно. Если вы автоматизируете сбор показателей, то речь идет о предварительных инвестициях. Если вы решите использовать сбор показателей вручную, то это связано с меньшими предварительными затратами, зато в этом случае больше постоянных инвестиций;
• Отклонения: Проект имеет определенный набор параметров, которыми можно оперировать, таких как стоимость и качество. Если проект начнет выходить за пределы этих параметров или приблизится к ним, вы захотите иметь под рукой показатель, который укажет на такое отклонение;
• Доверие. Показатели могут быть очень ценным инструментом, если использовать их для честных обсуждений, обучения и поощрения сотрудников. Вы не должны наказывать сотрудников, если показатели становятся плохими, но обязательно должны наказывать тех людей, которые не обращают внимания на плохие показатели;
• Вы, как и раньше, должны разговаривать с людьми. Показатели могут время от времени сигнализировать, что у вас проблема, но они никогда не предоставляют всей информации, необходимой для принятия правильного решения. Вам по-прежнему необходимо регулярно общаться с людьми, чтобы понять основные причины.

Антишаблоны

С показателями связаны следующие антишаблоны:

• Заработанная стоимость по документам. В традиционном подходе к управлению подсчитывается определенный процент "заработанной стоимости", а, следовательно, и прогресса, при заполнении таких важных документов, как спецификация требований или детализированная документация проекта. В реальной жизни большая часть спецификаций содержит дефекты - мы не знаем, сколько именно, до тех пор, пока не реализуем и не протестируем программу согласно этой спецификации. Традиционная заработанная стоимость, таким образом, дает ложное ощущение стабильности прогресса. Единственный правильный критерий прогресса в разработке программного обеспечения - это регулярная поставка функционирующего программного обеспечения;
• Показатели без действий: Сбор показателей и отказ от выполнения каких-либо действий при достижении ими пороговых значений приводит к противоположным результатам, поскольку вы несете расходы, но не получаете преимуществ.

Типовые рекомендации

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

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

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

Непрерывный мониторинг проекта

Непрерывный мониторинг проекта означает именно то, что подразумевает его название: вы регулярно отслеживаете состояние проекта в вашей организации посредством автоматизированного сбора показателей, пересмотров проекта и даже устных отзывов. Во многих организациях в любой данный момент времени в работе находятся десятки, а иногда и сотни ИТ-проектов. Каждый проект имеет текущее состояние, которое будет изменяться в течение его жизненного цикла. У вас могут быть проекты в различных регионах и временных зонах; кроме того, в вашей организации может быть несколько процессов разработки ПО. Независимо от этих особенностей, каждый проект должен отслеживаться, если он нуждается в эффективном управлении. Кроме того, необходимо непрерывно осуществлять мониторинг проекта, если вы хотите быстро реагировать на неблагоприятные изменения и появляющиеся возможности.

Для непрерывного мониторинга проектов существует несколько способов, которые можно комбинировать друг с другом:

1. Автоматические измерения. Фиксируются показатели проекта при помощи автоматизированных средств из имеющихся инструментов, которые используются в повседневной работе над проектом. Эти показатели обрабатываются и отображаются с помощью специальной программы для вывода показателей для вычисления состояния каждого проекта в численном выражении;
2. Пересмотры проекта. Пересмотры проекта, в том числе пересмотры контрольных точек - это периодические пересмотры, которые проводятся в конце каждой итерации или в других контрольных точках. Это позволяет убедиться в том, что разработанный функционирующий код удовлетворяет актуальным требованиям заинтересованных лиц, а состояние проекта хорошее. Вместе с тем, необходимо выявить области улучшения и отметить успехи;
3. Анализ причин неудачи. Анализ причин неудачи осуществляется в конце проекта либо потому, что система была успешно введена в эксплуатацию, либо потому, что проект был закрыт. Если проект был успешным, то цель этого действия- проанализировать, было ли достигнуто первоначальное представление проекта, могла ли система продемонстрировать заявленные преимущества, удовлетворены ли заинтересованные лица ходом выполнения проекта. Если проект был признан неудачным, то цель - дать рабочей группе возможность сбросить напряжение и, как мы надеемся, позволить им двигаться дальше и наилучшим образом выявить области усовершенствования, чтобы не повторять ошибок; к сожалению, кажется, что эта цель редко может быть достигнута после того, как проект был провален;
4. Устное общение. Иногда лучший способ определить текущее состояние проекта - послушать, что вам о нем скажут люди. Хотите выяснить, как продвигается работа над проектом? Спросите об этом кого-нибудь из членов рабочей группы. Показатели могут проинформировать вас, что с проектом что-то происходит, но пока вы не поговорите с членами рабочей группы, вы не узнаете, что на самом деле происходит.

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

Преимущества

Непрерывный мониторинг проектов имеет ряд преимуществ:

1. Управление на основе фактов. Осуществляя непрерывный мониторинг проектов, вы можете строить вашу управленческую деятельность, исходя из актуальных, точных фактов. Обычными индикаторами проблем могут быть отклонения от ожидаемых значений или отрицательные тенденции, например, увеличение количества дефектов;
2. Обратная связь на ранних этапах. Непрерывный мониторинг проектов позволяет обнаруживать проблемы на ранних этапах, а это дает возможность принять меры по исправлению ситуации скорее рано, чем поздно. Благодаря этому вы сохраните проекты или, при необходимости, откажетесь от них, прежде, чем вырастут ваши потери;
3. Эффективное управление. Мониторинг правильно выбранных показателей (см. описание метода "Простые и значимые показатели") обуславливает правильное поведение рабочей группы, потому что "вы получаете то, что измеряете" (см. ниже). Непрерывный мониторинг стимулирует правильное поведение в рамках всего проекта, а не только в контрольных точках.

Необходимость изменений

С этой методикой ассоциируются следующие моменты:

• Необходимо правильно выбрать показатели. Вы получите то, что измеряете - это значит, что рабочие группы понимают важность измерений тех моментов, которые вы требуете отслеживать как показатели, и вы можете быть уверены в том, что они сосредоточатся на измеряемых моментах. Значит, вам нужно убедиться в том, что они измеряют то, что нужно. Измерение инвестиций, разработанных функций и динамики дефектов - это на самом деле хорошее начало, потому что можно использовать эти простые показатели для определения эффективности рабочей группы проекта. Более подробно об этом написано в разделе "Простые и значимые показатели";
• Необходимо быть гибким. Значимость показателей и выявляемых с их помощью тенденций будет разной в разных точках жизненного цикла проекта. Например, во время фазы уточнения (Elaboration) проекта процент дефектов может на время вырасти, пока вы исследуете совместную работу различных технологий, зато потом, в фазах конструирования (Construction) и передачи (Transition) можно ожидать, что процент дефектов будет непрерывно снижаться. Если вы понимаете, как показатели изменяются в соответствии с фазой проекта, то вы лучше подготовлены к выявлению реальных аномалий;
• "Предупреждающие знаки" - это только предупреждения. Каждый проект не похож на другие и каждая рабочая группа работает в динамической среде. Некоторые предупреждающие знаки сигнализируют о долгосрочных проблемах, которые придется решать, другие - о кратковременных трудностях, которые не требуют особого внимания. Иногда происходят события, например, изменения политики в сообществе заинтересованных лиц проекта или принятие нового законодательного акта, которые могут создать для рабочей группы временные проблемы;
• Вы должны вкладывать деньги в автоматизацию. В ближайшей перспективе вам придется вкладывать деньги в инструментарий для автоматического сбора интересующих вас показателей;
• Вы, как и раньше, должны разговаривать с людьми. Показатели могут служить только предупреждающими знаками; они не способны точно обозначить тип проблемы (или возможности), с которыми сталкивается рабочая группа и не могут предоставить необходимую информацию, которая могла бы помочь рабочей группе. Чтобы управление проектом было эффективным, вам придется активно сотрудничать с рабочей группой.

Антишаблоны

С мониторингом проекта связаны следующие антишаблоны:

• Управление по показателям. Корректирующие действия предпринимаются для того, чтобы устранить симптомы на основе показателей в отчетах, при этом у руководителя проекта нет понимания основных причин. Предположим, например, что процент дефектов в отчете рабочей группы за одну итерацию вырос до 57%. Это может означать, что у рабочей группы возникли проблемы, а может быть, они только что взяли на работу действительно хорошего тестировщика-исследователя или начали использовать программу для отслеживания дефектов для управления требованиями, а также традиционными отчетами о дефектах (тем самым оптимизируя процесс и повышая общую производительность). Обсудив эту ситуацию с рабочей группой, вы узнаете, следует ли, например, задержать выход версии или продолжить работу в обычном режиме;
• Море показателей. Автоматизированный сбор показателей часто связан со следующей проблемой: вы собираете множество показателей, потому что это просто сделать. Безусловно, у вас под рукой много цифр, но что они на самом деле означают и как их можно использовать с пользой для дела? Небольшое количество значимых показателей, предоставляющих ценную информацию, гораздо важнее, чем десятки показателей непонятного назначения - польза от них только кажущаяся. Вашей целью должно стать качество и еще раз качество.

Типовые рекомендации

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