Ценности ежедневных Scrum-встреч

Вот уже второй раз посещаю ретроспективу проекта одной из дружеских команд. Вчера был скорее зрителем в отличие от первой встречи, когда ребятам нужен был какой-то толчок в направлении света в конце туннеля, в который они себя загнали. Суммарно впечатление осталось хорошее, ситуация значительно изменилась в позитивном направлении и все это почувствовали, это радует. Формат «Что понравилось?/Что не понравилось?», который они использовали, видно, что уже начинает надоедать ребятам и скоро скорее всего через 3-4 спринта перерастет еще одну встречу, чтобы была. В первую встречу мне уже рассказали их проблемы и я вокруг этих проблем и проводил ретроспективу. На мой взгляд вышло неплохо, если техники, которые нашли на ней — помогли за один спринт показать общекомандное облегчение. Надеюсь через некоторое время также посетить ребят и дать им какую-нибудь новую технику проведения ретроспективы, ибо ретроспектива — чуть ли не самое важное мероприятие в Scrum-е с точке зрения самого Framework-а (но это уже тема отдельной статьи). Сейчас же хотелось поговорить про тот момент, который я заметил у ребят на обоих ретроспективах.

Одним из мероприятий Framework-а является ежедневный Scrum, когда вся команда в одно и тоже время в одном и том же месте собирается и отвечает на три вопроса:

• Что я делал с предыдущей встречи
• Чем планирую заниматься дальше
• Какие у меня есть сложности, проблемы, препятствия на пути к достижению цели спринта

Встреча должна длиться не более 15 минут и предназначена для того, чтобы синхронизировать информацию по спринту между всеми членами команды. По результатам встречи каждый член команды получает новую картинку о том, на каком этапе сейчас находится проект и какие шансы есть, чтобы завершить спринт законченным в отведенное время, обсудить проблемы и найти пути их разрешения. В теории все достаточно просто, но вот на практике уже начинаются некоторые сложности. Разберемся с этими сложностями и попробуем найти методы их устранения (! — я не буду рассматривать абсолютно все проблемы, т.к. это очень долго, а только те, с которыми столкнулась конкретная команда).

Синхронизация руководителя с проектом

После интервьюирования команды, мы пришли к выводу, что команда ходит на ежедневные встречи для достижения двух вещей: синхронизировать руководителя с тем, что они делают, а также обсудить некоторые детали по реализации. Сразу скажу, что вторым по Scrum на ежедневных встречах заниматься не стоит, для этого должны организовываться стихийные митинги для обсуждения этих технических вопросов. На ежедневной встрече можно озвучить информацию о том, что необходимо организовать такую встречу и может быть назначить время для нее (либо после встречи остаться нужным людям и обсудить все). Хотелось бы большее внимание обратить на вопрос синхронизации руководителя с проектом. Это конечно благая цель и очень хорошая, но дело в том, что всю ценность этого шага получает только руководитель, ни один член команды, кроме руководителя, не получает никакой ценности от этого мероприятия (ну разве что очередная галочка о том, какой я молодец). Получается так, что на мероприятие приходит 5 человек и каждый из них тратит свое время только на то, чтобы сделать хорошо одному единственному человеку.

Почему же это плохо на мой взгляд? Ежедневная встреча должна синхронизировать всю команду. Это значит, что каждый член команды должен не просто ответить на три своих вопроса и после этого вернуться в свой панцирь. Это означает еще, что они должны пропустить через себя то, что говорит другой, проверить как это сказывается на нем конкретно, на всем проекте в целом. Именно такая фильтрация создает возможность понимания того, что делает команда. С другой стороны это очень важно потому, что даже в команде, в которой у каждого появляется какая-то роль, — действия отдельных членов команды приводят в действие других членов. Тем самым, если Вася выполняет задачу А, то скорее всего это затронет и Петю. И если Петя будет пропускать через информацию о том, что Вася сейчас начал или планирует начать делать эту задачу, то он должен подумать о том, как это касается того, что делает Петя сейчас и как Вася ему может помочь своей работой или наоборот добавить дополнительных проблем. В такие моменты могут появляться такие предложения: «А давай ты отложишь эту задачу, т.к. я сейчас мне нужен 1 день, чтобы доделать движок, под который тебе все равно придется потом адаптировать твою задачу. И ты сделаешь работу один раз» или «Друг, это конечно классная задача, но в этом спринте мы должны были заниматься совершенно другими задачами» и так далее.

Какими методами можно решать данную проблему. Во-первых стоит сразу же обозначит, что ежедневная встреча — это не совещание, это мероприятие, которое нужно команде. Для этого можно попробовать поменять формат встречи, провести ее в игровой форме, например предложив какую-нибудь игру с бэклогом или диаграммой выгорания. Можно пару раз вместо руководителя попросить поприсутствовать на встрече другого человека, чтобы команда почувствовала, что это ее мероприятие, а не руководителя. Во время такой встречи — дать задание (каждый раз разному человеку) — быть секретарем для руководителя и узнать у каждого про его прогресс.

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

Не вытаскивайте меня из кокона

Частенько случается так, что ежедневные встречи переходят в формат планерки — каждый рассказал за себя, выдохнул и залез обратно в свою каморку гениальных идей. Да, программисты — творческие люди, которых не следует трогать, пока они творят. Но ежедневная встреча для того и предназначена, чтобы выбраться из мира иллюзий и узнать, чем же занимаются другие и как это может быть мне полезно, или для людей следующего уровня — чем они могут быть полезны другим. Уже повторюсь, но ежедневная встреча должна быть полезна тому, кто на нее пришел, если нет, то я бы предложил и не ходить на нее. Теперь более прагматичным языком. Чем может быть полезно узнать, что делают другие для меня.

Я буду знать, что кто-то будет трогать код, с которым мне нужно работать в ближайшие дни и у нас могут возникнуть конфликты при соединении наших решений. Лучше было договориться о том, как можно это сделать без проблем сейчас, чем опять тратить кучу времени на синхронизацию наших решений потом (а. договориться, что кто-то подождет другого, б. обговорить кто будет какую часть трогать, в. договориться о нескольких беседах промежуточных, когда обсудят свои текущие изменения).
Я буду знать, что кто-то готовит для меня большой пласт работы и буду готов к тому, что нужно будет потратить много времени на это. Например, если кто-то отвечает за слияние всех решений, то для него информация о том, что кто-то напрограммировал уже 500 строк кода и собирается еще столько же сделать, будет крайне полезной, чтобы остановить этого трудягу сейчас, а не заниматься чисткой авгиевых конюшен через пару дней.
Я увижу, что кто-то делает «левые» задачи и в конце спринта нам всем придется много потрудиться, чтобы довести спринт. Часто бывает, что в спринт попадают задачи, которые не согласуются с целью спринта. И если они съедают ресурсы, которые планировали потратить на достижение цели спринта. А это прямо ведет к тому, что всем придется напрягаться в конце спринта. Для этого нужно наших героев вовремя заставить вернуться к работе над нужными задачами, и не слышать такие фразы: «Я только сейчас понял, что мы половину спринта делали задачи, которые не должны, и я потратил кучу времени на то, что смотрел эти ср*ные Pull request-ы вместо того, чтобы заниматься своими задачами.
Я увижу, что кто-то уже сейчас сделал часть моей работы и сэкономлю мозг на том, чтобы не думать о том как это сделать, если Вася уже потратил кучу своего мозга.
Я предложу самую простую для начала практику, которая поможет начать борьбу с этим. Техника заключается в том, чтобы ребята по кругу договорились записывать друг за другом ответы на вопросы. Также каждый из записывающих должен следить за тем, чтобы его подопечный отвечал за свои слова. То есть, если Вася сегодня говорит, что «завтра я буду заниматься задачей П», а на следующий день говорит «я делал задачу А». Тут у Пети должен прозвучать вопрос: «А почему ты делал А, вместо П, как обещал». Вот тут можно будет узнать о проблемах, которые есть и попытаться их устранить, а не ждать ретроспективы, на которой мы каким-то образом узнаем об этой проблеме. В дополнении к этому бонусу каждый член команды будет вынужден пропускать через себя информацию и хочет он или нет, но менять картину всего проекта в своем представлении. А как результат мы будем вынуждены быть более в курсе проекта, нежели раньше, а значит думать о них и, что самое главное, через некоторое время начнем чувствовать к чему это приведет. Так, например, через некоторое время при фразе Пети «Я буду делать ту задачу по изменению АПИ для поиска», Вася будет думать «Опять, он же там такого «накодирует» опять» и быстренько поможет Пете не начинать работать над этой задачей, что сэкономит многим время, эмоции, а также моральный дух.

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