Solit 2014, Scrum для большого проекта. Как это работает на практике, Слисенко Константин
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Solit 2014, Scrum для большого проекта. Как это работает на практике, Слисенко Константин

on

  • 143 views

Слисенко Константин, Минск. Компания JazzTeam, Senior Software Engineer ...

Слисенко Константин, Минск. Компания JazzTeam, Senior Software Engineer

«Scrum для большого проекта. Как это работает на практике». Development секция. Agile отделение.
«MapReduce и машинное обучение на Hadoop и Mahout». Development секция. Для разработчиков. Высокий уровень подготовки.

Statistics

Views

Total Views
143
Views on SlideShare
127
Embed Views
16

Actions

Likes
0
Downloads
1
Comments
0

2 Embeds 16

http://solit.isoligorsk.org 13
http://www.slideee.com 3

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Solit 2014, Scrum для большого проекта. Как это работает на практике, Слисенко Константин Presentation Transcript

  • 1. Константин Слисенко JazzTeam Scrum для большого проекта Как это работает на практике
  • 2. О проекте ❏ CRM-система ❏ 73 региона, 20 тыс пользователей, 60 миллионов клиентов ❏ Распределенная команда ~100 человек (большая часть в Москве) ❏ Сочетание Scrum, Agile и традиционных методологий ❏ Поставка в прод новой версии каждые 2 недели ❏ Основа - коробочный продукт Amdocs CRM CRM 8.1
  • 3. Почему Agile/Scrum Первое внедрение ❏ Строительство нового здания для центра обслуживания клиентов, закупка нового оборудования, мебели и т.д. ❏ Закрытие маленьких региональных офисов, перевод сотрудников в новое здание Новый центр должен работать на нашей CRM! Дата запуска центра чётко обозначена! Реальный пример agile-заказчика: ❏ Важна работающая версия в конце каждой короткой итерации чтобы в любой момент начать внедрение ❏ Если не укладываемся в сроки - режем скоуп ❏ Активная заинтересованность в процессе разработки
  • 4. Почему Agile/Scrum В итоге ❏ Разработать CRM успели ❏ Здание не приняли сразу, строительство не успело в срок Scrum оправдал себя
  • 5. Подходы к процессам Преимущества agile/scrum ❏ Постоянно рабочая версия системы ❏ Минимальный риск сделать не то, что хочет заказчик ❏ Следуем приоритетам, не делаем лишнего ❏ Быстрое развитие команд, более быстрый въезд новых разработчиков ❏ Фокус на готовом функционале, а не на спецификациях ❏ Маленький прирост функционала после каждого спринта, нет риска повалить систему одновременным добавлением больших изменений Когда не совсем подходит agile/scrum ❏ Заказчик не понимает scrum, и scrum - это не то что он хочет ❏ Крупный заказчик не хочет формально принимать проект по маленьким кусочкам ❏ Бюрократия, много стадий согласований, заказчик хочет много документации ❏ Scrum плохо работает для fixed time, price, scope ❏ Много человек на проекте (около 100)
  • 6. Успех = комбинация подходов Свойственно agile/scrum ❏ Разделение на небольшие мобильные команды ❏ Короткие двухнедельные спринты, частые демо, планирования, scrum poker, story mapping, ежедневные митинги, ретроспективы ❏ Нет чёткой специализации среди разработчиков, “все делают всё” ❏ Применение scrum of scrums для объединения команд ❏ Добавление небольшой части нового функционала после каждого спринта ❏ используем feature toggling Мало свойственно agile/scrum ❏ Планирование надолго вперёд в виде release vision на несколько месяцев ❏ Формальная сдача проекта большими кусками, фиксированные сроки ❏ Использование системы управления требованиями, поддержка большого количества документации
  • 7. Структура проекта С точки зрения заказчика (по функциональности) ❏ Продажи ❏ Корпоративные клиенты ❏ Техподдержка ❏ Обслуживание ❏ Удержание С точки зрения разработчиков (по компонентам) ❏ Бизнес анализ ❏ Разработка CRM ❏ Интеграция ❏ Миграция ❏ Администрирование ❏ Тестирование
  • 8. Каким образом построены команды Интеграторы Миграторы Администраторы Архитектурный комитет (scrum of scrums) скрам-мастер 5 разработчиков тестировщик автоматизатор Бизнес-анализ Разработка Интеграция Миграция Администрирование Корпоративные клиенты Техподдержка Продажи Синхронные спринты скрам-мастер 5 разработчиков тестировщик автоматизатор скрам-мастер 5 разработчиков тестировщик автоматизатор Общее демо Общий транк Функциональность
  • 9. Процессы - обо всём по порядку Составление Release Vision ❏ цели ❏ требования, ограничения ❏ сроки ❏ архитектурные риски, способы борьбы ❏ ответственные аналитики Story mapping по каждому процессу обсуждение одного бизнес- процесса ❏ составление user stories ❏ приоретизация время vision story-mapping
  • 10. Планирование 1. Предварительное планирование ❏ Во время спринта ❏ То что будем делать потом (возможно в следующем спринте) 2. Основное планирование ❏ В начале спринта ❏ Только то, что разбирали раньше на преплане 3. Допланирование ❏ Если сделали всё раньше ❏ Аналитики не подготовили достаточно историй Планирование итеративное, как и сама разработка
  • 11. Структура скрама Архитектурный комитет (scrum of scrums) скрам-мастер 5 разработчиков тестировщик автоматизатор скрам-мастер 5 разработчиков тестировщик автоматизатор скрам-мастер 5 разработчиков тестировщик автоматизатор Представители команд, руководители разработки, бизнес- анализа, архитектор обсуждается новый функционал, планы на будущее Каждая команда проводит отдельно 1. планирования 2. митинги 3. ретроспективы Демо общее
  • 12. Planning poker На перплане (общая оценка историй) 2 4 8 16 На планировании (оценка для каждой задачи в рамках истории) 1 3 5 8 13 ❏ Результат - не средняя оценка! ❏ Соглашаемся на уровне команды на одну из оценок
  • 13. Ежедневный scrum-митинг 1. какие задачи сделаны? 2. какие не сделаны? 3. почему не сделаны? 4. почему лень - не ответ на пункт 3 ❏ Выяснить вопросы с аналитиками ❏ Сообщить о проблеме команде ❏ Дать понять тестировщикам что можно проверять ❏ Договориться о реализации чего-либо с другими разработчиками время Участники Аналитики Скрам-мастер Команда текущий спринтvision story-mapping
  • 14. Предварительное планирование ❏ имеем описанную бизнес-задачу ❏ задаём вопросы для дальнейшей проработки требований ❏ предлагаем высокоуровневую реализацию ❏ даём общую оценку истории по сложности (2, 4, 8, 16) ❏ препланируем на следующий спринт! время Участники Представитель заказчика Аналитики Скрам-мастер Команда Представители других команд vision story-mapping 3 преплана текущий спринт
  • 15. Планирование ❏ то что разбирали на преплане ❏ все вопросы выяснены! ❏ есть спецификации интерфейсов сторонних систем ❏ разбиение на маленькие задачи ❏ оцениваем каждую задачу (1, 3, 5, 8, 13) время Участники Аналитики Скрам-мастер Команда Представители других команд следующий спринтпланированиеvision story-mapping 3 преплана текущий спринт
  • 16. Демо Definition of done ❏ в новом функционале нет багов ❏ не сломали существующий функционал ❏ новый функционал задеплоен на систему заказчика Демо ❏ внутреннее и внешнее ❏ общее для всех команд ❏ аналитик зачитывает историю ❏ показываем, отвечаем на вопросы ❏ аналитик приминает решение ❏ принято ❏ принято с замечаниями (фикс в следующем спринте) ❏ не принято время демо - Деда, деда, смотри, Exception! - Т-сс, что не видишь, демо идёт, глянь что демоны вытворяют. * Де́мон — компьютерная программа в системах класса UNIX, запускаемая самой системой и работающая в фоновом режиме (википедия) следующий спринтпланированиеvision story-mapping 3 преплана текущий спринт
  • 17. Ретроспектива ❏ Отдельная для каждой команды (никто не запрещает сходить поругаться к соседям) ❏ Составление доски замечаний (snake on the board) ❏ каждое замечение назначается на исполнителя ❏ скрам-мастер следит чтобы все замечания были решены за спринт время демо и ретроспектива следующий спринтпланированиеvision story-mapping 3 преплана текущий спринт Долгое ревью, виноват Вася! Нечёткие требования по историям техподдержки “Плохой код” в логике назначения заявки Частые изменения требований, пришлось много переделывать Косяк на демо, не заработала интеграция со сторонней системой
  • 18. Пример Разработка простой CRM-системы 1. Бизнес-требования 2. Release vision 3. Story mapping
  • 19. 1. Бизнес-требования Тех. поддержкаКлиент Тех. обслуживание Реализация процесса технической поддержки ❏ Клиент звонит в поддержку ❏ Оператор создаёт заявку в системе ❏ Специалист по техническому обслуживанию выполняет ремонт
  • 20. Заявка Клиенты ФИО Номер пасспорта Иванов Иван 12312 Петров Вася 31241 ПоискОписание Сохранить Решена Требует решения Текущий функционал CRM 1. Выбираем клиента 2. Заполняем заявку 3. Сохраняем
  • 21. Новый функционал CRM Тех. поддержкаКлиент Тех. обслуживание Клиент с признаком оттока Тех. поддержка Кризис- менеджер ❏ Добавляется новая роль - кризис-менеджер
  • 22. 2. Пример release vision Release 1.0 Старт: 10.12.2013 Завершение: 10.03.2014 Цели релиза Функциональные требования Бизнес 1. Запуск подразделения обслуживания клиентов на платформе CRM 2. Уменьшение ухода клиентов благодаря взаимодействию с ними специального сотрудника кризис-менеджера (запуск процесса удержания) Технические 1. Добиться устойчивой работы системы в минимальном функционале 1. Поиск заявок 2. Поиск клиентов 3. Назначение заявок на кризис- менеджера 4. Повышение приоритетов заявок отточных клиентов 5. Отображение признака отточных клиентов на карточке клиента Границы релиза Архитектурные риски Бизнес 1. Процессы: техподдержка, удержание 2. Территория запуска: урал, сибирь Технические 1. Использование существующей платформы CRM Новая клиентская модель - способы борьбы: 1. быстрое прототипирование 2. консультации у заказчика Ответственные аналитики: Иванов Иван, Петров Вася время Диаграмма Ганта Release plan UAT Bug fixing
  • 23. Клиент Специалист ТП Кризис-менеджер Специалист ТО Добавляем карточки участников процесса
  • 24. Позвони ть в ТП Принять звонок и создать заявку с признаком оттока Выбрать заявку, сделать ремонт Выбрать заявку и позвонить клиенту Передать заявку на ТО Клиент Специалист ТП Кризис-менеджер Специалист ТО Отследить выполнение заявки, перезвонить клиенту Добавляем действия участников процесса
  • 25. Позвони ть в ТП Принять звонок и создать заявку с признаком оттока Выбрать заявку, сделать ремонт Выбрать заявку и позвонить клиенту Заведение роли для КМ Разделить список заявок для КМ и ТО Кнопка пере- направления заявки в ТО Передать заявку на ТО Галочка оттока на форме заявки Клиент Специалист ТП Кризис-менеджер Специалист ТО Отследить выполнение заявки, перезвонить клиенту Покрываем минимальный функционал
  • 26. Позвони ть в ТП Принять звонок и создать заявку с признаком оттока Выбрать заявку, сделать ремонт Выбрать заявку и позвонить клиенту Заведение роли для КМ Разделить список заявок для КМ и ТО Добавление признака оттока на карточку клиента Возможность снятия признака оттока с карточки пользователя вручную - только для КМ Кнопка пере- направления заявки в ТО Передать заявку на ТО Галочка оттока на форме заявки Отдельный список с отточными клиентами Клиент Специалист ТП Кризис-менеджер Специалист ТО Отследить выполнение заявки, перезвонить клиенту Наращиваем функционал
  • 27. Позвони ть в ТП Принять звонок и создать заявку с признаком оттока Выбрать заявку, сделать ремонт Выбрать заявку и позвонить клиенту Заведение роли для КМ Автоматическое повышение приоритета всех заявок отточного клиента Разделить список заявок для КМ и ТО Добавление признака оттока на карточку клиента Возможность снятия признака оттока с карточки пользователя вручную - только для КМ Кнопка пере- направления заявки в ТО Передать заявку на ТО Галочка оттока на форме заявки Отдельный список с отточными клиентами Email-нотификация при появлении отточного клиента Клиент Специалист ТП Кризис-менеджер Специалист ТО Отследить выполнение заявки, перезвонить клиенту Email-нотификация для КМ при выполнении отточной заявки
  • 28. Позвони ть в ТП Принять звонок и создать заявку с признаком оттока Выбрать заявку, сделать ремонт Выбрать заявку и позвонить клиенту Заведение роли для КМ Автоматическое повышение приоритета всех заявок отточного клиента Разделить список заявок для КМ и ТО Добавление признака оттока на карточку клиента Возможность снятия признака оттока с карточки пользователя вручную - только для КМ Кнопка пере- направления заявки в ТО Передать заявку на ТО Галочка оттока на форме заявки Отдельный список с отточными клиентами Email-нотификация при появлении отточного клиента Клиент Специалист ТП Кризис-менеджер Специалист ТО Отследить выполнение заявки, перезвонить клиенту Email-нотификация для КМ при выполнении отточной заявки Sprint 1 Sprint 2 Sprint 3
  • 29. Story mapping ❏ Хорошая модель для дискуссий и коллективного разума ❏ Выделяет пользовательские истории из требований ❏ Приоретизирует бэклог ❏ Хорошо визуализирует функционал, нужный пользователю, даёт лучшее понимание проекта ❏ Позволяет выделить наиболее маленькую часть доработок, для максимальной бизнес-ценности ❏ Помогает видеть проект в целом
  • 30. Процессы разработки Синхронные спринты для всех команд ❏ Полный регресс ❏ Общее демо ❏ В конце итерации - codefreeze ❏ Поставка в прод после каждого спринта SVN ❏ Один транк ❏ Одна ветка прошлого релиза (для хот- фиксов, сразу мерж в основную ветку) ❏ Комиты только по задачам ❏ Continuous integration + автотесты ❏ Деплой на тестовую среду из jenkins, делают все кому необходимо ❏ Размножение команд почкованием
  • 31. Jira Agile (Greenhopper) ❏ Все задачи в Jira ❏ Истории располагаются по приоритету сверху вниз ❏ Каждая задача проходит через ревью ❏ Отдельный таск по тестированию, включает написание тест-кейсов ❏ Разработчики не специализируются на конкретных типах задач ❏ По скраму работают все: аналитики, админы, миграторы, … ❏ у каждой команды своя доска
  • 32. Времязатраты нашего скрама Препланы 3 раза по 1 часу втечение спринта Демо, планирование, ретроспектива 1 день в спринт Скрам-митинги 15-20 минут в день Кодфриз После кодфриза нельзя делать новые истории, не успели доделать - откатываем 2 дня выделяется на фиксы багов и доработки Story mapping, архитектурный комитет ? Бывает что историю быстрее реализовать, чем отводится время на планирование
  • 33. Итоги Плюсы скрама ❏ хороший фундамент для саморазвития команд, обмена опытом ❏ помогает приоритезировать, не делать лишней работы ❏ подходит когда у вас хаос Минусы скрама ❏ довольно затратный, много времени тратится на общение ❏ нужно модифицировать процессы ❏ Никто не застрахован от переделок при нечёткой формулировке задачи ❏ Теряется эффективность при отсутствии специализации ❏ Нет возможности оценивать каждого сотрудника в отдельности ❏ Оценка в абстрактных единицах не привязана ко времени Не стоит работать 100% по скраму как написано в книжке ❏ комбинируем подходы ❏ делаем свой скрам, берём всё лучшее Do things right! а не do right things
  • 34. Agile = work and travel
  • 35. Всё будет хорошо, главное - мотивация
  • 36. Спасибо за внимание! kslisenko@gmail.com Вопросы?