Чек-лист для SCRUM-мастеров
Аналитика и Архитектура
Бизнес-анализ
1 Есть User Story на каждую фичу
2 Наличие сквозного описания актуального процесса
3 Ведение документации в Confluence или аналогичная система
4 Наличие критериев приёмки
5 Наличие метрики по каждой фичи
6 Согласование процессов с подразделениями Банка
7 Наличие НФТ по каждой "влияющей" фиче
8 Декомпозиция фич на базе User Story mapping
9 Каждая идея прорабатывается и декомпозируется на фичи, мы делаем это всей командой, в тесном взаимодействии с бизнес-заказчиком и product owner'ом
10 Проводится UX-проектирование фичи
11 Проводится UI-проектирование фичи
12 Есть Design Guideline
13 У нас есть База Знаний (Knowledge Base), которая доступна всем новичкам, и реально помогает им быстро понять, как работает наша система
Системный анализ
14 При начале работы над техническим решением есть проработанный дизайн
15 Наличие описания каждой фичи
16 Наличие сквозного описания актуального функционала
17 Ведение документации в Confluence или аналогичная система
18 Оценка влияния на Архитектуру по каждой фиче
19 Наличие актуального описания БД
20 Наличие реестра предоставляемых сервисов
21 Наличие реестра потребляемых сервисов
22 Проработка технического решения совместно с DEV-командой
23 Проработка технического решения совместно с TEST-командой
24 Подготовка документации параллельно с разработкой
25 Автоматизация документирования интерфейсов
26 Автогенерация сопроводительной документации
27 Налажен процесс проработки решений с другими командами
28 Внедрён принцип "contract first" на уровне API
29 Наличие описания микросервиса в реестре микросервисом (metadata)
Архитектура
30 Наличие актуальной архитектурной системы
31 Наличие актуальной ER (Entity-Relation) диаграммы БД
32 Согласование архитектуры по каждой "влияющей" фиче
33 Фиксация технического долга в backlog
34 Наличие актуальной to-be архитектурной схемы доменной модели
35 Проектирование новых фич осуществляется с учётом и в соответствии с архитектурой to-be
36 Проводится планирование задач тех долга
1 Есть User Story на каждую фичу
2 Наличие сквозного описания актуального процесса
3 Ведение документации в Confluence или аналогичная система
4 Наличие критериев приёмки
5 Наличие метрики по каждой фичи
6 Согласование процессов с подразделениями Банка
7 Наличие НФТ по каждой "влияющей" фиче
8 Декомпозиция фич на базе User Story mapping
9 Каждая идея прорабатывается и декомпозируется на фичи, мы делаем это всей командой, в тесном взаимодействии с бизнес-заказчиком и product owner'ом
10 Проводится UX-проектирование фичи
11 Проводится UI-проектирование фичи
12 Есть Design Guideline
13 У нас есть База Знаний (Knowledge Base), которая доступна всем новичкам, и реально помогает им быстро понять, как работает наша система
Системный анализ
14 При начале работы над техническим решением есть проработанный дизайн
15 Наличие описания каждой фичи
16 Наличие сквозного описания актуального функционала
17 Ведение документации в Confluence или аналогичная система
18 Оценка влияния на Архитектуру по каждой фиче
19 Наличие актуального описания БД
20 Наличие реестра предоставляемых сервисов
21 Наличие реестра потребляемых сервисов
22 Проработка технического решения совместно с DEV-командой
23 Проработка технического решения совместно с TEST-командой
24 Подготовка документации параллельно с разработкой
25 Автоматизация документирования интерфейсов
26 Автогенерация сопроводительной документации
27 Налажен процесс проработки решений с другими командами
28 Внедрён принцип "contract first" на уровне API
29 Наличие описания микросервиса в реестре микросервисом (metadata)
Архитектура
30 Наличие актуальной архитектурной системы
31 Наличие актуальной ER (Entity-Relation) диаграммы БД
32 Согласование архитектуры по каждой "влияющей" фиче
33 Фиксация технического долга в backlog
34 Наличие актуальной to-be архитектурной схемы доменной модели
35 Проектирование новых фич осуществляется с учётом и в соответствии с архитектурой to-be
36 Проводится планирование задач тех долга
Разработка
1 Разработка ведётся в IDE
2 Разработка ведётся на современных обновляемых \ поддерживаемых вендором языках программирования
3 Для хранения исходников используется система контроля версий (SVN, GIT и т.д.)
4 В команде используется TaskTracker \ BugTracker (например, JIRA)
5 Хранение исходного кода в системе контроля версий учитывает версионность программного обеспечения (например, под версии создаются отдельные ветки в репозитории)
6 Разработчики имеют представление об основных паттернах разработки и проектирование программного обеспечения и могут рассказать о классификации паттернов по GOF
7 Разработка ведется при наличии документации или верхнеуровневом описание требований с четко определённым понятием выполненных работ
8 В команде есть договоренность по правилам документирование кода
9 В команде используется механизм автоматического создания документации (автодокументирование)
10 В команде есть DoD для задачи
11 В команде есть и постоянно развивается база знаний по особенностям продукта в разработке (особенности системы, архитектуры, типичные проблемы и т.д.)
12 Разработчики обладают навыками написания и используют в работе механизмы автоматических проверок участков исходного кода:
12.1 В проекте пишутся UnitTest
12.2 В проекте пишутся автоматические интеграционные тесты
12.3 В проекте пишутся UI тесты
13 В команде развернут mock сервер
14 Команда использует тестовые сервера для передачи разработанного функционала на приемку
15 Процесс обновления тестовых сред автоматизирован CD
16 В команде существует описание стиля разработки программного обеспечения (CodeStyle)
17 В команде используется процесс CodeReview
18 В команде используется оптимистичный подходов в CodeReview (Rewiew после установки задачи)
19 В команде используются практики XP:
19.1 Парное программирование
19.2 Test Driven Development
19.3 Коллективное владение кодом
19.4 Частые небольшие релизы
20 Команда делает постоянный рефакторинг с целью улучшения архитектуры, небольшими порциями в рамках бизнес-задач
21 В команде построен CI: непрерывная интеграция всех фич идёт на ежедневной основе. Все фичи вливаютсяв общую ветку каждый день (отсутствие крупных мерджей с большим риском ошибок в конце цикла разработки)
22 Построен pipeline для автоматической проверки качества кода, запуска автотестов,автоматический мердж веток, precommit проверки с нотификацией
23 Используется подход BDD (Behavior driven development)24Feature toggle:
24.1 В продукте реализован подход Feature
24.2 Все новые фичи выпускаются с Feature toggle
25 Разработчики не ждут финализации документации и могут приступить к разработке параллельно с созданием системных требований
26 Кросс-функциональность:
26.1 В команде есть кросс-функциональных подход, часть разработчиков обладают дублирующими компетенциями
26.2 Все компетенции разработки в команде имеют бэкап от других разработчиков
26.3 Все разработчики кросс-функциональны по отношению к задачам команды
27 В команде есть практика использование сторонних библиотек
28 В команде есть практика шаринг BestPractice между разработчиками внутри команды
29 В команде есть практика презентаций кейсов\докладов между разработчиками
30 В команде есть практика шаринг BestPractice между разработчиками других команд
31 В команде разработчики участвуют в проработке аналитики и архитектуры по новым задачам
32 Команда следит за последними технологиями и новинками
33 В команде пилотируются новые подходы и новые технологии
2 Разработка ведётся на современных обновляемых \ поддерживаемых вендором языках программирования
3 Для хранения исходников используется система контроля версий (SVN, GIT и т.д.)
4 В команде используется TaskTracker \ BugTracker (например, JIRA)
5 Хранение исходного кода в системе контроля версий учитывает версионность программного обеспечения (например, под версии создаются отдельные ветки в репозитории)
6 Разработчики имеют представление об основных паттернах разработки и проектирование программного обеспечения и могут рассказать о классификации паттернов по GOF
7 Разработка ведется при наличии документации или верхнеуровневом описание требований с четко определённым понятием выполненных работ
8 В команде есть договоренность по правилам документирование кода
9 В команде используется механизм автоматического создания документации (автодокументирование)
10 В команде есть DoD для задачи
11 В команде есть и постоянно развивается база знаний по особенностям продукта в разработке (особенности системы, архитектуры, типичные проблемы и т.д.)
12 Разработчики обладают навыками написания и используют в работе механизмы автоматических проверок участков исходного кода:
12.1 В проекте пишутся UnitTest
12.2 В проекте пишутся автоматические интеграционные тесты
12.3 В проекте пишутся UI тесты
13 В команде развернут mock сервер
14 Команда использует тестовые сервера для передачи разработанного функционала на приемку
15 Процесс обновления тестовых сред автоматизирован CD
16 В команде существует описание стиля разработки программного обеспечения (CodeStyle)
17 В команде используется процесс CodeReview
18 В команде используется оптимистичный подходов в CodeReview (Rewiew после установки задачи)
19 В команде используются практики XP:
19.1 Парное программирование
19.2 Test Driven Development
19.3 Коллективное владение кодом
19.4 Частые небольшие релизы
20 Команда делает постоянный рефакторинг с целью улучшения архитектуры, небольшими порциями в рамках бизнес-задач
21 В команде построен CI: непрерывная интеграция всех фич идёт на ежедневной основе. Все фичи вливаютсяв общую ветку каждый день (отсутствие крупных мерджей с большим риском ошибок в конце цикла разработки)
22 Построен pipeline для автоматической проверки качества кода, запуска автотестов,автоматический мердж веток, precommit проверки с нотификацией
23 Используется подход BDD (Behavior driven development)24Feature toggle:
24.1 В продукте реализован подход Feature
24.2 Все новые фичи выпускаются с Feature toggle
25 Разработчики не ждут финализации документации и могут приступить к разработке параллельно с созданием системных требований
26 Кросс-функциональность:
26.1 В команде есть кросс-функциональных подход, часть разработчиков обладают дублирующими компетенциями
26.2 Все компетенции разработки в команде имеют бэкап от других разработчиков
26.3 Все разработчики кросс-функциональны по отношению к задачам команды
27 В команде есть практика использование сторонних библиотек
28 В команде есть практика шаринг BestPractice между разработчиками внутри команды
29 В команде есть практика презентаций кейсов\докладов между разработчиками
30 В команде есть практика шаринг BestPractice между разработчиками других команд
31 В команде разработчики участвуют в проработке аналитики и архитектуры по новым задачам
32 Команда следит за последними технологиями и новинками
33 В команде пилотируются новые подходы и новые технологии
Тестирование
Функциональное тестирование
1 Есть стратегия функционального тестирования
2 Проводится ревью документации тестировщиками
3 Используется единый инструмент ведения ошибок
4 Есть шаблон оформления дефекта с перечнем минимально необходимой информации
5 В любой момент можно получить (с помощью единого инструмента) актуальную информацию по дефекту: статус исправления, версия ПО, в которой будет исправлен дефект и пр.
6 Есть отчеты по тестированию в привязке к номеру версии ПО, на котором проводилось тестирование
7 Используется единый инструмент ведения тест-кейсов
8 Реализована связь требований с тест-кейсами, тест-кейсов с дефектами
9 Отслеживается покрытие функциональности тест-кейсами (матрица traceability)
10 Используется инструмент управления тестированием: тест-циклы собираются централизованно, есть возможность в реальном времени отслеживать статус прохождения тестов
11 Проводится ревью тест-кейсов аналитиками
12 Ведется тестовая модель, при тестировании используются различные наборы тестов в зависимости от ситуации: Smoke, Регресс, Интеграционные и т.д.
13 Проводится анализ дефектов ПРОМ, по итогам анализа выполняются меры по недопущению повторного пропуска дефектов: доработка тестовой модели, проверка на специфических наборах данных и пр.
14 При тестировании используется mock-сервер
15 Есть библиотека скриптов для подбора тестовых данных
16 Проводится оптимизация тестовой модели с целью сокращения сроков тестирования без потери качества
Автоматизированное тестирование
17 Применяется автоматизированное тестирование
18 Есть стратегия автоматизации тестирования
19 Определено целевое покрытие и распределение автотестов Unit \ API \ UI тестов
20 Проводится автоматизация на уровне User Interface
21 Проводится автоматизация на уровне API
22 Проводится автоматизация на уровне Unit
23 Есть набор автотестов для проверки работоспособности смежных систем (API)
24 Есть автоматическая генерация и\или подбор тестовых данных
25 Все тестировщики команды вовлечены в автоматизацию тестирования
26 Разработчики вовлечены в автоматизацию тестирования
27 Отслеживается покрытие тестовой модели автотестами
28 Запуск автотестов проводится на переодической основе, отчет по результатам прохождения автотестов рассылается на команду
29 Инструмент тестирования интегрирован с инструментом управления тестированием: есть возможность запускаи перезапуска автотестов из тест-циклов, результаты автозапуска тестов отражаются в общем тест-цикле
30 Автотесты используют mock-сервер для выполнения интеграционных проверок
31 Автоматизирован Smoke
32 Smoke набор автотестов может быть прогнан на мокированной среде
33 Набор автотестов для smoke запускается автоматически после каждой сборки
34 Автоматизирован регресс
35 Регрессионный набор автотестов может быть прогнан на мокированной среде
36 Набор автотестов для регресса запускается автоматически после выкладки сборки на тестовый сервер
Автоматизированное тестирование
37 Проводится регулярное нагрузочное тестирование
38 Есть профиль нагрузочного тестирования, сформированный на основании текущей статистики использования ПО в промышленной среде и планов\перспектив развития
39 Проводится тестирование безопасности
40 Проводится Usability тестирование
41 Собираются, анализируются и исправляются замечания и пожелания конечных пользователей из внешних источников
42 Проводится интеграционно-функциональное тестирование
1 Есть стратегия функционального тестирования
2 Проводится ревью документации тестировщиками
3 Используется единый инструмент ведения ошибок
4 Есть шаблон оформления дефекта с перечнем минимально необходимой информации
5 В любой момент можно получить (с помощью единого инструмента) актуальную информацию по дефекту: статус исправления, версия ПО, в которой будет исправлен дефект и пр.
6 Есть отчеты по тестированию в привязке к номеру версии ПО, на котором проводилось тестирование
7 Используется единый инструмент ведения тест-кейсов
8 Реализована связь требований с тест-кейсами, тест-кейсов с дефектами
9 Отслеживается покрытие функциональности тест-кейсами (матрица traceability)
10 Используется инструмент управления тестированием: тест-циклы собираются централизованно, есть возможность в реальном времени отслеживать статус прохождения тестов
11 Проводится ревью тест-кейсов аналитиками
12 Ведется тестовая модель, при тестировании используются различные наборы тестов в зависимости от ситуации: Smoke, Регресс, Интеграционные и т.д.
13 Проводится анализ дефектов ПРОМ, по итогам анализа выполняются меры по недопущению повторного пропуска дефектов: доработка тестовой модели, проверка на специфических наборах данных и пр.
14 При тестировании используется mock-сервер
15 Есть библиотека скриптов для подбора тестовых данных
16 Проводится оптимизация тестовой модели с целью сокращения сроков тестирования без потери качества
Автоматизированное тестирование
17 Применяется автоматизированное тестирование
18 Есть стратегия автоматизации тестирования
19 Определено целевое покрытие и распределение автотестов Unit \ API \ UI тестов
20 Проводится автоматизация на уровне User Interface
21 Проводится автоматизация на уровне API
22 Проводится автоматизация на уровне Unit
23 Есть набор автотестов для проверки работоспособности смежных систем (API)
24 Есть автоматическая генерация и\или подбор тестовых данных
25 Все тестировщики команды вовлечены в автоматизацию тестирования
26 Разработчики вовлечены в автоматизацию тестирования
27 Отслеживается покрытие тестовой модели автотестами
28 Запуск автотестов проводится на переодической основе, отчет по результатам прохождения автотестов рассылается на команду
29 Инструмент тестирования интегрирован с инструментом управления тестированием: есть возможность запускаи перезапуска автотестов из тест-циклов, результаты автозапуска тестов отражаются в общем тест-цикле
30 Автотесты используют mock-сервер для выполнения интеграционных проверок
31 Автоматизирован Smoke
32 Smoke набор автотестов может быть прогнан на мокированной среде
33 Набор автотестов для smoke запускается автоматически после каждой сборки
34 Автоматизирован регресс
35 Регрессионный набор автотестов может быть прогнан на мокированной среде
36 Набор автотестов для регресса запускается автоматически после выкладки сборки на тестовый сервер
Автоматизированное тестирование
37 Проводится регулярное нагрузочное тестирование
38 Есть профиль нагрузочного тестирования, сформированный на основании текущей статистики использования ПО в промышленной среде и планов\перспектив развития
39 Проводится тестирование безопасности
40 Проводится Usability тестирование
41 Собираются, анализируются и исправляются замечания и пожелания конечных пользователей из внешних источников
42 Проводится интеграционно-функциональное тестирование
DevOps
Continuous integration & continuous delivery
1 Используются средства автоматизации \ скриптования для создания инфраструктуры
2 Имплементирован подход Iaac (Infrastructure As A Code)
3 В продукте используется виртуализация, все сервера виртуальные
4 В продукте настроена контейнеризация инфраструктуры
5 Автоматизировано создание и конфигурирования ОС и среды выполнения
6 Автоматизирована подготовка и импорт\миграция данных для DEV \ TEST сред
7 Расхождение данных между средами PROD-PREPROD-TEST и лаг синхронизации данных минимизированы, репликация\синхронизация данных со среды на среду автоматизирована
8 Проверки готовности среды (подтверждающие её полную консистентность и работоспособность) автоматизированы
9 Сборка билдов автоматизирована
10 Установка на среды DEV \ TEST автоматизирована
11 Установка на PREPROD \ PROD автоматизирована
12 Ручная установка на среды DEV \ TEST запрещена, у разработчиков нет прав на установку
13 Установка мобильных приложений на среды DEV \ TEST среды автоматизирована
14 Автоматизирована выкладка мобильных приложений в App Store \ Play Market
15 Ручная установка мобильных приложений на среды DEV \ TEST запрещена, у разработчиков нет прав на установку
16 Автоматизирован минимальный набор тестов, подтверждающий работоспособность приложения
17 Создание сред-сборка билдов-установка-автотесты объединены в автоматизированный пайплайн
18 Все устанавливаемые артефакты (билды) созданные в CI пайплайне хранятся в централизованном репозитории
19 Информация какой билд установлен на какую среду легко доступна для всех участников команды и является частью пайплайна
20 Билды-тесты-задачи взаимосвязаны. Связи прозрачны - билд может быть сопоставлен со спринтами\устанавливаемыми задачами и выполненными по ним тестами
21 Настроен мониторинг и репортинг по CI пайплану, алёрты и отчёты автоматически направляются участникам CI процесса
Процесс сопровождения
22 Первая линия сопровождения находится вне команды
23 По продукту существует документация и инструкции для первой линии сопровождения
24 Выбран продукт и настроен мониторинг следующих уровней:
24.1 Инфраструктура
24.2 Операционная система и среда выполнения
24.3 Сервер приложений
24.4 Клиентское приложение
25 Определены технические метрики и пороговые значения по ним. Настроен мониторинг и Dashboard с отчетностью.
26 Определены бизнес-метрики и пороговые значения по ним. Настроен мониторинг и Dashboard с отчетностью.
27 Настроен алертинг по превышению пороговых значений метрик приложений и инфраструктуры
28 Все изменения в продукте отражаются в метриках и учитываются на Dashboards
29 В продукте настроено логирование и сбор технических событий
30 В продукте настроено логирование и сбор бизнес-событий
31 Используется централизованное средство работы с логами (сбор, хранение, поиск, фильтрация)
32 У всех членов команды есть доступ к инструментам сопровождения (логи, алерты, дашборды)
33 Настроена автоматическая регулярная отчетность по работе продукта
34 Для мобильных приложений настроен автоматический сбор информации с App store\Google play
35 В продукте внедрен процесс автомасштабирования ресурсов при недостатке вычислительных мощностей
Культура \ знания \ документы
36 Есть схема развертывания продукта и регулярный процесс ее актуализации
37 Есть актуальная инструкция по алгоритму подготовки стендов
38 Настроен мониторинг и репортинг по CI пайплайну, алёрты и отчёты автоматически направляются сайзинг оборудования
39 Есть инфраструктурная схема, согласованная с заинтересованными лицами
40 Есть карта сетевых соединений, согласованная с заинтересованными лицами
41 При использовании новых технологий мы оповещаем архитекторов и заинтересованные лица
42 Собрана информация о сетевых доступах (in\out) и заведена в документацию. Выстроен процесс актуализации.
43 Есть описание процесса\соглашение об алгоритме разработки-установки-тестирования (gif flow)
44 У команды есть все доступы и права для доставки изменений dev-test-preprod-prod
45 У команды есть прозрачный процесс оценки и выделения ресурсов для продакшн
46 В команде есть роль DevOps инженера
47 Между членами команды есть sharing функций DevOps
48 В команде проповедуется и внедрен принцип автоматизации всех повторяющихся действий
49 Определен стандартный технологический стек и команда его придерживается
1 Используются средства автоматизации \ скриптования для создания инфраструктуры
2 Имплементирован подход Iaac (Infrastructure As A Code)
3 В продукте используется виртуализация, все сервера виртуальные
4 В продукте настроена контейнеризация инфраструктуры
5 Автоматизировано создание и конфигурирования ОС и среды выполнения
6 Автоматизирована подготовка и импорт\миграция данных для DEV \ TEST сред
7 Расхождение данных между средами PROD-PREPROD-TEST и лаг синхронизации данных минимизированы, репликация\синхронизация данных со среды на среду автоматизирована
8 Проверки готовности среды (подтверждающие её полную консистентность и работоспособность) автоматизированы
9 Сборка билдов автоматизирована
10 Установка на среды DEV \ TEST автоматизирована
11 Установка на PREPROD \ PROD автоматизирована
12 Ручная установка на среды DEV \ TEST запрещена, у разработчиков нет прав на установку
13 Установка мобильных приложений на среды DEV \ TEST среды автоматизирована
14 Автоматизирована выкладка мобильных приложений в App Store \ Play Market
15 Ручная установка мобильных приложений на среды DEV \ TEST запрещена, у разработчиков нет прав на установку
16 Автоматизирован минимальный набор тестов, подтверждающий работоспособность приложения
17 Создание сред-сборка билдов-установка-автотесты объединены в автоматизированный пайплайн
18 Все устанавливаемые артефакты (билды) созданные в CI пайплайне хранятся в централизованном репозитории
19 Информация какой билд установлен на какую среду легко доступна для всех участников команды и является частью пайплайна
20 Билды-тесты-задачи взаимосвязаны. Связи прозрачны - билд может быть сопоставлен со спринтами\устанавливаемыми задачами и выполненными по ним тестами
21 Настроен мониторинг и репортинг по CI пайплану, алёрты и отчёты автоматически направляются участникам CI процесса
Процесс сопровождения
22 Первая линия сопровождения находится вне команды
23 По продукту существует документация и инструкции для первой линии сопровождения
24 Выбран продукт и настроен мониторинг следующих уровней:
24.1 Инфраструктура
24.2 Операционная система и среда выполнения
24.3 Сервер приложений
24.4 Клиентское приложение
25 Определены технические метрики и пороговые значения по ним. Настроен мониторинг и Dashboard с отчетностью.
26 Определены бизнес-метрики и пороговые значения по ним. Настроен мониторинг и Dashboard с отчетностью.
27 Настроен алертинг по превышению пороговых значений метрик приложений и инфраструктуры
28 Все изменения в продукте отражаются в метриках и учитываются на Dashboards
29 В продукте настроено логирование и сбор технических событий
30 В продукте настроено логирование и сбор бизнес-событий
31 Используется централизованное средство работы с логами (сбор, хранение, поиск, фильтрация)
32 У всех членов команды есть доступ к инструментам сопровождения (логи, алерты, дашборды)
33 Настроена автоматическая регулярная отчетность по работе продукта
34 Для мобильных приложений настроен автоматический сбор информации с App store\Google play
35 В продукте внедрен процесс автомасштабирования ресурсов при недостатке вычислительных мощностей
Культура \ знания \ документы
36 Есть схема развертывания продукта и регулярный процесс ее актуализации
37 Есть актуальная инструкция по алгоритму подготовки стендов
38 Настроен мониторинг и репортинг по CI пайплайну, алёрты и отчёты автоматически направляются сайзинг оборудования
39 Есть инфраструктурная схема, согласованная с заинтересованными лицами
40 Есть карта сетевых соединений, согласованная с заинтересованными лицами
41 При использовании новых технологий мы оповещаем архитекторов и заинтересованные лица
42 Собрана информация о сетевых доступах (in\out) и заведена в документацию. Выстроен процесс актуализации.
43 Есть описание процесса\соглашение об алгоритме разработки-установки-тестирования (gif flow)
44 У команды есть все доступы и права для доставки изменений dev-test-preprod-prod
45 У команды есть прозрачный процесс оценки и выделения ресурсов для продакшн
46 В команде есть роль DevOps инженера
47 Между членами команды есть sharing функций DevOps
48 В команде проповедуется и внедрен принцип автоматизации всех повторяющихся действий
49 Определен стандартный технологический стек и команда его придерживается
Процессы и культура
Автономность
1 В команде на постоянной основе присутствуют все необходимые компетенции, чтобы вести разработку продукта без привлечения специалистов из других отделов\команд
2 Любой член команды, может эффективно подменить коллегу по команде, какой бы сложной компетенцией он ни обладал (разработка, тестирование, аналитика)
3 Наш скрам-мастер не давит на нас, и умеет развивать нас через вопросы, давая возможность найти ответ самостоятельно (коучинг)
4 У команды налажено стабильное рабочее взаимодействие с другими командами, вовлеченными в работу над продуктом
5 Принятие командой на себя обязательств не сопровождается давлением на команду
6 Микроменеджмент в команде осуществляется самой командой, а не PO/SM/иным лицом
Непрерывное улучшение
7 Мы регулярно собираемся вместе, анализируем свои успехи и препятствия, и принимаем решения об улучшениях рабочего процесса
8 Принятые на ретроспективе решения всегда отслеживаются и полностью выполняются
9 Мы сравниваем свою работу сейчас и в прошлом на основе накопленных нами данных об эффективности и производительности нашей работы
10 У нас есть метрики, на основании которых мы можем прогнозировать свою производительность(Velocity Chart / Cumulative Flow Chart)
11 Мы регулярно проводим эксперименты и пробуем новые практики
12 Мы с интересом беремся за трудные задачи
Командная координация
13 У меня нет препятствий к тому, чтобы обратиться с вопросом или за помощью к коллеге с другой компетенцией (аналитик, разработчик, фронтенд)
14 Каждый день, в одно и то же время мы собираемся вместе и синхронизируем свою работу,чтобы знать, кому нужна помощь, и кто на сколько далеко продвинулся
15 В команде есть практика совместной разработки - разные разработчики делают разные части одной задачи, чтобы быстрее справиться с ней
16 Для нас обычная ситуация, когда мы разрабатываем продукт в тесном взаимодействии с другими командами. Это всегда эффективно, ускоряет разработку, и дает отличный результат
17 Живой диалог считается естественной и достаточной формой согласования рабочих вопросов. Договоренности фиксируются.
18 Распределение задач происходит на основании понимания всей командой оптимальности такого распределения
19 В команде принято озвучивать наличие свободного времени и\или возможности помочь другим членам команды
Прозрачность работы
20 Мы регулярно (не реже, чем раз в 2 недели) показываем заинтересованным лицам и заказчикам готовую к поставке часть работы
21 Мы визуализируем свой процесс работы в виде потока задач на доске, так что легко понять на какой стадии сейчас находится работа по продукту
22 Мы вместе вырабатываем общее видение бизнес-ценности задачи, прежде чем взять ее в работу
23 Все понимают, чем в целом сегодня занимается каждый человек в команде
24 Все заинтересованные лица знают, где и как получить оперативную информацию о состоянии интересующих их задач
25 У команды есть среднесрочное планирование и понимание среднесрочных целей
26 У команды есть RoadMap задач на квартал
27 В команде есть публичный план и описание будущих релизов
Фокус
28 Мы ставим цели и получаем результат без лишних отвлечений и проволочек
29 Каждый из участников команды имеет возможность сосредоточиться только на одной задаче, без распыления усилий
30 Мы доводим задачи, за которые беремся, до внедрения
31 Мы выполняем на себя взятые обязательства по срокам
32 У нас не бывает задач, которые взяты в работу, но остаются в одинаковой стадии готовности по несколько дней
Обязательства
33 Мы способны влиять на факторы вне нашей команды
34 Мы никогда не ищем причину своих проблем и неудач в других командах или людях
35 Невыполненные обещания из-за проблем у одного из членов команды означает, то остальные члены команды вовремя не оказали необходимую помощь
36 Каждый участник команды ставит командные цели выше своих личных локальных целей
37 Каждый из участников команды отвечает за общий результат
Вовлеченность
38 Большую часть времени каждый знает, что делать, зачем нужна его работа и текущая деятельность воспринимается как интересная
39 Мы с радостью приходим на работу каждый день
40 Мы искренне заинтересованы в создании первоклассного продукта
41 У нас нет в работе лишних или неактуальных задач
42 Я знаю и чувствую свою долю вложения в общее дело и горжусь этой сопричастностью
Уважение
43 Мы не держим обид на своих коллег и других людей в компании
44 Мы не ищем и не назначаем виноватых в случае проблем, а ищем пути решения
45 У нас есть позитивный опыт решения конфликта на основе взаимного уважения
46 Мы умеем конструктивно обсуждать проблемы даже когда эмоции на пределе
47 Мы умеем признавать себя неправыми
48 Чем больше времени мы работаем вместе, тем реже у нас возникают конфликты и напряжения
Открытость
49 Мы без сомнений поднимаем любые темы, которые нас волнуют, даже если они конфликтные
50 Мы не мешаем другим людям в команде пробовать реализовывать свои идеи, даже если онинам не полностью понятны или не кажутся перспективными
51 Мы открыто выражаем свою точку зрения
52 Мы не прибегаем к личным обвинениям, апеллируем к общему командному результату
53 Мы открыто выражаем свои чувства
54 Мы внимательно выслушиваем и искренне пытаемся понять других, даже когда нам кажется, что они не правы
55 Мы легко признаем свои ошибки
56 Юмор широко присутствует, но остается в рамках не переходящих грань сарказма, высмеивания, навязывания чувства ущербности
57 Мы приветствуем изменения - они нам дают новый опыт и возможности
Принятие решений
58 Мы уделяем достаточно времени обсуждению при принятии важных решений
59 Мы никогда не застреваем и не ходим кругами во время групповых обсуждений
60 У нас есть ясное понимание модели\процесса принятия решений по большинству вопросов в команде
61 Во время групповых обсуждений мы обычно сохраняем позитивный настрой
62 Во время групповых обсуждений все мы в основном остаемся вовлечены в процесс
63 В процессе обсуждения решений мы предлагаем, а не критикуем
1 В команде на постоянной основе присутствуют все необходимые компетенции, чтобы вести разработку продукта без привлечения специалистов из других отделов\команд
2 Любой член команды, может эффективно подменить коллегу по команде, какой бы сложной компетенцией он ни обладал (разработка, тестирование, аналитика)
3 Наш скрам-мастер не давит на нас, и умеет развивать нас через вопросы, давая возможность найти ответ самостоятельно (коучинг)
4 У команды налажено стабильное рабочее взаимодействие с другими командами, вовлеченными в работу над продуктом
5 Принятие командой на себя обязательств не сопровождается давлением на команду
6 Микроменеджмент в команде осуществляется самой командой, а не PO/SM/иным лицом
Непрерывное улучшение
7 Мы регулярно собираемся вместе, анализируем свои успехи и препятствия, и принимаем решения об улучшениях рабочего процесса
8 Принятые на ретроспективе решения всегда отслеживаются и полностью выполняются
9 Мы сравниваем свою работу сейчас и в прошлом на основе накопленных нами данных об эффективности и производительности нашей работы
10 У нас есть метрики, на основании которых мы можем прогнозировать свою производительность(Velocity Chart / Cumulative Flow Chart)
11 Мы регулярно проводим эксперименты и пробуем новые практики
12 Мы с интересом беремся за трудные задачи
Командная координация
13 У меня нет препятствий к тому, чтобы обратиться с вопросом или за помощью к коллеге с другой компетенцией (аналитик, разработчик, фронтенд)
14 Каждый день, в одно и то же время мы собираемся вместе и синхронизируем свою работу,чтобы знать, кому нужна помощь, и кто на сколько далеко продвинулся
15 В команде есть практика совместной разработки - разные разработчики делают разные части одной задачи, чтобы быстрее справиться с ней
16 Для нас обычная ситуация, когда мы разрабатываем продукт в тесном взаимодействии с другими командами. Это всегда эффективно, ускоряет разработку, и дает отличный результат
17 Живой диалог считается естественной и достаточной формой согласования рабочих вопросов. Договоренности фиксируются.
18 Распределение задач происходит на основании понимания всей командой оптимальности такого распределения
19 В команде принято озвучивать наличие свободного времени и\или возможности помочь другим членам команды
Прозрачность работы
20 Мы регулярно (не реже, чем раз в 2 недели) показываем заинтересованным лицам и заказчикам готовую к поставке часть работы
21 Мы визуализируем свой процесс работы в виде потока задач на доске, так что легко понять на какой стадии сейчас находится работа по продукту
22 Мы вместе вырабатываем общее видение бизнес-ценности задачи, прежде чем взять ее в работу
23 Все понимают, чем в целом сегодня занимается каждый человек в команде
24 Все заинтересованные лица знают, где и как получить оперативную информацию о состоянии интересующих их задач
25 У команды есть среднесрочное планирование и понимание среднесрочных целей
26 У команды есть RoadMap задач на квартал
27 В команде есть публичный план и описание будущих релизов
Фокус
28 Мы ставим цели и получаем результат без лишних отвлечений и проволочек
29 Каждый из участников команды имеет возможность сосредоточиться только на одной задаче, без распыления усилий
30 Мы доводим задачи, за которые беремся, до внедрения
31 Мы выполняем на себя взятые обязательства по срокам
32 У нас не бывает задач, которые взяты в работу, но остаются в одинаковой стадии готовности по несколько дней
Обязательства
33 Мы способны влиять на факторы вне нашей команды
34 Мы никогда не ищем причину своих проблем и неудач в других командах или людях
35 Невыполненные обещания из-за проблем у одного из членов команды означает, то остальные члены команды вовремя не оказали необходимую помощь
36 Каждый участник команды ставит командные цели выше своих личных локальных целей
37 Каждый из участников команды отвечает за общий результат
Вовлеченность
38 Большую часть времени каждый знает, что делать, зачем нужна его работа и текущая деятельность воспринимается как интересная
39 Мы с радостью приходим на работу каждый день
40 Мы искренне заинтересованы в создании первоклассного продукта
41 У нас нет в работе лишних или неактуальных задач
42 Я знаю и чувствую свою долю вложения в общее дело и горжусь этой сопричастностью
Уважение
43 Мы не держим обид на своих коллег и других людей в компании
44 Мы не ищем и не назначаем виноватых в случае проблем, а ищем пути решения
45 У нас есть позитивный опыт решения конфликта на основе взаимного уважения
46 Мы умеем конструктивно обсуждать проблемы даже когда эмоции на пределе
47 Мы умеем признавать себя неправыми
48 Чем больше времени мы работаем вместе, тем реже у нас возникают конфликты и напряжения
Открытость
49 Мы без сомнений поднимаем любые темы, которые нас волнуют, даже если они конфликтные
50 Мы не мешаем другим людям в команде пробовать реализовывать свои идеи, даже если онинам не полностью понятны или не кажутся перспективными
51 Мы открыто выражаем свою точку зрения
52 Мы не прибегаем к личным обвинениям, апеллируем к общему командному результату
53 Мы открыто выражаем свои чувства
54 Мы внимательно выслушиваем и искренне пытаемся понять других, даже когда нам кажется, что они не правы
55 Мы легко признаем свои ошибки
56 Юмор широко присутствует, но остается в рамках не переходящих грань сарказма, высмеивания, навязывания чувства ущербности
57 Мы приветствуем изменения - они нам дают новый опыт и возможности
Принятие решений
58 Мы уделяем достаточно времени обсуждению при принятии важных решений
59 Мы никогда не застреваем и не ходим кругами во время групповых обсуждений
60 У нас есть ясное понимание модели\процесса принятия решений по большинству вопросов в команде
61 Во время групповых обсуждений мы обычно сохраняем позитивный настрой
62 Во время групповых обсуждений все мы в основном остаемся вовлечены в процесс
63 В процессе обсуждения решений мы предлагаем, а не критикуем
