Читать книгу Гибкое управление IT-проектами. Руководство для настоящих самураев - Джонатан Расмуссон - Страница 10

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

Если у вас возникает вопрос: «А где все программисты, тестировщики и аналитики?» – не волнуйтесь, они никуда не исчезли. Просто при гибкой разработке не так важно, кто именно играет конкретные роли.

Начнем с рассмотрения самой важной роли в гибком проекте – клиента.

Клиент гибкого проекта

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

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

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

Все это не происходит в вакууме. Речь идет о совместной работе с командой разработчиков, ведь могут быть технические причины, по которым целесообразно сделать сначала одни элементы, а потом другие (иными словами, снизить технологический риск).

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

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

Разумеется, чтобы все это получилось, требуется очень тесное сотрудничество клиента с командой (в идеале – в течение всего рабочего дня). В ранних версиях экстремального программирования было принято говорить о «заказчике в команде» (on-site customer). В скраме аналогичная роль называется «владелец продукта» (product owner).

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

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

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

Теперь поговорим о команде разработчиков.

Команда разработчиков

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

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

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

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

Гибкий аналитик

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

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

Аналитик выполняет в гибком проекте множество задач: помогает клиенту писать пользовательские истории (см. главу 6); выполняет глубокий анализ, когда дело доходит до разработки; помогает создавать имитационные объекты (mock-ups) и прототипы; использует в ходе анализа все доступные ему инструменты, чтобы донести до разработчика сущность пользовательских историй.

Подробнее о функционировании гибкого анализа мы поговорим в разделе 9.4.

Гибкий программист

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

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

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

♦ Они пишут много тестов и часто пользуются ими при разработке (см. главы 12 и 14).

♦ Они постоянно дорабатывают и оптимизируют архитектуру программы по мере работы (см. главу 13).

♦ Они уверены, что базовый код всегда готов к использованию и может быть развернут по первому требованию (см. главу 15).

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

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

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

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

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

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

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

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

• Что я ценю?

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

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

Эта идея называется упражнением Друкера[4]. При всей простоте оно очень помогает сплотить команду, наладить необходимую коммуникацию и уровень доверия, необходимый для любой высокопроизводительной команды.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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