Поскольку в гибком проекте тестировать нужно буквально все, ни один этап работы не обойдется без участия тестировщика. Он будет работать бок о бок с клиентом, помогая ему оформить предъявляемые требования в виде тестов.
Что, если начинать каждый проект вот так?
Предположим, в начале каждого проекта вы вместе с командой пытаетесь ответить на четыре простых вопроса о себе.
• В чем я особенно хорош?
• Как я привык работать?
• Что я ценю?
• Каких результатов можно от меня ожидать?
Затем, получив новые идеи, задайте те же вопросы коллегам, чтобы они рассказали вам, в чем они хороши, как работают, что ценят и какой результат могут выдать.
Эта идея называется упражнением Друкера[4]. При всей простоте оно очень помогает сплотить команду, наладить необходимую коммуникацию и уровень доверия, необходимый для любой высокопроизводительной команды.
Тестировщик будет тесно сотрудничать с разработчиками, помогая автоматизировать тесты, отыскивая «дырки» и выполняя широкое исследовательское тестирование, пытаясь проверить приложение под любым возможным углом.
Кроме того, тестировщик будет представлять себе целостную картину тестирования и никогда не упустит из виду тестирования с возрастающей нагрузкой, масштабируемости и всех остальных деталей, которые требуется учесть для создания высококлассного продукта.
В книге Джанет Грегори и Лизы Криспин Agile Testing: A Practical Guide for Testers and Agile Teams [GC09] подробно описана важность роли тестировщика при гибкой разработке.
Подробнее о механизмах гибкого тестирования мы поговорим в разделе 9.6.
Гибкий менеджер проектов
Гибкий менеджер проекта знает, что успех невозможен без плодотворной работы всей команды. Вот почему хороший менеджер проекта сделает все возможное и невозможное, чтобы ничто не мешало его команде достичь успеха.
В частности, он займется планированием и перепланированием, а при необходимости – корректировкой курса (см. главу 8).
Кроме того, к его задачам относится улавливание ожиданий всех людей, занятых в работе над проектом: передача отчетов о состоянии дел владельцам (stakeholders), стимулирование взаимодействий внутри компании, а также защита рабочей группы от неблагоприятных внешних воздействий. Все это – обязанности хорошего гибкого менеджера проектов.
Хороший менеджер проекта не рассказывает команде, чем ей заниматься, – этого просто не требуется. Он помогает создать такую среду, в которой команда будет чувствовать себя максимально независимо и продолжать отлично работать и в отсутствие менеджера проектов. На самом деле фирменной чертой хорошего гибкого менеджера проектов является умение исчезнуть и вернуться через две недели, но так, чтобы никто этого не заметил.
Подробнее об управлении проектами мы поговорим в главах 8 и 9.
Гибкий разработчик взаимодействия с пользователем
Разработчики уровня взаимодействия пользователя с программой сосредоточены на создании полезных, удобных и приятных функций, обеспечивающих такое взаимодействие. Специалист, интересующийся проблемой удобства работы с программой (юзабилити), будет стремиться понять, что нужно пользователю, а затем сотрудничать с оставшейся командой, чтобы найти наилучшие способы удовлетворения пользовательских потребностей.
К счастью, многие практические методы, используемые юзабилити-экспертами, хорошо согласуются с духом гибкой разработки программ. Акцент на ценности продукта, быстрая коммуникация и максимальное удовлетворение потребностей клиента – общие цели как гибких разработчиков, так и специалистов по удобству программы.
Кстати, юзабилити-экспертам не в новинку работать постепенно, и они привычны к итерациям. Они проектируют и создают новые функции по мере того, как пишется код (а не пытаются сделать все заранее и кардинально опередить всю команду).
Если вы можете заполучить в ваш проект специалиста по юзабилити, считайте, что вам повезло. Такой человек может поделиться массой полезного опыта и знаний и очень поможет общему делу в области анализа и разработки уровня взаимодействия с пользователем.
Все остальные
Перечислю остальные важные роли и специалистов, которых не упомянул выше. Это администраторы баз данных, системные администраторы, технические писатели, инструкторы, специалисты по улучшению текущей деятельности, инфраструктуры и обслуживанию сетей. Все они – члены команды разработки и равноправные участники проекта.
В скраме есть роль руководителя (scrum master). В гибком проекте ему отводится место тренера и продюсера рок-звезды в одном флаконе. Такие тренеры могут быть очень полезны при «раскочегаривании» новых команд. Они умеют объяснить и привить принципы гибкой разработки и соответствующую философию, а также гарантировать, что команда не собьется с курса и не вернется к прежним вредным привычкам. Работа тренера хорошо описана в книге Agile Coaching [SD09].
Опытной команде, как правило, не требуется специальный тренер, но новому проекту такой специалист определенно не повредит.
И последнее: рассказывая об этих ролях, дайте людям понять, что в гибком проекте вполне нормально (и ожидаемо), что человек будет одновременно играть несколько ролей.
Иными словами, пусть аналитик знает, что разработчик имеет полное право беседовать с клиентом (это даже приветствуется). Пусть тестировщики не удивляются тому, что разработчику придется написать немало автоматизированных тестов. А если в вашем проекте не будет специального разработчика пользовательских интерфейсов, это не означает, что никто не собирается заниматься юзабилити и дизайном. Разумеется, все это будет сделано, только другими людьми, которые исполняют в гибком проекте сразу несколько ролей.
В завершение немного поговорим о том, как набирать людей в команду.
2.4. Советы по подбору команды для гибкой разработки
Хотя большинству людей должно понравиться работать в высокопроизводительной гибкой команде, есть некоторые вещи, на которые нужно обращать внимание при подборе квалифицированных профессионалов.
Ищите универсалов
Универсалы хорошо приживаются в гибких проектах, поскольку сама методология требует от людей систематически работать и использовать для этого все предоставляемые возможности. Если говорить о программисте, то нам нужен разработчик, который имеет представление обо всем технологическом стеке проекта. Аналитики и тестировщики должны соответственно проводить анализ и уметь работать с тестами.
Кроме того, универсал легко вживается в разные роли. Сегодня человек пишет код, завтра занимается анализом, а послезавтра – тестированием.
Люди, не боящиеся неопределенности
Если проект гибкий, это не означает, что в нем все пойдет как по маслу. Требования не будут преподноситься на блюдечке – нужно работать и самостоятельно выяснять их. Планы будут меняться, и вам придется приспосабливаться к этим изменениям.
Ищите людей, которые не боятся отбивать закрученные мячи, умеют держать удар и при необходимости изменять курс, не прекращая движения вперед.
Командные игроки, умеющие подавлять свое эго
Звучит избито, но для гибкой разработки лучше подойдут люди, которые умеют работать слаженно и подавлять собственное эго.
Не всем по вкусу расплывчатость ролей, принятая в гибкой методологии. Некоторые люди стараются защищать область, которую считают своей епархией.
Просто ищите тех, кто не имеет противоречий с самим собой, не боится делиться знаниями и искренне наслаждается взаимным обучением и ростом.
УЧЕНИК: Мастер, я запутался. Если в гибком проекте нет предопределенных ролей, то как же он работает?
МАСТЕР: Команда сделает то, что должно быть сделано.
УЧЕНИК: О да, Мастер, но если нет специальной роли тестировщика, как можно быть уверенным, что все необходимые тесты будут проведены?
МАСТЕР: Без тестирования никак не обойтись, поэтому команда будет им заниматься. Команда решает, сколько нужно тестов и сколько сил на это потратить.
УЧЕНИК: А если никто не хочет заниматься тестированием? Что, если всем нравится просто сидеть и писать код?
МАСТЕР: Тогда нужно найти людей, которым нравится тестировать, и самому убедиться, какими ценными членами твоей команды они станут.
УЧЕНИК: Благодарю тебя, Мастер. Я подумаю над этим.
Что дальше?
Мы рассмотрели, как в гибких проектах исчезают четкие границы между ролями, почему команда будет работать наиболее успешно, если все соберутся в одном месте, и как, подыскивая людей в команду, находить специалистов-универсалов и тех, кто не боится неопределенности.
