Текст бизнес-книги "Менеджмент цифрового мира"

Автор книги: Максим Цепков

Раздел: О бизнесе популярно, Бизнес-книги

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

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

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

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

Схема Scrum – деление на спринты и подготовка к ним

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

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

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

Начнем с сокращенной схемы.

Итерации: создаем ценность в каждой, а не просто квантуем поток

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

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

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

Отметим, что далеко не в любых проектах можно перейти к инкрементальной реализации с поставкой ценности. Понятным примером являются строительные проекты: мост или здание надо построить целиком и запустить в эксплуатацию. Другим примером является организация конференции или другого мероприятия – тут есть финальный релиз и нет промежуточных этапов, приносящих ценность. Однако, есть большая зона, где преобразование возможно в том или ином объеме. И надо отметить, что хорошо поддаются преобразованию проекты НИОКР. Например, концерн Калашникова на одной из встреч, что они применяют 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 будущих спринтов, или предварительные переговоры по поводу каких-то будущих рекламных компаний и поиск контрагентов для реализации. Аналогично и в других отраслях. Задачи обучения членов команды или улучшений процесса тоже. естественно, могут ставиться в любой области.

Схема Scrum – ежедневная работа внутри спринта

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

Ежедневное выполнение задач

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

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

Возникает вопрос: а какую задачу член команды должен взять с доски, когда он закончил предыдущую? Ответ: ту, взятие им которой наилучшим образом продвинет спринт к завершению. Это вопрос личного выбора, при котором он учитывает текущую ситуацию, представленную на доски, свои собственные компетенции и компетенции других членов команды. При этом, естественно могут быть приняты определенные правила, которые призваны облегчить выбор, сделать его быстрым. Например, правило выбирать самую важную задачу. Но правила могут быть и более сложными, например, в начале спринта приоритет может отдаваться задачам, которые на планировании оценили как наиболее рискованные по реализации, в том числе длительным, а в конце спринта, наоборот, небольшим задачам, чтобы уменьшить количество незавершенных задач. Могут быть правила, по которым при скоплении на поздних этапах исполнения часть членов команды переключались на них. То есть, если говорить об IT разработчики начинали заниматься тестированием, если тестировщики вдруг не успевают. Особую остроту это приобретает, если используются WIP– лимиты. Могут быть и другие правила.

Срочные задачи

Как правило, sprint backlog фиксируется при планировании. Однако, в конкретных командах может быть необходимо уметь включать в спринт дополнительные задачи, например, если команда не только создает новый функционал, но и устраняет ошибки в старом, или обрабатывает какие-то срочные обращения клиентов или поручения руководства. Если срочные задачи появляются регулярно, то на такие задачи обычно выделяется резерв мощности команды при планировании спринта. Сгорание этого резерва можно отдельно рисовать на Burndown Chart снизу-вверх. Управления срочными задачами также желательно вести через доску, а не прямыми поручениями. Задача может быть просто повешена на доску, если ее содержание ясно. Если требуются дополнительные пояснения, то хорошая практика – подождать до очередного Daily Scrum для информации всей команде.

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

Нет прерываниям!

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

Если члены команды видят реальные потери производительности из-за частых отвлечений, это следует обсудить на ретроспективе и договориться о правилах работы. Отметим, кстати, этот прием: если кто-то увидел проблему, он начинает немедленно возмущаться и пытаться решить, а фиксирует возникшее напряжение. А потом высказывает его на соответствующей встрече, в данном случае это ретроспектива, а в случае острой проблемы – daily scrum. А результатом обсуждения чаще является не просто выраженное намерение исправиться, похожее на детское «я больше не буду» или «я буду стараться», а правило, учитывающее разные классы ситуаций: «отвлекать можно в случаях 1-2-3, а в остальных не надо», или «отвлекать можно, если отложенное решение несет такие-то риски».

Daily Scrum

Хотя работа каждого члена команды идет автономно, необходима синхронизация движения. Для этого служит ежедневная встреча – Daily Scrum. В свое время он назывался StandUp meeting, потому что рекомендовалось проводить его стоя вокруг доски. Эта рекомендация по-прежнему актуальна, если команда сидит вместе, но в случае распределенной команды это невозможно. Отметим, сидеть в одном помещении, лучше – отдельном для команды также крайне важно. А проведение митинга стоя, а не сидя способствует, во-первых, тому, чтобы члены команды оторвались от своей текущей работы, а, во-вторых, не затягивали митинг. Это – статус, а не обсуждение работы.

Если на встрече выяснилось, что какая-либо задача требует отдельного обсуждения, то надо зафиксировать, и далее ответственный за задачу должен его отдельно организовать, например, сразу после митинга. Превращение Daily Scrum в обсуждение задач, а не статус – наиболее распространенная ошибка. Рекомендация продолжительности для Daily Scrum – 15 минут, и если команда систематически превышает его, то стоит подумать о причинах и способах сокращения. Что касается времени проведения, то его команда выбирает самостоятельно, с учетом индивидуального расписания работы ее членов. В те времена, когда все начинали работу одновременно, следуя корпоративным традициям хорошим вариантом было утро сразу после начала рабочего дня, но эти времена ушли в прошлое. Может быть выбрано время перед или после обеда, если команда обедает примерно в одно время. На Daily Scrum важно участие всех членов команды, и даже если по каким-то причинам они не могут быть лично, желательно дистанционное участие. Процедура Daily Scrum следующая: люди говорят о том, что было сделано накануне с прошлой встречи, о том, чем предполагают заниматься, и о том, какие есть препятствия для движения вперед. Коротко. Как легко догадаться, при 15 минутах на команду из 7 человек каждому будет не более 2 минут. Поэтому препятствия – фиксируются и назначаются нужные обсуждения. В каком порядке говорят люди? Есть два подхода, наиболее простой – говорить по кругу. Другой порядок – на основе расположения задач на доске, начиная от крайне правой колонки, поскольку чем задача продвинулась дальше по этапам, тем важнее ее завершение.

Кроме статуса по текущим задачам Product Owner информирует команду о срочных задачах, включенных в спринт, и других важных изменениях. Но это не должно существенно увеличивать размер Daily Scrum, если требуется длительное обсуждение, то о его времени надо отдельно договориться.

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