Возврат задач на доске в предыдущий статус ч. 2
Привет 🫂
В продолжение темы о возвратах в процессе разработки. В комментариях к посту про Time in Status я обещала краткий пересказ выступления А. Пименова на конференции Teamly на тему возвратов.
Итак, Алексей так же пропагандирует отказ от возвратов. Его аргументация частично схожа с моей, частично затрагивает области, о которых я не упомянула, частично отличается, так как мы с ним используем разные подходы.
Для начала стоит обозначить, что Алексей, как и я, говорим о блокерах, так как в случае простого дефекта, который можно исправить после завершения работы над задачей, надеюсь, не происходит движения назад. Если происходит, то картина еще более печальна, чем я себе могу представить. Чаще всего, все-таки, команды двигают задачи назад из-за появления каких-то дефектов/нехватки инвормации, которые блокируют дальнейшую работу или не позволяют завершить работу в связи с Definition of Done, то есть, все равно являются блокерами.
Аргументы Алексея: 1️⃣ При возвратах непонятно в какую задачу уже вложено больше усилий (читай: денег в терминологии Алексея), и, на основании вложений, какая из задач приоритетнее, то есть какую из них надо быстрее закрыть, если они обе находятся в одной колонке после возвратной операции. Схоже с п. 2 в моей аргументации, который я назвала “Надежда на память”.
2️⃣ Так как Алексей предлагает создавать блокер в колонке, в которой его обнаружили и идти каждому члену команды справа налево в поиске работы, так как приоритеты идут справа налево, то этот подход так же помогает вовлечь команду в весь процесс целиком, а не только в свою часть работы. Из плюсов, озвученных им: на ежедневных скрамах/синках люди заинтересованы сначала и до конца, а не только в своей части. Тут я предположу, что, возможно, это рабочий механизм - поиска задач справа налево, если у вас физическая доска. Как это реализовать в той же Jira, чтобы не потерять метрики и прозрачность, я не представляю. Его подходом, к слову, ни разу не пользовалась. И, да, во всех моих проектах люди работают 90% времени в своих колонках. Вовлечение в процесс я реализовываю через другие механики.
3️⃣ Наличие задач-блокеров позволяет накапливать знания и проводить анализ систематических проблем на длинной дистанции не только по области скопления проблем, т.е. по вероятности их возникновения в той или иной области, но и по длительности их решения, то есть по влиянию. Подходим к управлению рисками 😊 Это, конечно, можно сделать и в случае возвратов, но аналитика займет кртано больше времени, и после первой итерации вряд ли у кого-то будет желание повторять эту процедуру: найти все возвраты, найти причины возвратов, отсортировать эти проблемы, сгруппировать наиболее важные, проанализировать. И я искренне не завидую тем, кто тратит на это время, так как данная цепочка может быть сокращена до двух последних шагов: сгруппировать и проанализировать 🙃
01.10.2025
