Delicta facti permanentis
Когда в продукте один придумавший его программист, ему не особо нужен таск-трекер. Он и так помнит, что сделал, что делает и что собирается делать. Но когда разрабов становятся двое и больше, нужно как-то отслеживать задачи. Можно, конечно, завести пробковую канбан-доску, но по мере роста команды, всё больше стен будет завешано этими досками, пока, наконец, их перестанет хватать и вы перейдёте на программный таск-трекер.
Но настроить команды, флоу и доски недостаточно. Нужна культура. О ней и поговорим.
В целом, ситуацию с тасками в таск-трекере можно значительно улучшить, применив всего две вещи:
- Нормальное формулирование заголовков и описаний тикетов.
- Запрет давать новые задачи в комментариях к тикетам.
О заголовках и описаниях
Неполные и некорректные описания в тикетах — настоящий бич современной разработки. На первый взгляд, кажется, что вы экономите время, но через некоторое время выясняется, что по старым тикетам решительно ничего понять невозможно.
Насколько должна быть полна постановка задачи в таск-трекере — вопрос дискуссионный, он сильно зависит от квалификации ваших разработчиков. Если она невысока, есть вариант включить в цепочку специального системного аналитика, который будет делать понятную детализацию, но современный рынок разработки не испытывает недостатка в специалистах, можно найти разрабов должной квалификации.
Очень плохая идея — сделать таск, состоящий из одного заголовка. И этим грешат многие операционные пиэмы. Дескать, разраб сам разберётся. Да, в конце концов разберётся, но на логистику этих разборок уйдёт много времени.
Каюсь, я делал подобные таски, когда работал администратором разработки в продуктово-заказной компании. Прилетел запрос на SQL-отдел — завёл его в таск-трекере, написал в описании, что разраб должен обратиться к внедренцу напрямую, тот всё расскажет.
Плохая практика. Ответственный разраб сам напишет постановку, но если не проконтролировать, изрядная часть таких тасков останется без описания. А если разраб безответственный, он может забить и на написание пояснительной записки. И тогда через несколько месяцев, когда в доработке вылезет баг, вас будет ждать сюрприз — в коде доработки придётся разбираться с нуля, никто ничего не помнит.
Для чего вам нужны нормальные постановки:
- Исполнитель может по ним дать оценку и спокойно пойти работать, никого не пиная вопросами, а сосредоточившись на задаче.
- Вы можете ждать, что в указанное время задача будет готова, а исполнитель вам не скажет: «В тикете надо было спросить Васю, но Вася был занят и не мог говорит, я жду».
- Когда бы будете делать ретро по проекту или будете приводить тикеты в порядок, вам не надо будет отчаянно морщить лоб, вспоминая, «А чего же тут имелось ввиду и почему на тикет с такой постановкой потратили неделю?!»
- И отдельно, такой подход очень помогает вдолгую. Бывает, всплывает вопрос: «А кто и когда эту фичу и в рамках чего добавил?» и вот тогда вы лезете в ваш трекер, находите постановку и – вуаля – достаете все данные, которые важны (кто, когда, что именно и почему сделал).
Короче, вы либо пишете нормальные полные описания в тасках, либо жёстко отслеживаете, чтобы системный аналитик или разработчик написали её самостоятельно. Иначе беда.
Прочтите ещё, пожалуйста, статью о правилах создания багов.
О комментариях к таскам
У вас может возникнуть соблазн вести по данному таску все активности в одном тикете. Туда же сливать вопросы и предложения от дизайнеров, чтобы тестеры складывали туда свои вопросы и туда же выкатывали перечни дефектов. В общем, не надо так, вы наплодите настоящую вавилонскую башню, которую потом будет очень трудно разбирать и анализировать.
Кроме того, топ-менеджмент очень не любит таски-помойки, в которые влито по триста-четыреста часов.
Если к задаче прилетели какие-то новые вводные, заведите новый тикет. В джире и большинстве других таск-трекеров можно создавать иерархии элементов. Пользуйтесь этой возможностью.
С багами тоже вопрос дискуссионный. Если они мелкие и их мало, в принципе, можно и в исходном таске. Но если тестер сгенерил тридцать-сорок замечаний, лучше под каждый завести отдельный тикет, будет проще отслеживать.
Резюме
- Делайте нормальные описания в тасках.
- Не плодите вавилонские башни в комментах к таскам.
Не то, чтобы это решило все ваши проблемы, но такой подход сделает работу с таск-трекером более комфортным.
