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

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

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

Ссылки на описания групп бордов для тех, кто вернулся после прочтения

• Задачи в работе

• Обработка входящих

• Планирование

---

Проблема

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

Косвенно подтверждает наличие проблемы регулярное появление тематических статей на просторах хабра. Одни, обессилев, решаются сбрасывать таски из бэклога в магический статус «не смотри на меня». Другие проводят багатоны-субботники, чтобы хоть как-то разгрести дно неуправляемого бэклога. Третьи смирились и с безразличным видом медленно скролят в условной JIRA плоский километровый список из накопленного, с надеждой уж в этот раз наверняка отыскать среди шелухи задачку, за невыполнение которой могут и уволить.

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

С набором хотя бы в сотню задач не справляется в лоб ни JIRA, ни Redmine. Ни YouTrack, ни, прости господи, Trello. Все они с решением проблемы большого пула задач справляются не лучше Todoist'а или борда в Miro. Новоиспечённые «убиваторы JIRA» в рекламных статьях кроме перекладывания прямоугольников из одной вертикальной полосочки в другую ничего не предлагают.

Победитель этой рубрики, — «у нас даже верхняя плашка синяя, как в JIRA».

Словно квест про стикеры и столбцы всё ещё никем не решён и возможность двигать что-то из колонки в колонку и впрямь серьёзное конкурентное преимущество.

Атрибут задачи «приоритет», несомненно, поможет рассортировать бэклог в пару десятков задач. Но если у вас только «срочных / major» несколько десятков, то еще более срочную задачу придётся делать «критической / critical». Когда уже критических накопится несколько десятков, то, чтобы выделить среди них совсем-совсем критически срочно-важную, придётся заниматься уже очень странными делами.

Задачи, кроме признака срочности, делятся ещё и на важные и неважные (квадрант Эйзенхауэра). Хотя бы при сочетании этих двух характеристик можно было бы говорить о фактической приоритизации задач. Но известные системы «управления» задачами ничего подобного не предлагают. А в скалярном атрибуте «приоритет» особенно не развернёшься.

Известные инструменты

На текущем месте работы применяется JIRA Server, но такой же подход я применял раньше на YouTrack. Также приходилось работать с Redmine, TargetProcess.

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

Кроме того:

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

• или любой запрос (как для swimlane в JIRA);

• то же можно сделать и для горизонтальных плашек; в пересечениях будет INNER JOIN — с вариациями можно заиграться;

• колонки возможно раздвигать в ширину или сдвигать (с ума сойти!);

• если колонку свернуть, то крупные прямоугольники задач превращаются в набор маленьких довольно милых квадратиков, получается узор, чем-то напоминающий интерфейс старой утилиты дефрагментации Windows с бегающими разноцветными квадратиками же;

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

Такой вот rocket science, да... И прилично отрисовано. И реализовано пятнадцать лет назад. Что с лицом, Atlassian?

Инструмент хоть и стоит особняком, сделан прилично. Но там есть странности с менеджментом, а головной сайт начал неистово обрастать Agile-инфоцыганщиной, как мне это видится. И бесплатного тарифа больше нет. Попытка принуждения к переходу на платный показалась не совсем приличной. А когда пару месяцев назад зашёл на сайт, часть информации вовсе оказалась в поддомене IBM.

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

Типовые баг-трекеры болеют одной болезнью: инструментами этими обзаводятся с целью усмирить и упорядочить большой объём задач... и ни один из них не предлагает абсолютно никакого решения этой проблемы.

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

• «Волобуев, вот ваш борд!»;

• Сцена из фильма «The Golden Child» с Эдди Мёрфи, где тот бросает монетку в черноту пропасти и ждёт, когда же монетка, наконец, звякнет, достигнув дна. Над пропастью горит надпись: «А это ваш бэклог! Все задачи здесь, пользуйтесь, как удобно... Удобно же?».

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

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

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

Применимость предлагаемых практик

Рассматриваемое решение хорошо себя показывает в условиях, когда:

• у вас небольшой коллектив из 5–10 человек;

• вы работаете не по каскаду;

• на вход хотя бы изредка залетают задачи сомнительной полезности и в невнятных формулировках;

• отдельных людей для управления задачами пять дней в неделю нет и не предвидится;

• обнаруживать в свалке задач бэклога что-то полезное и актуальное стало проблематично.

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

Подход может вам не подойти, если:

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

• в вашем бэклоге «семнадцать с половиной» задач;

• ваши процессы не обладают никакими признаками Agile-подходов или вы называете эджайлом полное отсутствие правил, ролей, соглашений;

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

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

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

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

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

Также хотел бы отметить, что управление задачами — это ещё не управление проектом и продуктом. Ничего кроме управления задачками в таск-трекере, описанное в статье решение не предлагает. Остальное — отдельные темы для разговора.

Словарь

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

Проект
Здесь имеется в виду общее пространство, в котором нужно управлять набором задач конкретной команды. Проектная у вас деятельность (в терминах PMBOK), текучка или продукт, MVP и прочее — не имеет значения. Слово «проект» будет употребляться в его вольной интерпретации.

Баг-трекер
Он же таск-трекер и просто трекер. Инструмент учёта задач, управления задачами.

Задеклайнить (decline)
И кэнсельнуть (cancel). Отменить задачу, закрыть без выполнения.

Таска
Отдельная задача, зарегистрированная в трекере.

Борд (board)
Доска с вертикальными столбцами и горизонтальными плашками, на которой отображаются задачи в таск-трекере с учётом заданного фильтра и правил группировки.

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

Квик-фильтр (quick filter)
В JIRA это «быстрые фильтры» — дополнительные предопределённые пользователем наборы условий, предикаты, которыми можно отфильтровать задачи на борде или в отчёте, привязанном к этому же борду; отображаются над бордом в виде гиперссылок, например, квик-фильтр «Созданные мной» из всего множества задач на борде оставит только созданные текущим пользователем.

---

Цели

Перед решением по управлению задачами ставлю простые цели:

• важные задачи не должны теряться;

• задачи, на которые здесь и сейчас незачем тратить время, не должны отнимать нисколько времени.

Решение

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

В основе предлагаемого решения лежат следующие рассуждения, тезисы:

• чтобы плохая^* задачка не мешалась, её нужно из перечня хороших задач убрать;

• отменить или удалить такую задачу некорректно — сегодня неготовая и плохая, через месяц она может стать задачей первого приоритета;

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

• среди хороших задач могут быть несвоевременные — таковых желательно отложить в сторону, чтобы не мешали работать с хорошими и своевременными;

• хороших и своевременных всё равно останется много, среди них важно выделить наиболее ценные; при запаздывании по срокам важно суметь выявить наименее ценные задачи, которыми было бы уместно пожертвовать;

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

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

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

Лейблы выбраны, потому что их редактирование по умолчанию доступно каждому пользователю трекера. В некоторых реализациях лейблы редактируются на уровне проекта, и пользователям доступен только предопределённый набор, но в JIRA и YouTrack, это свободно редактируемый атрибут, набросать в поле Labels задачи можно всё что угодно. Привилегиями администратора обладать необязательно. Для создания новых бордов дополнительные права могут понадобиться, но всё ещё не админские. А сохранённые фильтры, как правило, тоже дозволяется создавать кому угодно.

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

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

Перейдём к описанию решения.

Задачи в работе

▍ Personal Kanban

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

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

Здесь лучше выбрать группировку задач по исполнителю и добавить несколько полезных квик-фильтров.

Фильтры по лейблам не применяются. Если задача в работе, то она в работе.

▍ Squad Kanban

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

Статусы воспроизводить в колонках один к одному здесь уже лишнее. Достаточно показать:

• ближайшие планы (To Do);

• что в работе (In progress);

• допустимо выделить тестирование и прочие проверки, где реализованные задачки могут застрять (Verification);

• готовность к релизу (Ready For Release), если вы не катите, как на санках с горки, сразу в прод;

• ценность доставлена потребителю (Done).

На борде хорошо видна суммарная загрузка коллектива. Свимлейны не нужны — понять общую картину горизонтальная группировка здесь только помешает.

Фильтры по лейблам не применяются.

▍ Open Bugs

За багами очень желательно следить отдельно, выделять из общего набора задач в работе и готовых к тому, чтобы быть взятыми в работу. Цветовая индикация на Personal Kanban и других бордах отчасти в этом помогает, но это, что называется, несерьёзно. Нужен отдельный борд.

Здесь тоже все статусы в колонках не нужны, про баг достаточно оперативно понять, что он:

• ещё не взят в работу (To Do);

• взят в работу, но решение не найдено или не проверено (In progress);

• фикс готов к публикации (Ready For Release);

• проблема устранена (Done).

Группировка нужна по приоритетности бага. Имеет смысл выделить:

• Fix ASAP — срочные и критичные баги;

• Fix Next — вторые в очереди; серьёзные, но не смертельные баги;

• Fix If Time — чиним, если не осталось серьёзных багов, или у работника образовалась пауза для небольшой задачки.

Вычисление этих приоритетов — отдельная история. Некоторые инструменты (TargetProcess) предлагают в поле «приоритет» бага выбрать один из перечисленных выше вариантов из выпадашки. Это лучше, чем в JIRA, но я с таким подходом не согласен. Хотя для начала сойдёт и так.

Видеть в одной выпадашке разные характеристики бага «critical» и «blocker» для меня вовсе нонсенс. Один баг блокирует важную функциональность и массово, другой — вторичную и для небольшой доли пользователей. Почему у них один «приоритет» со значением «blocker»? Или второго блокера нельзя в такой ситуации отметить как «blocker»? Да, можно поиграть в слова, сказать, что «blocker» — это когда выявленный QA баг блокирует релиз. А найденный пользователем серьёзный баг, значит, не может быть «blocker»? Мысль интересная.

Пример фильтра для свимлейна Fix ASAP: labels in (bug:blocker) AND (labels in (bug:mass) OR priority in (Critical)) OR labels in (bug:must_have_feature) AND priority >= Major. Отбираются массовые блокеры и баги с задранным вверх приоритетом.

Фильтры по лейблам: если баг-репорт требует подробностей от автора, значит, в To Do этому багу рано отображаться. Ищите в Unclear Tasks (борд описан ниже по тексту). К багам в работе фильтр не применяется — фактическую активность нужно видеть.

Обработка входящих

▍ Funnel

Воронка — центральный элемент системы диспетчеризации поступающих задач.

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

Может показаться, что это неподъёмная сверхзадача, а идея постоянно перебирать «пару-тройку сотен задач», мягко говоря, странная. Штука в том, что каждая задача преодолевает воронку единожды. И «пара-тройка сотен» — это пример объёма бэклога, а не число поступающих задач в единицу времени. Если целый год собирать по одной новой задаче в день, то в конце получится бэклог в 365 задач. Однако в день обрабатывать весь этот год приходилось бы аж по одной-единственной задаче — объём работы, при котором можно и заскучать.

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

Если на борде есть несколько свимлейнов, каждый со своим фильтром, то задача оказывается в одной или другой горизонтальной группе по такому алгоритму:

• задача соответствует критериям первой группы? да — отображается в этой группе, нет — проваливается в следующую вниз по порядку;

• соответствует критериям второй группы? да — остаётся здесь, нет — проваливается в следующую. И так далее. Работает в точности как воронка.

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

Структура воронки

Чтобы задача сама сообщила, какие действия над ней требуются, ей нужно оказаться в одной из групп. Каждая группа обозначает как бы очередь в конкретный кабинет поликлиники для прохождения ко́мплексного медосмотра. Если задачка прошла первого врача, то оказывается в очереди к следующему. Если была признана приболевшей, то улетает в санаторий, и пока не поправится больше никого не тревожит. Даже для «только спросить».

Этапы прохождения задачи через воронку:

1. Первичный осмотр, Triage новой задачки без лейблов. Решением будет либо признание задачи недостаточно готовой к принятию в работу и сброс её в отстойник Unclear Tasks, либо включение задачи в ближайшую покер-сессию для оценки воспринимаемой значимости (ценности).

2. Оценка Value. Проводим асинхронную покер-сессию, ведущий завершает и просматривает выставленные оценки^*. Если часть команды затруднилась дать оценку или оценки слишком разошлись — это повод вернуть задачу на уточнение, а не двигать в разработку.

3. Линковка. Что задачи, что баги без контекста очень неудобны в управлении. Крайне желательно при обработке входящей задачи обвешать её семантическими связями. Задача может относиться к эпику или к другой задаче на похожую тему (линк «relates»). Баг может быть зарегистрировать для исправления версии продукта, в которой возник (линк «fixes»). Если баг породила недавняя задача, то желательно связать и с ней (линк «caused by»).

4. Указание специализации. Добавляем в описание задачи лейблы, обозначающие необходимые компетенции для её решения. Попутно есть шанс осознать, что задача нуждается в декомпозиции, если тэгнуть пришлось слишком много языков, подсистем, инструментов. При необходимости в декомпозиции, задача улетает в Unclear Tasks, иначе включается в ближайшую покер-сессию для оценки воспринимаемой сложности.

5. Оценка Effort. Проводится аналогично сессии с оценкой Value. Если часть команды затруднилась дать оценку или оценки слишком разошлись — это снова повод вернуть задачу на уточнение постановки. Слишком высокая оценка сложности — причина для декомпозиции и перепроведения через воронку уже более смартовых, атомарных задач.

6. Выбор приоритета: повыше или пониже. Средний приоритет считаем отсутствием принятого решения. Атрибут «приоритет» далее применяется для перетекания задачи из одной группы фактической приоритизации в другую при пограничных сочетаниях оценок значимости и сложности.

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

* — значения Value и Effort мы измеряем в T-Short sizes.

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

Для багов воронка слегка отличается: первичный осмотр должен закончиться либо пометкой о том, что от автора нужны подробности, либо навешиванием лейблов с характеристиками бага. В характеристиках (лейблах) указываем:

• степень влияния бага на функционал — блокер или нет;

• массовость — проявляется у большинства или у небольшой группы пользователей;

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

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

Пример коллекции лейблов

Для тасок и фич
need:clarification — «вы нам прислали что-то на эльфийском»
need:specification — «мысль понятна, но что конкретно?»
need:proof_of_concept, need:research — задачи-исследования без чёткой постановки
value:xs, value:s, value:m, value:l, value:xl — оценка значимости, Value
effort:xs, effort:s, effort:m, effort:l, effort:xl — оценка сложности, Effort

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

Agile-плагин для JIRA, с помощью которого проводим покер-сессии, умеет сохранять выбранный вариант оценки в заданное числовое поле карточки задачи. И, к слову, умеет показать букву (T-Short Size), а сохранить цифру (Story Points, Value Points). Для числового представления оценок мы выбрали довольно распространённый вариант — числа Фибонначчи. Но измерения «в попугаях» — не тема данной статьи.

Для багов
need:debugging_details, need:investigation — непонятное
bug:blocker, bug:has_workaround, bug:enhancement — степень влияния, Impact
bug:mass, bug:individual — массовость, Reach
bug:loophole — найден способ обходить ограничения
bug:must_have_feature — повышалка приоритета любого бага
effort:xs, effort:s, effort:m, effort:l, effort:xl — оценка сложности, Effort

Баги в оценке Value не участвуют — у них вместо этого Impact. А в оценке Effort участвуют вместе с тасками. Impact рассчитывается налету с учётом навешанных лейблов.

Специализация
Здесь у каждой команды будет свой набор. У нас это, например:
code:csharp, code:tsql, code:js, code:tsql — на чем кодить
cicd:teamcity, cicd:octopus, cicd:jira, cicd:sonarqube — где ковыряться или с чем интегрироваться по REST API
docs:guide, docs:rules — иногда нужно и для людей буквы писать

Возврат в Funnel
need:actialization — явный сброс в актуализацию/груминг.

need:triage, need:estimation, need:linking, need:prioritezation — тоже были задуманы для явного возврата на определённый этап воронки, но де-факто не применяются. Проще оказалось снести проставленные лейблы, признанные некорректными, или урегулировать расхождение на месте.

Сам борд воронки выглядит не слишком интересно, настройка свимлейнов — это прямое отражение условий прохождения этапов воронки.

Для плашки Estimation needed, к примеру, используется отрицания фильтра NOT labels in (need:estimation) AND labels in (effort:xs, effort:s, effort:m, effort:l, effort:xl). То есть с учётом отрицания получается: либо стоит пометка для явного захода в повторную оценку, либо в лейблах не отмечен ни один из вариантов оценки. Остальные фильтры такие же прямолинейные.

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

И, к слову, как видно на скриншоте, отсекать совершенно не нужный на многих бордах блок Everything Else в JIRA всё ещё невозможно.

Теоретическое обоснование

Подход не такой уж кастомный, его составляющие далеко не ноу-хау:

• Воронка — Upstream Kanban;

• Набор лейблов и атрибутов, которыми должна обрасти задача — Definition of Ready;

• Сбрасывание зависших задач в актуализацию — Time Guillotine.

Поступающие задачи пропускаем через воронку (Funnel), ведём по Upstream-потоку, доводим до состояния готовности к принятию в работу (Ready To Go). Потом случается планирование и момент принятия обязательства (Commitment Point) по исполнению задачи, лежащей в бэклоге. И стартует путешествие задачи по Downstream-потоку от разработки к релизу.

На просторах Хабра тоже попадаются статьи, которые оперируют термином «воронка», например вот эта. В статье рассуждения построены вокруг прогнозирования сроков выполнения задач, но для этой цели также необходимо выстроить управляемые Upstream- и Downstream-потоки. В конце упомянутой статьи приводится краткий сценарий проведения аудита имеющихся обстоятельств и построения плана преобразований.

▍ Unclear Tasks

Отстойник всякой мути. Сюда улетают задачи, которые «не должны отнимать нисколько времени». И всё, что нуждается в уточнении, перепроверке, прочих дополнительных действиях для доведения задачи до состояния, близкого к SMART.

Фильтр — отбираем всё с лейблами про непонятность. Группировка — по характеру непонятности. Needs detail of clarity, Needs more focus, Needs debugging details — заходим на StackOverflow и смотрим, как это делается. Один в один воспроизводить незачем, поскольку сценарии возникновения задач сильно разные, но почерпнуть вдохновение можно.

Борд может помочь в формировании пула задач для очередного груминга. Давно валяющиеся здесь без движения — кандидаты на отмену.

Планирование и отслеживание

▍ Ready To Go

Задача, прошедшая через воронку, и не свалившаяся в отстойник Unclear Tasks, готова к принятию в работу. Такие задачи можно отобразить на одном борде и отсортировать по важности, сложности, срочности.

Колонки, отвечающие за статусы, здесь абсолютно не актуальны — отображаемые задачи лежат в бэклоге. Но JIRA по-другому не умеет. Хотя здесь бы очень удачно смотрелся концепт квадрантов с пересечениями Value-Effort. Имеем, что имеем, поэтому снова свимлейны.

Группы определены следующим образом:

• Low hanging fruit — лёгкие и ценные задачи;

• Grand prix / Major target — ценные, но сложные;

• Chicken feed / Afterwards have a look at — не сильно сложные, но и не особо нужные;

• Dead ducks / Discuss before assignment — не бессмысленные, но со слабо выраженной ценностью, притом относительно сложные.

Здесь можно учесть родное поле трекера «Приоритет», чтобы была возможность принуждать задачки к переходу в соседнюю группу. Оценили как Chicken feed, но начальство настояло на срочности — оценки не меняем, но задираем приоритет до Critical. Сомнительной ценности задачка оказывается в топе.

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

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

Готова к работе? Добро пожаловать на борд!

Дополнительный фильтр: если задача находится в эпике, то эпик должен быть в работе. Набрасывать задачи в эпик наперёд — нормальное занятие, но хвататься за эти задачи раньше времени совершенно незачем. Формулировка у такого фильтра не самая очевидная: "Epic Link" is EMPTY OR "Epic Link" is not EMPTY AND issueFunction in issuesInEpics("statusCategory = 'In Progress' and filter = <Id базового фильтра задач вашего проекта>")

Когда у задачки появляется исполнитель (Assignee), с этого борда её можно убирать. Из Ready она явно продвинулась в Go.

Для удобства сто́ит создать несколько квик-фильтров по специализации. Так, любой желающий найти себе небольшую таску, допустим, по C# или по написанию документации, сможет это сделать в пару кликов. И отвлекать менеджера для этого не придётся. Все готовые к работе и свободные таски отображаются на борде Ready To Go, в нём нажимаем квик-фильтр с интересующей специализацией, далее наблюдаем ответ на свой вопрос. Вот тебе посложнее, вот попроще, вот поважнее, вот второстепенные. Бери да делай.

▍ Epic progression

Задачи часто объединяются в эпики. По мере реализации задач хочется понимать, насколько продвинулись к закрытию эпика.

Колонок много не требуется, подойдёт тот же набор, что в Squad Kanban. Группировка — по эпику. Просто и наглядно.

Фильтров по лейблам нет. Если задача мутная, то её незачем включать в эпик.

У бордов JIRA есть опция «скрывать завершённые задачи через N недель после закрытия». В прочих бордах это может быть уместно, а здесь помешает и снизит наглядность. Опцию рекомендую отключить, но придётся сделать чуть более замороченный общий фильтр борда, чем обычно. Если закрытая задача относится к незавершённому эпику, то пусть отображается. А если эпик завершён, то в просмотре не нужен ни он сам (горизонтальная плашка), ни задачи из него.

Некоторые трекеры (но не JIRA) способны показать, сколько задач в эпике всего и число завершённых. Это удобно.

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

▍ Initiatives

Раз эпики существуют, значит, ими нужно управлять. Жизненный цикл эпиков не обязан быть таким же сложным, как у тасок. Часто выделяют всего три статуса: To Do, In Progress и Done. Потребности в наглядности и перетаскивании из одной колонки в другую — те же, что у тасок и багов. Однако ни один рассмотренный выше борд эту потребность не удовлетворяет.

В управлении задачами можно выделить сущность Initiative или направление деятельности. Эпики живут не в вакууме, не ради самих себя, они направлены на улучшение конкретных продуктов, на развитие автоматизации одного или другого направления бизнеса. На решение класса задач. Иерархически эпики могут и не быть связаны, но по контексту их часто уместно объединить, поскольку прямо или косвенно каждый эпик относится к какому-либо направлению деятельности, вектору приложения усилий команды. Поэтому удачно будет такие эпики объединить общей надсущностью. Направления в отличие от эпиков как раз бесконечные. Эпики бесконечными делать нехорошо — они должны быть ограничены во времени, когда-то начинаться и однажды заканчиваться.

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

Фильтры по лейблам не актуальны.

Роадмап имеет смысл формировать и поддерживать в контексте либо борда Initiatives, либо Epic Progression. Направления деятельности на роадмапе никак не отображаются (они же бесконечные), но могут быть использованы для группировки эпиков по аналогии с группировкой на борде.

---

Подведение итогов

Семь бордов

Как обещал, семь бордов в помощь небольшой команде со средним бэклогом в пару сотен задач:

1. Personal Kanban.

2. Squad Kanban.

3. Open Bugs.

4. Funnel.

5. Unclear Tasks.

6. Ready To Go.

7. Epic Progression.

8. Initiatives.

Я сказал семь? Восемь.

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

Ну и парочкам других бордов тоже нужны не колонки, а иная механика, так что и они не совсем «борды».

С подобным набором бордов, вспомогательных квик-фильтров и базовыми диаграммами из Agile-плагина к JIRA вполне реально достаточно легко и непринуждённо справляться с потоком задач, бэклогом среднего размера в одиночку.

Комментарии

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

«Лучше день потерять, потом за пять минут долететь!» — та самая история.

Система получается незабюрократизированная, вполне в духе Agile. Где лейблы и фильтры для человека, а не человек для тыщи обязательных полей и вечно несбалансированной диаграммы Ганта. Отдельно хотел бы обратить внимание, что в предлагаемом подходе ни в каком сценарии управляющему задачками не приходится бороздить на утлой лодчонке вечно штормящий океан из триллиона задач. Полный список не вываливается на пользователя таск-трекера нигде. Его можно найти, если сильно захотеть, но причин регулярно скролить всё снизу доверху при такой организации работы не существует.

Если история c лейблами показалась слишком сложной, надуманной, но борд в команде фактически один, и очевидна проблема с потерей фокуса управления, то предложил бы добавить в коллекцию хотя бы Open Bugs и Epic Progression.

Выбрать лейблы про неудачную формулировку задачи может помочь опыт StackOverflow — ребята на этом, как говорится, собаку съели. Вот так внезапно в очередной раз вышли на Джоэля Спольски. Также рекомендую побродить по репозиториям популярных продуктов на GitHub, посмотреть, какую систему лейблов там применяют для управления баг-репортами, фича-реквестами, релизами.

В дополнение к бордам имеет смысл также завести дашборды с гаджетами: счётчики, графики. На некоторые фильтры можно подписаться и регулярно получать уведомления от JIRA при попадании задач под условия этих фильтров.

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

Успехов в управлении!

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

1

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

Сколько у вас уйдёт времени, кликов, сколько нужно будет задать вопросов кому-то, кроме вас самого, чтобы ответить на вопрос программиста и дать номера пары-тройки подходящих под описание задач?

Семь Бордов: открываем Ready To Go, тыкаем квик-фильтр «code:js», смотрим в блоки Chicken Feed, Low Hanging Fruit. Других людей тревожить не нужно. Можно показать JS-нику, как вы это делаете, и попросить далее не беспокоить в таких вопросах даже вас.

2

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

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

Семь Бордов: открываем Open Bugs, сразу видим, что с ASAP-багами. Здесь же видим, нет ли багов, заведённых под эпик, подходящий под описание. Тыкаем квик-фильтр, если баг относится к понятному компоненту. Других беспокоим, только если вообще ничего похожего не нашли.

3

Менеджер проекта/продукта, которому неинтересно копаться в тасках, спрашивает о прогрессе по двум эпикам. Что завершено, нет ли каких блокеров.

Как долго, из скольких мест вы будете собирать эту информацию, сколько людей придётся задействовать, сколько поисковых запросов выполнить?

Семь Бордов: открываем Epic Progression, наблюдаем готовый ответ на заданный вопрос. Объясняем менеджеру, как сюда зайти, как применить квик-фильтр для обнаружения блокеров. Предлагаем перестать вас беспокоить по таким вопросам.