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

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

Довольно стандартные вещи, правда?

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

Понимание прошлого

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

Наш старый процесс управления невыполненными работами заключался в том, чтобы использовать эпики для «больших камней». У нас были бы эпосы на все темы, о которых мы хотели бы поговорить с другими подразделениями компании. Интеграционный проект? Это эпопея. Добавляете функцию? Эпично. Готовитесь к новому микросервису? Ага, эпично.

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

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

Меньше всего внимания уделили функциям, и в них даже меньше информации, чем в эпосах. Это были просто ведра с историями. Мы устанавливали их в начале проекта и добавляли истории по ходу.

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

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

Смена фокуса

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

И знаешь, что? Это действительно имело огромное значение.

Когда мы перешли на следующую встречу по планированию спринта, мы начали с этой функции. Мы сказали: «Это то, о чем эта функция, и это требования». Команда немного обсудила эту функцию, а затем перешла к историям.

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

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

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

И знаешь, что? И там мы получили такие же хорошие результаты.

Преимущества и результаты

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

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

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

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

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

Заключение

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

  • Обязательства улучшились. Команда лучше поняла, чего мы пытаемся достичь, используя краткосрочные ориентиры и стратегию их достижения.
  • Сотрудничество и общение стали лучше. Все согласились с этой стратегией, поэтому обсуждения и дебаты были продуктивными и интересными, и все мы были сосредоточены на достижении одних и тех же целей.
  • Масштаб проекта стало легче контролировать. Истории пользователей имели больше смысла, потому что у этой функции была четко определенная финишная черта. Эпос также получил более заметный конец.
  • Эффективность, продуктивность и моральный дух повысились. Это создало цикл успеха. Тесно ограниченные функции давали нам значимые цели, которые были в пределах досягаемости каждую неделю.

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