Гибкое планирование программного обеспечения: что делать, если классическое двухнедельное планирование спринта не работает для вашей команды

Dec 02 2022
Проблема Первого августа я покинул команду, с которой проработал более трех лет, и стал менеджером по продукту соседней команды под названием Catalyst. Catalyst была очень результативной командой; в нем было десять инженеров, восемь из которых были «старшими».

Проблема

Первого августа я покинул команду, с которой работал более трех лет, и стал менеджером по продукту соседней команды под названием Catalyst. Catalyst была очень результативной командой; в нем было десять инженеров, восемь из которых были «старшими». Инженеры». Catalyst была мощной командой.

Через две с половиной недели после того, как я присоединился к группе, кто-то поднял вопрос о наших планерках . Они не работали; вся команда согласилась. Основными жалобами были:

  • Наши встречи по планированию были очень длинными. Каждый понедельник мы все проводили час в зум-звонках (технически это были чередующиеся сеансы «планирования» и «уточнения» в рамках «двухнедельного спринта»). Они были длинными, не самыми увлекательными и сомнительно продуктивными.
  • У большинства наших заявок не было контекста; было неясно, как они связаны с большей целью.
  • У нас почти не было достаточно времени для изучения/планирования в малых группах. Люди жаждали занятий на доске, сессий из 3-5 человек, где мы могли бы действительно разобрать вещи и разработать/проектировать решения.

Что мы пробовали

Позже мы втроем в комитете по предложениям собрались вместе и рассмотрели проблемы. Мы обсудили реальное бремя усталости от планирования/совещаний, которое может навалиться на инженера и снизить его производительность на целый день (или больше).

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

Мы записали несколько утверждений о нашей новой системе, которые хотели быть правдой:

  • Мы не хотим привязываться к двум неделям. Нам нужна система, которая расширяется и сужается от недели к неделе в зависимости от того, сколько времени команде нужно спланировать на этой неделе.
  • Мы не видели полезного различия между планированием и уточнением.
  • Мы хотели, чтобы люди могли выбирать или отказываться от планирования в зависимости от своих личных потребностей, интересов или временных ограничений.
  • Мы хотели значительно сократить время, в течение которого все 12 из нас разговаривали по телефону, глядя на нашу доску Trello. Мы считали, что это утомительно для команды и не очень продуктивно. В комнате было слишком много людей , чтобы заняться реальным практическим планированием, которого мы так жаждали.
  • Мы хотели оптимизировать для рабочих сессий с участием 3–5 человек, на которых мы могли бы фактически анализировать тесты и решения и писать заявки.
  • Каждый понедельник одно и то же. Нет никакой разницы между «планирующим» понедельником и «уточняющим» понедельником.
  • Каждый понедельник в 10:30 мы все присоединяемся к 30-минутной встрече «Церемонии открытия».
  • У нас есть четыре других 30-минутных блока времени, запланированных каждый понедельник в течение дня: блок A, блок B, блок C и блок D.
  • На церемонии открытия PM и технический менеджер представляют последние новости, касающиеся более широкого контекста продукта и поставки. Любой, кто ведет данный тест или продукт, дает краткую информацию. Кто-то дает техническое обновление здоровья.
  • Затем группа решает, как лучше всего использовать четыре пригодных для использования блока в этот день . Какие проекты требуют времени на планирование?
  • Группы решают, когда состоится «Церемония закрытия»; либо во время одного из Используемых блоков, либо в Standup во вторник (если у нас закончатся блоки). Все делятся обновлениями в Slack и в общем документе планирования.
  • Проекты могут использовать блоки в качестве времени для планирования в небольшой группе. Небольшие группы обсуждают цели проекта, разбивают задачи на подзадачи и вместе пишут билеты.
  • Церемония закрытия занимает всего 10–15 минут. Каждая небольшая группа информирует команду о том, что они сделали.
  • На церемонии закрытия команда просматривает любые предстоящие сроки, которые будут информировать о приоритетах заявок.
  • Над чем мы работаем? Мы проверяем тесты и т. д., над чем мы работаем
Расписание типичного понедельника в олимпийском планировании

Что нам понравилось в этой идее

Было несколько вещей, которые нас особенно взволновали в связи с этой новой идеей.

  • Процесс был совершенно эластичным ; в некоторые недели, когда у нас было много работы по планированию, у нас было 2,5 часа времени планирования, уже заблокированных в календаре. В другие недели, когда у нас уже было много всего, мы могли устроить 15-минутную регистрацию на церемонии открытия, а затем закончить. Инженеры могли сразу приступить к работе.
  • Мы резко сократили количество больших совещаний и оптимизировали рабочие сессии для 3–5 человек.
  • Мы уполномочили себя в будущем решать, что нужно планировать. Блок времени может быть использован для обдумывания голубого неба, составления плана теста или разговора о техническом долге.

Компания Catalyst в течение 3 недель пробовала планирование в олимпийском стиле, а затем провела еще один ретроспективный анализ, чтобы понять, что работает, а что нет. Хотели ли мы сохранить олимпийское планирование?

Отзывы были исключительно положительными. По всем причинам, которые мы предполагали, команде нравилось планирование в олимпийском стиле гораздо больше, чем то, что мы делали раньше.

Самыми большими проблемами, с которыми люди сталкивались, были:

  1. Если человек пропускал сеанс планирования интересующего его продукта, после этого он чувствовал себя полностью потерянным и не знал, как подключиться снова . инженеры, чтобы наверстать упущенное.
  2. Если человека интересовало все, что мы делаем, это приводило либо к сложному выбору, либо к очень долгому понедельнику совещаний.
  3. Если бы мы не были очень точны в проведении встреч в нужное время и с правильными телефонными ссылками, людям было бы очень трудно найти встречу по планированию.

Чтобы решить проблему №1, мы отказались от концепции церемоний закрытия. Вместо этого мы решили поддерживать работающий документ «Олимпийское планирование», в котором каждую неделю отслеживали, какие блоки должны использоваться для каких тем. Мы ввели новое правило, в котором говорилось, что:

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

Уроки выучены

В целом Catalyst считает планирование в олимпийском стиле огромным успехом. Гибкий процесс, оптимизирующий планирование рабочих сессий, — это именно то, что сейчас нужно Catalyst .

Кто-то спросил в нашем недавнем ретро: «Должны ли мы заново изобретать больше наших еженедельных ритуалов таким же образом?»

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

Меня больше всего восхищает то, как мы претворили в жизнь ценности Agile -манифеста, не слишком зацикливаясь на общих практиках , которые смешались с самой концепцией Agile-разработки.

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

Если вам это покажется интересным, я бы посоветовал любой команде, которой не нравятся их ритуалы планирования, попробовать планирование в олимпийском стиле; но это не совсем то . Суть вот в чем: мы все должны постоянно размышлять о наших процессах и спрашивать себя: «Это работает на нас?»

Гениальность Agile не в механических процессах. Дело в том, что это побуждает нас быстро пробовать большие смелые вещи, зная, что ничего страшного не произойдет, пока вы можете быстро подумать о том, работает ли эта вещь (и изменить ее/вернуть обратно так же быстро, если это необходимо). Быстрая итерация, основанная на быстрых петлях обратной связи. Резкие изменения пугают только в том случае, если вы не можете быстро изменить их/вернуть обратно.

Мы все еще занимаемся планированием в олимпийском стиле! Это будет оставаться нашим любимым способом планирования, пока не перестанет им быть.