Постигая Agile

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

Существует веская причина, по которой XP не имеет закрепленных ролей. Вот что Кент Бек говорит об этом в своей книге Extreme Programming Explained: Embrace Change.

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

Это отражает два важных ХР-принципа.

Принятие ответственности

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

Возможность

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

Есть еще одна идея, применимая в такой ситуации: коллективное владение. Помимо 13 основных XP-практик существует также 11 вытекающих из них практик-следствий.

Истинная вовлеченность клиентов

Реальное вовлечение клиентов в квартальные и еженедельные сессии планирования и учет их мнений.

Инкрементальное развертывание

Развертывание небольших частей системы по отдельности, а не «одним ударом» (с верой в то, что внедрение можно выполнить таким путем).

Целостность команды

Объединение эффективных команд.

Сокращение команд

Когда команда улучшается, она может выполнять работу быстрее. Но вместо того чтобы увеличивать объем еженедельной работы, исключите из команды одного человека (и используйте его для переноса ХР-культуры в другую команду).

Анализ первопричин

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

Общий код

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

Код и тесты

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

Единая база кода

Не поддерживайте несколько версий кода.

Ежедневное развертывание

Развертывайте новые версии в производственную среду каждый день.

Согласованный объем контракта

Как принято в консалтинговых компаниях, вместо того чтобы фиксировать объем и время переговоров (часто жертвуя качеством, чтобы уложиться в срок), фиксируйте время и регулярно договаривайтесь об объемах.

Плата за использование

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

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