1. Ценности
1.1. Как можно видеть в Scrum всего 5 ценностей и они очень важны при его реализации, так как они изменяют стиль работы команды и создают возможности сотрудничества между командой и бизнес заказчиками. Разделение командой этих ценностей и воплощение их в жизнь создает основу Scrum. Все ценности взаимосвязаны и если будет потеряна хоть одна, то добиться успеха будет невозможно.
1.1.1. работу лучше начать со смелости и открытости
1.1.2. Успешность использования Скрама напрямую зависит от того, насколько хорошо люди придерживаются этих ценностей.
1.2. Смелость
1.2.1. Смелость — принимать сложные решения, указывать на проблемы в команде или в процессе.
1.2.2. Примерами смелости могут быть:
1.2.3. Отказаться от еще одного дополнительного проекта, когда вы уже в другом проекте;
1.2.4. Сказать «нет» дополнительным задачам, которые ставят под угрозу цель спринта;
1.2.5. Сказать «стоп», когда команда разработки на планировании берет больше User Story, чем может сделать.
1.3. Открытость
1.3.1. Открытость — команда и заинтересованные лица (заказчик) остаются открытыми относительно всего процесса поставки ценности и возникающих трудностей.
1.3.2. Примерами открытости могут быть:
1.3.3. Сделать прозрачным для всех заинтересованных лиц процесс выдачи оценок;
1.3.4. Во время сообщать о возникающих трудностях;
1.3.5. Сделать прозрачным для всех заинтересованных лиц процесс принятия тех или иных решений.
1.4. Уважение
1.4.1. Уважение — участники команды уважают профессионализм, индивидуальность и самостоятельность каждого.
1.4.2. Примерами уважения могут быть:
1.4.3. Исключение микроменеджмента;
1.4.4. Дать возможность команде разработки учиться на собственных ошибках;
1.4.5. Уважение со стороны команды разработки к тем, кто не имеет богатого технического опыта.
1.5. Сфокусированность
1.5.1. Сфокусированность — команда разработчиков сфокусирована на выполняемых задачах, на цели спринта и на ее достижении без прерывания и переключения
1.5.2. Примерами сфокусированности могут быть:
1.5.3. Не брать новую задачу, если текущая не доделана;
1.5.4. Исключение переключение и возможные прерывания;
1.5.5. Не вносить изменения, которые меняют цель спринта;
1.5.6. На том, что нужно заказчику.
1.6. Обязательность
1.6.1. Обязательность — это когда ты можешь сказать, что на меня можно положиться.
1.6.2. Примерами обязательности могут быть:
1.6.3. Scrum команда обязуется сотрудничать, чтобы достигнуть цели спринта;
1.6.4. Product Owner обязуется прояснить и донести до команды разработки Product Vision;
1.6.5. Product Owner обязуется поддерживать Product Backlog Items в актуальном состоянии, достаточно детализированными и приоритезированными;
1.6.6. Product Owner обязуется смотреть законченный функционал в течение спринта не дожидаясь его окончания;
1.6.7. Scrum Master обязуется защищать и удалять все препятствия у команды на пути достижения цели спринта.
2. Скрам-команда
2.1. Владелец Продукта
2.1.1. Характеристики
2.1.1.1. Несет ответственность за достижение максимальной ценности продукта
2.1.1.2. Роль Владельца Продукта исполняет один человек, а не группа людей.
2.1.1.3. Единственный человек, который отвечает за управление Бэклогом Продукта
2.1.1.4. Владелец Продукта может выполнять эту работу как самостоятельно, так и делегировать её выполнение членам Команды Разработки.
2.1.2. Управление бэклогом включает в себя
2.1.2.1. описание Элементов Бэклога Продукта ясным и понятным образом;
2.1.2.2. управление порядком Элементов Бэклога Продукта для наилучшего достижения целей и миссий;
2.1.2.3. оптимизацию ценности работы, выполняемой Командой Разработки;
2.1.2.4. обеспечение доступности, прозрачности и ясности Бэклога Продукта для всех участников процесса. Бэклог Продукта при этом отражает, над чем Скрам-команда будет работать дальше;
2.1.2.5. гарантию, что Команда Разработки в достаточной степени понимает Элементы Бэклога Продукта.
2.2. Команда разработки
2.2.1. Характеристики
2.2.1.1. Они самоорганизующиеся: никто (даже Скрам-мастер) не может указывать Команде Разработки как превратить Бэклог Продукта в готовые к релизу Инкременты.
2.2.1.2. Они кросс-функциональны: команда обладает всеми навыками, которые необходимы для создания Инкремента Продукта.
2.2.1.3. Разработчик — единственная роль для членов Команды Разработки, независимо от типа задач, которые он выполняет. Скрам не признает других ролей в Команде Разработки, это правило не имеет исключений.
2.2.1.4. Скрам не признает подкоманд в Команде Разработки, независимо от областей, над которыми необходимо работать (например, тестирование, архитектура, эксплуатация или бизнес-аналитика). Это правило не имеет исключений.
2.2.1.5. Команда Разработки несет коллективную ответственность за создание Инкремента Продукта. При этом отдельные члены Команды Разработки могут обладать различными специализированными навыками и экспертизой.
2.2.2. Размер Команды Разработки
2.2.2.1. 3-9 человек без учета Скрам-мастера и Владельца Продукта
2.3. Скрам мастер
2.3.1. Харакетиристики
2.3.1.1. Скрам-мастер несет ответственность за продвижение и поддержку Скрама в соответствии с Руководством по Скраму.
2.3.1.2. Скрам-мастер — это лидер-слуга для Скрам-Команды.
2.3.1.2.1. Лидер - защищает команду
2.3.1.2.2. Доминант - защищается от команды
2.3.2. Услуги Скрам-мастера для Владельца Продукта
2.3.2.1. обеспечивает условия, при которых Скрам-команда как можно лучше понимает цели, объём работ и предметную область;
2.3.2.2. помогает найти наиболее эффективные техники для управления Бэклогом Продукта;
2.3.2.3. объясняет Скрам-команде необходимость кратких и понятных Элементов Бэклога Продукта;
2.3.2.4. объясняет особенности планирования продукта в эмпирической среде;
2.3.2.5. помогает Владельцу Продукта упорядочить Бэклог Продукта, чтобы получить максимальную ценность продукта;
2.3.2.6. способствует лучшему пониманию гибкости и её применения;
2.3.2.7. фасилитирует10 события Скрама при необходимости.
2.3.3. Услуги Скрам-мастера для Команды
2.3.3.1. коучит Команду Разработки быть самоорганизующейся и кросс-функциональной;
2.3.3.2. помогает Команде Разработки создавать продукты с высокой ценностью;
2.3.3.3. устраняет препятствия, мешающие прогрессу Команды Разработки;
2.3.3.4. фасилитирует события Скрама при необходимости;
2.3.3.5. коучит Команду Разработки в тех частях организации, в которых Скрам еще не полностью понят и принят.
2.3.4. Услуги Скрам-мастера для Организации
2.3.4.1. направляет и коучит организацию при внедрении Скрама;
2.3.4.2. планирует переход на Скрам в организации;
2.3.4.3. помогает сотрудникам и заинтересованным лицам понять теорию и практику Скрама, правильно реализовать принципы эмпирической разработки продуктов;
2.3.4.4. способствует изменениям, направленным на повышение продуктивности Скрам-команд;
2.3.4.5. сотрудничает с другими Скрам-мастерами для повышения эффективности применения Скрама в организации.
3. Назначение Руководства по Скраму
3.1. Скрам – это фреймворк, предназначенный для разработки, поставки и поддержки сложных продуктов
3.2. Это Руководство содержит описание Скрама, оно рассказывает о ролях, событиях, артефактах2 и правилах фреймворка
4. Определение Скрама
4.1. Скрам (сущ.) — это фреймворк, который помогает решать изменяющиеся в процессе работы задачи, чтобы продуктивно и творчески поставлять клиентам продукты с максимально возможной ценностью
4.2. Скрам не является процессом, техникой или исчерпывающим методом. Напротив, Скрам — это фреймворк, в котором можно использовать разнообразные процессы и методы
4.3. Скрам является
4.3.1. компактным,
4.3.2. простым для понимания,
4.3.3. трудным для совершенного овладения.
4.4. Скрам проявляет несовершенства в управлении продуктом и методах работы, чтобы вы могли постоянно улучшать продукт, команду и рабочее окружение.
4.5. Каждый элемент фреймворка служит определенной цели и является обязательным для успешного использования Скрама.
4.6. Правила Скрама связывают вместе события, роли и артефакты, регулируют отношения и взаимодействия между ними. Они описаны в этом документе.
5. Применения Скрама
5.1. Области применения
5.1.1. 1) исследовать и выявлять жизнеспособные рынки, технологии и возможностипродуктов;
5.1.2. 2) разрабатывать продукты и улучшать их;
5.1.3. 3) выпускать продукты и их обновления по несколько раз в день;
5.1.4. 4) разрабатывать и поддерживать облачные технологии (онлайн, безопасно, по требованию) и другие среды для использования продуктов;
5.1.5. 5) поддерживать и обновлять продукты
5.2. Суть Скрама — это маленькая команда людей. Каждая отдельная команда чрезвычайно гибка и адаптивна. Эти преимущества проявляются, распространяясь на любое количество команд в организации
6. Теория Скрама
6.1. Скрам основан на теории эмпирического управления (эмпиризме). Согласно этой теории, источником знаний является опыт, а источником решений – реальные данные.
6.2. Скрам использует итеративный и инкрементальный подход, чтобы улучшать прогнозируемость и управлять рисками. Процесс эмпирического управления основан на «трех китах»: прозрачности, инспекции и адаптации.
6.2.1. Прозрачность
6.2.1.1. «Прозрачность» означает, что значимые характеристики процесса должны быть известны тем, кто отвечает за его результат. Прозрачность требует: эти характеристики должны быть обозначены общими соглашениями, чтобы все участники одинаково понимали происходящее.
6.2.2. Инспекция
6.2.2.1. Участники процесса должны регулярно инспектировать артефакты Скрама и свой прогресс в движении к Цели Спринта, чтобы вовремя обнаружить нежелательные отклонения. Частота проведения проверок не должна мешать работе. Проверки приносят наибольшую пользу, когда выполняются профессионалами с соответствующими навыками.
6.2.3. Адаптация
6.2.3.1. Если в результате инспекции выясняется, что одна или несколько характеристик процесса выходят за допустимые пределы, и это приводит продукт в неприемлемое состояние, то процесс или обрабатываемый материал необходимо изменить. Чем раньше будут внесены изменения, тем меньше риск дальнейших отклонений.
6.2.4. Скрам предполагает четыре формальных события для инспекции и адаптации:
6.2.4.1. Планирование Спринта;
6.2.4.2. ЕжедневныйСкрам;
6.2.4.3. Обзор Спринта;
6.2.4.4. Ретроспектива Спринта.
7. События Скрама
7.1. Общие характетистики
7.1.1. Регулярно
7.1.2. Ограничено по времени
7.1.3. Возможность для инспекции и адаптации
7.1.4. Обязательно
7.2. Спринт
7.2.1. Характеристики
7.2.1.1. Длительность месяц или меньше
7.2.1.1.1. Выгоды
7.2.1.2. Создается пригодный к использованию и выпуску Инкремент продукта.
7.2.1.3. Новый начинается после окончания предыдущего
7.2.1.4. Правила
7.2.1.4.1. не допускаются изменения, которые могут поставить под угрозу Цель Спринта;
7.2.1.4.2. качество продукта не должно снижаться;
7.2.1.4.3. по мере появления новых знаний, объём работ может быть уточнен и заново согласован между Владельцем Продукта и Командой Разработки.
7.2.2. Отмена Спринта
7.2.2.1. Существует единственное основание для отмены Спринта — потеря актуальности Цели Спринта
7.3. Планирование Спринта
7.3.1. Характеристики
7.3.1.1. Планирование Спринта ограничено по времени
7.3.1.2. Для Спринта длительностью один месяц Планирование не должно занимать более 8 часов
7.3.1.3. По результатам Планирования Спринта Скрам-команда решает:
7.3.1.3.1. • каким будет Инкремент в конце Спринта;
7.3.1.3.2. как организовать работу, чтобы получить готовый Инкремент Продукта
7.3.2. Тема первая: что будет сделано?
7.3.2.1. Команда Разработки прогнозирует объём функциональности, который будет разработан в течение Спринта
7.3.2.2. Владелец Продукта выносит на обсуждение два важных вопроса:
7.3.2.2.1. бизнес-цели, которые должны быть достигнуты в Спринте
7.3.2.2.2. Элементы Бэклога Продукта, необходимые для достижения Цели Спринта
7.3.2.3. Для проведения Планирования Спринта нужны:
7.3.2.3.1. Бэклог Продукта
7.3.2.3.2. последний Инкремент продукта
7.3.2.3.3. прогноз возможностей Команды Разработки в будущем Спринте
7.3.2.3.4. статистика её прошлой производительности
7.3.2.4. Команда Разработки определяет количество Элементов Бэклога Продукта, которые могут быть выполнены в Спринте
7.3.2.4.1. Ей же принадлежит исключительное право оценивать объём работ, который по силам завершить в текущем Спринте.
7.3.3. Тема вторая: как будет выполнена работа?
7.3.3.1. Команда Разработки решает, как реализовать эту функциональность в виде готового Инкремента продукта в течение Спринта
7.3.3.2. Выбранные Элементы Бэклога Продукта и план их реализации называют Бэклогом Спринта.
7.3.3.2.1. Часто к концу Планирования Спринта Команда Разработки более тщательно детализирует работу, которую будет выполнять в первые дни Спринта.
7.3.3.3. Команда Разработки самоорганизуется как во время Спринта, так и во время его Планирования при работе над Бэклогом Спринта.
7.3.3.3.1. Владелец Продукта помогает прояснить смысл выбранных элементов
7.4. Цель Спринта
7.4.1. Характеристики
7.4.1.1. Цель Спринта формируется во время его Планирования и объясняет Команде Разработки, для чего создается Инкремент.
7.4.1.2. Цель Спринта оставляет Команде Разработки некоторую гибкость в объёме функциональности, которую они разрабатывают в рамках Спринта
7.4.1.3. Цель Спринта – это ориентир для Команды Разработки
7.4.1.4. Чтобы его достичь, команда должна использовать технологии и реализовывать функциональность.
7.4.1.5. Если объём работ становится отличным от ожиданий Команды Разработки, команда договаривается с Владельцем Продукта об объёме Бэклога текущего Спринта
7.5. Ежедневный Скрам
7.5.1. Характеристики
7.5.1.1. Встреча не должна занимать более 15 минут, за которые Команда разработки планирует свою работу на ближайшие 24 часа
7.5.1.2. Команда оптимизирует взаимодействие между её членами и повышает свою производительность, анализируя сделанное за последние сутки и прогнозируя оставшуюся на этот Спринт работу.
7.5.1.2.1. Для упрощения Ежедневный Скрам проводится каждый день в одно и то же время.
7.5.1.3. Команда Разработки использует это событие для инспектирования своего продвижения к Цели Спринта и отслеживания прогресса по работе над Бэклогом Спринта, а также для того, чтобы понять, успевает ли она завершить задачи Спринта в срок.
7.5.1.4. Команда сама определяет формат встречи, но акцент всегда остается на достижении Цели Спринта.
7.5.1.4.1. Что я сделал вчера, что помогло Команде Разработки приблизиться к Цели Спринта?
7.5.1.4.2. Что я сделаю сегодня, чтобы помочь Команде Разработки достичь Цели Спринта?
7.5.1.4.3. Вижу ли я какие-либо препятствия, которые могут помешать мне или Команде Разработки достичь Цели Спринта?
7.5.1.5. Скрам-мастер следит, чтобы встреча Команды Разработки состоялась, но за проведение Ежедневного Скрама отвечает сама команда.
7.5.1.6. Ежедневный Скрам улучшает коммуникации, делает другие встречи ненужными, помогает выявить препятствия в разработке, которые необходимо устранить. Он способствует и поощряет быстрое принятие решений, повышает уровень знаний Команды Разработки. Это ключевая встреча для Инспекции и Адаптации.
7.6. Обзор Спринта
7.6.1. Обзор Спринта проводится в конце Спринта с целью инспекции Инкремента и, по необходимости, адаптации Бэклога Продукта.
7.7. Ретроспектива Спринта
7.7.1. Ретроспектива Спринта — это возможность для Скрам-команды провести инспекцию, направленную на себя, и создать план улучшений командной работы в следующем Спринте.