Когда поспешать лучше без проворства

Методология "быстрой" разработки программных продуктов, agile software development, чрезвычайно популярна в том числе и в России. Делают на неё ставку и многие интеграторы, создавая с нуля либо дорабатывая в соответствии с запросами заказчика специфическое ПО, — ведь этот гибкий подход даёт возможность вводить прикладной продукт в строй поблочно, максимально оперативно откликаясь на корректируемые клиентом в ходе приёмки требования. Увы, как показывает бесстрастная статистика, с agile как стратегией софтверной разработки далеко не всё гладко. Скорость ради скорости За почти уже четверть века активного применения методология agile (этот термин корректнее было бы переводить, наверное, как "проворная", а не "быстрая" разработка, поскольку формируемая ею траектория создания продукта какая угодно, только не прямолинейная), безусловно, доказала свою пригодность для решения самых разных нетривиальных задач. В частности, клиенты из госсектора, как отмечают отечественные разработчики, частенько склонны не планировать всерьёз и надолго, а жить "в ритме джаза", сколь это ни казалось бы парадоксальным, — и потому в отсутствие гибких моделей менеджмента софтверных проектов сотрудничать с ними навряд ли удастся. И всё же проворная разработка — не панацея; более того, в целом ряде случаев бездумно полагаться на неё — значит заведомо навредить проекту. Недавнее исследование, проведённое по заказу шотландской консалтинговой компании Engprax среди 600 инженеров-программистов из США и Великобритании, засвидетельствовало, что проекты, разработка которых ведётся в соответствии с принципами "манифеста agile", имеют ни много ни мало на 268% больше шансов не оказаться доведёнными до конца, чем базирующиеся на более свежей методологии "Impact Engineering" ("ударная разработка"). Претензий к agile у изрядного числа практиковавших эту методику разработчиков накопилось множество, начиная с удручающей неопределённости со сроками завершения проектов, — это беспокоит 81% британских участников исследования и 89% американских. Почти две трети — 65% — проектов, реализованных по методикам проворной разработки, не уложились в намеченные заказчиком сроки и бюджетные рамки одновременно с достижением заданной планки качества. Для ударной разработки этот же показатель, по заявлению Engprax, составляет всего 10%, — правда, справедливости ради следует отметить, что история impact engineering только начинается, и статистически значимой базы на длительных временных интервалах для объективной оценки её успешности пока не набрано. В чём же, по мнению заказавшей исследование компании, недостатки подхода agile? Упомянутый манифест этой методологии содержит четыре ключевых утверждения: люди и взаимодействие важнее процессов и инструментов; работающий продукт важнее исчерпывающей документации; сотрудничество с заказчиком важнее согласования условий контракта; готовность к изменениям важнее следования первоначальному плану. Авторы концепции проворной разработки призывают — не отрицая важности того, что приведено в каждом из этих четырёх пунктов прямым шрифтом, — всё-таки больше ценить выделенное курсивом. Ни в коей мере не ставя под сомнение первое утверждение (о людях и взаимодействии), сторонники ударной разработки отмечают вместе с тем уязвимость трёх оставшихся с точки зрения реальных задач, ставящихся заказчиком перед программными инженерами. И психическое здоровье Так, проведённое исследование показывает, что проекты, перед началом работы над которыми на руках у программистов уже имелась хотя бы общая спецификация финального продукта или хоть как-то задокументированные пожелания клиента в этом плане, на 50% чаще оказывались успешными (доводились до стадии финальной готовности и принимались заказчиком), чем не имевшие мало-мальски формализованного документального подкрепления. Если же клиентские запросы оформлялись перед обращением к программистам детально и чётко — и не менялись затем по ходу процесса, — то показатель успешности для таких проектов и вовсе достигал 97%. В то же время открытость заказчика к прямой и откровенной коммуникации с программными инженерами действительно важна, как показало исследование. Проекты, в ходе реализации которых программисты совершенно свободно могли взаимодействовать с клиентом по любым возникающим в ходе разработки вопросам, быстро отыскивая взаимоприемлемое решение, увенчивались успехом на 87% чаще, чем лишённые каналов открытой и быстрой коммуникации. Ещё одно важное, хотя на первый взгляд и тривиальное извлечение из опроса: если поставленная клиентом задача была призвана решить некую конкретную проблему в его бизнес-практике, то такой проект на 54% имел больше шансов на успешное завершение — чем тот, запрос на который порождался некими общими соображениями заказчика "вот у нас вроде как всё хорошо, — но давайте подумаем, как бы можно было сделать ещё лучше". Выходит, примерно половина проектов, над которыми приходится биться разработчикам, в принципе не могут иметь чётко поставленных целей — раз клиента не ощущает некой определённой боли, которую создаваемое программное решение должно снять. Понятно, что в ситуации подобного расплывчатого целеполагания agile-разработка может вестись по сути бесконечно, вхолостую расходуя усилия, время и бюджеты, — ибо нет предела совершенству. Наконец, проведённый по заказу Engprax опрос выявил отсутствие статистически значимой зависимости между успешностью того или иного реализованного разработчиком проекта — и тем, единственным на данном отрезке времени тот был для разработчика, или же тот вёл несколько подобных проектов разом. Понятно, что заниматься одной какой-то задачей для каждого отдельного специалиста проще, чем переключать внимание между несколькими. Но, судя по всему, если не ставить невыполнимых целей и не доводить сотрудников до физического и ментального истощения, разработчик всё-таки может позволить себе реализовывать более одного важного проекта одновременно. Авторы исследования утверждают, что методология проворной разработки вовсе не идеальный ответ на все вопросы и боли заказчика, — и что для успешного завершения проекта без выхода за временные рамки и выделенный бюджет в большинстве случаев необходимо: четко формулировать намеченные к достижению цели с самого начала, а также
заботиться о психологическом комфорте непосредственно ведущих разработку специалистов. На первый взгляд, пустой трюизм, не стоивший подкрепления специально проведённым исследованием на широкой статистической базе. Однако множество выполненных по критериям agile проектов так и не увенчались успехом именно потому, что этими — самоочевидными исходя из банального здравомыслия — положениями стали огульно пренебрегать. Возможно, impact engineering и вправду окажется более действенным инструментом в приложении к программной разработке на заказ, — и не только в Великобритании и США? Ссылка на источник