Оригинальное название:

Scrum: a BreathtakinglyBrief and Agile Introduction

Автор:

Chris Sims,Hillary Johnson

Правовую поддержку обеспечивает юридическая фирма AllMediaLaw

www.allmedialaw.ru

Из IT-сферы в малопредсказуемые проекты

Подход к управлению проектами под названием Scrum (в переводе с английского – «схватка») впервые упомянули в 1986 году в статье журнала Harvard Business Review Хиротака Такеучи и Икуджиро Нонака. Японцы отметили, что проекты, над которыми работают небольшие команды из специалистов различного профиля, обычно добиваются лучших результатов. Они объяснили это «подходом регби», использовав спортивный термин Scrum (толкотня, схватка вокруг мяча в игре, благодаря которой он остается в поле). Четко сформулировали и задокументировали же методологию Scrum американские инженеры-программисты Кен Швабер и Джефф Сазерленд.

Scrum получил наибольшую популярность в технологическом секторе, где небольшие сплоченные команды создают сложное программное обеспечение. Но его, по мнению авторов этой книги, легко адаптировать к другим отраслям. Например, инструменты скрама можно использовать для совершенствования мышеловки, управления маркетингом в компании по производству собачьего корма или для совместной работы над книгой, как это сделали Крис Симс и Хиллари Джонсон. Они написали 54-страничную инструкцию по скраму на основе их опубликованного годом ранее 184-страничного бестселлера The Elements of Scrum («Элементы скрама»), который используется сейчас в вузах США как учебное пособие.

«Эта крошечная книга – только факты, мэм – представляет собой введение в ряд движущих элементов скрама: роли, артефакты и мероприятия спринта», – так описали авторы свой последний на сегодняшний день совместный писательский труд.

Работа в спринтах позволяет Scrum-командам получать больше обратной связи – от членов команды, бизнес-заказчиков и пользователей (клиентов) – и с ее помощью быстрее учиться. То, что команда узнает, работая в одном спринте, помогает планировать следующий спринт. В скраме это называется «проверкой и адаптацией» (одна из мантр Scrum), но можно называть это «непрерывным улучшением», как советуют авторы, поскольку скрам-команда постоянно фокусируется на улучшении продукта и процесса.

Чтобы скрам работал, должны соблюдаться:

• проверка и адаптация;

• прозрачность.

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

Ценности, принципы Agile и элементы Scrum

Чтобы лучше понимать суть Scrum, Крис Симс и Хиллари Джонсон рекомендуют прочитать полный текст Agile-манифеста, подписанного в 2001 году в США представителями различных гибких методологий. Этот документ содержит 4 ценности и 12 принципов (на сайте agilemanifesto.org они представлены на 68 языках).

Ценности Agile:

1. Люди и взаимодействие важнее процессов и инструментов.

2. Работающий продукт важнее исчерпывающей документации.

3. Сотрудничество с заказчиком важнее согласования условий контракта.

4. Готовность к изменениям важнее следования первоначальному плану.

Принципы Agile:

1. Наивысшим приоритетом является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного программного обеспечения.

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

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

4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.

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

6. Непосредственное общение – самый практичный и эффективный способ обмена информацией как с самой командой, так и внутри команды.

7. Работающий продукт – основной показатель прогресса.

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

9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

10. Простота – искусство минимизации лишней работы – крайне необходима.

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

12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Элементы Scrum можно представить в виде схемы:

Роли

Скрам распознает только три отличающиеся роли:

• владелец продукта (product owner);

• скрам-мастер (scrum master);

• член команды (team member).

Скрам-команда состоит из одного владельца продукта, одного скрам-мастера и нескольких членов команды по созданию продукта. Владелец продукта и скрам-мастер взаимно дополняют друг друга: первый способствует улучшению продукта, второй – процесса. Члены команды сосредотачиваются на результатах. Согласно общепринятому правилу, в команде должно быть от пяти до девяти человек. У меньшего количества людей может не хватить разнообразных навыков, а у большего могут возникнуть проблемы с продуктивностью из-за чрезмерных расходов на социальные коммуникации.

Рисунок из книги Scrum: a Breathtakingly Brief and Agile Introduction

Владелец продукта

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

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

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

Чаще всего владелец продукта добавляет требования в бэклог продукта в виде пользовательских историй. Например, «Как ‹роль› я хочу ‹функцию›, чтобы ‹чего-то достичь›» или «Как ‹тип пользователя› я хочу ‹что-нибудь сделать›, чтобы ‹добавить ценность›». Такая форма понятна всем – разработчикам, заказчикам, клиентам.