Дао Scrum

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

Как известно, центром любого scrum-проекта является product backlog. Это место, куда product owner записывает свои пожелания, оценивая их значимость и вместе с командой планирует итерации. Казалось бы, что может быть проще? Но чем же этот подход оказался лучше других? Чем он отличается, скажем, от случая, когда заказчик просто заводит тикеты, например, в JIRA? Что делает этот проект столь эффективным?

Для того, чтобы это понять, достаточно взглянуть на перевод термина “backlog” (ну, или в толковый словарь для носителей языка):

backlog

1. долг, задолженность
2. невыполненные заказы
3. резервы (товаров, материалов и т. п.)

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

Backlog – это не список задач для разработчиков

Нет, конечно, в конечном счете разработчик работает со списком конкретных задач. Но изначально, с точки зрения product owner, список конкретных задач – это скучные подробности. В первую очередь из перевода следует, что backlog – это не список задач и даже не список user stories, которые нужно выполнить, а список недостатков системы. Под недостатками подразумеваются недостающая функциональность, недостаточное качество реализации, недостаточное соответствие ожиданиям бизнеса и так далее. Тут видно замечательное свойство термина “недостаток”, которое заключается в том, что оно обобщает артефакты нескольких подпроцессов: фича, улучшение, дефет.

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

У такого подхода, среди прочих достоинств, есть одно важное преимущество: он построен на позитивном мышлении творцов, стремящихся в своей работе к совершенству, подогревая творческий потенциал участников процесса. Ведь даже Микеланджело был приверженцем такого принципа: на вопрос о том, как он создает столь совершенные скульптуры, он ответил “Я просто беру резец и отсекаю от мрамора все лишнее”. Правда похоже? :)

Подразумевается, что приложение существует на этапе планирования

Хорошо известный постулат любого agile-проесса напрямую следует из предыдущего пункта. Ведь прежде чем определить недостатки системы, да еще и определить их степень важности, нужно иметь некую текущую версию, глядя на которую и можно сказать, чего ей не достает. Нужен тот самый кусок мрамора. Ведь сложно искать недостатки в белизне чистого листа бумаги. Поэтому и существуют правило о доступе product-owner-а к актуальной рабочей версии приложения пополам с особым акцентом на коммуникации между заказчиком и разработчикам.

Выживают важнейшие требования

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

К чему это все?

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

Всех с Новым годом! :)

Опубликовать

Tweet