Pull to refresh

Comments 5

Если процесс разработки и производства организован в платформе типа Jira или GitLab, то никто, кроме разработки, не понимает, что там к чему.

Это правда, по крайней мере в абсолютном большинстве случаев. Лично мне на некоторых проектах удавалось реализовать таски в Jira или на GitHub так, чтобы бизнес был в состоянии понимать, что происходит у разработки — по крайней мере в достаточной степени, чтобы у них пропадал зуд перетащить задачи разработки в асану/ношион/трелло/прочую ересь. Но я согласен, что эти случаи редкое исключение.


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


Для задач разработки трекер должен обладать некоторыми фичами:


  • дружественный к клавиатуре
  • задачи очень легко добавлять, нет необходимости заполнять кучу полей
  • быстрый
  • поддержка markdown и подсветки синтаксиса кода
  • легко отслеживать простой статус (backlog/todo/in progress/done) задачи, сложно потерять задачу
  • быстрые уведомления по email при изменении задачи, но умеренные, без избыточного спама
  • задачи автоматически связываются с ветками (а для этого у задач должны быть ID, которых в асане я не видел)
  • задачи автоматически связываются с pull request-ами
  • задачи автоматически закрываются (или меняют статус) при мерже связанного pull request
  • задачи автоматически меняют статус при изменениях в репо (напр. переключаются в in progress при заливании в репо связанной с задачей ветки, переключаются в in review при открытии pull request)

Если (значительной части) этих фич нет — разработчики просто не будут его полноценно использовать. Иными словами — множество задач, которые должны были быть в трекере просто никто не будет создавать, вместо этого их будут писать в комментариях, в файлах TODO, но чаще всего просто держать в голове — и в результате эти задачи очень часто будут тупо теряться.


У таких требований есть ряд объективных причин:


  • у разработки возникает множество чисто технических (не интересных и непонятных бизнесу) задач, и если эти задачи им будет неудобно создавать и отслеживать, то разработчики их просто поленятся создавать, и о них никто никогда не узнает (что будет увеличивать тех.долг и количество "сакрального знания" в головах, создавая в результате проблему бизнесу)
  • для эффективной и управляемой разработки задачи должны быть очень мелкими (в идеале на несколько часов, максимум на 2-3 дня каждая), что сильно увеличивает количество задач которые необходимо отслеживать разработке, относительно небольшого количества исходных бизнес-задач, которые необходимо отслеживать менеджерам
  • если при работе с задачами бизнеса и менеджмента важнее гибкость (привет, асана!), то при работе с задачами разработки важнее строгость (ограниченное количество статусов задач, жёсткие правила перехода между статусами, жёсткий контроль ответственного за задачу, etc.)

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


P.S. Обычно несложно проверить, насколько удобен трекер для разработки: нужно узнать, насколько часто статус задачи в трекере не соответствует действительности, и бывают ли изменения в репо (pull request-ы) для которых не существует задач в трекере. Если трекер удобен, то такие ситуации — редкость (условно, один-два случая в месяц), а если неудобен — ежедневная норма жизни.

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

Из перечисленных вами фич, которыми должен обладать трекер, в Asana есть добрая половина. ID задачи мы получаем в адресной строке. Статусы меняются автоматически. Уведомления работают. Есть процессы, которые позволяют автоматически отправлять задачи на оценку разработчикам, на оплату в бухгалтерию, подробности запросов автоматически подтягиваются в описание задачи.

Мы, преимущественно, работаем с бизнес-задачами. И далеко не всегда они связаны с одним репозиторием. Это бывает 2, а то и 3 репозитория. Мы не организовываем бэк, фронт (+ иногда расширение) в монорепозиторий.

Так как Asana используется всеми отделами нашей компании, а не только разработчиками, то острой нужды уведомлять постановщика (менеджер проекта в случае с клиентской разработкой, сотрудник технической поддержки в случае бага, руководство в случае разработки какой внутренней фичи) о том, что коммит исполнителя сейчас находится на ревью или его «слили» в мастер — нет, ему это не очень интересно и от отдела разработки он ждёт условного «Готово, принимайте».

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

Это которые выглядят а-ля 1124785706319289? Такие ID крайне неудобно использовать в обсуждении, именах веток и описаниях PR.


Статусы меняются автоматически.

Было бы очень интересно почитать детальнее, как именно Вы это настраиваете. Именно в разрезе интеграции с репо/ветками/PR/мержами.


Есть процессы, которые позволяют автоматически отправлять задачи на оценку разработчикам

Какие задачи? Бизнес-задачи, т.е. достаточно крупные, оценка по которым выражается в неделях? Если да, то это не те задачи, которые способны относительно корректно оценивать разработчики — оценку крупных бизнес-задач нужно собирать из оценок кучки мелких задач, появляющихся после декомпозиции бизнес-задачи, иначе погрешность в оценке будет слишком большой. Иными словами, та бизнес-задача, которую Вы (предположительно) отправляете на оценку — это вовсе не те задачи, которые реально должны оценивать разработчики.


Мы, преимущественно, работаем с бизнес-задачами. И далеко не всегда они связаны с одним репозиторием. Это бывает 2, а то и 3 репозитория.

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


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

Всё верно. Но вот в команде разработчиков есть люди (обычно — тимлид, иногда PM), которым такие уведомления жизненно необходимы.


Я пытаюсь сказать, что Вам стоит внимательнее присмотреться к тому, как использование асаны сказалось на отделе разработки. Потому что я не вижу в описании ваших процессов тех элементов, которые решают проблемы именно отдела разработки, зато вижу те, которые им проблемы создают. Соответственно, стоит выяснить, как отдел разработки решает для себя эти проблемы (эффективное управление тучами мелких и/или технических задач, которые никому кроме них не интересны, а так же автоматизацию управления статусами задач чтобы уменьшить ошибки из-за человеческого фактора). Если они нашли какой-то подход, помогающий справиться с этими проблемами в асане — было бы крайне интересно про него почитать. А если не нашли, то загнав разработку в асану Вы заложили в компании мину замедленного действия.

Это которые выглядят а-ля 1124785706319289? Такие ID крайне неудобно использовать в обсуждении, именах веток и описаниях PR.

Теперь поняли, о каких именно вы идентификаторах. Когда дойдём до плотной интеграции Asana и Gitlab, скорее всего будем генерировать короткие легкочитаемые коды (в Asana есть возможность присваивать таскам кастомные поля). Хотя, перед проектированием ещё раз подумаем о целессообразности этого, в тех же PR можно просто оставить линк на задачу в Asana. Или вовсе организовать работу из Asana (прокидывать туда уведомление со ссылкой на PR, чтобы главным агрегатором информации и «побуждений к действию» всё-таки оставалась Asana)

Было бы очень интересно почитать детальнее, как именно Вы это настраиваете. Именно в разрезе интеграции с репо/ветками/PR/мержами.

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

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

В ситуации, когда нет плотной интеграции с Git’ом, не всегда есть смысл делить задачи например на «Сделать форму конфигурации для чат-бота», «Реализовать аутентификацию в чат-боте», «Реализовать бизнес-логику чат-бота», когда всеми задачами занимается один и тот же исполнитель и отвечает за весь результат целиком (ему и время трекать удобнее, ведь не нужно «скакать» между задачами в тайм-трекере, не всегда возможно делать связанные задачи «строго по очереди»)

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

Может быть у вас есть статьи/материалы по успешным кейсам интеграции между системой управления проектами и системой контроля версий, в компаниях, которые используют тайм-трекер и это не «компании одного продукта»? Мы будем очень благодарны!
когда всеми задачами занимается один и тот же исполнитель и отвечает за весь результат целиком (ему и время трекать удобнее, ведь не нужно «скакать» между задачами в тайм-трекере, не всегда возможно делать связанные задачи «строго по очереди»)

На эту граблю наступали в начале работы примерно вообще все. Вкратце: нет, это не так.


по успешным кейсам интеграции между системой управления проектами и системой контроля версий

Увы, но нет. Я лично наблюдал ровно три варианта:


  • Трекер удобен бизнесу, разработчиков в него загоняют (а-ля описанное в статье) — в результате у разработчиков куча проблем, которые со временем начинают сказываться и на бизнесе. Чем заканчивается в дальней перспективе не знаю, потому что лично я (как и многие другие квалифицированные разработчики) с таких проектов сваливаю сразу, как только понимаю, что это всерьёз и надолго — просто нет мотивации героически преодолевать искусственно созданные препятствия. Впрочем, очевидно, что от такой утечки лучших кадров бизнесу лучше не станет.
  • Трекер удобен разработчикам, бизнес мучительно пытается с ним работать — в результате бизнес сдаётся, и просто перестаёт использовать трекер сверх необходимого минимума (вроде ответов на вопросы в комментах и заведения багов), обычно при этом бизнес-задачи уползают в какой-то более удобный бизнесу трекер, но разработчики про это ничего не знают… и со временем обычно возникает пропасть между представлением бизнеса о происходящем у разработчиков, и реальным положением дел.
  • Трекеров два, и кто-то (обычно проджект менеджер или лид тестировщиков — кто-то имеющий достаточное понимание и задач бизнеса/юзеров и технических проблем) синхронизирует между ними информацию вручную (т.е. резюмирует результат множества тасок разработчиков в изменения небольшого количества бизнес-задач, инициирует декомпозицию бизнес-задач в кучу тасок для разработчиков, плюс следит за соблюдением приемлемого соотношения между совсем уж техническими задачами и задачами имеющими отношение к бизнесу в трекере разработчиков) — этот вариант работает лучше всего.

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


На своих проектах в последние года полтора я пытаюсь (с переменным успехом) организовать понятную бизнесу картину на "досках" (projects) GitHub. Но это, в лучшем случае, решает половину проблемы: бизнес может кое-как ориентироваться в трекере разработчиков, но задачи не связанные с разработкой бизнес всё-равно вынужден вести в другом трекере, потому что гитхаб, при всей моей к нему любви, для таких задач абсолютно не приспособлен.

Sign up to leave a comment.

Articles