Итерации Scrum – целостная схема, а не прикольная картинка

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

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

Я тут хочу оговориться, что текст далее в значительной мере посвящен IT. Сделано это не только потому, что, я думаю, много читателей будет из IT и им это интересно, но и потому, что если вы будете переносить процесс в другие отрасли, то следует понимать те изменения, которые в IT потребовались для успешной реализации – вам придется делать аналогичные адаптации или смириться с недостаточной эффективностью процесса, или отказаться от него. Это касается не только Scrum, но и других методов Agile. И несмотря на все эти оговорки, можно сказать, что применение Scrum за пределами IT является более эффективным, чем регулярный менеджмент, и это дает компаниям преимущество – что и объясняет интерес к применению.

Отметим, что создатель Scrum Джеф Сазерленд в своей книге «Scrum – революционный метод управления проектами» пишет о том, что он был скептически настроен по применению Scrum за пределами IT, потому что полагал, что фреймворк сильно нагружен IT-спецификой. Однако, по мере того, как его пробовали использовать и достигали успеха, его скепсис развеялся, и в книге он приводит различные примеры использования.

Я рекомендую эту книгу всем, кто хочет понять дух и культуру Scrum и Agile в целом. При этом Джеф описывает сам фреймворк, логику и историю его создания, и дает множество кейсов применения. А еще книга достаточно очищена от IT-специфики, так что может быть обобщенным руководством. Кстати, говорят, что это - одна из двух книг, прочитав которые Герман Греф проникся новым менеджментом. Вторая «Открывая организации будущего» Фредерика Лалу.

А вторая книга, которую я хочу порекомендовать – Хенрик Книберг «Скрам и XP: заметки с передовой», в оригинале «Scrum and XP from the Trenches». Русский перевод был сделан энтузиастами и долгое время лежал на infoq.com, потом был оттуда убран, но в сети остался, например, здесь, а английский по прежнему доступен на infoq уже во втором издании. Книга – про IT, очень популярна и в свое время именно по ней изучали Agile-методы. Я тоже впервые детально познакомился со Scrum именно по ней в 2007. Книга актуальна не только для IT-шников, но и для заказчиков софта, особенно в корпорациях, она помогает понять логику разработки и наладить сотрудничество.

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

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

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

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

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

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

Ну а теперь перейдем к устройству фреймворка Scrum.

Для начала отметим, что Scrum – нормированный процесс, и он описан в Scrum Guide. Он описан очень аккуратно: в нем четко определены функции элементов, и рекомендуется их процедурное содержание. При этом предполагается, что возможна и даже необходима адаптация для конкретного проекта. Однако, надо понимать, что с некоторого момента адаптации становятся настолько большими, что вы уже не можете говорить «мы работаем по Scrum», а должны говорить «у нас собственный процесс на основе Scrum». Об этом часто забывают, и в результате Скрамом сейчас по факту называют самые различные вещи.

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

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

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

Предполагается, что у нас есть список задач, которые следует выполнить для достижения цели – Product Backlog, и задачи там упорядочены по важности и приоритетам. О том, каким образом наполняется этот список мы поговорим дальше. Перед стартом итерации из этого списка выбираются задачи, которые планируется выполнить в Sprint Backlog. Но, что важно, мы не просто выбираем некоторое количество задач из начала списка. Дело в том, что в конце итерации должен получиться целостное приращение к продукту, несущее ценность потребителю и пригодное к использованию. Собственно, в этом состояла основная революция: при традиционном проектном подходе команда работала несколько месяцев и продукт в понятном для потребителя и пригодном для использования виде собирался только в самом конце, а о пригодности для потребителя промежуточных сборок никто не заботился, даже если применялись практики continuous integration и проверка работоспособности сделанного.

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

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

Переход к инкрементальному созданию приложения в IT потребовал кардинального пересмотра способов работы с требованиями и проектирования приложения. Появились новые форматы, такие как user story, каждая из которых описывала ценную для пользователя функциональность и была относительно мала, так, что можно было легко ими маневрировать при планировании, в отличие от цельных проектов большого функционала, с которым работали в прошлом. И первая версия Scrum Guide (можно скачать отсюда) рекомендовала использовать именно их в качестве элементов бэклога. По мере распространения Scrum другие форматы ведения требований и проектирования тоже адаптировались. Например, Ивар Якобсон адаптировал формат use case и появился Use Case 2.0, пригодный для инкрементальной реализации..Ссылка ведет на сайт Ивара, где книга бесплатно доступна после регистрации, а .здесь мой конспект мастер-класса Ивара о них в 2013. Так что сейчас для элементов бэклога могут применяться разные варианты.

Отметим, что далеко не в любых проектах можно перейти к инкрементальной реализации с поставкой ценности. Понятным примером являются строительные проекты: мост или здание надо построить целиком и запустить в эксплуатацию. Другим примером является организация конференции или другого мероприятия – тут есть финальный релиз и нет промежуточных этапов, приносящих ценность. Однако, есть большая зона, где преобразование возможно в том или ином объеме. И надо отметить, что хорошо поддаются преобразованию проекты НИОКР. Например, концерн Калашникова на одной из встреч, что они применяют Scrum для разработки новых видов оружия. При этом за две недели получается сделать в железе некоторый очередной прототип, демонстрация которого позволяет увидеть ошибки проектирования и неверные пути, которые при традиционном способе были бы проявлены только через полгода, и это дает большую экономию и средств и времени. На AgileBusiness-2018 о применении Scrum для разработки новых материалов рассказывала Северсталь (мой конспект в отчете с конференции), а для создания коллекций одежды - 12Storeez (есть видео и мой конспект), можно найти много других примеров.

Отмечу также, что Scrum может применяться и для организации работы в случае, когда существенную часть работ вообще нельзя запланировать. Например, на AgileDays-2018 Марина Симонова (Marina Alex) рассказывала о применении Scrum в сети стоматологических клиник (видео), в которых работа состоит в обслуживании пациентов, и не может быть запланирована. В этом случае спринты Scrum использовались только для задания еженедельного ритма работы. Но при этом сознательно был выбран именно фреймворк Scrum для того, чтобы путем резких изменений организации работы и переходе к командам обеспечить изменение культуры в коллективе и наладить сотрудничество между врачами, медсестрами и немедицинским персоналом, которые обычно в медицине сильно разделены. Там были образованы именно смешанные команды, включающие все роли.

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

Каждая итерация начинается с Планирования. Это встреча, на которой определяются цели на спринт и scope (объем и содержание) работ. Цель фокусирует работу спринта и в идеале формулирует ту ценность для потребителя, которая будет в рамках спринта создана. Но может задавать и вектор движения, по которому намечается значительное продвижение. Вообще, говоря про цель следует иметь ввиду все, что сказано выше про разные варианты итераций Scrum, обусловленные особенностями деятельности.

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

Помимо этих задач в начале бэклога обычно находятся задачи, связанные со срочными доработками или с устранением замечаний по ранее реализованному функционалу, полученными на Демо (Sprint Review). Если их относительно немного и они помещаются в спринт вместе с основными, то они могут быть включены. Однако, если срочных задач и замечаний достаточно много, то возникает вопрос выбора: сократить количество основных задач или отложить срочные задачи? Ответ – основной scope сокращать нельзя, цель спринта должна быть руководством к действию, а не декларацией. А если срочных задач накопилось действительно много, сделайте отдельный спринт, целью которого будет как раз выполнение срочных задач и устранение замечаний. Только ее тоже надо сформулировать сфокусированно, например, «дорабатываем систему, чтобы отдел Z стал счастлив».

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

И, наконец, следует рассказать о четвертой категории задач и связанных с ними дополнительными целями спринта. Это задачи, направленные на повышение эффективности самого процесса работы команды или снижение его рисков. Типичным примером является увеличение bus factor – уникальных специалистов команды, болезнь которых или отсутствие по другим причинам может остановить работу команды полностью или над конкретными видами задач. Название, собственно, это и объясняет: речь идет о числе членов команды, попадание которых под автобус остановит проект. Близкой к этому является задача устранения бутылочных горлышек, возникающих, если в спринте оказываются задачи определенного типа, по которым у команды компетенции недостаточны или сосредоточены у одного человека.

Если такая ситуация зафиксирована и устранение Product Owner и члены команды признали важным, то она может быть включена как дополнительная цель в какой-либо спринт со средствами решения. Средства решения могут быть различны – обучение сотрудников, выполнение каких-то исследований и прототипов, или просто выполнение задач определенного типа не опытными, имеющими необходимые компетенции, а теми, кто таких компетенций не имеет. Цель должна звучать конкретно, например «Петя учит Васю делать отчеты, чтобы снизить bus factor», и, естественно, в спринте должны быть задачи по отчетам. Дальше такая цель учитывается внутри спринта, а на планировании оцениваются и закладываются накладные расходы, связанные с ее достижением.

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

Описанные категории задач свойственна не только IT, но и другим областям, хотя наполнение может сильно различаться. Например, в IT-разработки целью спринта может быть реализация целостного набора функций, ориентированного на определенные группы пользователей, которые привлекут их к продукту, называемых фичами (от feature, это уже есть в словарях!) или эпиками (от epic story, а этого в словарях еще нет). А для отдела продаж целью может быть реализация определенной промоакции, сфокусированной на некоторой группе потребителей и сопровождаемая массовыми предложениями, или фокусное продвижение на определенном рынке, или работа над заключением определенного крупного контракта.

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

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

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

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