плач по eXtreme Programming

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

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

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

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

далее: методика XP подходит для заказных проектов. для "коробочных" решений, в частности, очень тяжело привлечь заказчика к ежедневному участию в разработке.

командная разработка (whole team)

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

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

плюсы: заставляет всех разработчиков принимать активное участие в проекте

минусы: заказчик, заказчик, где ты?

planning game

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

теоретически, все хорошо: собрались в начале итерации (в понедельник, естественно), составили список задач и разбежались по рабочим местам. в конце итерации подвели итоги: что сделано, что не сделано. иного по принципам XP не дано. задача не может быть выполнена на 90%. градации всего две: готово и не готово. вопрос в том, что делать с теми задачами, которые не выполнены. опыт говорит, что может иметь место ситуация, когда выполнение некоторых пунктов плана даже не начиналось. мы такие задачи (в терминологии XP -- user story) просто переносим с следующую итерацию. не уверен, что это правильно, потому что впоследствии сложно оценить ошибки планирования. если, конечно, планирование велось электронным способом без архивов. с бумажками проще, наверное.

мы используем для планирования TWiki + XPTrackingPlugin. для небольших проектов -- то, что надо.

плюсы: при правильном подходе помогает определить ошибки планирования

минусы: при невозможности успешно выполнить story требуется другая интерпретация постановки задачи

парное программирование (pair programming)

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

в нашей группе программист разрабатывал детектор нестандартных кодовых ошибок в ИКМ-потоке. практически все было сделано, когда выяснилось, что алгоритм работает не совсем корректно. в режиме одиночного программирования на решение проблемы была запланирована примерно неделя. но этой недели у нас не было, поэтому пришлось искать ошибку в режиме pair programming. результат -- задача была решена менее чем за один день. что мы имеем? пятикратное увеличение скорости разработки, а производительность одного разработчика выросла в два с половиной раза.

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

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

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

плюсы: увеличение скорости и эффективности разработки, повышение квалификации "отстающих" участников

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

смена задач

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

практика показала, что в небольшом коллективе это практически невозможно, или возможно эпизодически, то есть, по мере необходимости. в основном, один человек в течение итерации решает одну задачу и ему совершенно нет дела до других проблем. такова человеческая натура: "я делаю то, что определили в самом начале, не успеваю, и оставьте меня в покое". естественно, это следствие ошибок планирования. кто виноват? конечно же, руководитель проекта.

плюсы: динамичность разработки, отсутствие синдрома "замыливания глаз"

минусы: короткие сроки для решения отдельно взятой задачи одним (или парой) разработчиков

сначала тестирование

как cppunit и junit -- библиотеки автоматизированного тестирования объектно-ориентированных приложений. а что делать с драйверами ядра и программами для встраиваемых систем (код FPGA, например)? писать свои библиотеки тестирования? возможно. но на это требуется много времени и сил.

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

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

плюсы: гарантированно рабочий код

минусы: больше времени на реализацию (теоретически), невозможность толком оттестировать GUI

небольшие релизы (small releases)

по правилам XP предлагается в результате каждой итерации выпустить промежуточную программного продукта (сказать "выпустить релиз" язык не поворачивается, масло маслянное получится).

в России, правда, существует поговорка "дуракам полработы не показывают", и это идет вразрез с правилом "small release". но, так как заказчика на самом деле поблизости нет, то можно выдать версию для внутреннего использования. в этом помогает ежедневная автоматическая сборка всего проекта. было бы неплохо, если бы вместе со сборкой выполнялись тесты для всех компонентов собираемой системы. результат сборки высылается email'ом всем участникам разработки.

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

плюсы: всегда есть что отдать заказчику

минусы: нет. один раз потратить времени на описание принципов выпуска версии и механизмы сборки.

простой дизайн

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

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

плюсы: эффективный, короткий и функциональный код.

минусы: нет

coding standard

стили оформления кода и сопровождающей документации всего проекта должны быть едиными. в этом нам помогает программа indent (для c/c++) и пакет texinfo.

плюсы: очевидны

минусы: некоторые вещи приходится внедрять силовыми методами. например, тем, кто привык к ms word, очень тяжело объяснить достоинства texinfo. хотя, конечно же, инструменты для работы с документацией не являются таким принципиальным вопросом, как единый стиль оформления исходных текстов.

в неделе 40 рабочих часов

да. сорок. не больше. уставший разработчик -- плохой разработчик. авральный режим никогда не даст хорошего конечного результата. продукт, конечно, будет выпущен, но потом нужно будет его дорабатывать на порядок дольше. c'est la vie.

плюсы: рабочий день заканчивается раньше, больше времени для отдыха.

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

метафора

никогда не использовали. может быть, потом, когда-нибудь...

заключение

выводы из вышеизложенного такие: XP -- вещь хорошая, но некоторые ее части иногда (никогда?) нельзя реализовать на практике. руководитель проекта, естественно, сам решает, подходит ему эта методика или нет. а я всего лишь попытался рассказать о личном опыте использования принципов extreme programming в небольших проектах. надеюсь, что кому-нибудь этот текст будет полезен.

с комментариями прошу сюда.

ссылки

1. http://xprogramming.com и http://xprogramming.com/xpmag/whatisxp.htm

-- TonyFeldman - 11 Oct 2006