'

Введение в Скрам

Понравилась презентация – покажи это...





Слайд 0

Введение в Скрам <ваше имя> <дата>


Слайд 1

Введение в Скрам <ваше имя> <дата> Представлено:


Слайд 2

Мы проигрываем эстафету Хиротака Такеучи и Икуджиро Нонака, “The New New Product Development Game”, Harvard Business Review, Январь 1986. “Подход ‘эстафета’ к разработке продукта… может противоречить целям максимальной скорости и гибкости. Вместо этого, целостный или ‘регби’-подход, где команда пытается пройти дистанцию как единое целое, передавая мяч назад и вперед - может лучше служить сегодняшним конкурентным требованиям.”


Слайд 3

Скрам – это один из Agile процессов, который позволяет фокусироваться на поставке наиважнейших, с точки зрения бизнеса, ценностей в наикратчайшие сроки Он позволяет нам быстро и регулярно осматривать реально работающее программное обеспечение (от двух недель до месяца). Бизнес расставляет приоритеты. Команды самоорганизовываются и определяют лучший способ, чтобы выпустить функции с высоким приоритетом. С регулярностью от двух недель до месяца все могут видеть реально работающий программный продукт, и решить выпускать его как он есть либо продолжить улучшение в следующем спринте. Скрам в 100 словах


Слайд 4

Истоки Скрам Джеф Сазерленд Зарождение Скрам в корпорации Easel в 1993 IDX и 500+ людей работают по Скрам Кен Швабер ADM Представление Скрам на OOPSLA 96 совместно с Сазерлендом Автор трех книг по Скрам Майк Бидл Шаблоны Скрам в PLOPD4 Кен Швабер и Майк Кон Создание Скрам-альянса в 2002, изначально в рамках Agile-альянса


Слайд 5

Популярность Скрам Microsoft Yahoo Google Electronic Arts Lockheed Martin Philips Siemens Nokia IBM Capital One BBC Intuit Nielsen Media First American Real Estate BMC Software Ipswitch John Deere Lexis Nexis Sabre Salesforce.com Time Warner Turner Broadcasting Oce


Слайд 6

Применение Скрам Коммерческое ПО Внутренняя разработка Разработка на заказ Проекты с фиксированной стоимостью Финансовые приложения ISO 9001-сертифицированные приложения Встроенные системы 24x7 системы с требованиями 99.999% работоспособности Создание «Унифицированного истребителя-бомбардировщика» Разработка видеоигр Жизненно важные системы, утвержденные Управлением по контролю за продуктами и лекарствами (США) ПО контроля за спутниками Веб-сайты Портативное ПО Мобильные телефоны Приложения работы сети ISV приложения Некоторые крупнейшие, широко используемые приложения


Слайд 7

Основные характеристики Самоорганизующиеся команды Продукт разрабатывается серией “спринтов”, каждый не больше месяца Все требования записываются в виде единого списка “бэклога продукта” Инженерные практики не являются частью Скрам Использует простые правила для создания гибкой среды разработки проектов Один из “Agile процессов”


Слайд 8

Agile-манифест – декларация ценностей Источник: www.agilemanifesto.org/iso/ru


Слайд 9

Уровни помех проекта Просто Запутанно Анархия Сложно Технология Требования Далеко от согласия Близко к согласию Близко к определенности Далеко от определенности Источник: «Стратегический менеджмент и организационная динамика», Ральф Стейси в «Гибкая разработка ПО со Скрам» , Кен Швабер и Майк Бидл


Слайд 10

Скрам Бэклог продукта


Слайд 11

Теперь все вместе Картинка доступна на www.mountaingoatsoftware.com/scrum


Слайд 12

Спринты Скрам проекты развиваются сериями “спринтов” Это аналогично “итерациям” в Экстремальном Программировании (XP) Типичная продолжительность – от 2-х недель до месяца с жестким ограничением по времени Постоянная продолжительность спринта привносит ритм в разработку Продукт проектируется, разрабатывается и тестируется на протяжении одного спринта


Слайд 13

Вместо того, чтобы выполнять эти активности по очереди... ... Скрам команды делают понемногу от каждой все время Требования Дизайн Разработка Тестирование Источник: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986. Разработка: Последовательная против параллельной


Слайд 14

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


Слайд 15

Структура Скрам Владелец продукта Скрам-мастер Команда Роли Бэклог продукта Спринт бэклог Burndown charts Артефакты


Слайд 16

Структура Скрам в деталях Владелец продукта Скрам-мастер Команда Роли Бэклог продукта Спринт бэклог Burndown charts Артефакты


Слайд 17

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


Слайд 18

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


Слайд 19

Команда Обычно 5-9 человек Кросс функциональная программисты, тестировщики, дизайнеры... Заняты полный рабочий день Могут быть исключения (например, администратор базы данных) Команды самоорганизуюются В идеале, нет специальных ролей Состав команды может меняться только между спринтами


Слайд 20

Структура Скрам в деталях Владелец продукта Скрам-мастер Команда Роли Бэклог продукта Спринт бэклог Burndown charts Артефакты


Слайд 21

Планирование Спринта Планирование Бизнес среда Команда Бэклог продукта Технология Продукт


Слайд 22

Подробнее про планирование Команда выбирает из Бэклога Продукта требования, которые они могут реализовать за спринт Создается Бэклог Спринта Задачи идентифицируются и оцениваются (1-16 часов) Все делается командой, а не Скрам-мастером Учитывается высокоуровневая архитектура приложения Как отдыхающий, я хочу посмотреть на фото отелей


Слайд 23

Ежедневный скрам Характеристики Ежедневно 15 минут Стоя Не для решения проблем Приглашены все желающие Только участники команды могут говорить (владелец продукта - тоже часть команды) ScrumMaster лишь ведет собрание


Слайд 24

Каждый отвечает на три вопроса Это НЕ статусный отчет Scrum-мастеру! Это обязательства перед коллегами


Слайд 25

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


Слайд 26

Ретроспектива Периодический пересмотр того, что работает, а что нет Обычно 15-30 минут После каждого спринта Вся команда участвует Возможно, приглашен Владелец продукта, заказчики или кто-то из менеджмента компании


Слайд 27

Начать / Прекратить / Продолжить Вся команда собирается за тем, чтоб обсудить, что они хотят: Начать Прекратить Продолжить


Слайд 28

Структура Скрам в деталях Владелец продукта Скрам-мастер Команда Роли Планирование спринта Обзор спринта Спринт ретроспектива Ежедневный Скрам Ритуалы Бэклог продукта Спринт бэклог Burndown charts Артефакты


Слайд 29

Бэклог продукта Требования Список желательной функциональности В идеале написан так, что каждый элемент имеет значение для конечного пользователя Приоритеты выставляются Владельцем продукта Приоритеты обновляются в начале спринта


Слайд 30

Пример бэклога продукта


Слайд 31

Цель спринта Короткое предложение, описывающее, на чем будет сфокусирована работа во время спринта БД Финансы Наука Поддержка функциональности необходимой для изучения генетики Добавить поддержку котировок в реальном времени Сделать в приложении поддержку MSSQL в дополнение к Oracle


Слайд 32

Управление бэклогом спринта Члены команды выбирают работу на свой выбор Задачи никогда не назначаются принудительно Оценка оставшейся работы ежедневно обновляется Любой член команды может добавить, удалить или изменить элементы Бэклога Спринта Задачи на спринт могут появляться в ходе работы Если задача не понятна, то этому элементу бэклога резервируется больше времени и он разбивается на составные части позже Оценка оставшейся работы обновляется, по мере того как узнаем больше о задачах


Слайд 33

Пример бэклога спринта Активности Сделать интерфейс пользователя Сделать логику Протестировать логику Написать руководство пользователя Вынести утилиты в общий класс Пн Вт Ср Чт Пт


Слайд 34

Спринт burndown chart Часы


Слайд 35

Осталось 40 30 20 10 0 Пн Вт Ср Чт Пт Активности Сделать user interface Сделать логику Протестировать логику Написать User Manual Пн 8 16 8 12 Вт Ср Чт Пт 50


Слайд 36

Масштабируемость Обычно команда состоит из 7 ± 2 человек Масштабируемость за счет групп команд Факторы расширения Тип приложения Размер команды Рассредоточенность команды Продолжительность проекта Scrum использовался в проектах со сложной структурой, где работало более 500 человек


Слайд 37

Масштабирование посредством Скрама из Скрамов


Слайд 38

Скрам из Скрамов, которые также из Скрамов


Слайд 39

Где еще почитать www.mountaingoatsoftware.com/scrum www.scrumalliance.org www.controlchaos.com scrumdevelopment@yahoogroups.com


Слайд 40

Книги по Scrum Agile and Iterative Development: A Manager’s Guide by Craig Larman Agile Estimating and Planning by Mike Cohn Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen Agile Software Development Ecosystems by Jim Highsmith Agile Software Development with Scrum by Ken Schwaber and Mike Beedle Scrum and The Enterprise by Ken Schwaber Succeeding with Agile by Mike Cohn User Stories Applied for Agile Software Development by Mike Cohn


Слайд 41

Авторские права Вы можете: Делиться ?копировать и передавать эти материалы Изменять ? адаптировать и дополнять эти материалы При условии Первоисточник. Вы должны указать в своей работе всех авторов материалов, которые предоставлены на основе этой или других лицензии(но это не означает, что автор поддерживает вас или вашу работу ). Ничто в этой лицензии не нарушает и не ограничивает моральные права автора Подробнее о лицензии можно узнать: http://creativecommons.org/licenses/by-nc/3.0/


Слайд 42

Контактная информация Презентация: Майк Кон mike@mountaingoatsoftware.com www.mountaingoatsoftware.com (720) 890-6110 Вы можете удалить этот слайд или какой-либо другой, но вы должны указать источник где-либо в вашей презентации. Используйте логотип и название компании (как, например, в левом нижнем углу) или включите в презентацию слайд, где говорится, что часть слайдов (или все) вашей презентации взяты из этого источника. Спасибо.


Слайд 43

Авторы перевода Перевод на русский язык осуществлен Марией Евграшиной и Тимофеем Евграшиным The Improved Methods http://tim.com.ua В соавторстве с Алексеем Кривицким SCRUMguides http://scrumguides.com This presentation was translated into Russian language by Mariia Yevgrashyna and Timofey Yevgrashyn The Improved Methods http://tim.com.ua Co-translator Alexey Krivitsky SCRUMguides http://scrumguides.com


×

HTML:





Ссылка: