Обзор методологии Scrum Auriga Inc. Дмитрий Сидоренко

Содержание Преимущества Происхождение Основы методологии Роли Сопутствующие методологии

Зачем меняться? Существующие методологии плохо приспособлены к изменению требований Необходимо знать все требования в начале Длительные циклы разработки проблемы при сдаче Требования – абстракция, которая интерпретируется по-разному Высокая вовлеченность клиента в начале проекта сходит на нет к окончанию работ Недостаточное тестирование Проблемы появляются в конце Прогресс определяется % от задачи

Преимущества Scrum Прозрачность для бизнеса Заказчик может вносить изменения Проблемы быстро идентифицируются Разработчики вовлечены в процесс Результаты быстро доступны для проверки Менеджмент видит прогресс Менеджмент разгружается Прогресс определяется наличием работающего приложения

Скрам – не панацея Проблемы, которые мы решаем, не связаны с процессами, они в людях Скрам и Agile основаны на теории, что для разработки програмного обеспечения не существует мета-решения. Только framework, который мы изучаем и адаптируем Разочаровывающе для тех, кто ищет процедуры и окончательные ответы

Scrum за 2 минуты Scrum – это гибкая методология, которая фокусируется на business value Позволяет быстро и последовательно предоставлять работающие части проекта заказчику Каждые две недели любой заинтересованный человек может участвовать на показе текущей версии Заказчик задает приоритеты. Команда самооопределяется, чтобы производить наиболее важную для заказчика функциональность Scrum задает только общие правила управления проектом

Agile Manifesto Люди и общение, а не процессы и инструменты Работающее приложение, а не сложная документация Сотрудничество с клиентом, а не составление контрактов Реакция на изменения, а не следование плану

Что значит Гибкая? Гибкость – означает быть открытым относительно того, что ты можешь сделать и делать это Кент Бек Система ценностей Люди Сотрудничество Открытость Доверие Отношение Принципы, выраженные в действиях Простая система для работы с изменениями Самоорганизация Видимость Проверка Адаптация Адаптивная экосистема Совместная работа команды и клиента

Происхождение Scrum – команда в регби The New New Product Development Game, Harvard Business Review, 1986, Takeuchi and Nonaka Origins of Scrum

Компании Microsoft Yahoo Google Electronic Arts High Moon Studios Lockheed Martin Philips Siemens Nokia Capital One BBC Intuit Time Warner Nival Luxoft

Характеристики Самоопределяющаяся команда Продукт разрабатывается в процессе серии итераций (sprints) Требования записываются в product backlog Инженерные практики не являются частью Scrum Использует простые правила для создания гибкой среды разработки проектов Один из agile процессов

Scrum CancelGift wrapReturn Sprint 2-4 недели GUI Цель Sprint'а Sprint backlog Потенциально готовый к поставкам продукт Product backlog КупоныДоставкаЗаказОтмена 24 часа

Sprints Проект разрабатывается в серии спринтов Типичная продолжительность – от 2-х недель до месяца Жесткое ограничение по времени Постоянная продолжительность спринта привносит ритм в разработку Продукт проектируется, кодируется и тестируется на протяжении одного спринта В конце спринта – полностью готовая функциональность

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

Framework Product owner ScrumMaster Команда Роли Планирование Sprint Sprint ревью Sprint ретроспектива Ежедневные пятиминутки Ритуалы Product backlog Sprint backlog Burndown charts Артефакты

Роли Нет фиксированных позиций Все участники кроссфункциональны Плоская структура Реальная жизнь вносит коррективы

Product owner Один человек Определяет требования (vision) Определяет дату релиза и наполненность Ответственен за доходность проекта (ROI) Приоритизирует требования, исходя из их рыночной ценности Корректирует приоритеты на каждой итерации, если необходимо Постоянно общается с всей командой Принимает работу

Как найти хорошего PO Хорошим Product Owner'ом не рождаются Эксперт в бизнес домене, готовый потратить 30 минут в день на общение с командой Product Owner заинтересован в проекте Высокопоставленный чиновник – редко хороший PO Вносите практики постепенно

Занятость PO Полдня на планировании спринта минут в день 2 часа на спринт-ревью Несколько дней на начальную идентификацию User Stories Желательна доступность в режиме онлайн skype, icq, messenger

ScrumMaster Ответственен за внедрение практик Устраняет препятствия Ответственен за эффективность работы команды Защищает команду от внешних воздействий Не раздает задания Обеспечивает видимость и прозрачность

Кто такой Скрам Мастер - 2 Лидер и помощник Ответственен за удаление препятствий обучение клиента упрощение жизни команды улучшение производительности команды улучшение применяемых инженерных практик

Памятка Скрам Мастера Command & control – иллюзия Магии не существует Прозрачность процессов

Команда Обычно 5-9 человек Кросфункциональные члены команды: программисты, тестеры, дизайнеры... Полный рабочий день Самоопределяющаяся В идеале, нет позиций (PM, TL, tester) Отвечает за результат перед PO

Product backlog Список желательной функциональности Управляет Product owner Приоритизируется Product owner Реприоритизируется в начале спринта В идеале написан так, что каждый элемент описывает Use case конечного пользователя

BacklogОценка Как гость, я хочу зарезервировать номер 3 Как гость, я хочу отменить резервацию 5 Как гость, я хочу изменить дату резервации 3 Как работник гостиницы, я хочу просматривать отчеты 8 Улучшить обработку исключений8 Сервер в продакшене упал Пример

Что НЕ Скрам? Противоречие Agile Manifesto Отсутствие итераций Отсутствие или игнорирование обратной связи Отсутствие пула задач с заданными приоритетами Непрозрачность

Когда Скрам не нужен? Проекты делаются полностью, вовремя, в полном объеме Команда собирается только на краткосрочный проект

Когда Скрам не работает? Гос. проект Тонущий проект, который отдали в офшор Скрам Мастер – традиционный ПМ Во всех остальных случаях, когда не работают другие методологии текучка распределенность низкий уровень технических знаний...

Команда: самоорганизация Не происходит сама по себе Требует внешних условий Команда должна понимать, зачем организовываться Частые и неформальные отзывы о работе очень важны Требует времени 4 этапа становления команды

Планирование Спринта Планирование Что делаем Анализ бэклога Цель спринта Как делаем Определение дизайна Создание бэклога спринта (задачи) Цель Sprint Sprint backlog Sprint backlog Клиент Команда Product backlog Технология Продукт

Цель спринта Короткое предложение, описывающее, каким должен быть результат спринта БД Финансы Интерфейс Написать графический интерфейс Включить поддержку загрузки котировок в реальном времени Запустить приложение на MS SQL

Планирование спринта Скорость работы команды задает объем работ на спринт Суммарный объем задач на спринте не должен превышать возможности команды Увеличение объема работ неизбежно приводит к падению качества

Подробнее про планирование Команда выбирает, что из product backlog будет реализовано на спринте Создается Sprint backlog Задачи идентифицируются и оцениваются Все делается командой, не Scrum master Учитывается High-level design Как отдыхающий, я хочу посмотреть на фото отелей Кодировать серверную часть (8) Написать GUI (4) Написать тесты (4) Обновить руководство пользователя (4)

Управление sprint backlog Работа выбирается самостоятельно, назначений нет Постоянная переоценка сложности задач Любой член команды имеет доступ к бэклогу спринта Изменения во время sprint нежелательны если нужно очень срочно - перенести часть задач обратно в product backlog

Ежедневный Scrum Характеристики Ежедневно, в одно время 15 минут Обмен информацией Не для решения проблем Приглашены все Только участники команды могут говорить (product owner – часть команды) Ведет ScrumMaster

Три вопроса Что ты сделал вчера? 1 Что будешь делать сегодня? 2 Что тебе мешает? 3 Это не статусный отчет СкрамМастеру!

Пример: спринт

Спринт ревью Команда представляет, что было сделано на спринте Фокус на результат, а не процесс Обычно принимает форму демонстрации Неформально 2 часа на подготовку Без слайдов Вся команда участвует Приглашены все

Ретроспектива Пересмотр эффективности практик минут После каждого спринта Вся команда участвует Возможно, приглашены клиенты

Инженерные методологии Unit testing Test Driven Development Continuous integration Refactoring Code review

Estimation Practices User Stories Estimation Game

Пример: Product backlog

Вариант определения приоритета Определение важности User Story Effort – затраты на реализацию Benefit – преимущество от включения Penalty – урон при отсутствии Business weight = benefit + penalty Release business value = BW/SUM(BW) ROI = rBV/Effort %

User Story Высокоуровневое описание функциональности с точки зрения конечного пользователя Помогает разработчикам оценивать проект не с технической точки зрения Помогает избавиться от как сделано в пользу что сделано Могут разбиваться на более мелкие в процессе работы

Good User Story INVEST Independent Negotiable Valuable Estimatable Sized Appropriately Testable

Где детали? Как пользователь, я хочу отменить бронь Полный или частичный возврат денег? Какой лимит во времени? Единый для всех пользователей? Единый для всех отелей? Следует ли слать подтверждение пользователю?

Estimation Game Основана на Expert Estimations Вся команда принимает участие Оценки даются независимо, результаты сверяются и обсуждаются Раунды оценок

Подробнее об оценке Agile Estimating and Planning, Mike Cohn User Stories Applied, Mike Cohn

Изменения в Scrum Принципы Scrum не безусловные истины Tailoring допустим и приветствуется Вносите новшества в команду постепенно

Возможные проблемы Большие команды Scrum of Scrums Клиент требует следования CMMi Scrum возможно сертифицировать по CMMi Level 5 Нет возможности найти на стороне заказчика PO PO внутри компании, возможно, не разработчик

Куда пойти Каждые две недели – семинары AgileRussia

Что читать Экстремальное программирование, Кент Бек Экстремальное программирование: планирование, Кент Бек и Мартин Фаулер Agile Estimating and Planning, Mike Cohn Agile Project Management with Scrum, Ken Schwaber Agile Retrospectives, Esther Derby and Diana Larsen Agile Software Development Ecosystems, Jim Highsmith Agile Software Development with Scrum, Ken Schwaber and Mike Beedle Scrum and The Enterprise, Ken Schwaber

Credits Mountain Goat Software Mike Cohn Mike Vizdos

Контакты Дмитрий Сидоренко skype: dmitry.sidorenko.work