Периодическое отслеживание работы тестировщиков + тесткейсов + автотестов
Актуализация документации + популяризация ведения документации в команде
Деплой задач + мониторинг + откат в случае проблем (роль релиз-менеджера)
Мониторинг периодический (отслеживание состояния сервиса) + его развитие/изменение в связи с изменениями в app
Демонстрация + согласование с бизнесом готовых задач
Решение инфраструктурных проблем в команде (тестовые стенды, сетевые проблемы, установка и обновлений ПО)
Обсуждение с руководителем проблем в команде + стратегических и технических задач
Оптимизация процессов разработки (оптимизация взаимодействия, этапов, обновление схем циклов и т.д.)
Проведение интервью по подбору разработчиков и тестировщиков
Проведение one-to-one встреч с каждым членом команды
Подготовка отчетов для бизнеса + технического руководителя (если таковой имеется)
Участие во встречах по приглашению, где нужна экспертиза, которой обладает тимлид
Деятельность команды
Давайте разберемся, сколько времени команда может потратить на реализацию задач, для этого определимся, из чего состоит наша деятельность.
20% внеплановые задачи 20% технических задачи NNд организационные задачи NNд ошибки в задачах (SLO) NNд корп. дни команды NNд отпуска в команде NNд болезни в команде NNд бизнесовые задачи (все остальное время)
Таким образом, просто просуммировав всю деятельность кроме бизнесовой, можно будет понять, сколько останется времени на бизнесовые задачи (такой расчет лучше проводить на пол года или год).
Препятствия
Что может препятствовать выполнению плана или еще большего кол-ва задач:
SLO
нехватка кадров
недостаточная компетенция кадров
отпуска
разнородная работа
инфраструктурные проблемы
недостаточное кол-во автотестов
неконсолидированные знания о тестировании
Из чего состоит большое бизнес-приложение
Микросервисы бизнес-приложения
Компоненты каждого микросервиса:
компонент frontend (например админка, может деплоиться отдельно)
компонент backend (например api, может деплоиться отдельно)
компонент etc (любой другой, который может деплоиться отдельно)
библиотеки используемые в выше указанных компонентах
Типы задач - разделяются на 2 вида
Бизнес-задачи (результат их выполнения заметен бизнес-пользователю):
улучшение функционала
ошибки в функционале
Технические задачи (результат их выполнения незаметен бизнес-пользователю):
вид задачи
лейбл
описание
issue type
технический долг
technicaldebt
устаревание кодовой базы, что сказывается на скорости разработки
можно не указывать
быстродействие
performance
достижение целевого показателя доступности через ускорение работы приложения
улучшение
проблема
мониторинг
monitoring
ускорение обнаружения проблем в приложении
улучшение
проблема
стабильность
stability
предсказуемость работы приложения с помощью тестирования
улучшение
проблема
какой-то другой
technical
вид задачи не понятен, но задача определенно техническая
можно не указывать
Как видно, каждая тех. задача должна помечаться одним из лейблов, это нужно для отчетности.
Шаги
Расчет приоритета
Давайте представим, что у нас 2 задачи, и нужно понять, какую задачу нужно делать в первую очередь:
Feature
Ценность для пользователя/бизнеса (User-Business Value)
Критичность по времени (Time Criticality)
Риски (добавляются/уменьшаются), Возможности (добавляются/уменьшаются) RR|OE value - Risk Reduction and/or Opportunity Enablement
Комментарии
Комментариев пока нет.