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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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