« Обзор литературы за 2002-2003 год | | "Организация и именование автоматизированных тестов", Кирилл Максимов »

"Серебряная пуля или горькая пилюля?", Кен Швабер

Кен Швабер

Original article (.pdf file about 90 kb)

За время, которое минуло с того дня, как сторонники гибких методологий составили в местечке Сноуберд свой «Agile Manifesto» (февраль 2001 года), их идеи последовательно прошли через стадии распространения, изучения и развития. Мир узнал о появлении нового, радикального подхода к разработке программного обеспечения. Помимо примечательной статьи в журнале «The Economist»[1], «Манифест» послужил толчком для появления множества книг, статей, конференций, веб-сайтов и, конечно же, не меньшего количества новоявленных авторитетов. Однако, наверное, самым удивительным открытием для сторонников гибких методологий было то, что в других областях – например, в промышленности и строительстве – такая революция произошла двадцатью годами раньше, когда гибкий процесс работы сменил принятый до этого линейный, жестко заданный подход. Видный итальянский экономист Энрико Цанинотто (Enrico Zaninotto[2]), выступавший на конференции ХР2002, заметил, что индустрия производства программного обеспечения пыталась копировать методы, которые давным-давно исчерпали себя в промышленности. Та теория организации промышленного производства, которой последние двадцать лет подражали разработчики ПО, претерпела существенные изменения еще в 70-хх[3]. Жестко заданный, подробно описанный процесс разработки ПО дискредитировал себя в промышленности, которая не замедлила отказаться от него и перешла к «облегченному» процессу производства (lean manufacturing). С точки зрения Энрико, этот процесс во многом напоминает экстремальное программирование и прочие гибкие методологии.

Многие сейчас пытаются разобраться, в чем же заключается эта пресловутая «гибкость». Некоторые ошибочно полагают, что гибкий процесс разработки – это просто более легкая версия традиционных «тяжелых» подходов. Другие попытались разделить гибкий процесс на составляющие, которые можно было бы применять по отдельности. Прочие измеряют гибкость процесса совершенно немыслимыми мерками – например, количеством написанных за день строк кода. Впрочем, есть и такие, которые смогли понять, что гибкие процессы разработки ПО, как швейцарские часы, представляют собой необыкновенно слаженную работу связанных между собой частей. Если вытащить из этих часов ходовую пружину, они попросту остановятся. Более того, эта пружина не может сама по себе показывать время. Некоторые, кроме того, еще и осознали, что гибкие методологии настолько же отличаются от традиционных жестких процессов, насколько «облегченный» процесс производства или синхронное контролирование процесса отличается от почтенной линии сборки Генри Форда. Прискорбная практика использования отдельных составляющих гибких процессов, без понимания и освещения лежащей в их основе теории и взаимосвязанности компонентов, началась, наверное, с маркетинговых заявлений корпорации «Rational»[4]. Если попытаться истолковать суть гибких процессов в терминах СММ, то придется признать, что оба этих подхода дают устойчивые повторяемые процессы вплоть до третьего уровня СММ. На более высоких уровнях разницу в исходных теориях не заметить уже просто невозможно, настолько велики идеологические расхождения. Гибкие процессы (притом, что в них тоже присутствует и жесткость, и строгость) дают команде лишь общую схему, внутри которой разработчики будут создавать свои собственные правила и техники. Более высокие уровни организации процесса разработки, к которым так стремится СММ, приходят сами собой, благодаря внутреннему развитию компании, но не разрабатываются и не навязываются команде извне.

На конференции INCOSE[5] предполагалось провести диспут между сторонниками гибких методологий и СММ. Председательствовал Роберт Томсетт (Robert Thomsett[6]). Впрочем, диспута не получилось. Вместо этого сторонники СММ пожелали своим «гибким» коллегам удачи, ибо сами когда-то изобрели СММ именно с целью улучшить процесс разработки ПО. Вначале они тоже питали большие надежды, и теперь им интересно, как сторонники гибких методологий собираются сохранять свои идеи в первозданной чистоте и незамутненности. Что касается СММ, то им уже случалось видеть, как их идеи бессовестно извращались и использовались всевозможными коммерсантами и дельцами-авантюристами. Кстати сказать, мне тоже уже приходилось видеть немало примеров того, как все те же дельцы и авантюристы пытаются сделать «гибкими» тяжелые методологии путем уменьшения их «веса». Однако уменьшение «веса» методологии отнюдь не подразумевает исчезновения теоретических расхождений, которые существуют между гибкими и не-гибкими процессами. Как метко заметил мой босс, когда мы попытались переставить IBM-овскую многосегментную виртуальную память на более мощный компьютер: «все равно, что поставить свинью на ролики». Один из поборников гибких методологий как-то сказал, что все это уже было предсказано в книге «The Alphabet Versus the Goddess»[7], поскольку любая идея проходит путь от общего образа до формализации, которой занимается левое полушарие головного мозга, иначе говоря, от общей концепции к деталям. Я откомментировал это высказывание на конференции ХР2002[8], сказав, что, по моему мнению, сторонники гибких методологий начинают больше интересоваться количеством ангелов, которые могут танцевать на острие иглы, а не чудом явления одного ангела[9].

Так можно ли сказать, что гибкие методологии – это пресловутая серебряная пуля, универсальное средство и панацея от всех бед? Некоторые вполне согласятся с таким утверждением – те, у кого техника разработки и так была на высоте, и кто использовал гибкие методологии в наиболее критичных для организации проектах. Компании, занимающиеся разработкой программных продуктов, как правило, используют гибкие методологии с большим успехом, потому что гибкий процесс позволяет их продукции успешно конкурировать на рынке. Что касается IT-компаний, то тут все обстоит не столь гладко – сначала полный успех, затем – горькая пилюля: огромное количество изменений, которых требует от компании применение гибких методологий. Такие изменения включают в себя:

  1. Существенное улучшение технологий, связанных со сборкой продукта, а также процессом контроля и управления программным кодом. Без этого просто невозможно создать хороший программный продукт, а при использовании гибких процессов отсутствие подобных практик становится прямо-таки очевидным.
  2. Культурные изменения, вызванные совместной командной работой и вспомогательными средствами (общее помещение для работы, открытость, доступность). Социологические исследования любой такой самостоятельной команды разработчиков необычайно увлекательны, а что касается продуктивности ее работы, то она просто невероятна.
  3. Изменения в руководстве компанией – организация становится изменчивой, нестабильной, команды получают большие полномочия для самостоятельной работы, руководители уже не играют в Больших Боссов, а становятся наставниками, учителями и помощниками.
  4. Изменения в руководстве компанией обусловлены еще одним фактором: четко учитывается прибыль на инвестированный в проект капитал. «Делать правильные вещи хорошо» и просто «делать правильные вещи» - совсем не одно и то же.
  5. Изменяется само понятие «владение», так как бизнесмены несут теперь ответственность за коэффициент окупаемости проекта на основе итеративности и инкрементности разработок, за постоянный баланс стоимости работ, за функциональность, сроки поставки и конечное качество продукта, и имеют возможность извлечь из всего этого максимум пользы.

Нет, я думаю, что гибкие методологии нельзя считать универсальной панацеей. Это всего лишь один из процессов разработки ПО, который требует от людей усердной работы, внимания, увлеченности и командного сотрудничества. Можно ли назвать гибкие процессы горькой пилюлей? Опять-таки, нет, если относиться к ним как к занятиям фитнесом: день за днем вы выкладываетесь на пределе своих возможностей, а потом вдруг замечаете, что чем дальше, тем легче даются все упражнения. Можно провести и литературную параллель: традиционные жесткие процессы – это «1984» Джорджа Оруэлла[10], а гибкие методологии – это «Fountainhead» Эйн Рэнд[11].

На конференции ХР2002 Кент Бек призвал объявить следующий, 2003 год, «годом менеджера», ибо теперь мы продвигаем гибкие методологии в сферу управления IT-организаций, и более того, в сферу взаимоотношений бизнес- и IT-руководства. Разумеется, гибкие методологии могут привести к серьезным изменениям в этих отношениях, а также в работе и обучении менеджмента. Эти изменения станут главным фактором, который обеспечит успех гибких методологий на ближайшие несколько лет.

У той группы, которая съехалась в феврале 2001 года в Сноуберд, не было ни малейшей идеи касательно того, что именно они затевают своим «Манифестом». Они знали только, что они правы, и что гибкие методологии имеют право на существование. Теперь у нас появилась новая организация – AgileAlliance Ее цель – создание общества людей, которые интересуются гибкими методологиями, их практиками, технологиями и культурой. Такое общество должно служить делу распространения идей и новой информации относительно этих методологий. Ведь, как мы видим, гибкие процессы постепенно становятся стандартом для тех проектов разработки ПО, которые ориентированы на самоокупаемость. Первая ежегодная встреча членов AgileAlliance состоялась на ХР/Agile Universe[12]. Многие были удивлены появлением этой организации, и теперь ее создателям приходится изо всех сил стараться не отстать от поезда, который уже покинул станцию и все набирает и набирает темп.


[1] «Agility Counts», статья от 20.09.2001 года (прим. перев.)

[2] Энрико Цанинотто (Enrico Zaninotto) – профессор университета в Тренто, Италия; декан экономического факультета.

[3] См. http://www.xp2002.org/talksinfo/zaninotto.pdf

[4] "You may be able to use the RUP and incorporate selected XP techniques into it". And: "When you combine the breadth of RUP with some of the XP techniques"… - from a 2001 advertisement. ("Вы можете использовать RUP, а в его рамках – отдельные практики ХР". "Используя всю широту RUP с отдельными практиками ХР"… - из рекламы 2001 года.

[5] Май 2002 года. Hampton Roads Area (HRA) Семинар 2002 года по управлению и интеграции разработок программных продуктов, проведенный совместно Hampton Roads Area отделением International Council on Systems Engineering (INCOSE), Virginia's Center for Innovative Technology и Hampton Roads Technology Council.

[6] Известный австралийский консультант, методолог, автор нескольких книг и множества статей. Руководитель консалтинговой компании «The Thomsett company» (прим. перев.)

[7] «The Alphabet Versus the Goddess: The Conflict Between Word and Image», Leonard Shlain , Viking Press, 1998. В книге на богатом культурологическом и историческом материале описываются различия в работе левого и правого полушария человеческого мозга. (прим. перев.)

[8] Конференция XP/Agile Universe, Чикаго, США, август 2002 года.

[9] «Сколько ангелов может поместиться (танцевать) на острие иглы?» – один из примеров вопросов, вокруг которых строились в Средние века схоластические споры. По сути, такие вопросы бессмысленны. Можно сказать, то были дискуссии на максимально отвлеченные, не существующие в реальности темы. (прим. перев.)

[10] Роман-антиутопия Джорджа Оруэлла был впервые напечатан на русском языке в 1989 году в журнале «Новый мир» и потом неоднократно переиздавался. (прим. перев.)

[11] «The Fountainhead», Ayn Rand, Bobbs-Merrill Co, June 1979 (прим. автора). Книга о добре и зле, индивидуальном и коллективном. Американские критики относят это произведение в разряд классических. Впервые книга была напечатана в 1943 году и с тех пор неоднократно переиздавалась. (прим. перев.)

[12] Конференция ХР/AgileUniverse, Чикаго, США, август 2002 года.


kirsa January 24, 2003 6:16 PM

Комментарии

Сделать комментарий




Запомнить меня?