Scrum. Революционный метод управления проектами
Оригинальное название: Scrum: The Art of Doing Twice the Work in Half the Time
Год первого издания: 2014
Достоинства: Описание современного метода организации работы от одного из его создателей.
Недостатки: Предлагаемый подход не так универсален, как кажется.
Издатель на русском языке: «Манн, Иванов и Фербер»
Время прочтения: 4–6 часов.
Уровень: Продвинутый.
Оценка: 8/10.
Разработка программного обеспечения – одно из самых передовых направлений человеческой деятельности. Неудивительно, что именно в этой среде находят применение самые свежие и оригинальные способы управления проектами. Книга бывшего боевого пилота, затем ставшего программистом, одного из создателей «Манифеста Agile» и принципов гибкого управления проектами Джеффа Сазерленда (написанная им совместно с сыном, Джей Джеем Сазерлендом, имя которого почему-то пропало из русского издания книги и упоминается только в разделе благодарностей) дает представление о современных методологиях, которые могут оказаться полезными и в работе, далекой от компьютерной индустрии.
Идеи оригинальных методов разработки программ начали появляться еще в конце 50-х годов, но настоящий прорыв наступил в 90-х, когда многим стало очевидно, что существующие тяжеловесные и излишне регламентированные подходы не позволяют качественно и быстро обеспечивать потребности заказчиков. В 2001 году эти методы были объединены в единую концепцию, получившую название «Гибкие методологии разработки» (в специальной литературе часто встречается также синонимичный термин «Agile-методологии»).
Манифест
В феврале 2001 года в курортном местечке Сноуберд в штате Юта в ходе встречи группы ИТ-специалистов был разработан программный документ, известный как «Манифест Agile» или «Манифест гибких методов разработки ПО». Манифест сводится к четырем утверждениям:
• личности и взаимодействие между ними важнее процессов и инструментария;
• работающий продукт важнее исчерпывающей документации по нему;
• сотрудничество с заказчиком важнее согласования деталей контракта;
• реакция на изменения важнее следования плану.
Этот манифест основан на 12 принципах, которые вполне универсальны.
1. Высшим приоритетом является удовлетворение заказчика путем своевременной и непрерывной поставки продукта, имеющего самостоятельную ценность.
2. Даже на поздних стадиях разработки приветствуется изменение требований к продукту, чтобы обеспечить заказчику конкурентное преимущество.
3. Выпускать работоспособную стадию продукта следует часто, каждые несколько недель, максимум – каждые несколько месяцев.
4. В течение всей работы над проектом представители бизнес-подразделений и разработчики должны постоянно сотрудничать.
5. Проекты следует выстраивать вокруг мотивированных личностей. Дайте им поддержку и условия, в которых они нуждаются, и доверьте делать их работу.
6. Наиболее практичным и эффективным методом обмена информацией как с командой, так и внутри команды является личная беседа лицом к лицу.
7. Главным показателем прогресса является работоспособный продукт.
8. Гибкие процессы способствуют устойчивому развитию. Все участники проекта, включая заказчика, должны быть способны постоянно поддерживать такой темп.
9. Непрерывное внимание к техническому совершенству и качеству проектирования увеличивает гибкость.
10. Чрезвычайно важна простота – искусство увеличивать долю работы, которую не придется делать.
11. Лучшие требования, решения и идеи возникают в самоорганизующихся командах.
12. Через регулярные интервалы команда должна анализировать возможности повышения своей эффективности и соответственно корректировать свой подход к работе.
Фактически речь идет о том, что разработку проектов следует разделить на этапы, результатом каждого из которых будет работоспособный продукт, который на каждой стадии постепенно расширяется, дополняется или совершенствуется. Иначе говоря, это развитие идеи MVP – минимально работоспособного продукта.
Основное отличие в том, что в случае «гибкого управления» минимально работоспособный продукт служит не для определения перспективности разработок, а для повышения эффективности взаимодействия с заказчиком. Он облегчает понимание истинного потенциала продукта, предоставляя возможность тестирования на самых ранних стадиях разработки, и позволяет своевременно вносить изменения в проект.
Одним из авторов манифеста и был программист Джефф Сазерленд. Разработанный им метод «гибкого управления проектами», известный как Scrum, сейчас завоевывает все большую популярность среди самых разных отраслей бизнеса.
Спортивный подход
Спортивный термин Scrum, обозначающий положение, при котором тесно стоящие регбисты, толкаясь, пытаются завладеть мячом, для описания разработки продуктов впервые применили Хиротака Такеучи и Икуджиро Нонака в своей статье в Harward Business Review в 1986 году.
В ней они, опираясь на исследования компаний, производящих автомобильную и множительную технику, утверждали, что можно повысить скорость и гибкость разработки. Для этого Такеучи и Нонака предлагали использовать одну немногочисленную межфункциональную команду, работающую в режиме последовательных перекрывающихся этапов, каждый из которых она проходит «как единое целое, передавая мяч между собой». В 1995 году Джефф Сазерленд и Кен Швабер представили этот подход как оформленную методику, которую и назвали Scrum.
В основе Scrum – небольшие группы, включающие в себя специалистов во всех необходимых для автономной работы областях. В группе должны быть выделены двое ответственных. Один из них следит за соблюдением процессов и поддержанием конструктивной атмосферы в команде, а второй, условно называемый «владелец продукта», отвечает за формулировку требований задания, расстановку приоритетов, замыкая на себя общение с заинтересованными сторонами.
Задание разделяется на отдельные фрагменты так, чтобы каждая часть была по возможности небольшой, функционально независимой и потенциально способной использоваться отдельно от остального проекта, то есть имеющей самостоятельную бизнес-ценность. После этого фрагменты упорядочиваются по степени их важности, и оцениваются трудозатраты на каждый из них.
Вся дальнейшая работа ведется короткими итерациями, называемыми спринты, которые длятся от одной до четырех недель. Вначале группа с учетом скорости своей работы набирает фрагменты проекта, которые собирается выполнить за спринт, начиная с самых важных. Затем члены команды по мере выполнения разбирают их в работу в соответствии с установленными приоритетами. Ежедневно проводится короткое общее совещание, на котором участники «сверяют часы» и обсуждают возникающие проблемы. В конце каждой итерации должен быть представлен работоспособный элемент проекта.
Для определения целей отдельных спринтов книга предлагает использовать набор из пяти критериев: цели должны быть определенные, измеримые, достижимые, значимые и имеющие срок выполнения.
После завершения каждого спринта его необходимо проанализировать, чтобы иметь возможность усовершенствовать свои процессы. Также нужно провести демонстрацию результатов разработки, чтобы получить «обратную связь» от «владельца продукта», который может изменить (или оставить прежними) требования к проекту и расстановку приоритетов, после чего можно запускать следующий спринт.
Чтобы получить качественную «обратную связь», нужно продемонстрировать именно готовую работу, а не красивую презентацию или отчет. Понять необходимость изменений заказчик сможет, только увидев то, что уже сделано. А поскольку мерилом успеха является прирост функциональных возможностей продукта, то лучше показать его на практике.
Обязанности владельца
«Владелец продукта» играет особенно важную роль в разработке по методу Scrum, так как именно он определяет порядок реализации проекта. Для этого автор книги предлагает персонифицировать пользователей создаваемого продукта, придав образам конкретные цели и потребности в ценностях.
Затем можно заняться определением функциональных потребностей этих пользователей. Их наиболее удобно представлять визуально, на доске. Сначала выявляются основные виды деятельности, из них проистекают базовые задачи, которые, в свою очередь, разделяются на подзадачи, расположенные по мере убывания их значимости. Верхний слой подзадач – основные, обеспечивающие минимальное функционирование продукта и обычно попадающие в первые спринты. Ниже оказываются различные расширения, дополнения и улучшения, и чем ниже подзадачи находятся, тем они менее важны.
Чтобы понять, какие задачи являются базовыми, следует учитывать, к какой категории функциональности продукта они относятся. Три основные категории, которые предлагает автор книги, – обязательные, линейные и привлекательные. Обязательные функции – те, без которых продукт не нужен. Линейные – те, которые повышают удовлетворенность потребителя при эксплуатации. А привлекательные – те, которые влюбляют потребителя в продукт, например дизайн или эргономичность. Важно понимать, что обязательные функции надо развивать до определенного предела, так как с какого-то момента их усовершенствование перестанет повышать удовлетворенность потребителя, в то время как улучшение линейных и привлекательных функций его радует всегда.
Книга Джеффа Сазерленда была написана спустя 20 лет после возникновения метода. За прошедшее время он создал компанию Scrum, Inc, консультировал многие фирмы по всему миру и имел возможность испытать свои идеи в самых разных отраслях деятельности.
Благодаря этому в книге содержится множество кейсов, которые в данном случае совершенно уместны – они используются не в качестве образцов, а для иллюстрации широкой применимости подхода. Постоянная смена описываемых сфер применения Scrum поможет читателю самостоятельно адаптировать методику к собственному бизнесу.
Отдельное уважение вызывает то, что Сазерленд не пытается приписать себе чужие заслуги – в книге очень часто упоминается Производственная система Toyota и цитируются авторы многих книг, с которыми вы познакомились в предыдущих разделах.
Но у книги есть одно слабое место: может создаться ложное впечатление, что Scrum применим в абсолютно любой организации. Это не вполне соответствует действительности, и, прежде чем внедрять такие подходы, стоит хорошенько подумать, подходят ли они вашей компании. Впрочем, думать вообще не вредно.