Начать. Это бесплатно
или регистрация c помощью Вашего email-адреса
SM School создатель Mind Map: SM School

1. Спринт ревью

1.1. Демо (команда + пользователи)

1.1.1. Демонстрация инкремента

1.1.2. Получение фидбека

1.2. Подведение итогов (команда + стейкхолдеры)

1.2.1. Обзор метрик

1.2.2. Обзор прод инцидентов

1.2.3. Анализ результатов продуктовых экспериментов

1.2.4. Ревью Roadmap продукта

2. Создание команды

2.1. 4 столпа

2.1.1. Цель

2.1.2. Ценности

2.1.3. Компетенции

2.1.4. Полномочия

2.2. Роли в команде (модель Белбина)

2.3. Жизненный цикл команды (модель Такмана)

2.3.1. Forming

2.3.2. Storming

2.3.3. Norming

2.3.4. Performing

3. Управленческий цикл

3.1. Модель Кеневин

3.1.1. Simple/Obvious

3.1.2. Complicated

3.1.3. Complex

3.1.4. Chaotic

3.2. Типы подходов

3.2.1. Продукт

3.2.2. Проект

3.2.3. Операционная деятельность

3.3. Петли обратной связи

3.3.1. Что хотите контролировать

3.3.2. Что покажет, что (не)произошло?

3.3.3. Как получите информацию?

3.3.4. Ваши действия

3.3.5. Как поддерживать механизм ОС долго

3.4. Модели

3.4.1. HADI

3.4.2. PDCA

4. Визуализация продукта и проекта

4.1. Доска задач (Scrum, Kanban)

4.2. Sprint burndown

4.3. Dashboards

4.4. Диаграмма Гантта

4.5. User story mapping

4.6. Customer journey map

5. People management

5.1. Конструктивная конфронтация

5.1.1. Адресность

5.1.2. Своевременность

5.1.3. Данные и факты

5.1.4. Фокус на проблеме

5.2. Типология людей

5.2.1. DISC

5.2.2. PAEI (Адизес)

5.3. Встречи 1:1

5.3.1. Ice-break

5.3.2. Что ты хочешь обсудить?

5.3.3. Прошлые договоренности

5.3.4. Текущие вопросы

5.3.5. Договоренности на будущее

5.4. Принципы коммуникации "5П"

5.4.1. Полезность

5.4.2. Понятность

5.4.3. Презсказуемость

5.4.4. Прозрачность

5.4.5. Последовательность

6. Управление изменениями

6.1. Алгоритм

6.1.1. Текущее состояние

6.1.2. Желаемое сост ояние

6.1.3. План достижения

6.2. Снижение сопротивления

6.2.1. Информировать о том, зачем

6.2.2. Обсуждать план внедрения

6.2.3. Собирать обратную связь

6.2.4. Быть готовым изменить или откатить

6.3. Инкрементация

6.3.1. Горизонтальная

6.3.2. Вертикальная

6.4. PDCA цикл

6.4.1. Plan

6.4.2. Do

6.4.3. Check

6.4.4. Act

6.5. Чем выше неопределенность

6.5.1. Правила проще

6.5.2. Результаты чаще

6.5.3. Обратная связь чаще

6.5.4. Структура гибче

7. Продажа идей

7.1. Когда говорить об идеях?

7.1.1. Изучаем контекст

7.1.1.1. Стадия (модель Такмана)

7.1.1.2. Среда (модель Кеневин)

7.1.1.3. Батарейка команды

7.1.2. В зависимости от контекста настраиваем:

7.1.2.1. Интенсивность продаж

7.1.2.2. Детализированность идей при продаже

7.1.2.3. Количество продаж

7.2. Об одном ли говорим?

7.2.1. Проверяем общее понимание

7.2.1.1. Цели

7.2.1.2. Общие термины

7.3. С кем и о чем говорить?

7.3.1. Кому выгодны изменения?

7.3.1.1. Чью боль исправляем

7.3.1.2. Кто ЦА

7.3.2. Кто принимает решение?

7.3.2.1. Выделение ЛПР и как изменение поможет им

7.3.2.2. Выделение ЛВР и как изменение поможет им

7.3.3. Ищем Стейкхолдеров, связанных с проектом

7.3.3.1. Учитываем затрагивает ли их изменение

7.3.3.2. При необходимости согласовываем / уведомляем

7.4. Как говорить?

7.4.1. DISC

7.4.2. PAEI

7.5. Внедрение идей

7.5.1. Формирование рабочих групп

7.5.2. Внедрение и поддержка

7.5.3. Получение обратной связи

7.6. Откуда брать идеи

7.6.1. Кейсы коллег

7.6.2. Обратные связи

7.6.3. Различные виды мозгового шторма

7.6.3.1. МОДЕЛЬ SCAMPER

7.6.3.2. ОБРАТНЫЙ МОЗГОВОЙ ШТУРМ

7.6.3.3. МЕТОД ФОКАЛЬНЫХ ОБЪЕКТОВ

8. Декомпозиция и планирование

8.1. Acceptance criteria

8.1.1. Пишутся с точки зрения пользователя

8.1.2. Краткие, однозначно понимаемы

8.1.3. Уникальны для каждой конкретной задачи

8.2. Definition of done

8.2.1. Может включать в себя как технические аспекты, так и этапы выполнения работ

8.2.2. В идеале - пишутся в виде чеклиста

8.2.3. Формулируются в таком виде, что всегда можно ответить “да” или “нет” на вопрос выполнено ли

8.2.4. Распространяются на все задачи/класс задач

8.3. Инкрементальная декомпозиция

8.3.1. Быстрая доставка бизнес-ценности

8.3.2. Хорошо снижает неопределенность

8.3.3. Простота тестирования

8.3.4. Снижается риск регрессионных проблем

8.3.5. Код ревью делается для меньшего количества строк за раз

8.3.6. Разбиение задач сложнее, чем для компонентной

8.3.7. Требовательна к уровню команды

8.3.8. Требует частых релизов

8.3.9. Ниже точность планирования

8.4. Компонентная декомпозиция

8.4.1. Проще, чем инкрементальная

8.4.2. При грамотной проработке показывает хорошие результаты даже с джунами

8.4.3. Каждый занимается своим делом, люди не мешают друг другу

8.4.4. Чаще всего проблемы возникают при интеграции задач

8.4.5. Требует ОЧЕНЬ детальной проработки точек интеграции

8.4.6. Требует много менеджмента чтобы пазл сложился

8.4.7. Плохо снижает неопределенность

8.5. Чеклист декомпозиции

8.5.1. Понятно, что нужно сделать чтобы задача была выполнена

8.5.2. Есть понимание как контролировать прогресс задачи

8.5.3. Полученные задачи пригодны для передачи исполнителям

8.5.4. Есть понимание, как интегрировать подзадачи между собой

9. Метрики

9.1. Ключевые вопросы

9.1.1. Что вы хотите узнать?

9.1.2. Что будете делать?

9.1.3. С какими метриками связано?

9.1.4. Зачем это нужно команде?

9.1.5. Данные-то качественные?

9.2. Типы метрик

9.2.1. Продуктовые

9.2.1.1. AARRR

9.2.1.2. LTV

9.2.1.3. Retention

9.2.1.4. Churn rate

9.2.2. Проектные

9.2.2.1. EVA

9.2.2.2. Burndown

9.2.2.3. Buffer

9.2.3. Качества

9.2.3.1. Bugs per ticket rate

9.2.3.2. Delivery on time rate

9.2.3.3. Escaped defects

9.2.3.4. Issue types

9.2.4. Производительности команды

9.2.4.1. Throughput

9.2.4.2. Velocity

9.2.4.3. Lead time

9.2.5. Инфраструктурные

9.2.5.1. Latency

9.2.5.2. Disk free space

9.2.5.3. Certificate lifespan

9.2.5.4. Free RAM

9.3. Метрики CFD

9.3.1. Время

9.3.1.1. Lead time

9.3.1.2. Cycle time

9.3.1.3. Wasted time

9.3.2. Объем

9.3.2.1. WorkInProgress

9.3.2.2. RemainingToBeDone

9.3.3. Относительные

9.3.3.1. Effectiveness

10. Ретроспектива

10.1. Принципы

10.1.1. Без переходов на личности

10.1.2. Отделяйте факты от предположений и опасений

10.1.3. Опыт и мнение каждого участника важны

10.1.4. Конструктивное несогласие - это нормально

10.1.5. Blameless environment

10.1.6. Исключите авторитарность

10.2. Состав

10.2.1. Ice-break

10.2.2. Сбор данных

10.2.3. Генерация идей

10.2.4. Выбор решений

10.2.5. Закрытие

10.3. Форматы

10.3.1. Like/Wish/Wonder

10.3.2. Well done/Good fail/Bad fail

10.3.3. Кораблик

10.3.4. Stop/Start/More/Less/Keep

11. SCRUM

11.1. Роли

11.1.1. Владелец продукта

11.1.2. Scrum-мастер

11.1.3. Команда

11.2. События

11.2.1. Спринт

11.2.2. Планирование спринта

11.2.2.1. Цель спринта

11.2.2.2. Оценка задач

11.2.3. Ежедневный Scrum

11.2.4. Обзор спринта

11.2.5. Ретроспектива спринта

11.3. Артефакты

11.3.1. Бэклог продукта

11.3.2. Бэклог спринта

11.3.3. Инкремент

12. Kanban

12.1. Роли

12.1.1. Менеджер Запросов для Сервиса

12.1.2. Менеджер Поставки для Сервиса

12.1.3. Команда

12.2. Практики

12.2.1. Визуализируйте

12.2.1.1. Доска Kanban

12.2.2. Ограничивайте незавершённую работу

12.2.3. Управляйте потоком работы

12.2.3.1. Классы работы

12.2.4. Используйте явные правила

12.2.5. Используйте петли обратной связи

12.2.6. Улучшайтесь и эволюционируйте