Гибкое управление IT-проектами. Руководство для настоящих самураев

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

Гибкий тестировщик

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

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

Что, если начинать каждый проект вот так?

Предположим, в начале каждого проекта вы вместе с командой пытаетесь ответить на четыре простых вопроса о себе.

• В чем я особенно хорош?

• Как я привык работать?

• Что я ценю?

• Каких результатов можно от меня ожидать?

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

Эта идея называется упражнением Друкера[4 - http://agilewarrior.wordpress.com/2009/11/27/the-drucker-exercise.]. При всей простоте оно очень помогает сплотить команду, наладить необходимую коммуникацию и уровень доверия, необходимый для любой высокопроизводительной команды.

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

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

В книге Джанет Грегори и Лизы Криспин Agile Testing: A Practical Guide for Testers and Agile Teams [GC09] подробно описана важность роли тестировщика при гибкой разработке.

Подробнее о механизмах гибкого тестирования мы поговорим в разделе 9.6.

Гибкий менеджер проектов

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

В частности, он займется планированием и перепланированием, а при необходимости – корректировкой курса (см. главу 8).

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

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

Подробнее об управлении проектами мы поговорим в главах 8 и 9.

Гибкий разработчик взаимодействия с пользователем

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

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

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

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

Все остальные

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

В скраме есть роль руководителя (scrum master). В гибком проекте ему отводится место тренера и продюсера рок-звезды в одном флаконе. Такие тренеры могут быть очень полезны при «раскочегаривании» новых команд. Они умеют объяснить и привить принципы гибкой разработки и соответствующую философию, а также гарантировать, что команда не собьется с курса и не вернется к прежним вредным привычкам. Работа тренера хорошо описана в книге Agile Coaching [SD09].

Опытной команде, как правило, не требуется специальный тренер, но новому проекту такой специалист определенно не повредит.

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

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

В завершение немного поговорим о том, как набирать людей в команду.

2.4. Советы по подбору команды для гибкой разработки

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

Ищите универсалов

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

Кроме того, универсал легко вживается в разные роли. Сегодня человек пишет код, завтра занимается анализом, а послезавтра – тестированием.

Люди, не боящиеся неопределенности

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

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

Командные игроки, умеющие подавлять свое эго

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

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

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

УЧЕНИК:Мастер, я запутался. Если в гибком проекте нет предопределенных ролей, то как же он работает?

МАСТЕР:Команда сделает то, что должно быть сделано.

УЧЕНИК:О да, Мастер, но если нет специальной роли тестировщика, как можно быть уверенным, что все необходимые тесты будут проведены?

МАСТЕР:Без тестирования никак не обойтись, поэтому команда будет им заниматься. Команда решает, сколько нужно тестов и сколько сил на это потратить.