Про канбан

Get Started. It's Free
or sign up with your email address
Про канбан by Mind Map: Про канбан

1. Agile

1.1. динамическое формирование требований

1.2. самоорганизующиеся рабочие группы

1.3. серии коротких циклов (итерации)

1.4. Основные идеи

1.5. Принципы

2. SCRUM

2.1. 9 правил

2.1.1. PO

2.1.2. Scrum master

2.1.3. Команда

2.1.4. Product backlog и sprint backlog

2.1.5. Sprint planing meeting

2.1.6. Daily scrum

2.1.7. Sprint review

2.1.8. Burndown chart

2.2. маленькие, кросс-функциональные, самоорганизующиеся команды

2.3. Разделите Вашу работу на маленькие, конкретные компоненты

2.4. Оптимизируйте план релиза и корректируйте приоритеты совместно с клиентом, основываясь на данных, получаемых при рассмотрении релиза после каждой итерации.

2.5. Оптимизируйте процесс с помощью проведения ретроспективы после каждой итерации.

3. Kanban

3.1. Визуализируйте поток работ

3.1.1. Типы задач

3.1.1.1. Фиксированная дата

3.1.1.2. Фича

3.1.1.3. Баг

3.1.1.4. Техническое

3.1.2. Правила для этапов

3.2. Ограничьте WIP

3.2.1. Ценность поставки

3.2.2. Скорость поставки

3.3. Управление потоком

3.3.1. Уменьшение Lead Time (время ожидания)

3.3.2. Flow diagram

4. Сравнение

4.1. RUP XP SCRUM Kanban

4.2. RUP

4.2.1. RUP - избавиться от лишнего. Scrum – добавить недостающее.

4.2.2. 30 ролей

4.2.3. >20 мероприятий

4.2.4. >70 артефактов

4.3. XP

4.3.1. SCRUM + инженерные практики типа TDD и парное программирование

5. Как влиять и развивать процесс

5.1. Scrum и Kanban являются эмпирическими

5.1.1. Количество людей

5.1.2. Ограничения WIP

5.1.3. Длинна итерации

5.1.4. Частота и качество планирования

5.1.5. и т.д.

5.2. SCRUM

5.2.1. Команды должны быть кросс-функциональными

5.2.2. Команда определяет, какой объем работы взять на спринт

5.2.3. Команда определяет длительность спринта

5.2.4. Измеряют скорость

5.2.5. План спринта не меняется

5.3. Kanban

5.3.1. Может быть на несколько команд

5.3.2. Должны ограничивать WIP

5.3.3. Нет спринтов

5.3.4. Измеряют время ожидания

5.3.5. Легко добавить задачу в начало

6. Заключение

6.1. Движение задач назад

6.1.1. Вносит хаос

6.1.2. Нарушает ограничения

6.1.3. Приоритет теряется

6.1.3.1. Задачи ближе к завершению важнее завершить

6.1.4. Есть новые знания

6.1.4.1. Новые требования или сценарий воспроизведения

6.1.4.2. Новый код

6.1.4.3. Опять ревью

6.1.4.4. Еще раз тестирование

6.1.5. Легко решается

6.1.5.1. Помечать и заводить связанную задачу

6.1.5.2. Дополнить тестирование bugfixing

6.2. Ценность для пользователя

6.2.1. Чаще устанавливать пользователю

6.2.2. Собирать ОС

6.2.3. Корректировать план и требования

6.3. Busfactor

6.3.1. CI, Unit tests, Codereview

6.3.2. Документирование также необходимо

6.4. Долгосрочное планирование

6.4.1. Перспектива

6.4.2. Риски

6.4.3. Приоритезация задач

6.5. Вопросы?

6.5.1. Было интересно?

6.5.2. Что-то новое узнали?

6.5.3. Согласны с данными подходами? Готовы применять?