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

В компании Landmark Graphics мы использовали разные методы и процессы разработки ПО и за последние несколько лет начали лучше понимать некоторые из руководящих принципов, определяющих «почти достаточность». Обратившись к истории наших проектов, мы обнаружили, что на процесс разработки наиболее серьезно влияют два фактора — сложность проекта и его неопределенность. Для более точного количественного определения этих факторов мы разработали модель их оценки и нанесли результаты по каждому проекту на диаграмму с четырьмя секторами. По аналогии с Бостонской матрицей, предложенной консалтинговой компанией Boston Consulting Group, мы дали этим секторам следующие названия:

  • «собаки» — простые проекты с низкой неопределенностью;
  • «жеребята» — простые проекты с высокой неопределенностью;
  • «коровы» — сложные проекты с низкой неопределенностью;
  • «быки» — сложные проекты с высокой неопределенностью.

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

Искать сочетание гибкой и плановой методик разработки ПО мы начали с исследования методов Crystal, предложенных Алистером Коберном [1], и подхода Барри Боэма на основе оценки риска. В методах Crystal нам понравилась классификация проектов по размерам и важности, но мы понимали, что на методику их выполнения влияют и другие показатели. Тогда мы составили список критически важных показателей, которые повлияли на выбор методик в наших успешных проектах. Затем мы перешли к обобщениям и выявили два первичных фактора — сложность и неопределенность. Исходя из них, мы выпустили краткий отчет , который проектные группы могут использовать для оценки своих проектов.

В то время Барри Боэм и Ричард Тернер еще не опубликовали свою работу о соотношении гибкости и дисциплины [3]. В ней проекты классифицируются на основе пяти признаков: размер, важность, динамизм, компетентность персонала и организационная культура. Наш подход одновременно расширяет и упрощает их принципы. В своей оценке мы используем больше показателей, но затем сводим их к двум критериям — сложности и неопределенности.

Факторы сложности

Сложность проекта определяется его структурой. Мы разработали систему оценки сложности проекта (табл. 1).

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

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

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

Зрелость группы. Сложившееся ядро экспертов, в течение многих лет совместно работающих над совершенствованием продуктовой линейки, может заранее предугадать трудности, с которыми столкнутся другие члены группы. Этим они отличаются от совершенно новой группы, состоящей из сравнительно неопытных специалистов. Во многих отношениях данный показатель подобен предложенному Коберном критерию способности персонала к обучению и творчеству по принципу Сю-Ха-Ри, которым пользуются также Боэм и Тернер [3].

Знание предметной области. Продукты Landmark Graphics строятся с учетом передовых технологий разведки и добычи нефти и газа. Очень важен постоянный контакт разработчиков со специалистами предметной области, помогающий устранить все неясности и выпустить нужный продукт. Мы выяснили, что процесс разработки сильно упрощается, если разработчики сами являются такими специалистами, и существенно усложняется, если к сведениям из предметной области имеется ограниченный доступ.

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

Факторы неопределенности

Неопределенность проекта зависит от рыночных условий и проектных ограничений. Основные показатели неопределенности проекта (табл. 2).

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

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

Длительность проекта. Чем больше времени пройдет от начала реализации проекта до выпуска продукта, тем вероятнее, что проект пострадает от технической или рыночной неопределенности.

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

Распределение по категориям

Рис. 1. Соотношение между сложностью и неопределенностью в проектах трех подразделений. Подразделения представлены маркерами разной формы

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

«Собаки»: простые проекты с низкой неопределенностью

«Собаки» — обычно зрелые продукты, разрабатываемые малыми группами. В таких проектах, не являющихся особо сложными или неопределенными, лучше всего позволить группе разработчиков свободно заниматься их деятельностью. Часть проектов имеют некоторую неопределенность, но можно сократить их продолжительность и ограничить таким образом ее влияние. В этот сектор часто попадают разработка опытных образцов и научно-исследовательские проекты — «скунсы» (Skunk Works, то есть «скунсовая фабрика», — ставшее именем нарицательным неофициальное название одного из научно-производственных подразделений аэрокосмической корпорации «Локхид Мартин». — Прим. пер.). Для «собак» и «скунсов» дополнительные организационные меры и документация неэффективны и не нужны, так что мы управляем ими, задействуя лишь минимальный набор основных методов, которые мы используем для всех проектов во всех секторах. Такой подход напоминает методы Crystal Clear, предложенные Коберном [6]. Приблизительно 60% наших проектов попадают в сектор «собак».

«Жеребята»: простые проекты с высокой неопределенностью

Для новых продуктов характерны рыночная и техническая неопределенность. Малые проектные группы могут быстрее реагировать на изменения обстановки и справляться с неопределенностью. Метафора «жеребенок» довольно метко описывает такие проекты. Они находятся в самом начале своего пути, полны энергии и чувства свободы. Большинство наших проектов, связанных с экстремальным программированием [8], попадают в этот сектор. Мы обнаружили, что для него весьма эффективны ежедневные экспресс-совещания, подобные пропагандируемым в процессе Scrum [9]. Примерно 20% наших проектов относятся к категории «жеребят».

«Коровы»: сложные проекты с низкой неопределенностью

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

Проекты в этом секторе могут оставаться гибкими, но нуждаются в определении и публикации интерфейсов к зависящим от них проектам. Они также требуют более непосредственного управления, в том числе рассмотрения таких проблем, как взаимосвязи между группами и критические пути. Значительная часть наших «коров» — интеграционные проекты, связанные с множеством других проектов, обычно «собак». Для управления многими из этих проектов мы использовали группу руководителей групп, нечто подобное методике Scrum of Scrums [7]. «Коровы» составляют приблизительно 10% наших проектов.

«Быки»: сложные проекты с высокой неопределенностью

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

Основные составляющие процесса разработки

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

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

Список приоритетов. Каждой функции мы назначаем один из трех уровней приоритета: функции с приоритетом A необходимы в выпускаемом продукте, функции с приоритетом В желательны, а функции с приоритетом С могут быть включены в него, если позволит время. Проектная группа оценивает трудозатраты с учетом прогноза потребительной стоимости, сделанного менеджером продукта, и старается максимизировать возврат инвестиций. Клиентов мы знакомим только с функциями, имеющими приоритет A. Поскольку мы обязуемся реализовать все функции с приоритетом A, мы учитываем неопределенность и планируем график так, чтобы на их реализацию уходило не более 50% общего объема трудозатрат. Закончив реализацию таких функций, мы используем остаток выделенного на проект времени, чтобы реализовать функции с приоритетом В, а потом С. Работая над проектом, мы часто изменяем список приоритетов, особенно при итерациях, но без согласования с клиентом не удаляем функции с приоритетом A. Этот подход и его применение для максимизации потребительной стоимости описаны в статье [8].

Соглашение о качестве. Группа работает с менеджером продукта, чтобы достичь уровня качества, запланированного для данного выпуска. Мы модифицировали предложенный Робом Томсеттом [9] подход к соглашению о качестве, чтобы использовать приоритеты A/B/C. Нам кажется, это придает последовательность нашим дискуссиям и обеспечивает несколько большую степень детализации, чем релейный подход Томсетта.

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

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

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

Дополнительные рабочие процедуры

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

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

«Жеребята». Эти проекты, характеризующиеся высокой неопределенностью, выигрывают от применения трех дополнительных методов. С неопределенностью помогают справляться короткие итерации, ежедневные экспресс-совещания и автоматизированное тестирование модулей.

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

«Быки». Этими проектами весьма трудно управлять. Они могут быть большими и сложными, требовать дополнительных усилий для борьбы с неопределенностью. Для их успешного выполнения нужны те же методики, которые используются в проектах-«коровах», плюс гибкое регулирование, применяемое в проектах-«жеребятах». Итерации должны быть короче, чем в проектах-«коровах», но длиннее, чем в «жеребятах», а каналы коммуникаций — более эффективными. И что самое важное, необходимы наилучшие, опытнейшие менеджеры проекта, которые разбираются в гибких методологиях и способны преодолеть сложность путем сбалансированного разделения целого на части. Чаще всего в организациях очень мало таких менеджеров. Мы считаем неразумным инициировать большее количество «быков», чем число имеющихся в компании опытных менеджеров проектов. Подробнее о трудностях управления подобными проектами можно узнать из отчета Марджори Фармер [10].

Корректировка проекта. При оценке категории проекта может выясниться, что он является более сложным или неопределенным, чем казалось прежде. Иногда можно скорректировать проект, уменьшив его сложность или неопределенность. В частности, мы убедились в том, что снизить сложность большого проекта позволяет его разбиение на подпроекты.

Жизненный цикл продукта

Продукты в нашем портфеле на протяжении своего жизненного цикла имеют тенденцию к перемещению из сектора в сектор (рис. 3) — подобно тому, как это происходит в Бостонской матрице. Наиболее успешные продукты движутся по траектории 1. Они постепенно превращаются из «скунсов» с низкой сложностью и умеренной неопределенностью в «жеребят», а затем достигают успеха и становятся «быками» с высокой степенью сложности и неопределенности. Через какое-то время сложность снижается, и продукт становится «коровой», а потом — «собакой». Значительная часть продуктов, не испытывающих особой необходимости в усложнении, движется по траектории 2. В этом нет ничего плохого, поскольку большинство из них в результате становятся выгодными. Наши попытки запустить продукт по траектории 3 непосредственно из сектора «быков» неизменно заканчивались неудачей. Успеха достигали лишь те проекты-«быки», которые начинались в секторе «жеребят» или «собак».

Один из индикаторов успеха — показатель качества оценки (Estimation Quality Factor, EQF) [11], который отражает точность оценки проекта и, по существу, является обратным значением ошибки оценки. Так, EQF 5,0 соответствует совокупной ошибке оценки 20%. Как видно из рис. 4, после введения нового подхода наш средний показатель EQF (который с самого начала был существенно выше среднего по отрасли EQF 3,8, приведенного Томом Демарко [11]), устойчиво повышался с 4,8 до 8,4.

Рис. 4. Повышение среднего качества оценки в нашей компании

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

ЛИТЕРАТУРА
  1. Алистер Коберн. Быстрая разработка программного обеспечения. — М.: ЛОРИ, 2002.
  2. J. Highsmith. Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. — Dorset House. — 2000.
  3. B. Boehm and R. Turner. Balancing Agility and Discipline: A Guide for the Perplexed. — Addison-Wesley. — 2003.
  4. C.E. Shannon. A Mathematical Theory of Communication // Bell System Tech. ]. — Vol. 27. — July and Oct. 1948. — Pp. 379-423, 623-656.
  5. A. Cockburn. Crystal Clear. — Addison-Wesley, 2004.
  6. Кент Бек. Экстремальное программирование, СПб.: Питер. — 2002.
  7. K. Schwaber and M. Beedle. Agile Software Development with SCRUM // Prentice Hall, 2001.
  8. T. Little. Value Creation and Capture: A Model of the Software Development Process // IEEE Software. — Vol. 21, no. 3, 2004. — Pp. 48-53.
  9. R. Thomsett. Radical Project Management // Prentice Hall. — 2002.
  10. M. Farmer. DecisionSpace Infrastructure: Agile Development in a Large, Distributed Team // Proc. 2004 Agile Development Conf.. — IEEE Press, 2004. — Pp. 95-99.
  11. T. DeMarco. Controlling Software Projects // Prentice Hall. — 1982.

Тодд Литтл (tlittle@lgc.com) — старший менеджер по новым разработкам компании Landmark Graphics.

Бостонская матрица

Бостонская матрица, предложенная консалтинговой компанией Boston Consulting Group, стала общепринятым инструментом управления портфелем продуктов. Продукты наносятся на диаграмму в соответствии с ростом рынка и рыночной долей.

Бостонская матрица (рисунок предоставлен компанией Boston Consulting Group)

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

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

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

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

Todd Little. Context-Adaptive Agility: Managing Complexity and Uncertain, IEEE Software, May/June 2005. IEEE Computer Society, 2005, All rights reserved. Reprinted with permission.