Исаак Ньютон не смог бы работать в коллективе, использующем методы скорого программирования. Он не любил распространяться о своей работе, редко общался с коллегами и скрывал полученные им результаты из опасения, что их кто-то присвоит. Сотрудничеству Ньютон предпочитал вражду. Особенно не любил он Роберта Хука и Готфрида Лейбница и спорил с ними по поводу приоритета в открытиях, которые считал своими (см. James Gleick, Isaac Newton. — Pantheon, 2003). Причем враждебное отношение Ньютона к Лейбницу не сводилось только к спорам о приоритете в открытии дифференциального исчисления — он буквально был готов убить коллегу-конкурента.

Избранный Ньютоном стиль работы полностью противоположен модели программирования, ориентированной на сотрудничество. Великий физик, безусловно, разрушил бы любую команду, принявшую на вооружение методы скорого программирования (от английского agile — «скорый, гибкий, проворный; быстрый, живой, подвижной, расторопный, шустрый». — Прим. перев.). Несмотря на фантастические способности Ньютона, любой менеджер проекта подумал бы дважды, прежде чем пригласить в группу программистов человека с таким характером.

Фоме Аквинскому тоже не удалось бы добиться успеха в области скорого программирования. Из-за своей молчаливости он получил кличку «тугодум». Один из однокашников Фомы решил, что он не принимает участия в классных дискуссиях, поскольку не понимает материала, и, движимый благими намерениями, предложил с ним позаниматься. Все шло хорошо, пока им не встретился вопрос, на который «педагог» не знал ответа. И каково же было его удивление, когда Аквинский без труда все ему объяснил.

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

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

Все скорые методики основаны на одних и тех же принципах.

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

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

Решение проблем с помощью скорых методов

Психологи разделяют процесс решения проблемы на четыре этапа.

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

Сравнивая этапы решения проблемы с принципами скорых методик, можно обнаружить некоторые нестыковки.

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

Методика скорого программирования ставит во главу угла создание работающего кода. «Отвлекшись» на исследования, специалист перестает создавать такой код. Более того, он мешает писать другим: экстремальное программирование предполагает, что на одной машине работают два программиста, причем занимаясь одним и тем же фрагментом кода. Один из них не может писать код, если другой погружен в исследования. Если для «приобщения к знаниям» специалист прибегает к помощи Internet, то, совершенно очевидно, его коллеге просто негде писать код.

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

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

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

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

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

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

Вещи или люди

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

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

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

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

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

Виктор Сковронски (victor.skowronski@ngc.com) — ведущий инженер компании Northrop Grumman Information Technology.

Определение «компетентности» программиста, следующего скорым методикам

Статья «Эмпирические выводы в скорых методах» (Empirical Findings in Agile Methods/Proc. Extreme Programming and Agile Methods; fc-md.umd.edu/mikli/Lindvall_agile_universe_eworkshop.pdf) посвящена дискуссии о том, каким должен быть хороший программист, придерживающийся скорых методов. В ней говорится: «Для успешной реализации скорого проекта часть группы должны составить опытные специалисты. От четверти до трети группы необходимо формировать из «компетентных и опытных». В данном контексте последнее означает, что программист имеет реальный опыт работы в сфере технологий, принимал участие в создании аналогичных систем и обладает хорошими навыками общения с людьми».

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

Эта цитата свидетельствует и о том, какие трудности могут возникнуть из-за придания в скорых методах особого значения личным контактам.

Victor Skowronski, Do Agile Methods Marginalize Problem Solvers? IEEE Computer, October 2004. IEEE Computer Society, 2004, All rights reserved. Reprinted with permission.