Постигая Agile

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

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

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

Лучшая поставка для проекта «Электронная книга»

Как эти принципы могут помочь нашему проекту «Электронная книга»? Вспомним о проблемах, с которыми столкнулась команда: их проект провалился, потому что отсутствовали важные функции, которые были у конкурентов (поддержка отраслевого стандартного формата для электронных книг и предоставление пользователям доступа к почте на этом устройстве), а функции оказались неактуальными (шаблон для создания интернет-магазина).

Давайте снова запустим проект, но на этот раз менеджер разделит работу команды и стейкхолдеров на месячные спринты. Ситуация сразу стала иной.

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

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

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

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

Используя непрерывные релизы, приветствуя изменения и предоставляя рабочее программное обеспечение после каждой итерации, команда проекта «Электронная книга» сумела поставить успешный продукт гораздо раньше. В отличие от неэффективного водопадного подхода, в котором утвержденные в начале проекта требования отгородили команду от клиентов, agile-методология позволила команде все время взаимодействовать с клиентами. Это дало возможность реагировать на изменения и создать лучший продукт.