Comments 11
Статья супер!
Хотела ещё дополнить:
в разных компаниях, конечно, по-разному процесс устроен, но обычно если это не бага, а доработка (т.е. что-то неучтённое в ТЗ), то это уже не тестировщик, а аналитик заводит, предварительно исправляя ТЗ
Спасибо)
А про ТЗ - это если это самое ТЗ есть в принципе. Просто тема наличия и качества технического задания, как мне кажется, это вообще отдельная головная боль любого проджекта, аналитика и всей команды в принципе.
Ну ТЗ может вообще в Конфе хранится, а в Жире ссылка на него)
Вы безусловно правы) Хорошо, когда разработчик понимает, что техническое задание пишется не только для проджекта/аналитика, но и для всей команды. Ведь есть же немалое количество приложений, где реализация на платформах разнится. Вот поэтому наша задача: донести до всей команды работать максимально синхронизированно. И столь же немаловажно, чтобы команда научилась без дополнительных подсказок синхронизировать до того, как фича реализована, вместо того, чтобы потом править на той стороне, которая "не так" поняла смысл написанного =)
В целом, бодро написано. А только при чем тут именно jira? Можно же любой таск-трекер подставить и суть сохранится.
Жира и слак возможно лучшее чем я пользовался за всю жизнь
Хорошая статья про Джиру.
Но первое, ТЗ должно быть в Конфлюенсе, эпик должен иметь формулировку реализовать ТЗ по ссылке на Конфлюенс.
Джира это таск трекер, в ней трекаются задачи, которые должны быть декомпозированы до каких то примитивных заданий с расчетным временем выполнения 2-4 часа, что бы в течении дня было понятно продвижение по плану работы над эпиком, что бы какие то затруднения в работе можно было заметить в течении одного дня и выполнить планирование по их преодолению (изменить постановку - сделать новую задачу, или старой задаче назначить нового исполнителя, или создать новые задачи и отметить исходную задачу как поставленную на паузу до решения новых порожденных задач, или вовсе отменить исходную задачу и заменить ее совершенно новой - пути Господни неисповедимы, мало ли что выясниться по ходу работы над задачей).
И что обязательно, при проставлении финального статуса в Джире (готово или отменена), надо добавлять коментарий или с фактическим результатом выполнения задачи (результат не всегда бывает таким каким был в постановке задачи) или с причиной отмены задачи. Больше комментариев в задаче о ходе работы над задачей ! Потомки будут вам благодарны.
Второе, не согласен со статьёй только в части о возврате задачи на доработку или создание новой задачи, я считаю задача должна создаваться новая, всегда.
Потому что задача в себе содержит оценку времени - план разработчика по затратам времени, и задача должна содержать факт по затраченому времени
Поэтому когда плановое время израсходовано полность и даже чуть больше,то наступает момент когда надо оставить комментарий с результатом работы над задачей.
По этим результатам делаем новую декомпозацию на задачи и даём новую оценку этим задачам.
Тогда всегда будет видно почему задача затянулась по времени и как над ней работали.
Хорошая статья, я бы еще добавил следующее (из личного опыта):
Пройти бесплатное обучение у Атлассиан - https://university.atlassian.com/student/catalog/list?category_ids=21734-free-training - там не только Джира но вообще все их продукты
Также, зарегать аккаунт и открыть свой проект и там уже практиковаться с реальным продуктом
Несмотря на недостакти (а они есть), пока что это лучшая система с которой я работал
Осталось понять, где в статье планирование
Мне найти не удалось
Джира для джунов, или как планировать и “не сгореть”