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

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

Начни с базы

Ключевые понятия: проект (project), задача (task), спринт (sprint), эпик (epic), исполнитель, асайн (assign), эстимейт (estimate)

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

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

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

Спринт - двухнедельные промежутки разработки ПО по технологии Scrum. Это сделано для того, чтобы процессы, запущенные в рамках проекта, удобнее было планировать и отслеживать выполнение. 

Эстимейт - это количество времени, за которое, как полагает ваш тимлид, вы справитесь с той или иной задачей. Ваш тимлид верит в Вас - не огорчайте его.

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

Принципы работы в Jira

Как мы  с вами уже поняли, Jira - это не только заведённые задачки, но и планирование и отслеживание прогресса всего проекта. Следует отметить, что планирование в целом включает в себя не только разработку, тестирование и прочие айтишные прелести, но и выполнение определённых обязательств перед конечным заказчиком проекта. А заказчик может поинтересоваться статусом своего проекта примерно в любое время. И вашему ПМу придётся примерно в это же самое любое время отвечать на вопросы заказчика. При этом, если команда чётко понимает и отрабатывает принципы работы, то вашему ПМу остаётся только открыть программу и по статусам задач рассказать всё заказчику. Таким образом, мы возвращаемся к первому тезису: Ваш ПМ не должен нервничать.

Изучи эпик

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

Работаем по принципу: глупо стесняться задавать вопросы.

После того, как договорённости согласованы, ПМ и тимлид декомпозируют эпик на подзадачи. Перед тем, как приступить к задаче, необходимо изучить полностью эпик, понять его структуру и сформировать в голове картину: "Что после чего идёт и как это всё будет" - именно так все джуны эволюционируют в мидлов. И не надо бояться этого процесса. Вспомните, как в школе мы писали сочинения согласно составленному плану. Только в школе нас заставляли сначала самому писать план, а потом по нему уже - сочинение. Здесь даже проще: план вам уже составили, надо лишь ознакомиться.

Столбики на доске (To Do, Ready For Build): что происходит?

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

10 заповедей работы с Джирой

1. Ваш ПМ не должен нервничать

2. Перед началом работы изучи эпик

3. Берёшь задачу - ставь себя исполнителем

4. Не затрекал часы - не получил зарплату

5. Бага без контекста - не бага, а претензия.

6. Овертаймы только вредят.

7. Номер задачи = название ветки в гите

8. Чёткость работы - залог высокого качества.

9. Метки, фильтры, эстимейт повышают джуну грейд.

10. Без ТЗ результат традиционный. 

Читай ТЗ!

Давайте сначала разберёмся: что такое "Техническое задание" и зачем оно вообще? Непосвящённым может показаться, что документация нужна только для руководства, а создание этой самой документации только наводит лишнюю суету, и зачем она вообще нужна: и суета, и документация. Но ведь когда в юности мама нам писала список для похода в магазин, что это как не техническое задание проекта: есть план, есть объём работы, есть порядок выполнения задач, есть смета проекта и сроки: "Чтобы через час был дома!"

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

Отличительной чертой проактивного специалиста, желающего развиваться, является стремление именно к личностному росту. В статье про хронофаги мы уже писали про раздражающий кейс: "Тебя что, в гугле забанили? - Нет, я просто решил, что у тебя спросить будет быстрее". Да, старшие товарищи могут знать немного больше, но мы просто уверены, что для того, чтобы знать больше, они тоже читали ТЗ, гуглили статьи и прочие полезные штуки.

Не копипастим ТЗ в Jira

Есть такое понятие как "ключевые слова". Разработчик грейда J-1 должен уметь искать, понимать и оценивать прочитанный текст. Если техзадание проекта состоит из 100 страниц текста и схем -  сделайте корректную выборку по ключевым словам в Джиру, чтобы разработчику не пришлось тратить на это время и ресурсы. 

Хорошим тоном для любого технического задания будет отдельный раздел, посвящённый юзкейсам и юзерстори. Так вот, у талантливого аналитика юзерстори могут занимать до 30% от объёма технического задания. А именно юзерстори дают полное представление о поведении приложения, в них могут войти такие нюансы, которые не всегда укладываются в алгоритмическую схему представления поведения.

Пример из жизни:

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

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

Как работать с фильтрами

Это лакмусовая бумажка, которая позволяет сконцентрироваться на более узкопрофильных задачах. Правильно выставленные фильтры позволяют не обращать внимания на остальные задачи до наступления их законного времени. То есть задача "заводящей стороны": правильно выставить все параметры, метки и приоритеты в задаче, а стороны принимающей: правильно понять, что же вам хотели сказать этим "Метка: iOS, Приоритет: наивысший. Релиз: завтра". Чем выше приоритет у задачи, особенно у баги, тем больше нервничает ваш ПМ: у него точно горят сроки и планирование.

Кто заводит задачи и баги

Слегка перефразируя классика английской литературы Д.Г. Байрона: "Мухи отдельно, котлеты отдельно" - эпики, истории, задачи и подзадачи - это забота вашего ПМа и частично тимлида. Ответственность за заведение и отслеживание багов - полностью забота тестировщика. 

И здесь хочется процитировать Экзюпери:

"Мы в ответе за тех, кого приручили". Завёл задачу или багу - доведи до статуса “готово” сам или с компанией.

Бага или доработка

Нажимаю кнопку "Отправить", а она от меня убегает. Это что? Это бага.

Нажимаю кнопку "Отправить", а "Ваше письмо отправлено" сделать не догадались. А это что? Это доработка.

Много книг и умных статей написано о ловле, заведении, отслеживании и сопровождении багов. Добавим и мы свои несколько слов: чем чётче вы сформулируете проблему, тем понятнее принимающей стороне. Важно, чтобы не только вам были понятны ваши формулировки, но и тем людям, которые будут вас читать. Окружение, предусловия и шаги воспроизведения придумали не зря. Именно эти моменты помогут избежать лишних вопросов и выяснений: "А что же этим хотел сказать автор?"

Возвращать задачу или заводить багу

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

Вкладывайтесь в эстимейты

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

См.заповедь 1: Ваш ПМ не должен нервничать =)

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

Если забыли заасайнить задачу

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

Доска и бэклог: как это работает

А вот здесь как раз всё очень просто: на доске - актуальное, в бэклоге - грядущее. И именно в бэклоге можно подсмотреть, как выглядит будущее всей команды.

Трекайте в ту задачу, которую делали

Есть у меня два любопытных примера: первый показательный, второй забавный. Но всё по порядку.

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

Забавный случай - это когда заходишь в рабочий чат, а там: "Заведите мне задачу в Jira на ксерокопирование документов". Думаешь: "прикалываются, ладно". А они не прикалываются: у разработчика случился простой в работе и его решили привлечь к общественно-полезному труду: бланки размножить. Разработчик, помня о том, что нежелательно выходить за эстимейты задач, попросил своего ПМа завести отдельную задачу на документы, чтобы затрекать потраченные часы отдельно. При этом разработчик помнит ещё одно золотое правило: не затрекал - не получил зарплату.

Всегда давайте контекст

“Слушай, я там по поводу картинок, о которых мы говорили на прошлой неделе….”

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

Заключение

Надеемся, что теперь Jira стала понятнее для начинающих котиков, и проблем с ней будет возникать меньше. Если вам есть что добавить - го в комментарии!)