1. Code freeze
1.1. Берутся только баги по фичам + запланированные баги, оцененные менее чем в пол дня
1.2. За неделю до RC?
1.3. Спринтовый в последний четверг перед демо
2. Совещания
2.1. Общее
2.1.1. Если принял совещание, то обязан быть во время
2.1.2. Совещание не может длиться более 1 часа 15 минут. Если не укладываетесь - делаете перерыв в 15 минут.
2.1.3. Вначале каждого совещания ведущий озвучивает
2.1.3.1. Цель совещания
2.1.3.2. Время проведения
2.1.3.3. Жесткий формат по которому действует, вплоть до последовательности действий если нужно
2.1.3.4. Все остальное что нужно ведущий для того чтобы выполнить цели совещания
2.1.3.5. В конце резюмирует достигнута ли цель совещания
2.1.4. На обсуждениях не сидеть в телефонах
2.1.5. Не галдим на совещаниях
2.1.6. Спор внутри команды ограничен 1-й минутой, спор решает анонимное голосование
2.2. Планирование
2.2.1. Обсуждать технические вопросы до начала спринта меньшим составом
2.2.2. Интеграционные задачи планировать завершить в 1-ю неделю спринта
2.2.3. На планировании навешиваем на разработчиков сразу задачи. Хотя бы на 2 дня.
2.2.4. Если не можем дать оценку, проводим исследование
2.2.5. Все что затрагивает несколько компонентов - сперва брать исследование
2.2.6. Начинаем с формирования цели спринта
2.3. Грумминг с ПО
2.3.1. На грумминге требуем нормального описания US
2.4. Стендап
2.4.1. На стендапе отвечать на 3 вопроса
2.5. Демо
2.5.1. Показываем функционал через закрытие потребностей
2.6. Ретро
2.6.1. Конструктивно озвучивать проблемы, а не ныть. Следить за формулировками
3. PR
3.1. Перед созданием запускать проект и ЮТ
3.2. Комментарии нужно стараться писать таким образом, чтобы было понятно без дополнительных вопросов
4. Доска
4.1. Создание задач
4.1.1. Если не получается разделить параллельно, разделяем последовательно
4.1.2. При декомпозиции задач разделять их по функционалу, для того чтобы каждая задача представляла собой отдельную бизнес ценность и для того чтобы можно было сразу протестировать и не создавать отдельные задачи по тестированию.
4.1.3. Создавать баги согласно шаблону
4.2. Передвижение задач
4.2.1. Если задача вновь попадает в ToDo то нужен комментарий почему
4.2.2. Жесткие архитектурные вещи брать в начале спринта
4.2.3. Стараемся брать задачи, в которых плохо разбираемся
4.2.4. До ready for test за задачей следит разработчик, до done - тестировщик
4.2.5. Если нет задач - брать обучение, либо техдолг
4.2.5.1. Смотреть след. спринт (планируем свою часть) - проверяем баги, смотрим есть ли задачи
4.2.5.2. Брать техдолг
4.2.5.3. Брать обучение
4.2.5.4. Смотреть бэклог и актуализировать баги
4.2.6. Готовить следующий спринт в 1-ю неделю после планирования
4.2.7. Распределять проблемы на интеграционном на всех тестировщиков
4.2.8. В отсутствии задач оповестить TL и можно брать обучение
4.3. Задачи с внешними связями проверять заранее (сразу после планирвания) на доступность
5. Code review
5.1. На CodeReview отводится не более суток
5.2. Задачи, полученные по итогам аналитики должны проходить тех. ревью
5.3. Тест кейсы
5.3.1. Ревьювит разработчик функционала
5.3.1.1. Убедиться что покрыты все необходимые кейсы
5.3.1.2. Убедиться что нет лишних тест кейсов, которые покрываются UT
5.3.1.3. Решения по прочим комментариям принимают тестировщики