Когда в команде появляются новые люди, предоставляйте им две или три итерации, в течение которых они задают массу вопросов, выполняют роль партнеров при программировании в парах и изучают огромные объемы тестов и кода. Когда они почувствуют себя достаточно подготовленными, они смогут принять на себя ответственность за выполнение новых задач, однако фактор нагрузки для них необходимо снизить. Когда они продемонстрируют свою способность выпускать качественный код, фактор нагрузки можно будет поднять.
Если состав команды будет меняться постепенно, меньше чем за год вы можете заменить изначальную команду абсолютно новыми людьми, не нарушая при этом как технической поддержки работающего продукта, так и текущей разработки новой функциональности. Это значительно менее рискованный подход, чем типичное: Вот эта и эта кипы бумаги содержат всю необходимую для вас информацию, изучив которую вы сможете приступить к работе. В действительности передать новичку информацию о культуре, в рамках которой ведется разработка проекта, – это также важно, как передать информацию о деталях дизайна и реализации, и это возможно только при личном контакте.
Если заказчик больше не может придумать ни одной новой истории, значит, наступило время хорошенько посыпать систему нафталином. Теперь необходимо написать пяти-, может быть, десятистраничное описание системы – документ, который может вам потребоваться в случае, если через пять лет вы захотите что-то изменить внутри.
Это хорошая причина для того, чтобы умереть, – заказчик доволен системой и не может придумать ничего, что можно было бы добавить в систему в обозримом будущем (я никогда с таким не сталкивался, однако я слышал об этом, поэтому я рассматриваю этот вариант для полноты картины).
Существует также и другая, не очень хорошая причина для смерти – система находится в неудовлетворительном состоянии. Заказчик нуждается в новых возможностях, а вы не можете добавить их по экономическим соображениям. Количество дефектов может вырасти до величины, которая является неприемлемой.
Это смерть от энтропии, с которой вы боретесь как можно более долгое время. ХР – это не волшебство. Проекты ХР подвержены энтропии точно так же, как и любые другие проекты. Вы просто надеетесь, что это произойдет как можно позже.
В любом случае, мы столкнулись с невозможным – система должна умереть. Когда это происходит, глаза всех участников проекта должны быть открыты. Команда должна быть в курсе экономической ситуации. Команда, заказчики и менеджеры должны согласиться с тем, что ни команда, ни система не могут выдать заказчику то, что ему нужно.
Теперь наступает время нежного прощания. Устройте вечеринку. Пригласите всех, кто работал над проектом. Это должен быть вечер воспоминаний. Воспользуйтесь возможностью и попытайтесь проанализировать причины того, что система погибла. Благодаря этому вы сможете лучше понять, с чем вам, возможно, придется иметь дело в будущем. Вместе с командой подумайте о том, как именно следует изменить свои действия, чтобы добиться успеха при работе над следующим проектом.
Глава 22.
Если состав команды будет меняться постепенно, меньше чем за год вы можете заменить изначальную команду абсолютно новыми людьми, не нарушая при этом как технической поддержки работающего продукта, так и текущей разработки новой функциональности. Это значительно менее рискованный подход, чем типичное: Вот эта и эта кипы бумаги содержат всю необходимую для вас информацию, изучив которую вы сможете приступить к работе. В действительности передать новичку информацию о культуре, в рамках которой ведется разработка проекта, – это также важно, как передать информацию о деталях дизайна и реализации, и это возможно только при личном контакте.
Смерть
Хорошо умереть – это также важно, как и хорошо жить. Для ХР это является такой же истиной, как и для людей.Если заказчик больше не может придумать ни одной новой истории, значит, наступило время хорошенько посыпать систему нафталином. Теперь необходимо написать пяти-, может быть, десятистраничное описание системы – документ, который может вам потребоваться в случае, если через пять лет вы захотите что-то изменить внутри.
Это хорошая причина для того, чтобы умереть, – заказчик доволен системой и не может придумать ничего, что можно было бы добавить в систему в обозримом будущем (я никогда с таким не сталкивался, однако я слышал об этом, поэтому я рассматриваю этот вариант для полноты картины).
Существует также и другая, не очень хорошая причина для смерти – система находится в неудовлетворительном состоянии. Заказчик нуждается в новых возможностях, а вы не можете добавить их по экономическим соображениям. Количество дефектов может вырасти до величины, которая является неприемлемой.
Это смерть от энтропии, с которой вы боретесь как можно более долгое время. ХР – это не волшебство. Проекты ХР подвержены энтропии точно так же, как и любые другие проекты. Вы просто надеетесь, что это произойдет как можно позже.
В любом случае, мы столкнулись с невозможным – система должна умереть. Когда это происходит, глаза всех участников проекта должны быть открыты. Команда должна быть в курсе экономической ситуации. Команда, заказчики и менеджеры должны согласиться с тем, что ни команда, ни система не могут выдать заказчику то, что ему нужно.
Теперь наступает время нежного прощания. Устройте вечеринку. Пригласите всех, кто работал над проектом. Это должен быть вечер воспоминаний. Воспользуйтесь возможностью и попытайтесь проанализировать причины того, что система погибла. Благодаря этому вы сможете лучше понять, с чем вам, возможно, придется иметь дело в будущем. Вместе с командой подумайте о том, как именно следует изменить свои действия, чтобы добиться успеха при работе над следующим проектом.
Глава 22.
Роли для людей
Для того чтобы команда ХР могла работать, необходимо, чтобы кто-то взял на себя исполнение некоторых определенных ролей: программиста, заказчика, инструктора, ревизора.
Спортивная команда играет лучше, если каждый игрок берет на себя исполнение определенной роли. Например, в состав футбольной команды, как правило, входит вратарь, нападающий, защитник и так далее. В баскетбольной команде присутствуют центр, нападение, защита и так далее. Игрок, играющий в одной из этих позиций, принимает на себя определенный набор обязанностей – помощь своим соратникам в нападении, защита от нападения соперников, возможно, контроль над определенным участком поля. Некоторые из этих ролей предусматривают действия в индивидуальном порядке. Другие созданы для исправления ошибок других игроков команды и координации их действий.
Подбор этих ролей основан на опыте и зачастую определяется в правилах игры. Это сделано потому, что данная комбинация ролей признана наиболее эффективной. Возможно, когда-то давно люди пробовали другие комбинации распределения обязанностей между игроками. Но то, что мы видим сегодня, сохранилось благодаря тому, что именно такая комбинация оказалась более эффективной, чем другие.
Хорошие тренеры учат игроков хорошо исполнять возложенные на них обязанности, иными словами, хорошо играть свою роль. Тренер наблюдает за поведением игрока, указывает на отклонения и либо помогает игроку скорректировать свое поведение, либо объясняет, почему игрок может вести себя несколько иначе.
Однако самый лучший тренер знает, что распределение ролей основано на опыте и не является неизменным законом природы. Время от времени игра меняется или игроки изменяются настолько, что появляется возможность добавить в существующий расклад новые роли или удалить из команды устаревшие, ставшие ненужными позиции. Гениальный тренер всегда следит за тем, какие преимущества появятся у команды в случае, если добавить новую роль или избавиться от одной из существующих.
Еще одна способность, которой обладают великие спортивные тренеры, – это их способность формировать систему в соответствии с командой, а не наоборот. Если у вас есть система, которая работает превосходно в случае, если вы используете быстрых игроков, и если команда, с которой вы работаете, показала себя на тренировках малоподвижной, но взамен этого сильной и выносливой, для вас будет лучше разработать новую систему, которая позволила бы вашей команде в полной мере проявить присущие ей таланты. Большинство тренеров не владеют этим. Вместо этого они настолько фокусируются на красоте системы, что подчас не замечают, что она не срабатывает.
Все это должно служить большим предупреждением для тех, кто слишком сильно привыкает к условиям, которые кажутся ему идеальными. Существуют роли, которые хорошо работали в предыдущих проектах. Если сейчас у вас в распоряжении люди, которые не соответствуют этим ролям, измените роли. Не пытайтесь менять людей (по крайней мере слишком значительно). Не следует действовать так, как будто никакой проблемы нет. Если роль предписывает, что этот человек должен быть склонен к большому риску, и вместо этого вы имеете дело со скрупулезным дотошным человеком, который все привык рассчитывать заранее и не предпринимает никаких действий, не взвесив все за и все против, вы должны найти иное разделение обязанностей, которое будет соответствовать поставленной перед вами цели, но без этой самой роли, которую должен играть рисковый человек.
Например, в свое время я общался с одним менеджером. Разговор шел о его команде. В ней программист являлся также и заказчиком. Я сказал моему собеседнику, что это не может эффективно работать, так как программист должен исполнять процесс и принимать технические решения. При этом необходимо, чтобы бизнес-решения принимались отдельно – заказчиком (см. описание игры в планирование).
Менеджер стал со мной спорить: Этот парень реальный биржевой брокер, выяснилось, что он умеет также и программировать. Другие брокеры любят и уважают его. Они уверены в нем и желают видеть его в качестве своего доверителя. Он обладает четким представлением о том, в каком направлении должна развиваться система. Другие программисты хорошо различают, когда он разговаривает от лица заказчика и когда он разговаривает от лица технического специалиста.
Хорошо. Правила утверждают, что программист не может быть заказчиком. В данном случае эти правила не применяются. Но по-прежнему остается в силе принцип разделения технических решений и бизнес-решений. Вся команда, сам программист/заказчик, и особенно инструктор ХР, должны точно знать, какую роль играет программист/заказчик в каждый конкретный момент времени. Кроме того, инструктор должен знать, что вне зависимости от того, насколько хорошо данная организация работала в прошлом, если команда попадает в затруднительную ситуацию, двойная роль является наиболее вероятной причиной проблемы.
Конечно же если заказчику не требуется программное обеспечение для того, чтобы поддерживать функционирование бизнеса, то никакой надобности в программистах не было бы.
С первого взгляда может показаться, что быть программистом ХР – это то же самое, что быть программистом в любом другом проекте. Вы проводите свое время, работая над программами, увеличивая их размер, упрощая код и повышая производительность приложений. Однако если копнуть глубже, в ХР ваши усилия концентрируются несколько иначе, чем в других дисциплинах. Ваша работа не заканчивается тогда, когда компьютер начинает вас понимать. Вашей основной задачей является передача важных сведений другим людям. Если программа уже работает, но при этом некий важный компонент коммуникации не завершен, значит, вы должны продолжить работу. Вы пишете тесты, которые демонстрируют жизненно важные аспекты разрабатываемого вами программного продукта. Вы разделяете программу на меньшие фрагменты или объединяете слишком маленькие куски программы в более крупные, более емкие части. Вы подыскиваете систему именования таким образом, чтобы выбираемые вами имена более точно отражали ваши намерения.
Это может показаться благородным стремлением к совершенству. На самом деле это все что угодно, но не погоня за совершенством. Вы пытаетесь разработать программное обеспечение, которое будет как можно более полезным для заказчика, однако при этом вы не пытаетесь делать нечто, что не является полезным. Если вы в достаточной степени сократите масштаб проблемы, тогда вы можете позволить себе более тщательно работать над тем, что от нее осталось. В результате вы начинаете работать тщательно по привычке.
Как программист ХР вы должны обладать навыками, которые не требуются или по крайней мере не являются настолько важными в рамках других стилей разработки. Например, программирование в паре – это не такое уж и сложное искусство, им вполне можно овладеть, однако зачастую оно вступает в противоречие с некоторыми особенностями людей, которые, как правило, занимаются программированием. Подозреваю, что я должен выразить свою мысль более простым языком: многие программисты являются малообщительными людьми. Конечно, из этого правила есть исключения, кроме того, если ты не чувствуешь себя свободно в общении, этому не сложно научиться. Однако факт остается фактом: для того, чтобы успешно делать свою работу, вы должны близко общаться с другими членами команды и координировать с ними свою деятельность.
Еще одним навыком, который необходим программисту ХР, является привычка к простоте. Когда заказчик говорит: Вы должны сделать это, это и это, вы должны быть готовым к обсуждению, являются ли все эти вещи действительно необходимыми и насколько? Простота также должна распространяться на разрабатываемый вами код. Программист, который привык в каждой из возможных ситуаций использовать то или иное готовое решение, вряд ли сможет удачно действовать в рамках ХР. Конечно же, скорее всего, вы справитесь со своей работой лучше, если у вас в запасе будет большее количество инструментов и приемов, однако будет лучше, если у вас будет множество инструментов, о которых вы будете знать, когда их не следует использовать. Это будет лучше, чем если бы вы знали все обо всем и с риском использовали бы в своем решении большое количество разнообразных приемов.
Вам также потребуются навыки, в большей степени технически ориентированные. Вы должны уметь хорошо программировать. Вы должны уметь перерабатывать код – это умение по крайней мере столь же глубокое и тонкое, сколь и программирование. Вы должны уметь писать тесты модулей для вашего кода – это умение, как и переработка, требует вкуса и рассудительности.
Вы должны отвыкнуть от желания получить в индивидуальное владение некоторую часть системы. Напротив, вы должны рассматривать всю систему как общую собственность, которая принадлежит не только вам, но и вашим товарищам по команде. Если кто-либо изменяет написанный вами код, в какой бы части системы этот код не находился бы, вы должны доверять сделанным изменениям и делать на основе этих изменений выводы. Конечно же, если эти изменения сделаны недостаточно продуманно, на вас лежит ответственность за улучшение текущего положения вещей.
И прежде всего остального вы должны быть готовыми посмотреть в лица своим страхам. Все мы боимся:
• выглядеть глупыми;
• показаться бесполезными;
• стать устаревшими;
• быть недостаточно хорошими.
Без запаса храбрости ХР просто не сработает. Вы можете потратить все ваше время, отчаянно пытаясь не совершить ошибку. Вместо этого, если вы желаете, воспользуйтесь помощью команды и взгляните в глаза своим страхам. После этого вы сможете оказаться в деле, вы будете в составе команды с большим удовольствием для себя создавать превосходное программное обеспечение.
Быть заказчиком в ХР не так-то просто. Вы должны научиться некоторым важным навыкам, например написанию хороших историй. И ваша целеустремленность в этом деле – это путь к успеху. Однако самое важное – вы должны научиться оказывать на проект мягкое влияние, не будучи в состоянии при этом контролировать его. Силы, которые действуют вне рамок вашего контроля, формируют то, что создается в рамках проекта в такой же степени, как и решения, которые вы принимаете. Изменения в характере функционирования бизнеса, эволюция технологий, состав и возможности команды – все эти факторы оказывают значительное влияние на программное обеспечение, которое разрабатывается в рамках проекта.
Вам придется принимать решения. Для всех тех заказчиков, с которыми мне приходилось работать, это было наиболее сложным навыком. Все они привыкли к информационным технологиям, которые не приносят и половины той пользы, которую им обещают, а та половина, которую получает заказчик, оказывается наполовину неправильной. Заказчики приучены не уступать информационным технологиям ни одной лишней йоты, так как они ожидают, что в любом случае окажутся разочарованными. ХР не работает с такими заказчиками. Если вы являетесь заказчиком ХР, команда должна быть способной сказать вам с полной уверенностью: Вот это более важно, чем вот это, Эта история слишком большая, ее части будет достаточно, Этих нескольких историй вполне достаточно. И когда время начинает поджимать, а оно фактически всегда начинает поджимать, команда будет нуждаться в том, чтобы вы заново обдумали свои требования и, возможно, пересмотрели некоторые из них. Ну что ж, я думаю, что мы вполне сможем обойтись без этого до следующего квартала. Способность принимать подобные решения иногда позволит вам сохранить вашу команду и снизить стресс настолько, что они будут способны сделать для вас все, что в их силах.
Лучшими заказчиками являются те, кто будет на практике использовать разрабатываемую систему. Однако при этом они должны также обладать некоторым перспективным взглядом на проблему, которую предстоит решить. Если вы являетесь одним из таких заказчиков, вы должны следить за тем, чтобы ваши мысли текли в правильном направлении. Иными словами, вы должны думать о том, как обычно выполняются те или иные действия и операции. Если вы на шаг или на два удалены от реального использования системы, вы должны приложить максимальные усилия для того, чтобы максимально точно представлять интересы реальных пользователей системы.
Вы должны научиться писать истории. Поначалу это может показаться почти невыполнимой задачей. Однако в ответ на первые несколько историй команда предоставит вам чрезвычайно полезный набор мнений и рекомендаций. Вы быстро научитесь, насколько емкой должна быть каждая из историй, какая информация должна быть включена в историю, а какой информации в ней быть не должно.
Вы должны научиться писать функциональные тесты. Если вы – заказчик приложения с математической базой, ваша задача упрощается – несколько минут или несколько часов работы с электронной таблицей будет достаточно для того, чтобы сформировать данные для тестового случая. Возможно, команда разработает специально для вас инструмент, упрощающий создание новых тестовых случаев. Программы, основанные на формулировках, также нуждаются в функциональных тестах. Вы должны тесно взаимодействовать с командой для того, чтобы понять, какие вещи полезнее всего протестировать и тесты какого типа являются излишними. Некоторые команды могут даже выделить вам специально техническую помощь для подбора, написания и запуска тестов. Ваша цель: написать тесты, которые позволят вам сказать: Ну, если все это срабатывает, значит, я уверен в том, что система работает нормально.
Наконец вы должны быть способны продемонстрировать отвагу. Между тем, где вы находитесь сейчас, и тем, куда вы намерены прийти, пролегает долгий путь. Эта команда поможет вам отыскать дорогу, если вы ей поможете в этом.
Тестер ХР – это не отдельный человек, специально нацеленный на разрушение системы и унижение программистов. Однако должен быть кто-то, кто будет регулярно запускать тесты (если вы не можете запустить тесты модулей и функциональные тесты одновременно), оповещать команду о результатах тестирования и проверять правильность работы тестирующих инструментов.
Для того чтобы делать правильные предварительные оценки, вам потребуется обратная связь и практика. Вы обязаны делать множество предварительных оценок и затем следить, насколько реальность соответствует этим оценкам. В следующий раз, когда команда будет формировать предварительную оценку, вы должны быть способны сказать: Две трети наших предположений в прошлый раз оказались завышенными по крайней мере на 50%. Последующие оценки – это по-прежнему обязанность людей, которые занимаются реализацией того, что оценивается, однако как ревизор вы должны предоставить им обратную связь, указать на неточности с тем, чтобы они смогли сделать оценки лучше, чем в прошлый раз.
Вы также должны следить за общей картиной разработки. На половине работы над очередной итерацией вы должны быть способны сказать команде, удастся ли достигнуть намеченной цели, если следовать ранее определенным курсом, или требуется что-либо изменить. Через две итерации в направлении даты выпуска очередной версии вы должны быть способны сказать команде, сможет ли она выпустить очередную версию без значительных изменений или потребуется чего-либо пересмотреть и переделать.
Как ревизор вы также выполняете функции историка команды. Вы ведете летопись результатов функционального тестирования. Вы вносите записи в журнал обнаруженных дефектов, кто несет ответственность за каждый из дефектов и какие тестовые случаи добавлены для идентификации каждого из дефектов.
Навык, который вы должны развивать в себе больше всех остальных, – это умение собирать необходимую для вас информацию, не беспокоя при этом весь остальной процесс больше, чем это необходимо. Конечно, вы должны немножко побеспокоить работающих соратников для того, чтобы выяснить, сколько времени им в реальности потребовалось для выполнения той или иной задачи. Однако это необходимо делать так, чтобы люди обращали на это как можно меньше внимания. Вы не должны становиться для них занозой в мягком месте так, что они будут избегать встречи с вами.
Каждый в команде ХР несет ответственность за осмысление методик ХР до определенной степени. Вы же отвечаете за более глубокое их восприятие:
• какие альтернативные методики могут помочь в решении текущего набора проблем;
• каким образом ХР используется в других командах;
• какие идеи лежат в основе ХР и какое отношение они имеют к текущей ситуации.
Наиболее сложный вывод, который я сделал, исполняя роль инструктора, – это то, что вы работаете лучше, если вы работаете не напрямую. Если вы видите ошибку в дизайне, прежде всего вы должны решить, является ли это настолько важным, что требуется ваше вмешательство. Каждый раз, когда вы начинаете влиять на поведение команды, вы делаете ее участников менее самостоятельными. Если вы будете руководить ими в большой степени, они потеряют возможность работать без вас. В результате снизится производительность, ухудшится качество и ослабеет моральный дух. Таким образом, прежде всего вы должны определить, стоит ли обнаруженная вами проблема того риска, который вы принимаете, решая вмешаться в обычный ход дела.
Если все же вы приняли решение, что ваше мнение в данной ситуации весомее, чем мнение команды, то вы должны сделать ваше вмешательство как можно менее разрушительным. Например, вместо того, чтобы самостоятельно изменять дизайн системы, будет лучше, если вы предложите такой тестовый случай, удовлетворить который можно, только изменив дизайн. Это великое искусство – не говорить напрямую, что вы видите, а говорить об этом так, что вся остальная команда тоже начинает видеть это. Однако в некоторых ситуациях вы должны действовать прямо, прямо до грубости. Уверенные в себе, агрессивные программисты ценны именно тем, что они уверены в себе и агрессивны. Однако при этом они становятся беззащитными перед определенного рода недальновидностью, и единственным лекарством в подобных ситуациях является прямой разговор. Когда вы позволили ситуации ухудшиться до той степени, что нежная рука на загривке не дает желаемых результатов, вы должны быть готовыми схватить удила в обе руки и прикрикнуть: А ну, п-шо-о-ол! направляя кого надо в нужную сторону. Но делать это надо только до того момента, пока команда не выедет на нужную дорогу. После этого вы должны вновь ослабить свое влияние.
Здесь я хочу еще кое-что рассказать о роли инструктора. Как инструктор я постоянно обучаю мою команду навыкам ХР – простому дизайну, переработке кода, тестированию. Однако я не считаю, что все это должно входить в определение роли инструктора. Если у вас есть команда, которая в достаточной степени технически самодостаточна, однако нуждается в помощи для организации процесса, вы можете быть инструктором и при этом не быть техническим волшебником. В этом случае вы по-прежнему должны добиваться от всех членов команды, чтобы они слушались вас. Однако когда все уже обладают необходимыми навыками, ваша задача будет заключаться в том, чтобы напоминать им о тех методиках, которые они собрались применять в тех или иных ситуациях.
Роль инструктора теряет свою значимость по мере того, как команда взрослеет и совершенствуется. В соответствии с принципами распределенного управления и принимаемой ответственности сам процесс ХР становится общей ответственностью. На ранних стадиях перехода к ХР просить программистов приходится о многих вещах.
Это является существенным преимуществом, так как команда становится чрезвычайно гибкой. Однако это является также и слабым местом, потому что время от времени команда нуждается в глубоких технических знаниях. Благодаря тому что ХР концентрируется на простоте дизайна, редко когда в процессе разработки возникает надобность в помощи со стороны специалистов, однако время от времени такое случается.
Спортивная команда играет лучше, если каждый игрок берет на себя исполнение определенной роли. Например, в состав футбольной команды, как правило, входит вратарь, нападающий, защитник и так далее. В баскетбольной команде присутствуют центр, нападение, защита и так далее. Игрок, играющий в одной из этих позиций, принимает на себя определенный набор обязанностей – помощь своим соратникам в нападении, защита от нападения соперников, возможно, контроль над определенным участком поля. Некоторые из этих ролей предусматривают действия в индивидуальном порядке. Другие созданы для исправления ошибок других игроков команды и координации их действий.
Подбор этих ролей основан на опыте и зачастую определяется в правилах игры. Это сделано потому, что данная комбинация ролей признана наиболее эффективной. Возможно, когда-то давно люди пробовали другие комбинации распределения обязанностей между игроками. Но то, что мы видим сегодня, сохранилось благодаря тому, что именно такая комбинация оказалась более эффективной, чем другие.
Хорошие тренеры учат игроков хорошо исполнять возложенные на них обязанности, иными словами, хорошо играть свою роль. Тренер наблюдает за поведением игрока, указывает на отклонения и либо помогает игроку скорректировать свое поведение, либо объясняет, почему игрок может вести себя несколько иначе.
Однако самый лучший тренер знает, что распределение ролей основано на опыте и не является неизменным законом природы. Время от времени игра меняется или игроки изменяются настолько, что появляется возможность добавить в существующий расклад новые роли или удалить из команды устаревшие, ставшие ненужными позиции. Гениальный тренер всегда следит за тем, какие преимущества появятся у команды в случае, если добавить новую роль или избавиться от одной из существующих.
Еще одна способность, которой обладают великие спортивные тренеры, – это их способность формировать систему в соответствии с командой, а не наоборот. Если у вас есть система, которая работает превосходно в случае, если вы используете быстрых игроков, и если команда, с которой вы работаете, показала себя на тренировках малоподвижной, но взамен этого сильной и выносливой, для вас будет лучше разработать новую систему, которая позволила бы вашей команде в полной мере проявить присущие ей таланты. Большинство тренеров не владеют этим. Вместо этого они настолько фокусируются на красоте системы, что подчас не замечают, что она не срабатывает.
Все это должно служить большим предупреждением для тех, кто слишком сильно привыкает к условиям, которые кажутся ему идеальными. Существуют роли, которые хорошо работали в предыдущих проектах. Если сейчас у вас в распоряжении люди, которые не соответствуют этим ролям, измените роли. Не пытайтесь менять людей (по крайней мере слишком значительно). Не следует действовать так, как будто никакой проблемы нет. Если роль предписывает, что этот человек должен быть склонен к большому риску, и вместо этого вы имеете дело со скрупулезным дотошным человеком, который все привык рассчитывать заранее и не предпринимает никаких действий, не взвесив все за и все против, вы должны найти иное разделение обязанностей, которое будет соответствовать поставленной перед вами цели, но без этой самой роли, которую должен играть рисковый человек.
Например, в свое время я общался с одним менеджером. Разговор шел о его команде. В ней программист являлся также и заказчиком. Я сказал моему собеседнику, что это не может эффективно работать, так как программист должен исполнять процесс и принимать технические решения. При этом необходимо, чтобы бизнес-решения принимались отдельно – заказчиком (см. описание игры в планирование).
Менеджер стал со мной спорить: Этот парень реальный биржевой брокер, выяснилось, что он умеет также и программировать. Другие брокеры любят и уважают его. Они уверены в нем и желают видеть его в качестве своего доверителя. Он обладает четким представлением о том, в каком направлении должна развиваться система. Другие программисты хорошо различают, когда он разговаривает от лица заказчика и когда он разговаривает от лица технического специалиста.
Хорошо. Правила утверждают, что программист не может быть заказчиком. В данном случае эти правила не применяются. Но по-прежнему остается в силе принцип разделения технических решений и бизнес-решений. Вся команда, сам программист/заказчик, и особенно инструктор ХР, должны точно знать, какую роль играет программист/заказчик в каждый конкретный момент времени. Кроме того, инструктор должен знать, что вне зависимости от того, насколько хорошо данная организация работала в прошлом, если команда попадает в затруднительную ситуацию, двойная роль является наиболее вероятной причиной проблемы.
Программист
Программист является сердцем ХР. На самом деле если бы программисты могли всегда принимать решения, в которых тщательно балансировались краткосрочные и долгосрочные приоритеты, в рамках проекта не нужны были бы никакие другие технические работники, кроме программистов.Конечно же если заказчику не требуется программное обеспечение для того, чтобы поддерживать функционирование бизнеса, то никакой надобности в программистах не было бы.
С первого взгляда может показаться, что быть программистом ХР – это то же самое, что быть программистом в любом другом проекте. Вы проводите свое время, работая над программами, увеличивая их размер, упрощая код и повышая производительность приложений. Однако если копнуть глубже, в ХР ваши усилия концентрируются несколько иначе, чем в других дисциплинах. Ваша работа не заканчивается тогда, когда компьютер начинает вас понимать. Вашей основной задачей является передача важных сведений другим людям. Если программа уже работает, но при этом некий важный компонент коммуникации не завершен, значит, вы должны продолжить работу. Вы пишете тесты, которые демонстрируют жизненно важные аспекты разрабатываемого вами программного продукта. Вы разделяете программу на меньшие фрагменты или объединяете слишком маленькие куски программы в более крупные, более емкие части. Вы подыскиваете систему именования таким образом, чтобы выбираемые вами имена более точно отражали ваши намерения.
Это может показаться благородным стремлением к совершенству. На самом деле это все что угодно, но не погоня за совершенством. Вы пытаетесь разработать программное обеспечение, которое будет как можно более полезным для заказчика, однако при этом вы не пытаетесь делать нечто, что не является полезным. Если вы в достаточной степени сократите масштаб проблемы, тогда вы можете позволить себе более тщательно работать над тем, что от нее осталось. В результате вы начинаете работать тщательно по привычке.
Как программист ХР вы должны обладать навыками, которые не требуются или по крайней мере не являются настолько важными в рамках других стилей разработки. Например, программирование в паре – это не такое уж и сложное искусство, им вполне можно овладеть, однако зачастую оно вступает в противоречие с некоторыми особенностями людей, которые, как правило, занимаются программированием. Подозреваю, что я должен выразить свою мысль более простым языком: многие программисты являются малообщительными людьми. Конечно, из этого правила есть исключения, кроме того, если ты не чувствуешь себя свободно в общении, этому не сложно научиться. Однако факт остается фактом: для того, чтобы успешно делать свою работу, вы должны близко общаться с другими членами команды и координировать с ними свою деятельность.
Еще одним навыком, который необходим программисту ХР, является привычка к простоте. Когда заказчик говорит: Вы должны сделать это, это и это, вы должны быть готовым к обсуждению, являются ли все эти вещи действительно необходимыми и насколько? Простота также должна распространяться на разрабатываемый вами код. Программист, который привык в каждой из возможных ситуаций использовать то или иное готовое решение, вряд ли сможет удачно действовать в рамках ХР. Конечно же, скорее всего, вы справитесь со своей работой лучше, если у вас в запасе будет большее количество инструментов и приемов, однако будет лучше, если у вас будет множество инструментов, о которых вы будете знать, когда их не следует использовать. Это будет лучше, чем если бы вы знали все обо всем и с риском использовали бы в своем решении большое количество разнообразных приемов.
Вам также потребуются навыки, в большей степени технически ориентированные. Вы должны уметь хорошо программировать. Вы должны уметь перерабатывать код – это умение по крайней мере столь же глубокое и тонкое, сколь и программирование. Вы должны уметь писать тесты модулей для вашего кода – это умение, как и переработка, требует вкуса и рассудительности.
Вы должны отвыкнуть от желания получить в индивидуальное владение некоторую часть системы. Напротив, вы должны рассматривать всю систему как общую собственность, которая принадлежит не только вам, но и вашим товарищам по команде. Если кто-либо изменяет написанный вами код, в какой бы части системы этот код не находился бы, вы должны доверять сделанным изменениям и делать на основе этих изменений выводы. Конечно же, если эти изменения сделаны недостаточно продуманно, на вас лежит ответственность за улучшение текущего положения вещей.
И прежде всего остального вы должны быть готовыми посмотреть в лица своим страхам. Все мы боимся:
• выглядеть глупыми;
• показаться бесполезными;
• стать устаревшими;
• быть недостаточно хорошими.
Без запаса храбрости ХР просто не сработает. Вы можете потратить все ваше время, отчаянно пытаясь не совершить ошибку. Вместо этого, если вы желаете, воспользуйтесь помощью команды и взгляните в глаза своим страхам. После этого вы сможете оказаться в деле, вы будете в составе команды с большим удовольствием для себя создавать превосходное программное обеспечение.
Заказчик
Заказчик – это вторая половина базовой двойственности экстремального программирования. Программист знает, как программировать. Заказчик знает, что программировать. Конечно, не с самого начала, но заказчик желает узнать столь же много, сколь знает программист.Быть заказчиком в ХР не так-то просто. Вы должны научиться некоторым важным навыкам, например написанию хороших историй. И ваша целеустремленность в этом деле – это путь к успеху. Однако самое важное – вы должны научиться оказывать на проект мягкое влияние, не будучи в состоянии при этом контролировать его. Силы, которые действуют вне рамок вашего контроля, формируют то, что создается в рамках проекта в такой же степени, как и решения, которые вы принимаете. Изменения в характере функционирования бизнеса, эволюция технологий, состав и возможности команды – все эти факторы оказывают значительное влияние на программное обеспечение, которое разрабатывается в рамках проекта.
Вам придется принимать решения. Для всех тех заказчиков, с которыми мне приходилось работать, это было наиболее сложным навыком. Все они привыкли к информационным технологиям, которые не приносят и половины той пользы, которую им обещают, а та половина, которую получает заказчик, оказывается наполовину неправильной. Заказчики приучены не уступать информационным технологиям ни одной лишней йоты, так как они ожидают, что в любом случае окажутся разочарованными. ХР не работает с такими заказчиками. Если вы являетесь заказчиком ХР, команда должна быть способной сказать вам с полной уверенностью: Вот это более важно, чем вот это, Эта история слишком большая, ее части будет достаточно, Этих нескольких историй вполне достаточно. И когда время начинает поджимать, а оно фактически всегда начинает поджимать, команда будет нуждаться в том, чтобы вы заново обдумали свои требования и, возможно, пересмотрели некоторые из них. Ну что ж, я думаю, что мы вполне сможем обойтись без этого до следующего квартала. Способность принимать подобные решения иногда позволит вам сохранить вашу команду и снизить стресс настолько, что они будут способны сделать для вас все, что в их силах.
Лучшими заказчиками являются те, кто будет на практике использовать разрабатываемую систему. Однако при этом они должны также обладать некоторым перспективным взглядом на проблему, которую предстоит решить. Если вы являетесь одним из таких заказчиков, вы должны следить за тем, чтобы ваши мысли текли в правильном направлении. Иными словами, вы должны думать о том, как обычно выполняются те или иные действия и операции. Если вы на шаг или на два удалены от реального использования системы, вы должны приложить максимальные усилия для того, чтобы максимально точно представлять интересы реальных пользователей системы.
Вы должны научиться писать истории. Поначалу это может показаться почти невыполнимой задачей. Однако в ответ на первые несколько историй команда предоставит вам чрезвычайно полезный набор мнений и рекомендаций. Вы быстро научитесь, насколько емкой должна быть каждая из историй, какая информация должна быть включена в историю, а какой информации в ней быть не должно.
Вы должны научиться писать функциональные тесты. Если вы – заказчик приложения с математической базой, ваша задача упрощается – несколько минут или несколько часов работы с электронной таблицей будет достаточно для того, чтобы сформировать данные для тестового случая. Возможно, команда разработает специально для вас инструмент, упрощающий создание новых тестовых случаев. Программы, основанные на формулировках, также нуждаются в функциональных тестах. Вы должны тесно взаимодействовать с командой для того, чтобы понять, какие вещи полезнее всего протестировать и тесты какого типа являются излишними. Некоторые команды могут даже выделить вам специально техническую помощь для подбора, написания и запуска тестов. Ваша цель: написать тесты, которые позволят вам сказать: Ну, если все это срабатывает, значит, я уверен в том, что система работает нормально.
Наконец вы должны быть способны продемонстрировать отвагу. Между тем, где вы находитесь сейчас, и тем, куда вы намерены прийти, пролегает долгий путь. Эта команда поможет вам отыскать дорогу, если вы ей поможете в этом.
Тестер
Большая часть обязанностей, связанных с тестированием, лежит на плечах программистов, поэтому роль человека, выполняющего тестирование, в команде ХР фокусируется на заказчике. Тестер помогает заказчику в подборе и написании функциональных тестов. Если функциональные тесты не являются частью интеграционного пакета, тестер отвечает за регулярный запуск функциональных тестов и публикацию результатов в обозримом для всех месте.Тестер ХР – это не отдельный человек, специально нацеленный на разрушение системы и унижение программистов. Однако должен быть кто-то, кто будет регулярно запускать тесты (если вы не можете запустить тесты модулей и функциональные тесты одновременно), оповещать команду о результатах тестирования и проверять правильность работы тестирующих инструментов.
Ревизор
Как ревизор вы должны быть совестью команды.Для того чтобы делать правильные предварительные оценки, вам потребуется обратная связь и практика. Вы обязаны делать множество предварительных оценок и затем следить, насколько реальность соответствует этим оценкам. В следующий раз, когда команда будет формировать предварительную оценку, вы должны быть способны сказать: Две трети наших предположений в прошлый раз оказались завышенными по крайней мере на 50%. Последующие оценки – это по-прежнему обязанность людей, которые занимаются реализацией того, что оценивается, однако как ревизор вы должны предоставить им обратную связь, указать на неточности с тем, чтобы они смогли сделать оценки лучше, чем в прошлый раз.
Вы также должны следить за общей картиной разработки. На половине работы над очередной итерацией вы должны быть способны сказать команде, удастся ли достигнуть намеченной цели, если следовать ранее определенным курсом, или требуется что-либо изменить. Через две итерации в направлении даты выпуска очередной версии вы должны быть способны сказать команде, сможет ли она выпустить очередную версию без значительных изменений или потребуется чего-либо пересмотреть и переделать.
Как ревизор вы также выполняете функции историка команды. Вы ведете летопись результатов функционального тестирования. Вы вносите записи в журнал обнаруженных дефектов, кто несет ответственность за каждый из дефектов и какие тестовые случаи добавлены для идентификации каждого из дефектов.
Навык, который вы должны развивать в себе больше всех остальных, – это умение собирать необходимую для вас информацию, не беспокоя при этом весь остальной процесс больше, чем это необходимо. Конечно, вы должны немножко побеспокоить работающих соратников для того, чтобы выяснить, сколько времени им в реальности потребовалось для выполнения той или иной задачи. Однако это необходимо делать так, чтобы люди обращали на это как можно меньше внимания. Вы не должны становиться для них занозой в мягком месте так, что они будут избегать встречи с вами.
Инструктор
Как инструктор вы отвечаете за весь процесс разработки. Вы должны обращать внимание на то, что люди отклоняются от заранее обусловленного порядка работы, и вы должны обращать на это внимание всей команды. Вы должны оставаться спокойным в то время, когда все остальные в панике. Вы должны помнить, что за следующие две недели вы сможете сделать объем работ, рассчитанный на две недели и не более (а возможно, и менее) того. Этого либо достаточно, либо нет, третьего не дано.Каждый в команде ХР несет ответственность за осмысление методик ХР до определенной степени. Вы же отвечаете за более глубокое их восприятие:
• какие альтернативные методики могут помочь в решении текущего набора проблем;
• каким образом ХР используется в других командах;
• какие идеи лежат в основе ХР и какое отношение они имеют к текущей ситуации.
Наиболее сложный вывод, который я сделал, исполняя роль инструктора, – это то, что вы работаете лучше, если вы работаете не напрямую. Если вы видите ошибку в дизайне, прежде всего вы должны решить, является ли это настолько важным, что требуется ваше вмешательство. Каждый раз, когда вы начинаете влиять на поведение команды, вы делаете ее участников менее самостоятельными. Если вы будете руководить ими в большой степени, они потеряют возможность работать без вас. В результате снизится производительность, ухудшится качество и ослабеет моральный дух. Таким образом, прежде всего вы должны определить, стоит ли обнаруженная вами проблема того риска, который вы принимаете, решая вмешаться в обычный ход дела.
Если все же вы приняли решение, что ваше мнение в данной ситуации весомее, чем мнение команды, то вы должны сделать ваше вмешательство как можно менее разрушительным. Например, вместо того, чтобы самостоятельно изменять дизайн системы, будет лучше, если вы предложите такой тестовый случай, удовлетворить который можно, только изменив дизайн. Это великое искусство – не говорить напрямую, что вы видите, а говорить об этом так, что вся остальная команда тоже начинает видеть это. Однако в некоторых ситуациях вы должны действовать прямо, прямо до грубости. Уверенные в себе, агрессивные программисты ценны именно тем, что они уверены в себе и агрессивны. Однако при этом они становятся беззащитными перед определенного рода недальновидностью, и единственным лекарством в подобных ситуациях является прямой разговор. Когда вы позволили ситуации ухудшиться до той степени, что нежная рука на загривке не дает желаемых результатов, вы должны быть готовыми схватить удила в обе руки и прикрикнуть: А ну, п-шо-о-ол! направляя кого надо в нужную сторону. Но делать это надо только до того момента, пока команда не выедет на нужную дорогу. После этого вы должны вновь ослабить свое влияние.
Здесь я хочу еще кое-что рассказать о роли инструктора. Как инструктор я постоянно обучаю мою команду навыкам ХР – простому дизайну, переработке кода, тестированию. Однако я не считаю, что все это должно входить в определение роли инструктора. Если у вас есть команда, которая в достаточной степени технически самодостаточна, однако нуждается в помощи для организации процесса, вы можете быть инструктором и при этом не быть техническим волшебником. В этом случае вы по-прежнему должны добиваться от всех членов команды, чтобы они слушались вас. Однако когда все уже обладают необходимыми навыками, ваша задача будет заключаться в том, чтобы напоминать им о тех методиках, которые они собрались применять в тех или иных ситуациях.
Роль инструктора теряет свою значимость по мере того, как команда взрослеет и совершенствуется. В соответствии с принципами распределенного управления и принимаемой ответственности сам процесс ХР становится общей ответственностью. На ранних стадиях перехода к ХР просить программистов приходится о многих вещах.
Консультант
В рамках проекта ХР, как правило, не возникает каких-либо специализаций. Каждый член команды работает в паре с любым из других членов, партнеры в парах часто меняются, пары меняют свой фокус в рамках системы с высокой частотой, и каждый член команды при желании может взять на себя ответственность за выполнение любой задачи. По этим причинам в проекте не возникает черных дыр, связанных с тем, что только один или два человека обладают доскональным знанием о той или иной части системы или обо всей системе в целом.Это является существенным преимуществом, так как команда становится чрезвычайно гибкой. Однако это является также и слабым местом, потому что время от времени команда нуждается в глубоких технических знаниях. Благодаря тому что ХР концентрируется на простоте дизайна, редко когда в процессе разработки возникает надобность в помощи со стороны специалистов, однако время от времени такое случается.