'

Scrum

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





Слайд 0

Scrum


Слайд 1

Product backlog ID – уникальный идентификатор – просто порядковый номер. Название – краткое описание истории. Важность (Importance) – степень важности данной задачи, по мнению product owner'а. Как продемонстрировать (how to demo) – краткое пояснение того, как завершённая задача будет продемонстрирована в конце спринта. Примечания – любая другая информация.


Слайд 2

Дополнительные поля для user story Категория (track). Компоненты (components) – указывает, какие компоненты будут затронуты при реализации истории. Инициатор запроса (requestor). ID в системе учёта дефектов (bug tracking ID).


Слайд 3

Подготовка к планированию спринта Product backlog должен существовать! У каждого продукта должен быть один product backlog и один product owner. Все наиболее важные задачи должны быть классифицированы по уровню важности, а их числовые значения не должны совпадать. Product owner должен понимать каждую историю.


Слайд 4

Итоги планирования спринта Цель спринта. Список участников команды. Sprint backlog. Дата демонстрации. Место и время проведения ежедневного Scrum’а.


Слайд 5

Почему без product owner'а не обойтись Команде и product owner’у просто необходимо планировать вместе, потому что каждая user story имеет три параметра, которые очень тесно связаны между собой.


Слайд 6

Почему качество не обсуждается Жертвовать внутренним качеством – это практически всегда очень и очень плохая идея. Сэкономленное время ничтожно мало по сравнению с той ценой, которую вам придётся заплатить как в ближайшем будущем, так и в перспективе. Как только качество вашего кода ухудшится, восстановить его будет очень тяжело.


Слайд 7

Распорядок встречи по планированию спринта 13:00 – 13:30. Product owner разъясняет цель спринта и рассказывает про бизнес-процессы из product backlog’а. Обсуждается время и место проведения демо. 13:30 – 15:00. Команда проводит оценку времени, которое потребуется на разработку бизнес-процессов и, при необходимости дробит их на более мелкие. 15:00 – 16:00. Команда определяет набор user story, которые войдут в следующий спринт. 16:00 – 17:00. Договариваемся о времени и месте проведения ежедневного Scrum’а. После чего приступаем к разбиению user story на задачи.


Слайд 8

Определение длины спринта Одна из основных задач планирования спринта – это определение даты демо. А это значит, что вам придётся определиться с длиной спринта.


Слайд 9

Определение цели спринта Цель спринта должна отвечать на главный вопрос “Зачем мы работаем над этим спринтом? Почему мы все просто не уйдём в отпуск?”.


Слайд 10

Выбор историй, которые войдут в спринт


Слайд 11

Как product owner может влиять на то, какие истории попадут в спринт?


Слайд 12

Как product owner может влиять на то, какие истории попадут в спринт?


Слайд 13

Как product owner может влиять на то, какие истории попадут в спринт?


Слайд 14

Как product owner может влиять на то, какие истории попадут в спринт?


Слайд 15

Как команда принимает решение о том, какие истории включать в спринт? на основе интуиции на основе подсчёта производительности


Слайд 16

Почему стоит использовать учетные карточки


Слайд 17

Разбиение историй на задачи


Слайд 18

Оценка трудозатрат с помощью игры в planning poker


Слайд 19

Уточнение описаний историй Нет ничего ужасней, чем ситуация, когда команда с пафосом демонстрирует новую функциональность продукта, а product owner тяжко вздыхает и говорит: “ну да – всё это красиво, вот только не то, что я просил!”


Слайд 20

Разбиение историй на более мелкие истории Истории должны быть не слишком маленькими, но и не слишком большими (в смысле оценок).


Слайд 21

Разбиение историй на задачи


Слайд 22

Выбор времени и места для ежедневного Scrum'а Все часто забывают, что на планировании спринта, помимо всего прочего, необходимо выбрать время и место проведения ежедневного Scrum'а. Без этого ваш спринт обречён на неудачный старт. Ведь первый ежедневный Scrum – это, по большей части, ввод мяча в игру, когда каждый решает с чего начать работу.


Слайд 23

Когда пора остановиться Приоритет №1: Цель спринта и дата демонстрации. Приоритет №2: Список историй, которые команда включила в sprint backlog. Приоритет №3: Оценки для каждой истории из sprint backlog'а. Приоритет №4: Поле "Как продемонстрировать" для каждой истории из sprint backlog'а. Приоритет №5: Расчёты производительности и ресурсов в качестве "испытания реальностью" для плана на спринт. Приоритет №6: Определённое время и место проведения ежедневного Scrum'а. Приоритет №7: Истории, разбитые на задачи.


Слайд 24

Технические истории Всё, что должно быть сделано, но невидимо для заказчика, не относится ни к одной user story, и не даёт прямой выгоды product owner'у.


Слайд 25

Использование учёта дефектов для ведения product backlog'а Product owner распечатывает самые высокоприоритетные задачи из Jira, выносит их на планирование спринта и вешает их на стенку с другими историями. Product owner создаёт истории, соответствующие задачам из Jira. Работы по исправлению ошибок не включаются в спринт, то есть команда определяет довольно низкий фокус-фактор. Заносим product backlog в Jira. Считаем баги обычными историями.


Слайд 26

Как донести информацию о спринте до всех в компании Важно информировать всю компанию о том, что происходит в вашей команде. Если этого не делать, то остальные начнут жаловаться, или – что ещё хуже – придумывать всякие ужасы про вас.


Слайд 27

Формат sprint backlog'a


Слайд 28

Пример доски задач через пару дней


Слайд 29

Как работает burndown-диаграмма


Слайд 30

Тревожные сигналы на доске задач


Слайд 31

Тревожные сигналы на доске задач


Слайд 32

Тревожные сигналы на доске задач


Слайд 33

Тревожные сигналы на доске задач


Слайд 34

Как отслеживать изменения Лучший вариант отслеживания изменений, при данном подходе – это делать фотографию доски задач каждый день.


Слайд 35

Как обустроить комнату для команды


Слайд 36

Усадите команду вместе В пределах слышимости В пределах видимости Автономно


Слайд 37

Не подпускайте product owner'а слишком близко Product owner должен находиться настолько близко к команде, чтобы в случае возникновения вопросов, команда могла бы спросить его лично, и чтобы он имел возможность на своих двоих подойти к доске задач. Но он не должен сидеть в одной комнате с командой


Слайд 38

Ежедневный Scrum:обновление доски задач По мере того, как каждый член команды рассказывает о том, что он сделал за вчерашний день и чем будет заниматься сегодня, он перемещает стикеры на доске задач. Как только рассказ касается какого-то незапланированного задания, то для него клеится новый стикер. При обновлении временных оценок, на стикере пишется новая оценка, а старая зачеркивается.


Слайд 39

Как быть с опоздавшими Некоторые команды заводят специальную копилку. Если вы опоздали, даже на минуту, вы кидаете в копилку определённую сумму. Без вариантов. Даже если вы позвонили перед началом ежедневного Scrum'а и предупредили, заплатить всё равно придётся.


Слайд 40

Что делать с теми, кто не знает чем себя занять Пристыдить По старинке Моральное давление Закабалить


Слайд 41

Почему каждый спринт должен оканчиваться демонстрацией Положительная оценка работы воодушевляет команду . Все остальные узнают, чем занимается ваша команда. На демо заинтересованные стороны обмениваются жизненно важными отзывами. Демо проходит в дружеской атмосфере, поэтому разные команды могут свободно общаться между собой и обсуждать насущные вопросы. Проведение демо заставляет команду действительно доделывать задачи и выпускать их.


Слайд 42

Подготовка к демо Постарайтесь как можно более чётко озвучить цель данного спринта. Не тратьте много времени на подготовку демо, особенно на создание эффектной презентации. Следите, чтобы демо проходило в быстром темпе. Пусть ваше демо будет бизнес-ориентированным, забудьте про технические детали. Если это возможно, дайте аудитории самой попробовать поиграть с продуктом. Не нужно показывать кучу исправлений мелких багов и элементарных фич.


Слайд 43

Почему нужно проводить ретроспективы Ретроспективы позволяют команде не наступать на одни и те же грабли снова и снова.


Слайд 44

Как проводить ретроспективы Продолжительность 1-3 часа Присутствуют: вся команда и product owner. Один из членов команды выступает в качестве секретаря. Scrum Master показывает sprint backlog и подводит итоги спринта. Серия обсуждений. Каждый говорит, что было плохо и что было хорошо. Прогнозируемая производительность сравнивается с фактической. Scrum Master обобщает все конкретные предложения по поводу того, что можно улучшить в следующем спринте.


Слайд 45

Как учиться на чужих ошибках Возможные способы решения проблем, найденных командой на ретроспективе, могут оказаться полезными не только для неё самой, но и для остальных. Как же собрать все эти результаты? Один человек принимает участие во всех ретроспективах в роли "связующего звена".


Слайд 46

Типичные проблемы, которые обсуждают на ретроспективах Нам надо было больше времени потратить на разбиение историй на подзадачи. Очень часто беспокоят извне. Мы взяли огромный кусок работы, а закончили только половину. У нас в офисе бардак и очень шумно.


Слайд 47

Отдых между спринтами В реальной жизни невозможно постоянно бежать как спринтер. Между забегами вам в любом случае нужен отдых. Если вы бежите с постоянной максимальной скоростью, то, по сути, вы просто бежите трусцой.


Слайд 48

Планирование релизов: определение приемочной шкалы


Слайд 49

Оценка наиболее важных историй


Слайд 50

Оценка наиболее важных историй


Слайд 51

Прогнозируемая производительность Определяем сколько story point-ов может выполнить команда за спринт.


Слайд 52

План релиза


Слайд 53

Сочетание Scrum и XP Scrum решает вопросы управления и организации, тогда как XP специализируется на инженерных практиках.


Слайд 54

Парное программирование Парное программирование улучшает качество кода. Частая смена пар даёт хороший результат. Парное программирование действительно способствует распространению знаний внутри команды. Ревью кода – хорошая альтернатива парному программированию. Не навязывайте парное программирование людям. Вдохновите их, дайте необходимые инструменты и позвольте самим дойти до этого.


Слайд 55

Разработка через тестирование Разработка через тестирование – это непросто. TDD оказывает глубокое положительное влияние на дизайн системы. Чтобы TDD стало приносить пользу в новом проекте, необходимо приложить немало усилий. Потрать достаточно времени, но сделай так, чтобы писать тесты было просто.


Слайд 56

Остальные практики XP Эволюционный дизайн Непрерывная интеграция (Continuous integration) Совместное владение кодом (Collective code ownership) Информативное рабочее пространство Стандарты кодирования Устойчивый темп / энергичная работа


Слайд 57

Идеальный вариант


Слайд 58

Реальность


Слайд 59

Минимизация фазы приемочного тестирования Максимально улучшить качество исходного кода, создаваемого Scrum-командой. Максимально увеличить эффективность ручного тестирования


Слайд 60

Повышение качества с помощью тестировщика в команде


Слайд 61

Чем занимается тестировщик, когда нечего тестировать? Установить и настроить тестовое окружение. Уточнить требования. Детально обсудить процесс установки. Написать документы по установке. Пообщаться с подрядчиками. Улучшить скрипты автоматизированной сборки. Последующее разбиение историй на задачи. Собрать ключевые вопросы от разработчиков и проследить, чтобы они не остались без ответов.


Слайд 62

Повышайте качество – делайте меньше за спринт! Почти всегда получается дешевле сделать меньше, но качественнее, чем больше, но потом в панике латать дыры.


Слайд 63

Стоит ли делать приёмочное тестирование частью спринта? Спринт ограничен во времени. Приёмочное тестирование (которое включает отладку и повторный выпуск продукта), довольно сложно втиснуть в чёткие временные рамки. Если две Scrum-команды работают над одним продуктом, тогда ручное приёмочное тестирование необходимо проводить, собрав результаты работы обеих команд.


Слайд 64

Соотношение спринтов и фаз приемочного тестирования


Слайд 65

Не начинать новые истории, пока старые не будут готовы к реальному использованию


Слайд 66

Начинать реализовывать новые истории, но наивысшим приоритетом ставить доведение старых до ума


Слайд 67

Ограничения системы Заставить разработчиков потестировать. Внедрить новые инструменты и скрипты, которые упростят тестирование. Добавить больше автоматизации. Сделать длиннее спринт и включить приемочное тестирование в спринт. Выделить несколько "тестовых спринтов", где вся команда будет работать над приемочным тестированием. Нанять больше тестировщиков.


Слайд 68

Сколько сформировать команд Если настолько сложно работать по Scrum'у с несколькими командами, то зачем вообще заморачиваться? Почему просто не собрать всех в одну команду?


Слайд 69

Виртуальные команды


Слайд 70

Виртуальные команды


Слайд 71

Оптимальный размер команды


Слайд 72

Синхронизировать спринты или нет?


Слайд 73

Как распределить людей по командам Позволить специально назначенному человеку провести распределение. Позволить командам каким-то способом самоорганизоваться.


Слайд 74

Команды, специализирующиеся на компонентах


Слайд 75

Универсальные команды


Слайд 76

Стоит ли изменять состав команды между спринтами? Если вы решили изменить состав команды, учитывайте все последствия. Будут ли это долговременные или кратковременные изменения? Если кратковременные, стоит их пропустить. На долговременные изменения можно пойти.


Слайд 77

Scrum-of-Scrums Scrum-of-scrums – это регулярные встречи, цель которых – обсуждение различных вопросов между Scrum-мастерами.


Слайд 78

Чередование ежедневных Scrum'ов


Слайд 79

«Пожарные» команды Тушить пожары. Прикрывать Scrum-команду от всяких раздражителей, вроде неожиданных запросов на изменение функционала, которые непонятно откуда берутся.


Слайд 80

Разбивать product backlog или нет? Один product owner – один backlog


Слайд 81

Разбивать product backlog или нет? Один product owner – несколько backlog'ов


Слайд 82

Разбивать product backlog или нет? Несколько product owner'ов – несколько backlog'ов


Слайд 83

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


Слайд 84

Управление географически распределенными командами


Слайд 85

Управление географически распределенными командами


×

HTML:





Ссылка: