В теме 1 ответ, и 2 участника, последнее обновление сделано пользователем 
check 10 г, 9 мес. назад.
-
Сообщения
-
Дорогие коллеги!
Неожиданно столкнулся с тем, что в команде нету четкого шаблона для создания задач и багов. Может кто-нибудь может поделиться своими best practices или примерами того какие поля вы используете в работе.
Спасибо!
Добрый день,Я не очень люблю вводить в средние и небольшие проекты тяжеловесные шаблоны, а потом из них выбрасывать ненужное для данной команды (данного проекта). Мне ближе иной подход — когда вводится минимум, а потом к этому минимум добавляется только то, что нужно.
И через короткое время можно получить полностью жизнеспособный процесс и документ, подходящий именно для этого проекта и этих людей в команде.Особенно это касается шаблона tasks (если я верно поняла, это задача на разработку). Тут все очень зависит от размера проекта, опытности команды, выбранного подхода (plan-driven, change-driven) и многого другого. Без деталей советовать трудно.
Что касается шаблона описания ошибки, из моего опыта не лишней будет следующая информация:
0) ID или номер ошибки — для удобства ссылки на нее.1) Название ошибки — краткое, но осмысленное (названия вроде «ничего не работает!!1″ или » критическая ошибка логина» не удачны).
2) Описание ошибки — более детальное описание c желательным указанием как система себя сейчас ведет, как должна вести и почему (ссылка на требования или иной артефакт).
3) Шаги для воспроизведения, включая необходимые для воспроизведения данные (роль, логин и пароль и т.д., под которыми произошла ошибка).
4) Часто нужна информация о среде, в которой произошла ошибка (ОС, браузер, его версия, номер релиза и иное).
5) Критичность ошибки — например, блокирующая, важная, средней важности и не важная.
6) Имя человека, который ее нашел и к кому можно обратиться за информацией.
7) Иные файлы (скриншоты, логи и т.д.), если они есть.
Указанная выше информация задается при регистрации ошибки, для дальнейшей же работы над ней могут понадобится: статус ошибки, оценка трудозатрат на ее исправление, срочность исправления, имя назначенного для исправления разработчика.
Если вы используете специальный инструмент для регистрации ошибок (багов), то он сам вам должен «подсказать» нужные поля).
Для багов:- ID
- Title
- Priority
- Severity
- Bug in Version
- Description
- Expected result
- Epic (to what feature relates)
Это базовый набор полей, который используется на моем текущем проекте.
Вы должны авторизироваться для ответа в этой теме.
