Организация процесса работы над задачами. Личный опыт

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

При работе в серьезном стартапе, или иной интенсивно развивающейся организации, программисты нагружены до предела. Приходится реализовывать очень много задач, создавая новую функциональность для сайта. И одновременно заниматься поддержкой уже работающих сервисов. Количество программистов в стартапе всегда ограничено финансовыми возможностями, что только увеличивает объем работ, который выпадает на долю каждого участника. Например, с начала 2014 года, до ноября 2014, я успела поработать над 140 задачами и проектами, не считая помощи отделу тестирования, саппорта, отделу по работе с контентом и некоторыми задачами, которые поступали из административного отдела.

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

Не только у меня такие проблемы :) Никто не в состоянии помнить все проекты и быстро ориентироваться в них. И тут на помощь людям приходит JIRA. JIRA — система управления задачами, она же багтрекер, она же тасктрекер. Я привожу в пример JIRA только потому, что последние 2 компании, в которых я работала, использовали именно эту систему. Вместо нее мог быть любой другой функциональный багтрекер.

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

Без тасктрекера процесс разработки продукта очень быстро превращается в хаос.

jira1
Пример 1. Список текущих задач для программиста в JIRA

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

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

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

Комментарий: на рабочей станции я предпочитаю Windows, для редактирования текстовых файлов — Far2.

Файл всегда имеет название в формате: <идентификатор_задачи_в_jira>_<ключевые_слова>.

Идентификатор нужен, чтобы легко найти файл, когда добрый менеджер присылает тебе ссылку на задачу. Ключевые слова помогают быстро вспомнить тему задачи.

Например:
API_81_expiration_date — это означает, что в JIRA задача имела идентификатор API-81, ключевое слово expiration_date помогает вспомнить, даже не открывая файл, что задача была связана с добавлением нового поля expiration_date в заголовки http-ответа на http-запрос клиента.

 

jira2
Пример 2. Список файлов в директории tasks

Каждый файл содержит технические комментарии к задаче, которые не станешь размещать в JIRA.

Обязательные данные в файле:

  • копия описания задачи из JIRA. Не спрашивайте, зачем :) Когда менеджер перепишет текст задачи, или вообще случайно обнулит — будет полезно. Лучше один раз сделать copy-paste. Опять же, бывает, менеджер приходит и говорит: «Помнишь, ты занимался задачей WEB-123?» — за пару секунд ты находишь файл и быстро подгружаешь смысл задачи в свой мозг. В файле задачи для этого уже все есть.
  • название ветки в git (Каждая задача разрабатывается в отдельной ветке git. Перед релизом ветку сливают с master).

Остальная информация — опционально, по ситуации. Это могут быть готовые строки curl для тестирования API, команды для запуска скриптов со всеми атрибутами, комментарии — какие трудности возникали, почему было принято то или иное решение, списки файлов, которые вошли в коммит, и т.д.

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

 

jira3
Пример 3. Содержимое файла по одной из поставленных задач

Иногда бывают ситуации, когда приходится решать задачи, не выставленные в JIRA. Прибегает начальник и просит сделать отчет. Звонит ответственный за контент редактор и просит помочь решить проблему. До этой осени я не логировала такие задачи. Но потом их стало много и они начали повторяться.

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

Для таких задачек я так же стала заводить файлы. Их название имеет формат: <адресат_или_инициатор>_<порядковый_номер>_<ключевое_слово>. Например: for_boss_23_reports, for_sviet_12_test_query