Кент Бек - Экстремальное программирование

166 Глава 21 • Жизненный цикл идеального ХР-проекта

ни, чем вы думали? Может быть, вы управились в два раза быстрее? Реализованы ли тестовые случаи в срок? Насколько приятно вам работать?

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

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

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

Внедрение в эксплуатацию

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

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

В ходе этой фазы вы также оптимизируете производительность системы. В данной книге я почти ничего не говорю о производительности. Я уверен в лозунге: «Сделайте, чтобы это заработало, сделайте, чтобы это было написано правильно, сделайте, чтобы это работало быстро» (Make it run, make it right, make it fast). На завершающих стадиях работы над версией наступает отличное время для оптимизации, потому что именно в это время вы получаете максимально возможное количество знаний, внедренных в дизайн системы, вы получаете наиболее реалистичные оценки производственной нагрузки на систему и, кроме того,

172 Глава 22 • Роли для людей

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

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

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

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

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

Программист 173

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

Программист

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

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

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