Как совместить подвижность с планом

Сергей Кузнецов
18.09.2003
Открытые системы, #09/2003

Июньский номер журнала Computer [1] — его краткий обзор можно найти в предыдущем выпуске «Открытых систем» — получился действительно тематическим: шесть больших статей посвящены так называемым «быстрым методам» (agile methods) инженерии программного обеспечения.

Его приглашенными редакторами являются Лаури Вильямс (Laurie Williams) и Алистер Кокбурн (Alistair Cockburn). Вводная заметка редакторов озаглавлена «Подвижная разработка программного обеспечения: об обратной связи и изменении» (Agile Software Development: It’s about Feedback and Change). (Мне не раз встречались активные обсуждения вариантов перевода термина agile на русский язык; но, поскольку ни одно из предложений не является идеальным, в этом обзоре я буду использовать простой, хотя и не вполне точный вариант — «подвижный».) В феврале 2001 года состоялась рабочая встреча специалистов в области инженерии программного обеспечения, которых объединяла приверженность к так называемым «легковесным» методологиям разработки. Участники встречи нашли много общего в используемых ими подходах. С этого времени начал использоваться термин «подвижная разработка программ». Был выпущен документ, названный авторами «Манифестом подвижной разработки программ» (Manifesto for Agile Software Development — www.agilemanifesto.org), в котором зафиксированы четыре основных принципа данного подхода:

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

Первый большой материал, озаглавленный «Подвижность благодаря дисциплине: дискуссия» (Agility through Discipline: A Debate), действительно содержит полемику Кента Бека (Kent Beck) и Барри Боэма (Barry Boehm). Бек приводит шесть определений термина «дисциплина», и, по его мнению, только одно из определений, а именно «управление на основе принуждения или приказов» не соответствует принципам организации подвижной программной группы. Боэм замечает, что рассуждения Бека применимы к группам численностью до 10 человек. В то же время, 83% программного обеспечения делается в гораздо более многочисленных группах. Для успешной работы таких групп требуется соблюдение дисциплины во всех имеющихся толкованиях этого термина, включая и тот, который неприятен для Бека.

Статья Крейга Лармана (Craig Larman) и Виктора Базили (Victor Basili) — «Итерационная и инкрементальная разработка: краткая история» (Iterative and Incremental Development: A Brief History). Авторы видят истоки подхода к итерационной и инкрементальной разработке (Iterative and Incremental Development, IID) в работах эксперта по качеству продукции компании Bell Labs Вальтера Шеварта, который в 30-е годы предложил совершенствовать качество за счет применения коротких циклов plan-do-study-act (PDSA). По отношению к разработке программного обеспечения подход IDD был впервые применен в начале 60-х в проекте NASA Project Mercury. В начале 70-х годов подход IDD начали применять в подразделении IBM Federal Systems Division. Командная и управляющая система для подводной лодки Trident (более миллиона строк кода) была сделана за четыре полугодовых итерации. В то же время проект на основе IDD выполнялся в компании TRW, разрабатывавшей систему противоракетной обороны. Проект был выполнен в течение нескольких лет за пять итераций разной временной протяженности. В 1987 году компания TRW начала четырехлетний проект по созданию нового командного и управляющего центра. Этот проект согласовывался с методологией, которую позже стали называть RUP (Rational Unified Process). Подход был официально признан Министерством обороны США. Широкое распространение получила и методология RUP. В статье приводится обширная библиография по тематике IDD.

Следующая статья, написанная Барри Боэмом и Ричардом Тернером (Richard Turner), носит название «Применение риска для балансировки подвижных и плановых методов» (Using Risk to Balance Agile and Plan-Driven Methods). Методологии, подобные экстремальному программированию (XP) и подвижной разработке программ, обещают обеспечить более полное удовлетворение потребностей заказчиков, уменьшение числа дефектов программного обеспечения, сокращение времени разработки и быструю реакцию на изменение требований. Плановые подходы, такие как Personal Software Process и методы, основанные на CMM, ориентированы на предсказуемость, стабильность и гарантирование качества. Однако оба подхода в определенных ситуациях могут приводить к неудаче и, в конечном счете, к провалу проекта. По мнению авторов, выход состоит в сбалансированном использовании обоих подходов с тем, чтобы в каждой ситуации использовать преимущества одного подхода и компенсировать недостатки другого. В статье представлен комбинированный подход к структуризации проекта, основанный на анализе риска. Полностью данный подход описан в книге двух этих авторов — Balancing Agility and Discipline: A Guide for the Perplexed (она выйдет в 2003 году в издательстве Addison-Wesley).

Статья «Разработка сложных проектов с использованием XP с расширениями» (Developing Complex Projects Using XP with Extensions) написана большой группой авторов из немецкой компании IT Workplace Solutions (www.it-wps.com). Первым в списке авторов обозначен Мартин Липперт (Martin Lippert). Экстремальное программирование — дисциплинарный подход, направленный на удовлетворение требований заказчиков и поддержку групповой работы. Однако ИТ-менеджеры часто оценивают эту методологию как несколько хаотичную; многие считают ее опасной и непредсказуемой, поскольку, по их мнению, в ней отвергаются принципы планирования и управления при выполнении масштабных долговременных проектов. Опыт авторов опровергает это представление. При правильном использовании XP проектов со сложными прикладными областями или ограниченными ресурсами методология обеспечивает высокий уровень безопасности и надежности с сохранением преимуществ подвижной разработки программного обеспечения. В компании IT Workplace Solutions развиваются методологические расширения XP, используемые в итеративном процессе разработки, в котором основное внимание уделяется на постоянную обратную связь с заказчиками, тщательную подготовку проекта и создание новых ролей для участников проекта. Приводится список крупных проектов, выполненных на основе расширенного подхода XP.

Майк Кон (Mike Cohn) и Дорис Форд (Doris Ford) представили статью «Внедрение в подвижный процесс в организации» (Introducing an Agile Process to an Organization). Подвижные процессы допускают наличие изменений требований заказчиков в цикле разработки и опираются на сотрудничество между разработчиками и заказчиками с целью сокращения времени выполнения проекта. В соответствии с «Манифестом подвижной разработки программ» в подвижном процессе на первое место выходят личности, а не формальные документы. К наиболее значимым подходам к организации подвижных процессов авторы относят XP, Lean Development, Crystal и Scrum. В последние четыре года авторы внедрили Strum в семи организациях в Соединенных Штатах. Некоторые проекты, оказавшиеся весьма сложными, выполнялись распределенными группами. В статье обсуждается полученный опыт и исследуется несколько подходов к успешному внедрению подвижного процесса в организацию. В частности, отмечается принцип Барри Боэма, считающийся центральным в подвижном подходе: «Команда должна состоять из небольшого числа очень талантливых людей». Кто бы спорил...

У последней статьи тематической подборки четыре автора из Университета Брунела (Великобритания) — Марк Лисетт (Mark Lycett), Роберт Макреди (Robert Macredie), Чайтали Пател (Chaitali Patel) и Рэй Пол (Ray Paul). Статья называется «Миграция подвижных методов в стандартизованную практику разработки» (Migrating Agile Methods to Standardized Development Practice). Для современных организаций свойственно постоянное изменение бизнес-процессов. Однако и в этой изменяющейся обстановке от организаций требуется поддержка качества продуктов, услуг и процессов, чтобы сохранить влияние на рынке и конкурентоспособность. Для компаний источником напряжения является потеря стабильности, на которой основано управление качеством. В области разработки программного обеспечения утрата стабильности может быть в большой степени связана с различиями между стандартизированными инженерными подходами и более современными подвижными методами. Авторами разработана основа подхода, при котором подвижные методы могут использоваться образом, согласованным со стандартными процессами CMM и RUP.

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

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

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

Литература

1. IEEE Computer, v. 36, no. 6, June 2003.