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

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

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

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

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

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

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

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

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

Завершение спринта в Scrum – демо и ретро

Продолжим рассмотрение схемы скрам и поговорим про завершение спринта – Демо, оно жа Sprint Review и Ретроспективу.

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

Возникает вопрос: а почему, собственно нужна такая обратная связь? Ведь задачи в процессе исполнения перемещались по доске, каждая смена статуса имела свой чек-лист завершения, включая, естественно, критерий сделанной задачи, Definition of Done (DoD)? Разве этого недостаточно? Ответ – нет, недостаточно. Если бы ценность задачи можно было бы обеспечить выполнением чек-листа, то никакой бы Agile был не нужен, с организацией IT-проектов хорошо бы справились методы классического менеджмента. Проблема состоит в высокой сложности социотехнических систем, в результате чего все представления о необходимых функциях и о работе пользователей – не более чем гипотезы, подлежащие проверки. А на бытовом уровне эта ситуация хорошо описывается словами «заказчик сам не знает, чего он хочет». Именно поэтому разработанный софт требует постоянной проверки: несет ли он ценность пользователям. Впрочем, тоже самое можно сказать о любых других продуктах – проверить, полезен ли он потребителям, нужен ли им можно только экспериментально.

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

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

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

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

Отметим, что далеко не всегда эти проблему могут быть в конкретно вашем проекте. Наоборот, в большинстве проектов демонстрации стейкхолдерам достаточно, иначе бы в Scrum Guide не было бы рекомендованного способа. Ну или так было, когда Scrum формировался. Отметим, кстати, что переход от функциональных требований к user story отчасти проблемы демонстрации решал: мы вместо выполнения функций описывали цели пользователей, и демонстрация, как пользователи будут их достигать, работая используя разработанный софт, должна быть достаточна. Однако, что делать, если проблема в вашем проекте существует? Правильный способ решения этих проблем – придумать альтернативные механизмы получения релевантной обратной связи и встроить в процесс именно их, чтобы обеспечить выполнение основной функции демо. Например, в цикл выполнения задачи может быть включено не только тестирование, но выкатка на боевые сервера и A/B тестирование на пользователях. Или установка его на тестовые сервера заказчика с приближенными к боевым данными, и проведение обучения и демонстрации конечным пользователям. Таким образом, есть различные варианты. Но на практике вместо разработки механизмов часто просто назначают формального ответственного «ты будешь смотреть и оценишь результат». И в результате команда идет по неверному пути, а выясняется это только на внедрении функционала. Я слышал истории, когда эти проблемы возникали даже когда таким ответственным стейкхолдером был руководитель проекта от заказчика: он был на демо, был очень доволен, команда была вдохновленной. А потом оказалось, что он не слишком давно работает у заказчика, и его представления о процессе были основаны на опыте работы в другом месте. Поэтому, когда функционал принесли конечным пользователям, то выяснили его слабую пригодность для реального процесса. Заметим, что техническая выкатка изменений на боевые сервера не спасает, так как пользователи, не зная о новых функциях им просто не пользуются. А вот изменение работы пользователей в любом случае надо отдельно организовывать.

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

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

Один из них – splitting sprint, при котором команда живет в двух спринтах, сдвинутых относительно друг друга, например, на неделю, в первом происходит разработка и тестирование вплоть до выкатке на боевые сервера, которое носит предсказуемый характер, а во втором —тестирование на реальных пользователях и экспресс-доработки по его результатам. Планирование учитывает оба процесса и связано с первым циклом спринтов, а демо может проходить дважды или быть связано со вторым циклом. Отметим, что команда при этом остается общей, и хотя разработку и тестирование на пользователях часто делают разные специалисты, экспресс-доработки и решение проблем требуют участия всей команды. Другой вариант – вынести получение обратной связи от пользователей за пределы Scrum в отдельный Kanban-процесс. Он целесообразен в том случае, если с ним связаны длительные временные лаги, не укладывающиеся в короткий Scrum-цикл.

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

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

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

Во-первых, на демо идет оценка достижения целей спринта со стороны стейкхолдеров. И связанное с этим позиционирование достигнутого результата как часть более крупных циклов планирования или целеполагания: вклад спринта в разработку релиза, в продвижение к квартальным или годовым целям. Подробнее о цикле релизного планирования я буду говорить в следующей статье, рассказывая полную схему Scrum. А вот работа с квартальными и годовыми целями находится за пределами обеспечиваемого Scrum, для этого можно применять OKR (Objectives and Key Results). До OKR я тоже доберусь в будущих статьях, хотя, наверное, без подробностей. Но независимо от метода, в демо полезно включить оценку продвижения к целям по мнению стейкхолдеров. Во-вторых, на Демо стоит получить обратную связь от стейкхолдеров по работе и восприятию команды в целом. Не по созданной ценности, а по характеру коммуникаций и другим аспектам взаимодействия. Впрочем, обе этих задачи следует ставить только в том случае, если стейкхолдеры достаточно квалифицированы в высказывании такой публичной обратной связи, а команда – достаточно зрелая, чтобы ее принять. В противном случае вместо конструктива можно получить негатив и демотивацию команды.

Однако, как и в случае оценки ценности, если эти виды обратной связи на Демо получить нельзя, необходимо обеспечить другие механизмы ее получения. Ответственным за получение и донесение до команды обратной связи по целям является Product Owner, а по взаимодействию – они делят эту ответственность со скрам-мастером. Почему делят? Потому что к части стейкхолдеров Product Owner все равно пойдет по первому вопросу, и может заодно выяснить второй, нет смысла в двойной коммуникации. В то же время, взаимодействие Команды со стейкхолдерами может не ограничиваться теми, кто получает ценность от созданного продукта, это могут быть смежные и обслуживающие подразделения и команды, и задача взаимодействия с ними в целом лежит на скрам-мастере. И всю обратную связь надо получить до Ретро, чтобы там команда могла это обсудить. Эти циклы обратной связи можно делать и более редкими, не обсуждая это каждый спринт, а проводя большие внешние ретроспективы с участием стейкхолдеров и оценкой ими достижений команды. Это – тоже работающая практика.

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

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

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

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

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

Первое – это позитивное мышление им нацеленность на улучшения. Не «что было хорошо, а что плохо», а «что было хорошо, что нам мешало и как это устранить, и что можно улучшить». Второе – не стоит побуждать всех высказаться, люди стесняются, у них могут быть разные другие причины молчать. Лучше предложить каждому написать тезисы о том, что было хорошо, препятствия и идеи улучшений на стикерах и вывесить. Стикеры можно использовать разных цветов, в зависимости от вида тезиса и эмоционального отношения к ней: для позитива оценивать его вид – счастье, сюрприз и так далее; для препятствий – силу возмущения, для улучшений – накал желания. А потом обсудить по порядку: что хорошо, какие препятствия и как можно устранить, что можно улучшить. Обсуждение тоже можно начать не всем вместе, а в парах – это стимулировать высказаться всем, а не самым активным. Третье – в результате должен быть план улучшений, в котором выделены те, которые считаем наиболее важными и берем в работу на следующий спринт. Важность стоит определять не в обсуждении, а голосованием точками. Можно оценивать не только рациональную важность, но и эмоциональное отношение к идеям, тоже какими-то смайликами. Четвертое – идея изменений может быть сложной, и предполагать несколько шагов, как и в любой задаче, в том числе включать взаимодействие со стейкхолдерами для получения одобрения действий. А реализация может быть достаточно длительной. Их можно включать в общий список задач, или вести на отдельной Kanban-доске со своими фазами.

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

В IT частным случаем работы с препятствиями является работа с техническим долгом. Очень часто при реализации принимаются решение о том, что необходимо быстрое частичное решение по ситуации (костыль), а полноценное будет сделано позднее. А потом сделать хорошо забывают. Об этом есть даже сленговая шутка «IT– единственное место, где на костылях быстрее, чем без них». И полноценные решения не делают, но скрытые в коде костыли несут риск. И важно уметь донести его стейкхолдерам в томвиде, вкотором он покажется нестерпимым… То же относится и к другим идеям.

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