Несмотря на то, что первым в Манифесте Гибких Методологий (Agile Manifesto) стоит правило "Люди и их взаимодействие гораздо важнее процесса и средств разработки", сами приверженцы таких методологий тратят на разговоры о процессе довольно много времени. К примеру, Экстремальное программирование (XP) описывает почти что исключительно процесс разработки: "Вы следуете процессу? Сначала тестируете, потом пишете код? Играете в планирование? Парами программируете?" и т.д.

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

Как обмануть Железный Треугольник

Когда речь заходит о руководстве проектами, мы постоянно сталкиваемся с пресловутым Железным Треугольником

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

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

И, несмотря на это некоторые из нас все же обнаруживают, что участвуют в проектах, где все три вершины "железного треугольника" уже заданы. Например, нам говорят, что мы должны разработать определенную функциональность за 18 месяцев с бюджетом 15 миллионов. Один из моих друзей постоянно получает задания, типа "у тебя есть четыре человека и три месяца, чтобы разработать вот такую функциональность". И, пусть с небольшими поправками, мы это делаем!

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

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

Вторая часть этого "секрета" состоит в том, что это ни для кого не секрет. Руководители проектов знали и использовали его на протяжении десятилетий. Я не уверен, что этот факт описывали в литературе, но старожилы часто рассказывали мне, как они давным-давно использовали то, что сейчас называется "гибкими методологиями", чтобы выполнить невыполнимый проект в срок.

Как же обмануть Железный Треугольник?

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

Вот три устоявшихся стереотипа, которые я стараюсь изменить:

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

Давайте заменим эти правила на другие:

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

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

Моя статья слишком мала, чтобы описать все стратегические и тактические приемы, которые они используют. К тому же, об этом можно прочесть в нескольких книгах: "Managing the Design Factory", "Skunk Works", "Theory of Constraints", "Lean Software Development", "Agile Software Development", и "Agile Management for Software Engineering.

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

Пусть все люди работают в одном помещении

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

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

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

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

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

"Тихая гавань и сходные стратегии управления проектами"

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

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

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

Тогда, в качестве последнего средства (сроки поджимают), лидера проекта решают на время перевести в комнату в том же здании, но тремя этажами выше. И - о чудо - за оставшиеся дни он успевает доделать все возложенные на него задачи (потому что ему никто не мешает сконцентрироваться на работе). Оставшаяся без "мозгового центра" команда справляется сама, медленнее, но все-таки справляется.

После выпуска продукта лидер проекта возвращается в общую комнату и работает там в прежнем режиме - отвечая на вопросы и разрабатывая свою часть проекта.

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

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

Здесь мы приводим лишь краткий пересказ статьи. Полностью ее можно прочитать на сайте Алистэра Коуберна: ("Cone of Silence and Related Project Management Strategies").

Но, несмотря на эту поправку, общая стратегия работы в одном помещении хорошо зарекомендовала себя как в реальных, так и в исследовательских проектах.

Быстрое документирование плюс обсуждение

Если разработчики активно обсуждают проект в ходе разработки, то документирование можно сделать менее формальным.

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

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

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

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

Наконец, документация должна быть только "приблизительным" описанием. А именно "достаточным для того, чтобы можно было понять, у кого что спрашивать (или где посмотреть это в коде), если возникнут вопросы".

Одновременная разработка

Итак, два приема мы уже усвоили, теперь дело за третьим - одновременной разработкой приложения.

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

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

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

Временные рамки

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

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

Однако есть и разница: в первом случае, требования "замораживаются" до истечения временного промежутка. Соответственно, в этих условиях команда может спокойно заниматься разработкой функциональности. Такой смысл термину "временные рамки" принято придавать в методологии Scrum (Schwaber, 2001). В другом случае, требования могут свободно меняться когда угодно, подразумевая, разумеется, что те, кто вносят изменения, имеют на это весьма веские причины. Именно так понимают этот термин приверженцы "экстремального программирования".

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

Одно из важнейших правил увеличения эффективности проекта, которое касается механизма "временных рамок", гласит:

Лучше урезать запланированную функциональность системы, но уложиться в сроки, чем тянуть (и тянуть, и тянуть) сроки, чтобы успеть завершить разработку функциональности.

На это существует ровно три причины:

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

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

Сколько это может продолжаться?

Мой коллега Джефф Пэттон (Jeff Patton), который сам использует все вышеизложенные правила, согласен с моими гипотетическими вычислениями: благодаря этим стратегическим уловкам можно сразу же сделать работу на 30% эффективнее. И тут же задал вопрос - можно ли повышать эффективность процесса разработок бесконечно, или же это единоразовая отдача?

Сначала мы полагали, что команда может обмануть "железный треугольник" только один раз. Однако, читая о повышении эффективности работ на Тойоте (Ohno, 1988), я пришел к выводу, что они занимались этим много раз на протяжении нескольких десятилетий.

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

Библиография

(Anderson 2003) Anderson, D.J., Agile Management for Software Engineering, Prentice-Hall PTR 2003.

(Cockburn 2002) Cockburn, Agile Software Development, Addison-Wesley, 2002.

(CoS URL) http://alistair.cockburn.us/crystal/articles/cos/coneofsilence.htm

(Ohno 1988) Ohno, T., Toyota Production System: Beyond Large-Scale Production, Productivity Press, 1988.

(Goldratt 1990) Goldratt, E., Theory of Constraints, North River Press, 1990.

(Poppendieck 2003) Poppendieck, M., Poppendieck, T., Lean Software Development:An Agile Toolkit, Addison-Wesley, 2003.

(Reinertsen 1996) Reinertsen, D., Managing the Design Factory, Free Press, 1997.

(Rich 1994) Rich, B., Janos, L., Skunk Works: A Personal Memoir of My Years at Lockheed, Little, Brown and Company, Boston, MA, 1994.Skunk Works

(Schwaber, 2001) Schwaber, K., Beedle, M., Scrum: Agile Software Development, Prentice-Hall, Upper Saddle River, NJ, 2001 (see also www.controlchaos.com).