10 июня 2024 г.

Методология «быстрой» разработки программных продуктов, 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 и вправду окажется более действенным инструментом в приложении к программной разработке на заказ, — и не только в Великобритании и США?

Источник: Максим Белоус, IT Channel News