Как работать с задачами и багами?

1.

Как работать с
задачами и багами?
Обучение внутри команды
20.11.2024

2.

С чем мы работаем?
Инициатива
Эпик 1
История 1
Задача 1
Баги
Эпик N
История N
Задача N
Баги
…
…
Баги
Мы с вами

3.

А что это такое?
Запоминаем:
1. Инициативу – предлагаем
2. Эпики – обсуждаем
3. Историю – контролируем
4. Задачу – ведем
5. Баги – не производим
Каждый член команды ответственен за каждую из представленных сущностей
выше!
С точки зрения ведения сущности в инструментах ответственность
распределяется так:
1. Инициатива + Эпик + Историю – владелец продукта (в помощь скрам мастер)
2. Задача + Баги – каждый член команды

4.

Как заводим задачи на
разработку?
Основные требования:
1. Пространство команды «Обеспечивающие сервисы»: APIOBSRV
2. Наименование задачи: конечная бизнес функциональность несущую ценность для
пользователя
3. Указание Родительской задачи: обязательно
4. Добавить дополнительные связи Child Of: согласно родительской задачи*
5. Связанные стримы, заказчики и финансирование, тип работ: согласно родительской
задачи
6. Указание Системы: обязательно
7. Исполнитель: актуальная УЗ сотрудника
8. Владелец: актуальная УЗ владельца продукта
9. Срок исполнения: последний день планируемого спринта
10. Оценка: согласно файлу планирования
11. Осталось = Оценка
12. Спринт: согласно графику спринтов ПроПро
13. Метки: «Разработка» и метка модуля функциональности приложения**
*если родительская задача фича – указываем фичу и эпик, к которому принадлежит эта фича
**подробнее тут: https://sfera.inno.local/knowledge/pages?id=837976

5.

Ответственные за заведение
задач
Ответственный за заведение задач и ведение по ходу спринта по разработке:
1. Андрей А: Максим, Федор
2. Ксения К: Константин, Андрей
3. Ксения М: Роман, Амир
Замещающий и ревьюер: Диана Н (Екатерина Н)
Задачи на разработку должны быть заведены: каждая вторая неделя вт, на неделе
закрытия спринта, до 18:00
Задачи должны быть описаны: каждая вторая неделя пт, на неделе закрытия спринта, до
18:00
Свои задачи должны быть заведены до: каждая вторая неделя ср, на неделе закрытия
спринта, до 16:00
P.S. Инструкции для команды, много полезного если что-то подзабыл: https://sfera.inno.local/knowledge/pages?id=952122

6.

ЖЦ задачи
Создано
В работе
Подтверждение
Выполнено
Закрыто
Запоминаем:
- "Создано" - задача не взята в разработку
- "В работе" - задача в работе
- "Подтверждение" - PR на рассмотрение
- "Выполнено" - задача смержена на контур dev И проведены минимальные тесты!
Смена статусов должна производиться на ежедневной основе!

7.

ЖЦ дефекта
Создано
Анализ
Локализация
Исправление
Отложен
Подтверждение
Внедрение
Запоминаем:
Тестирование
- «Создано» - дефект не взята в разработку
- «Анализ» – дефект локализуется
Закрыто
- «Исправление» - ведем работу по исправлению
- «Подтверждение» - PR на рассмотрение
- «Тестирование» - исправление смержено на контур dev И проведены минимальные
тесты!
- «Отложено» - дефект не воспроизводится, на уточнении у тестировщика
Смена статусов должна производиться на ежедневной основе!

8.

Про описание задач
Критерии успешности описания задачи:
Описание должно быть необходимым и достаточным.
Необходимым — не должно быть пересечений между задачами в описании. Разработчик должен понимать, какую именно
часть задачи ему сейчас реализовывать.
Достаточным — у разработчика не только не должно появиться дополнительных вопросов, но и возможности понять что-то
не так. Избегайте двусмысленности в задачах.
Текст задачи должен понять любой новый разработчик на проекте.
Нужно осознавать, что разработчики хуже понимают контекст проекта, чем аналитики, разработчики впервые видят
описание необходимого изменения.
Полезно написать, зачем вообще добавляется эта фича и почему она нужна пользователю - тогда у разработчика появятся
понимание, что он делает, и, возможно, предложения для улучшения пользовательского опыта.
Что должно включать описание задачи:
1. Цель - зачем эта фича пользователю (лучше user story)
2. Список задач необходимых для достижения цели (кратко)
3. Путь в системе. По необходимости добавить ссылку на макет в Figma или скетч
4. Описание каждой задачи из списка п.2. По необходимости ссылку на статью в Сфере с описанием этого пункта задачи запросы, логика обработки данных, логика обработки пустых данных, флк, логика обработки ошибок, ссылку на описанный
контракт (спецификацию)
5. Тест-кейс или ссылка на оформленный Use Case в Реестре сценариев использования: Реестр API_Тестирование. Use
Case.
6. Права доступа к функциональности и дополнительные ограничения

9.

И так
Шаги описания задачи
1. Получите все необходимые требования.
2. Убедитесь, что сами понимаете, что требуется реализовать.
3. Сформируйте правильное название задачи.
4. В самом начале описания задачи поясните разработчику ценность изменения.
5. Добавьте путь до изменяемого экрана, если это не очевидно.
6. Добавьте ссылки на макеты, если фича визуальная. Если есть разные состояния в зависимости от
условий, описываемых в задаче, то добавьте ссылки в контексте конкретного кейса.
7. Добавьте дополнительные ссылки на статьи в Сфере, которые требуются для выполнения задачи.
8. Если предполагается переиспользование для реализации, явно укажите это. Укажите, если в будущем
будет переиспользоваться, масштабироваться или меняться результат задачи.
9. Опишите функционально задачу и убедитесь в отсутствии пробелов в логике.
10. Опишите всю необходимую информацию по сетевым запросам (запрос, ответ, что парсим,
опциональность; не описывать неиспользуемые поля и указать, что их не парсим). Укажите, если данные
получаются при каком-то условии — например, касаются только авторизованных пользователей,
специальных типов API и т.д. Предоставление просто спецификации недостаточно!
11. Пропишите логику загрузки данных: есть ли постраничная подгрузка и т.д.
12. Укажите логику для пустых данных.
13. Опишите разные форматы отображения для разных форматов дат и т.д.
14. Пропишите логику для обработки специальных ошибок.
15. Убедитесь, что разработчики имеют доступ ко всем необходимым статьям или сервисам.
16. Перечитайте всю задачу от начала до конца!

10.

Закрытие спринта
За закрытие задач (и багов) ответственен каждый член команды по своим задачам!
Задачи должны быть закрыты до: каждая вторая неделя вт, на неделе закрытия спринта, до 16:00
Разработчику необходимо:
1. Убедиться, что все задачи, которыми он занимался включены в спринт, а теми которыми не занимался,
перенесены*
2. Убедиться, что кол-во трудозатрат по оценке составляет 2н**
3. Метка по всем задачам изменена с «Разработка» на «На_Тестирование» (смена производится по ходу
движения задачи/бага по статусной модели и ставится после приобретения статуса задачи «Выполнено»
или статуса бага «Тестирование»)
4. Проставлена резолюция «Готово»
5. Приложена ссылка на PR и указан номер сборки во всех задачах в разделе комментарии
6. Списано кол-во трудозатрат по каждой задаче согласно оценки
7. Если на момент наступления необходимости закрытия задач, дефект имеет статус отличный от
«Закрыто»***, самостоятельно закрыть дефект
*если задачи нет в спринте идем к ответственному за вас аналитику, если задачу не делали, можете самостоятельно перенести на следующий
спринт
**может отличаться по причине отпуска/отгула/выхода в выходной
***и вы его исправили, выложили PR, а это тестировщик не успел провести регресс

11.

Вопросы и предложения
Презентация проведена 20.11.2024.
Доработка и предложения 22.11.2024
Взята на исполнение командой 25.11.2024
Запись будет приложена ко встречи и выложена в канал обучения внутри команды:
https://video.dion.vc/video/channel/318bfad4-08c4-47b3-8c6c-00d722559625
Предложения