solit 2014, scrum для большого проекта. Как это работает на...

Константин СлисенкоJazzTeam

Scrum для большого проектаКак это работает на

практике

О проекте❏ CRM-система❏ 73 региона, 20 тыс пользователей,

60 миллионов клиентов❏ Распределенная команда ~100

человек (большая часть в Москве)❏ Сочетание Scrum, Agile и

традиционных методологий❏ Поставка в прод новой версии

каждые 2 недели❏ Основа - коробочный продукт

Amdocs CRM CRM 8.1

Почему Agile/ScrumПервое внедрение❏ Строительство нового здания для центра обслуживания

клиентов, закупка нового оборудования, мебели и т.д.❏ Закрытие маленьких региональных офисов, перевод

сотрудников в новое здание

Новый центр должен работать на нашей CRM!Дата запуска центра чётко обозначена!

Реальный пример agile-заказчика:❏ Важна работающая версия в конце каждой короткой

итерации чтобы в любой момент начать внедрение❏ Если не укладываемся в сроки - режем скоуп❏ Активная заинтересованность в процессе разработки

Почему Agile/Scrum

В итоге❏ Разработать CRM успели❏ Здание не приняли сразу, строительство

не успело в срок

Scrum оправдал себя

Подходы к процессамПреимущества agile/scrum❏ Постоянно рабочая версия системы❏ Минимальный риск сделать не то, что хочет

заказчик❏ Следуем приоритетам, не делаем лишнего❏ Быстрое развитие команд, более быстрый

въезд новых разработчиков❏ Фокус на готовом функционале, а не на

спецификациях❏ Маленький прирост функционала после

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

Когда не совсем подходит agile/scrum❏ Заказчик не понимает scrum, и

scrum - это не то что он хочет❏ Крупный заказчик не хочет

формально принимать проект по маленьким кусочкам

❏ Бюрократия, много стадий согласований, заказчик хочет много документации

❏ Scrum плохо работает для fixed time, price, scope

❏ Много человек на проекте (около 100)

Успех = комбинация подходовСвойственно agile/scrum❏ Разделение на небольшие мобильные

команды❏ Короткие двухнедельные спринты, частые

демо, планирования, scrum poker, story mapping, ежедневные митинги, ретроспективы

❏ Нет чёткой специализации среди разработчиков, “все делают всё”

❏ Применение scrum of scrums для объединения команд

❏ Добавление небольшой части нового функционала после каждого спринта❏ используем feature toggling

Мало свойственно agile/scrum❏ Планирование надолго вперёд в

виде release vision на несколько месяцев

❏ Формальная сдача проекта большими кусками, фиксированные сроки

❏ Использование системы управления требованиями, поддержка большого количества документации

Структура проекта

С точки зрения заказчика (по функциональности)❏ Продажи❏ Корпоративные клиенты❏ Техподдержка❏ Обслуживание❏ Удержание

С точки зрения разработчиков (по компонентам)

❏ Бизнес анализ❏ Разработка CRM❏ Интеграция❏ Миграция❏ Администрирование❏ Тестирование

Каким образом построены команды

Интеграторы

Миграторы

Администраторы

Архитектурный комитет (scrum of scrums)

скрам-мастер5 разработчиковтестировщикавтоматизатор

Бизнес-анализ

Разработка

Интеграция

Миграция

Администрирование

Корпоративные клиенты

Техподдержка Продажи

Синхронные спринты



Общее демо

Общий транк

Функциональность

Процессы - обо всём по порядку

Составление Release Vision❏ цели❏ требования, ограничения❏ сроки❏ архитектурные риски,

способы борьбы❏ ответственные аналитики

Story mapping по каждому процессуобсуждение одного бизнес- процесса❏ составление user stories❏ приоретизация

времяvision story-mapping

Планирование

1. Предварительное планирование❏ Во время спринта❏ То что будем делать потом

(возможно в следующем спринте)2. Основное планирование

❏ В начале спринта❏ Только то, что разбирали раньше на преплане

3. Допланирование❏ Если сделали всё раньше❏ Аналитики не подготовили достаточно историй

Планирование итеративное, как и сама разработка

Структура скрама

Архитектурный комитет (scrum of scrums)




Представители команд, руководители разработки, бизнес-анализа, архитектор

обсуждается новый функционал, планы на будущее

Каждая команда проводит отдельно1. планирования2. митинги3. ретроспективы

Демо общее

Planning poker

На перплане (общая оценка историй)

2 4 8 16

На планировании (оценка для каждой задачи в рамках истории)

1 3 5 8 13

❏ Результат - не средняя оценка!❏ Соглашаемся на уровне команды

на одну из оценок

Ежедневный scrum-митинг1. какие задачи сделаны?2. какие не сделаны?3. почему не сделаны?4. почему лень - не ответ на пункт 3

❏ Выяснить вопросы с аналитиками❏ Сообщить о проблеме команде❏ Дать понять тестировщикам что можно проверять❏ Договориться о реализации чего-либо с другими

разработчиками

время

УчастникиАналитикиСкрам-мастерКоманда

текущий спринтvision story-mapping

Предварительное планирование

❏ имеем описанную бизнес-задачу❏ задаём вопросы для дальнейшей

проработки требований❏ предлагаем высокоуровневую

реализацию❏ даём общую оценку истории по

сложности (2, 4, 8, 16)❏ препланируем на следующий спринт!

время

УчастникиПредставитель заказчикаАналитикиСкрам-мастерКомандаПредставители других команд

vision story-mapping

3 преплана

текущий спринт

Планирование

❏ то что разбирали на преплане❏ все вопросы выяснены!❏ есть спецификации интерфейсов

сторонних систем❏ разбиение на маленькие задачи❏ оцениваем каждую задачу

(1, 3, 5, 8, 13)

время

УчастникиАналитикиСкрам-мастерКомандаПредставители других команд

следующий спринтпланированиеvision story-mapping

3 преплана


ДемоDefinition of done❏ в новом функционале нет багов❏ не сломали существующий функционал❏ новый функционал задеплоен на систему заказчика

Демо❏ внутреннее и внешнее❏ общее для всех команд❏ аналитик зачитывает историю❏ показываем, отвечаем на вопросы❏ аналитик приминает решение

❏ принято❏ принято с замечаниями (фикс в следующем спринте)❏ не принято

время

демо

- Деда, деда, смотри, Exception!- Т-сс, что не видишь, демо идёт, глянь что демоны вытворяют.

* Де́мон — компьютерная программа в системах класса UNIX, запускаемая самой системой и работающая в фоновом режиме (википедия)


3 преплана


Ретроспектива❏ Отдельная для каждой команды (никто не запрещает сходить поругаться к соседям)❏ Составление доски замечаний (snake on the board)

❏ каждое замечение назначается на исполнителя❏ скрам-мастер следит чтобы все замечания были решены за спринт

время

демо и ретроспектива


3 преплана


Долгое ревью, виноват Вася!

Нечёткие требования по историям техподдержки

“Плохой код” в логике назначения заявки

Частые изменения требований, пришлось много переделывать

Косяк на демо, не заработала интеграция со сторонней системой

ПримерРазработка простой CRM-системы

1. Бизнес-требования2. Release vision3. Story mapping

1. Бизнес-требования

Тех. поддержкаКлиент Тех. обслуживание

Реализация процесса технической поддержки❏ Клиент звонит в

поддержку❏ Оператор создаёт заявку

в системе❏ Специалист по

техническому обслуживанию выполняет ремонт

Заявка Клиенты

ФИО Номер пасспорта

Иванов Иван 12312

Петров Вася 31241

ПоискОписание

Сохранить

РешенаТребует решения

Текущий функционал CRM

1. Выбираем клиента

2. Заполняем заявку

3. Сохраняем

Новый функционал CRM

Тех. поддержкаКлиент Тех. обслуживание

Клиент с признаком оттока

Тех. поддержка

Кризис-менеджер

❏ Добавляется новая роль - кризис-менеджер

2. Пример release visionRelease 1.0 Старт: 10.12.2013

Завершение: 10.03.2014

Цели релиза Функциональные требования

Бизнес1. Запуск подразделения обслуживания клиентов на платформе CRM2. Уменьшение ухода клиентов благодаря взаимодействию с ними специального сотрудника кризис-менеджера (запуск процесса удержания)Технические1. Добиться устойчивой работы системы в минимальном функционале

1. Поиск заявок2. Поиск клиентов3. Назначение заявок на кризис-

менеджера4. Повышение приоритетов заявок

отточных клиентов5. Отображение признака отточных

клиентов на карточке клиента

Границы релиза Архитектурные риски

Бизнес1. Процессы: техподдержка,

удержание 2. Территория запуска: урал, сибирь

Технические1. Использование существующей

платформы CRM

Новая клиентская модель - способы борьбы:1. быстрое прототипирование2. консультации у заказчика

Ответственные аналитики: Иванов Иван, Петров Вася

время

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

Release plan UAT Bugfixing

Клиент Специалист ТП Кризис-менеджер Специалист ТО

Добавляем карточки участников процесса

Позвонить в ТП

Принять звоноки создать заявку с признаком оттока

Выбрать заявку, сделать ремонт

Выбрать заявку и позвонить клиенту

Передать заявку на ТО


Отследить выполнение заявки, перезвонить клиенту

Добавляем действия участников процесса





Заведение роли для КМ

Разделить список заявок для КМ и ТО

Кнопка пере- направления заявки в ТО


Галочка оттока на форме заявки



Покрываем минимальный функционал







Добавление признака оттока на карточку клиента

Возможность снятия признака оттока с карточки пользователя вручную - только для КМ




Отдельный список с отточными клиентами



Наращиваем функционал






Автоматическое повышение приоритета всех заявок отточного клиента








Email-нотификация при появлении отточного клиента



Email-нотификация для КМ при выполнении отточной заявки






Автоматическое повышение приоритета всех заявок отточного клиента








Email-нотификация при появлении отточного клиента



Email-нотификация для КМ при выполнении отточной заявки

Sprint 1

Sprint 2

Sprint 3

Story mapping

❏ Хорошая модель для дискуссий и коллективного разума❏ Выделяет пользовательские истории из требований❏ Приоретизирует бэклог❏ Хорошо визуализирует функционал, нужный

пользователю, даёт лучшее понимание проекта❏ Позволяет выделить наиболее маленькую часть

доработок, для максимальной бизнес-ценности❏ Помогает видеть проект в целом

Процессы разработкиСинхронные спринты для всех команд❏ Полный регресс❏ Общее демо❏ В конце итерации - codefreeze❏ Поставка в прод после каждого

спринта

SVN❏ Один транк ❏ Одна ветка прошлого релиза (для хот-

фиксов, сразу мерж в основную ветку)❏ Комиты только по задачам

❏ Continuous integration + автотесты❏ Деплой на тестовую среду из

jenkins, делают все кому необходимо

❏ Размножение команд почкованием

Jira Agile (Greenhopper)

❏ Все задачи в Jira❏ Истории располагаются по

приоритету сверху вниз❏ Каждая задача проходит через

ревью❏ Отдельный таск по тестированию,

включает написание тест-кейсов❏ Разработчики не

специализируются на конкретных типах задач

❏ По скраму работают все: аналитики, админы, миграторы, …❏ у каждой команды своя доска

Времязатраты нашего скрамаПрепланы3 раза по 1 часу втечение спринта

Демо, планирование, ретроспектива1 день в спринт

Скрам-митинги15-20 минут в день

КодфризПосле кодфриза нельзя делать новые истории, не успели доделать - откатываем2 дня выделяется на фиксы багов и доработки

Story mapping, архитектурный комитет?

Бывает что историю быстрее реализовать, чем отводится время на планирование

Итоги

Плюсы скрама❏ хороший фундамент для саморазвития

команд, обмена опытом❏ помогает приоритезировать, не делать

лишней работы❏ подходит когда у вас хаос

Минусы скрама❏ довольно затратный, много времени

тратится на общение❏ нужно модифицировать процессы

❏ Никто не застрахован от переделок при нечёткой формулировке задачи

❏ Теряется эффективность при отсутствии специализации

❏ Нет возможности оценивать каждого сотрудника в отдельности

❏ Оценка в абстрактных единицах не привязана ко времени

Не стоит работать 100% по скраму как написано в книжке

❏ комбинируем подходы❏ делаем свой скрам, берём всё

лучшее

Do things right! а не do right things

Agile = work and travel

Всё будет хорошо, главное - мотивация

Спасибо за внимание!

[email protected]

Вопросы?

solit 2014, scrum для большого проекта. Как это работает на...

Technology

vision story

story mapping

scrum

agilescrum

crm

email

scrums