Большинство практик экстремального программирования (Extreme Programming, XP) известны давно, но в XP были объединены лучшие подходы, которые в случае комплексного применения позволяют трансформировать количественные улучшения в принципиально новое качество разработки программных продуктов. Экстремальное программирование имеет некоторую аналогию с медициной — многие способы лечения были найдены экспериментально, и зачастую, не имея теоретических и научных обоснований, они тем не менее прекрасно работают.

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

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

Практики XP

Парное программирование

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

Код, написанный в паре, более надежен. Представим, что один разработчик делает в среднем одну ошибку на 100 строк кода, а второй разработчик пишет код примерно с таким же качеством. Если их ошибки не пересекаются, то теоретически, работая вместе, они будут делать одну ошибку на 100 * 100 = 10 000 строк кода. Конечно, на практике улучшение кода не будет таким значительным, но в любом случае код, написанный парой, будет заметно надежнее.

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

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

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

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

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

Парное программирование позволяет быстро и точно оценить квалификацию людей. Если новый программист работает над достаточно изолированными задачами на классическом проекте, то иногда требуется несколько месяцев, чтобы объективно оценить его уровень. На XP-проекте опытный разработчик может уже через пару дней совместной работы оценить способности напарника, что позволяет использовать сильные стороны новичка наиболее оптимальным образом.

Пары в XP-проекте обычно не фиксированы — разработчики сами решают, как разбиться на пары исходя из опыта работы, знания разрабатываемой функциональности и личных предпочтений. Ротация в парах приветствуется, но разумно, чтобы отдельная задача целиком делалась одной парой. Совсем не обязательно целый день работать в паре, что пугает многих разработчиков. Некоторые виды работ можно делать независимо: изучение документации, исследование новых технологий, исправление несложных ошибок или реализация простой функциональности. Если разработчики проводят в паре около 70% времени, этого обычно вполне достаточно.

Модульное тестирование

Разработка в XP базируется на модульном тестировании (unit testing), которое направляет и ведет за собой все остальные фазы в написании кода. Модульные тесты постоянно автоматически тестируют большинство архитектурных уровней приложения за исключением, как правило, GUI уровня, который обычно проверяется тестерами вручную или с использованием автоматизированных скриптов. Самой первой мыслью разработчика при написании новой функциональности должна быть мысль об определении оптимального набора модульных тестов, которые будут эту функциональность тестировать. Из определения тестов рождается интерфейс функциональности — первоначальная реализация функциональности отсутствует, и, соответственно, модульные тесты вначале покажут ошибки, а программисту остается всего лишь написать реализацию функциональности таким образом, чтобы все тесты прошли успешно. При классическом подходе разработчик сразу начинает кодирование, откладывая тестирование «на потом», которое часто никогда не наступает.

Разумная пропорция времени, потраченного разработчиком на модульное тестирование, определяется опытом и здравым смыслом программиста, а также спецификой задачи. На самом деле модульные тесты могут быть достаточно сложными. Например, модульный тест может создавать необходимые тестовые данные в базе данных, тестировать функциональность, а затем удалять данные для теста. Написание хороших модульных тестов, покрывающих максимальный объем функциональности с минимальными усилиями, — искусство. В среднем примерно 20% от времени кодирования уходит на модульное тестирование.

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

Существуют многочисленные программные средства, технически поддерживающие модульное тестирование, такие как, например, NUnit.

Общее владение кодом

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

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

Ничего заранее

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

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

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

Простые решения

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

Постоянное улучшение кода

Представим, что программисты в проекте строго следуют двум предыдущим правилам XP: ‘Ничего заранее’ и ‘Простые решения’. Это замечательно, и в конце проекта код будет действительно очень простым и не содержащим ничего лишнего. Но с другой стороны, код получится огромным, с многочисленными дублированиями, а также полным отсутствием универсальных решений и базовых классов, которые иногда действительно необходимы и полезны. Чтобы избежать такой ситуации, и существует правило ‘Постоянное улучшение кода’.

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

Должен поддерживаться постоянный баланс между правилами ‘Ничего заранее’, ‘Простые решения’ и ‘Постоянное улучшение кода’, который определяется профессионализмом и здравым смыслом разработчиков.

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

Коммуникация внутри команды и с заказчиком

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

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

Ежедневные телеконференции с заказчиком чрезвычайно полезны для офшорных XP-проектов. Их организация, естественно, требует некоторой дополнительной технической поддержки и времени, но голосовое общение, безусловно, эффективнее коммуникации посредством e-mail. Дополнительное использование программ, поддерживающих демонстрацию через Internet, также очень продуктивно, причем в телеконференциях со стороны разработчиков лучше участвовать лишь менеджеру проекта. Конечно, иногда присутствие ведущего разработчика или тестера на телеконференции имеет смысл при обсуждении сложных технических деталей, но это все-таки должно быть исключением.

В целом, акцент на человеческое общение в XP-проектах вместо технических спецификаций делает процесс разработки программного обеспечения более плодотворным.

Быстрота реакции и гибкость вместо планирования

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

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

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

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

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

Постоянная интеграция

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

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

Все или ничего

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

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

XP как игра

Можно легко заметить, что XP напоминает игру, и даже такие термины, как ‘Игра в планирование’ или ‘Пользовательские истории’ намекают на такое сравнение. Мы развешиваем истории на стенах, видим зеленые и красные лампочки в программе NUnit в процессе модульного тестирования и так далее. Таким образом, XP формирует дружескую, ориентированную на людей, неформальную и творческую атмосферу, которая делает процесс разработки программного обеспечения более приятным и эффективным. Самый простой способ научиться новой игре — это принять в ней участие.

Игра в планирование

«Игра в планирование» (Planning Game) является очень важной практикой XP и позволяет быстро и точно оценить трудозатраты, необходимые для реализации функциональности заказчика. Важно заметить, что в процессе ‘Игры в планирование’ точная оценка может быть получена только в пределах одной итерации. Иногда заказчик просит оценить весь проект в целом, чтобы, например, определиться с бюджетом, но в таком случае необходимо заранее его предупредить, что оценка всего проекта будет очень приблизительной.

Итерация. XP-проект делается по итерациям, одна итерация длится от двух до четырех недель, и желательно избегать более длинных или коротких итераций. Для итерации длительностью менее двух недель один-два дня, потраченные на ‘Игру в планирование’, являются слишком большими накладными расходами. С другой стороны, практический опыт доказал, что невозможно в рамках ‘Игры в планирование’ точно оценить трудозатраты на период больше, чем 4-6 недель. Слишком уж велика вероятность того, что за длительный период времени могут измениться требования заказчика, опыт и знания команды, скорость работы и т.п.

Идеальные часы. Оценка в XP-проектах делается в идеальных часах (perfect hours), означающих время, необходимое на выполнение какой-то работы в идеальных условиях. Чтобы сделать такую оценку, разработчик должен представить себе работу в изолированной комнате при отсутствии всех отвлекающих факторов в виде чатов, электронной почты, Internet, перерывов на чаепитие или перекуры и так далее. Введение понятия ‘идеальный час’ позволяет улучшить нормализацию оценок. Если, например, спросить отдельного разработчика, как много времени понадобится на реализацию конкретной задачи, то каждый человек представит немного разные условия выполнения работы: кто-то включит в оценку изучение документации, кто-то отладку и исправление ошибок, время на обед и так далее. Предлагаемые ‘идеальные’ условия выполнения оценки подразумевают одинаковые условия для всех и делают оценку более точной.

Коэффициент Полезного Действия (Load Factor). Разработчики никогда не работают с ‘идеальной’ скоростью — время, требуемое на выполнение задачи, в среднем в два-четыре раза больше идеальной оценки и зависит от опыта и профессионализма исполнителей. В XP отношение реально потраченного времени к идеальной оценке для конкретного человека или команды называется Load Factor (коэффициент полезного действия). В разработке программных продуктов есть множество видов работ, которые сложно или просто нереально оценить заранее — исследование, отладка, исправление ошибок, работа с документацией с трудом поддаются оценке, однако мы можем взять истории множества программных проектов и определить среднее соотношение времени, потраченного в целом на проект, ко времени непосредственно кодирования, вычислив, таким образом, Load Factor. Показатель Load Factor позволяет статистически очень точно оценить суммарное время на сопутствующие разработке трудно оцениваемые виды работ, а, значит, мы будем иметь возможность точно оценить итерацию в целом. В наших оценках мы обычно берем среднее значение Load Factor, равное трем.

Скорость команды (Team Velocity). Скорость команды определяется, как количество идеальных часов, которые команда может выполнить за день. Например, наша типичная XP-команда состоит из семи человек: менеджер проекта, ведущий разработчик, ведущий тестер, три разработчика и тестер. Менеджер проекта не закрывает идеальных часов, соответственно остальные шесть человек закрывают в день 6 * 8 = 48 календарных часов. Для обычной команды мы можем взять средний Load Factor равным 3, тогда команда будет закрывать в день 48 / 3 = 16 идеальных часов. Таким образом, скорость (Team Velocity) средней команды из четырех разработчиков и двух тестеров равна 16 идеальным часам в день. Оценки команды должны быть реалистичными и честными. Теоретически команда может переоценить каждую задачу и в результате показать очень хороший Load Factor, однако опытный заказчик в любом случае почувствует, что команда работает медленно, что уменьшит вероятность продолжения проекта вне зависимости от значения формальных показателей. Недооценка проекта еще более опасна, так как в этом случае команде придется постоянно перерабатывать, что неизбежно ухудшит качество, даже если весь объем задач будет выполнен в срок. XP постулирует — работа более 40 часов в неделю более двух недель подряд нежелательна.

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

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

Нецелесообразно выделять задачи меньше 0,5 от идеального часа и задачи больше чем 16 идеальных часов.

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

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

XP-день

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

Утреннее планирование (Standup Meeting). На данной встрече все участники проекта определяют задачи на текущий день и распределяют их между собой, причем совещание проводится стоя в целях экономии времени — коммуникация между стоящими людьми происходит быстрее, чем в случае традиционного заседания. Надо стараться избегать ситуации, когда совещание сводится к изложению менеджером проекта своих идей — все вопросы, важные для команды, должны обсуждаться, а инициатива может исходить от любого участника. В ходе совещания разработчики обычно разделяются на пары, принимая во внимание конкретные задачи на день, опыт участников пары в соответствующей области и психологические предпочтения. Рабочий день не начинается с утреннего совещания, до него участники команды могут доделывать задачи предыдущего дня, исправлять текущие ошибки, просматривать спецификации и так далее.

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

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

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

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

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

Управление изменениями в XP

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

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

  1. Учитывая стоимость изменения, заказчик может отказаться от него, сочтя его неоправданно дорогостоящим.
  2. Заказчик может попросить включить изменение в текущий план итерации. Однако только первоначальная функциональность, согласованная на игре в планирование, является обязательством, которое разработчики должны выполнить к концу итерации. Команда будет стараться сделать и все изменения тоже, но не гарантирует этого.
  3. Если изменение является высокоприоритетным, заказчик может заменить часть первоначальных требований на данное изменение, чтобы гарантировать его выполнение в течение данной итерации.
  4. Заказчик может перенести изменение на следующую итерацию, переопределив его в пользовательскую историю.

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

Выгоды XP

Почему методология XP и вообще Agile-методы становятся все более популярными?

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

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

В классических проектах часто архитектурные слои делаются последовательно ‘по горизонтали’. Например, сначала разрабатывают уровень базы данных, потом бизнес-классы, потом графический интерфейс. Из-за этого легко может возникнуть ситуация, когда к дате выпуска версии 100% базы данных сделано, 100% бизнес-классов написано, но, например, только 50% графического интерфейса успели запрограммировать. Соответственно, заказчику практически не на что смотреть и нечем пользоваться. В XP функциональность делается по пользовательским историям, и для каждой истории все необходимые уровни разрабатываются одновременно ‘по вертикали’, а затем сразу же тестируются. Таким образом, заказчик имеет возможность гораздо раньше предоставить комментарии разработчикам и пользоваться различными частями приложения.

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

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

Неопытные программисты и тестеры могут быстро и эффективно обучаться благодаря парному программированию и акценту на коммуникацию в команде.

Ограничения XP

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

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

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

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

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

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

Сергей Андржеевский (sa@exigenservices.com) — менеджер XP-проектов компании Exigen Services, (г. Санкт-Петербург).

Scrum: гибкое управление разработкой
http://www.osp.ru/os/2007/04/4220063

Компания Exigen Services

Компания Exigen Services специализируется на разработке ИТ-решений для компаний из списка Global 1000, предоставлении услуг аутсорсинга и системной интеграции. Exigen Services располагает собственными методологиями разработки на основе SOA и специализированным ноу-хау для предоставления своим клиентам услуг по высокотехнологичному аутсорсингу. Exigen Services применяет передовые инструментальные средства и технологии, как собственные разработки, так и коммерческие программные продукты и продукты с открытым кодом, что позволяет уменьшить стоимость и длительность разработки, а также ускорить внедрение новых приложений. Компания сочетает СММ-сертифицированный производственный процесс с применением гибких методологий разработки ПО — экстремальное программирование и Scrum. Количество сотрудников — 1800.

Штаб-квартира в Сан-Франциско, центры разработки: Бостон, Санкт-Петербург, Дубна, Казань, Днепропетровск, Одесса, Рига, Вильнюс, Минск, Нижний Новгород.

Системы управления качеством: CMMI Level 5, ISO- 9001

Вертикальные рынки: страхование, финансовые услуги, государственный сектор, здравоохранение, телекоммуникации, ИТ-индустрия.

География клиентов: Северная Америка, Западная Европа, Центральная и Восточная Европа.

Пример XP-проекта

Заказчик — крупный производитель микропроцессоров — попросил разработать систему с КПК-клиентом на языке C# на платформе Compact .NET и Microsoft SQL CE. Команда имела большой опыт в разработке с применением C#/.NET/SQL для обычных компьютеров, но не с КПК, поэтому заказчик сразу решил использовать методологию XP как очень подходящую для ситуации со многими неизвестными. Для уменьшения рисков заказчик решил начать проект с недельной пилотной итерации, для того, чтобы убедиться в способности команды правильно оценивать и разрабатывать приложение для КПК-платформы.

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

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

Размер команды: семь человек (менеджер, ведущий разработчик, ведущий тестер, три разработчика и тестер). Трудозатраты: 1000 человеко-дней. Объем кода: 50 тыс. строк. Использованные технологии: XP, C#, Web Services, .NET, Compact .NET, SQL 2000, SQL Server CE 2.0. Программа для автоматизированного тестирования PDA: Test Suit 2.0. Платформа для клиента: PDA Dell Axim X5 с операционной системой Pocket PC 2003.

Инструментарий для XP

Разработанная нами бесплатно распространяемая программа X-Man (Extreme Manager, www.offshoreagile.com/resources/toolbox) автоматически рассчитывает все важные для XP параметры, показывая наиболее интересную информацию в двух графиках (рис. 1, 2).

Рис. 1. График текущего статуса проекта

График на рисунке 1 показывает ‘Статус относительно проделанной работы’ (малиновая линия), ‘Статус относительно оставшейся работы’ (синяя линия) и ‘Текущe. скорость работы’ (зеленая линия). Ось ‘X’ представляет рабочие дни итерации, а ось ‘Y’- отклонение от идеального хода проекта в идеальных часах. Если проект идет идеально (без опережения, без отставания и без изменений от заказчика по ходу проекта), то графики ‘Статус относительно проделанной работы’ и ‘Статус относительно оставшейся работы’ будут совпадать с осью X. Если команда работает быстрее плана, тогда малиновая линия будет идти выше оси X и отклонение от нуля будет соответствовать количеству идеальных часов в запасе у команды. Если же команда отстает от плана, тогда малиновая линия будет идти ниже оси X.

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

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

Рис. 2. Диаграмма изменения объема работы в идеальных часах

График на рисунке 2 ‘Оставшиеся идеальные часы’ представляет собой изменение во времени (ось X) оставшегося объема работы в терминах идеальных часов (ось Y). Дополнительные изменения, внесенные заказчиком, представлены на рисунке желтыми столбцами. Например, на графике можно видеть, что 18 декабря добавилось изменение заказчика, оцененное командой примерно в 9 идеальных часов. Самое интересное на графике — это автоматически рассчитанная пунктирная линия, которая предсказывает дату окончания итерации, используя среднее значение скорости работы команды для уже прошедших дней. Уже после нескольких первых дней итерации менеджер проекта может видеть прогноз и, соответственно, имеет возможность, если потребуется, предпринять корректирующие действия раньше, чем в случае типичного классического проекта.

Благодаря ежедневному отчету команды о закрытых за день задачах и явно оцененных внесенных изменений заказчика, контроль за состоянием и всеми параметрами XP-проекта с помощью программы X-Man получается очень точным и наглядным.