Декларация независимости в проектном управлении

ОБЗОРЫ

В январе 2005 г. собравшиеся в Сиэтле известные специалисты по программной инженерии сформулировали Декларацию независимости пользователей гибких (agile) методологий (www.pmdeclarationofinterdependence.org), развивающую идеи agile-манифеста, провозглашенного в 2001 г. Они задумали создать собственную альтернативу классическим подходам, пропагандируемым крупными институтами по проектному управлению (PMI.org и др.), и предложили шесть ключевых принципов, которыми рекомендуется руководствоваться в своей деятельности каждому менеджеру гибких проектов, разделяющему agile-концепции:

1) заказчик должен получать непрерывную отдачу от своих инвестиций в разработку;

2) обе стороны проекта (заказчик и исполнитель) руководствуются достоверными результатами о состоянии работ, постоянно взаимодействуя друг с другом и совместно владея всем программным "имуществом" (моделями, кодом, релизами, документацией);

3) степень неопределенности в проекте снижается за счет коротких проектных итераций, упреждения рисков и быстрой адаптации требований;

4) ключевым в работе программистов считается творческий потенциал и новаторство - рядовые исполнители являются главным ресурсом, а менеджеры лишь стараются создать такое окружение, в котором разработчики смогут проявить максимальную эффективность;

5) рост производительности достигается благодаря постоянной отчетности всех членов команды и коллективной ответственности за результат;

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

Нынешнее состояние и проблемы гибких методологий управления программными проектами обсуждались на ежегодной конференции Agile Project Management 2005 (www.agile2005.org), которая прошла летом 2005 г. в Денвере (шт. Колорадо, США). Абсолютное большинство более чем сотни выступлений было посвящено экстремальному программированию (XP, www.xprogramming.com, www.xprogramming.ru), методике SCRUM (www.controlchaos.com), которая популярна на Западе практически так же, как и XP, а вот в России неизвестна, а также семейству подходов Crystal (alistair.cockburn.us/crystal/crystal.html) и их различным вариациям. В этом году тематика выступлений была расширена докладами, посвященными вопросам тестирования ПО: ведь практически все современные гибкие подходы ориентированы на управление требованиями преимущественно на базе тестов, выдвигаемых пользователем. По этой причине agile-подходы хороши в условиях, когда требования заказчика постоянно изменяются и классические модели разработки наподобие спиральной или "водопада" неэффективны, а вот гибкие подходы динамически подстраиваются под нужды клиента.

На сложности поиска хороших тестировщиков сетовал Анко Тийман (Ordina, www.ordina.nl). Эти люди ни в коем случае не должны мыслить как разработчики - их задача не решать проблемы, а наоборот, создавать их, ничего не принимая на веру. Солидарен с коллегой и Макс Бауманн (Industrial Logic, www.industriallogic.com). По его мнению, типичная проектная проблема заключается в том, что тестировщикам не всегда удается точно перевести пожелания заказчика в формальные правила испытаний, и нередко ряд важных возможностей продукта не контролируется. Неплохой выход - использовать методики типа Storytest-Driven Development (www.industriallogic.com/catalogs/activities/ 000017.html), когда совместно с заказчиком для каждого требования одновременно вырабатывается и схема тестирования, после прохождения которого требование считается автоматически выполненным.

 Джим Хайсмит из консорциума Cutter (www.cutter.com) провел аналогию между программной инженерией и материаловедением. При использовании средств компьютерного анализа и моделирования новые материалы создаются в 100 раз быстрее и обходятся в 100 раз дешевле, нежели при использовании традиционных подходов, выработанных десятки лет назад. Аналогичный эффект достигается и при использовании гибких методологий в проектах, где необходимо осваивать новые технологии, продукт надо выпустить быстро и с высоким качеством, а требования заказчика могут постоянно меняться. Особую пользу приносят средства коллективной работы нового поколения, ориентированные не на цикл "планирование - исполнение", а на последовательные шаги "предусмотреть нужные действия - исследовать вопрос". Они поддерживают следующие типичные функции:

- определение и отслеживание всех сущностей, имеющих отношение к продукту (влияющих на результат);

- быстрый старт проектных работ;

- изучение требований с постепенной детализацией, итеративное планирование;

- частый выпуск работоспособных релизов продукта на базе запрограммированных и протестированных на данный момент функций;

- постоянная отчетность и обратная связь с заказчиком;

- интенсивное общение всех участников проекта;

- периодический просмотр и анализ достигнутых результатов.

Пауль Ходжеттс (Agile Logic, www.agilelogic.com) выделил три ключевые составляющие agile-методик: набор функций (backlog) создаваемого продукта, упорядоченных по приоритетам важности; требования заказчика к системе, представленные не слишком формально (stories); план выпуска релизов. Вопросы управления требованиями, безусловно, остаются актуальными и ключевыми для успеха проекта при использовании как гибких, так и классических методологий. Разница же между ними в том, что в последних подходах основной акцент делается на прямом управлении разработкой ПО, а в agile главными становятся бизнес-цели: управление ролями исполнителей, процессом формирования продукта на базе создаваемой им ценности для заказчика и механизмами взаимодействия с пользователем. Тут важно отметить, что внедрение гибкой модели отнюдь не проще "жесткой": agile-приемы эффективнее, но нередко и сложнее, особенно при использовании в организациях с выстроенной вертикальной структурой. Практика показывает, что если в компании уже имеется богатый, но не очень упорядоченный опыт разработки ПО, то переход к гибким методикам удастся успешно реализовать, как правило, эволюционным путем.

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

Важность непрерывной связи с заказчиком, необходимость объединения всех мало-мальски связанных с проектом людей в тесное сообщество упоминались практически в каждом выступлении. Так, четыре ключевых аспекта проектного сообщества обозначил Гил Броза (Industrial Logic):

- взаимообязательства (commitment): данные о текущем состоянии проекта вывешены на видном месте и доступны любому участнику; разработка ведется совместно с представителями заказчика и будущими пользователями, сидящими в одной комнате с программистами;

- взаимодействие (communication): все общение ориентировано на задачи проекта и происходит формально, без излишних эмоций и всегда в рамках единого рабочего пространства проекта, физически и виртуально объединяющего всех участников;

- итеративный процесс (process): на каждую проектную итерацию отводится небольшой срок, и чем сложнее платформа разработки (например, Си++), тем он должен быть короче (обычно не более недели);

- командная разработка (team development): каждый программист может кодировать любую часть кода.

Нюансы командной разработки уточнил Арло Белши (Critical Path Software, www.criticalpath.com). Он исследовал оптимальное время переключения между различными задачами проекта, предлагая разработчикам заниматься только одной задачей на протяжении от 30 мин до недели, и оказалось, что оптимальным временем работы над конкретным требованием можно считать 1,5 ч, после чего лучше перейти к другой задаче.

Стив Адольф (WSA Consulting, www.wsaconsulting.com) отметил в своем выступлении, что полезность гибкости и скорости для успеха практически любой деятельности давно доказана 2500-летней практикой ведения военных действий и выработанными на ее основе общеизвестными законами. Он провел аналогию между agile-концепциями и исследованиями прусского офицера Карла фон Клаузевица, теоретика немецкой военной стратегии и тактики XX века, сформулированными в его книге "О войне" ("на войне все очень просто - но именно простые вещи трудны"), и адаптировал к программной инженерии четыре принципа гармоничной деятельности:

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

- постоянная тренировка, причем не в искусственных условиях, а в повседневной деятельности на рабочем месте;

- лидерство - agile-лидер напоминает не столько классического менеджера, сколько спортивного тренера, который способен вдохновлять на рекорды и настойчивое достижение цели;

- стремление к истине, которая заключается в создании продукта с полезным и ясным предназначением.