Комментарии 4
Только нельзя забывать что эта красота не бесплатна - подробное описание задачи само по себе ресурсоёмко, чётко, коротко и ясно сформулировать не так просто. Поэтому важно контролировать баланс между потенциальными выгодами и потерями - насколько проблемы с потерей контекста обойдутся дороже чем ковровое документирование?
Я ни в коем разе не призываю к односложным тикетам для галочки, по которым вообще ничего не понятно, что и зачем нужно сделать, а исключительно обращать внимание на адекватность формализации, чтобы не организовать самим себе итальянскую забастовку.
А шаблоны заполнения тикетов - очень правильно.
Согласен, и наверное стоило раскрыть этот момент подробнее.
В идеале, сложности при составлении задачи — это отсутствие информации или уверенности в решении. Тогда уже стоит провести либо проводить исследования, либо обсудить ту же постановку с компетентными в вопросе коллегами (лучше даже с теми, кто эту задачу и будет выполнять). Но да, это тоже может занять время.
Поэтому я за то, чтобы писать достаточно полное описание. Ни больше, ни меньше.
За основу я взял примеры описаний из гибких методологий и разделил их по типам:
Для начала можно и тремя обойтись. Просто чтобы не перегружать людей. А остальные добавлять по мере необходимости.
Epic (Большая задача)
Feature (Новая функциональность)
Bug (Исправление ошибок)
Шаблоны описания
Лучше, когда это формы в багтрекере. Например https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#creating-issue-forms
Ну и конечно автоматизация и еще раз автоматизация. Закрывать тикеты автоматом комментарием в коммите - это очень удобно (https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests#linking-a-pull-request-to-an-issue). Гитхуки для проверки наличия тикета в коммите помогают не забыть про него. (можно настроить через https://jorisroovers.com/gitlint/latest/).
Для начала можно и тремя обойтись. Просто чтобы не перегружать людей. А остальные добавлять по мере необходимости.
Постарался описать свой кейс для наглядности, но в целом да — стоит пользоваться только тем, что окажется полезно в команде.
Лучше, когда это формы в багтрекере.
Совершенно верно, предоставил шаблоны чтобы было удобно скопировать в свои формы/шаблоны багтрекера)
А насчёт автоматизации можно написать и нагуглить ещё немало статей, тема довольно обширная. За ссылочки и тулзы спасибо :)
Эффективная постановка и ведение задач в IT-проектах