Написано в декабре 2009

Мы являемся свидетелями большой шумихи вокруг гибких процессов разработки (Agile Software Development, [1]). Термин, введённый разработчиками, распространился в мире ПО и за его пределами и используется часто не по назначению. Сегодня все «агильные», а быть «неагильным» просто стыдно. Сам будучи разработчиком пару лет назад, я зачитывался книгами Кента Бека [2] и Мартина Фоулера [3]. Книги замечательные. Эти люди создали очень эффективные методологии разработки ПО. Со смещением моего фокуса в сторону управления проектами, я научился видеть методологии разработки в бизнес-контексте и, в том числе, видеть границы применимости гибких методик. Некоторыми мыслями я хочу поделиться с этой статье.

Начальные условия

Для дальшейших рассуждений важно знать, из каких начальных условий я исхожу. В другой среде могут действовать совсем иные законы.

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

Принципы гибких методологий

Давайте взглянем на некоторые принципы гибкой разработки, сформулированные в агильном манифесте [4, 5]:

Нашим главным приоритетом является удовлетворение заказчика посредством ранней и непрерывной поставки работоспособного программного обеспечения.

Быть может прямо здесь и зарыта собака? Главным приоритетом является удовлетворение заказчика. Звучит логично, но кто этот заказчик?

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

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

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

Это в ВУЗе вас учили решать технические проблемы. Найти решение задачи, используя адекватный алгоритм (типа поиска пути в графе), было само по себе успехом. Лишь проработав несколько лет в области создания ПО,  я осознал, что суть не в том, чтобы решить задачу как таковую, а в том, чтобы решение было в заданных рамках – денежных и временнЫх. А ещё через несколько лет, продолжая расти по служебной лестнице, я понял, что ещё более сложная и важная головоломка – это сформулировать условия проекта (включая задачу, время и деньги) таким образом, чтобы заказчик подписал, а команда смогла решить задачу в этих рамках.

Возвращаемся к гибких процессам. Агильный манифест ценит «Сотрудничество с заказчиком выше, чем переговоры по контрактам». Хорошо. Я тоже. Но мой заказчик не начнёт проект без подписанного договора. А в договоре он (не я!) хочет видеть фиксированную цену. Иногда даже фиксированную дату поставки, но это отдельная история. Цена соответствует определённому объёму работы. Этот объём описан в техническом задании, прилагаемом к договору, с минимальной степенью детализации, необходимой, чтобы заказчик согласился такой документ подписать с одной стороны, и чтобы исключить крупнейшие риски для разработчика – с другой. Инвестировать много времени в детальный анализ невозможно, поскольку на этом этапе всегда есть риск, что договор не будет подписан. Поделить задачу на части и сначала подписать договор лишь на первую – это иногда удаётся, но редкий заказчик на это идёт. Он (справедливо) опасается, что инвестировав приличную сумму и получив половину решения, он получит астрономическую оценку стоимости для другой половины, а пути назад уже не будет. Такое сотрудничество возможно лишь при уже сформированной базе доверия.

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

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

О, да! Я согласен, что процесс, благосклонный к изменениям, очень хорош для заказчика и приносит ему конкурентные преимущества. Но для разработчика настрой «изменения – всегда пожалуйста» приносит лишь головную боль и дополнительные расходы – давайте называть вещи своими именами. Разработчик согласен принимать изменения, если заказчик понимает проблемы, создаваемые этим. И прежде всего готов компенсировать дополнительные расходы, вызванные влиянием  на стоимость и сроки этих изменений.

Изменение в требованиях означает:

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

Все это стоит денег. Немаленьких денег – бОльших, чем видно невооружённым глазом. И, конечно, это отнимает время. Слишком часто заказчик не готов оплатить и даже просто признать эти дополнительные сложности. «Это же просто пара строк кода» или «Мой практикант сказал, что на это надо 15 минут». Сколько раз мне приходилось такое слышать. А когда пустяковое изменение вдруг нарушает работоспособность уже готовых и протестированных модулей? С такой ситуацией заказчик менее всего готов примириться.

Итак, любое изменение задачи должно приводить к пересмотру всего треугольника объём/время/деньги. (Я надеюсь, что уровень качества – это фиксированный параметр, который не страдает от изменений в требованиях.) Если заказчик ожидает гибкости в отношении новых требований, он должен быть готов к гибкости в отношени бюджета и сроков. Если же фиксированная цена в контракте не может быть изменена, то никакие изменения в требованиях не могут быть толерированы. (В реальной разработке требования в подписанном техническом задании никогда не определяют задачу стопроцентно, так что всегда остаётся определённая свобода манёвра для обеих сторон, что, однако, не опровергает описанного выше подхода.)

Поставляйте работоспособное программное обеспечение часто: от раза в несколько недель, до раза в несколько месяцев, отдавая предпочтение коротким интервалам.

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

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

• Тестирование полученного результата итерации
• Частичная приёмка (поставленной части приложения) – это важно с точки зрения гарантий, а также относительно изменений (изменения в принятном куске уже очевидно являются новыми заказами)
• В зависимости от условий контракта – оплата частичной суммы

Если учитывать это, то и разделение проекта на итерации делается вдумчиво, а не просто «начнём с чего-нибудь и сделаем релиз, когда будет в очередной раз достаточно, чтобы что-нибудь показать заказчику». Посмотрите:

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

Это была цитата из книги “Applied Software Project Management” [7], из главы “Iteration abuse” («Злоупотребление итерациями»).

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

В такой форме я бы подписался под этим высказыванием. Вопрос в том, кто такие эти «представители бизнеса» и как выглядит совместная работа.

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

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

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

Наиболее эффективный способ передать информацию в команду проекта (а также передавать её внутри команды) — это непосредственное живое общение.

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

Конечно, необходимо решать проблемы с коммуникацией, порождённые географическим разделением. Так, к примеру, у нас в фирме наряду с электронной почтой важнейшим элементом фирменной культуры является Office Communicator – прежде всего система обмена мгновенными сообщениями в нём. Через него же проходят все телефонные звонки. У каждого сотрудника есть телефонная гарнитура, позволяющая позвонить одним щелчком мыши и бесплатно (через Интернет). Мы используем английский как официальный язык межофисного общения. Во всяком случае, все внутренние документы пишутся по-английски. И мы стараемся поощрять поездки сотрудников между офисами.

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

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

Такое ощущение, что мои заказчики с этим не согласны. (Хотя для разработки продуктов это, скорее всего, подходит.) Они предпочитают фиксированные цены, сроки, заданные на год вперед и возможность спокойно планировать наперёд. После того, как первая версия запущена в эксплуатацию, они ведут себя довольно осторожно. Если они приходят с дополнительными заказами, то они обычно меньшего объёма. И никогда нельзя заранее предсказать, будут ли они вообще и в каком количестве. Даже на договорах поддержки пытаются экономить. Устойчивая разработка (в смысле постоянного темпа разработки в течение длительного срока) их не интересует.

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

Выводы

Есть ли шанс соединить гибкую разработку ПО с жизненными реалиями?

Я думаю, что да. Если вернуться к самому тексту агильного манифеста, мы найдём там четыре простых высказывания:

 «… мы пришли к тому, чтобы ценить:

• Личности и их взаимодействия выше, чем процессы и инструменты.

• Работоспособное программное обеспечение выше, чем обширную документацию.

• Сотрудничество с заказчиком выше, чем переговоры по контрактам.

• Умение реагировать на изменения выше, чем следование плану.»

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

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

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

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

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

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

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

Конечно, мы ценим личности наших сотрудников выше, чем процессы и инструменты. Иначе просто невозможно, особенно в нашем высокотехнологичном секторе. В то же время, мы стандартизуем наши процессы и инструментарий по мере роста компании. От размера компании многое зависит – управление фирмой из 4, 20 или 100 человек всё же разительно различается. Мы собрали наш собственный процесс разработки и развиваем его, постоянно подгоняя под нужды компании. Мы стараемся сделать наш процесс полезным, консультативным и самоадаптивным, а не императивным и ограничительным.

Мы довольно успешны и с интересом ожидаем новых задач. А попадают ли наши процессы под определение «гибких» — в конечном счёте это неважно.

Ссылки

1. Гибкая методология разработки
2. Kent Beck, http://en.wikipedia.org/wiki/Kent_Beck, по-английски
3. Martin Fowler, http://martinfowler.com, по-английски
4. Манифест гибкой разработки ПО (Agile Manifesto, английский оригинал): http://agilemanifesto.org, в частности — принципы гибкой разработки ПО: http://agilemanifesto.org/principles.html
5. Перевод манифеста и принципов на русский язык в статье «Введение в гибкую разработку ПО. Часть 2» (в конце): http://www.kv.by/index2008354201.htm
6. The Agile Manifesto, Martin Fowler and Jim Highsmith, http://www.ddj.com/architect/184414755, 01.08.2001, по-английски
7. Applied Software Project Management, Andrew Stellman и Jenniefer Greene, http://www.stellman-greene.com/aspm/, по-английски

• Software