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

• Предыдущая
• 43/50
• Следующая

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

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

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

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

Наконец вы должны быть способны продемонстрировать отвагу. Между тем, где вы находитесь сейчас, и тем, куда вы намерены прийти, пролегает долгий путь. Эта команда поможет вам отыскать дорогу, если вы ей поможете в этом.

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

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

Как ревизор вы должны быть совестью команды.

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

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

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

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

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

Каждый в команде ХР несет ответственность за осмысление методик ХР до определенной степени. Вы же отвечаете за более глубокое их восприятие:

• какие альтернативные методики могут помочь в решении текущего набора проблем;

• каким образом ХР используется в других командах;

• какие идеи лежат в основе ХР и какое отношение они имеют к текущей ситуации.

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

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

• Предыдущая
• 43/50
• Следующая