Scrum

Материал из Википедии — свободной энциклопедии
(перенаправлено с «Скрам»)
Перейти к навигации Перейти к поиску
Разработка программного обеспечения
Процесс разработки ПО
Ключевые процессы
Анализ • Проектирование • Программирование • Документирование • Тестирование
Модели
Итеративная • Спиральная • Каскадная • V-Model • Dual Vee Model
Методологии
Agile (XP, Lean, Scrum, FDD и др.) • Cleanroom • OpenUP • RAD • RUP • MSF • DSDM • TDD • BDD
Сопутствующие дисциплины
Конфигурационное управление • Управление проектами • Управление требованиями • Обеспечение качества

SCRUM (/skrʌm/[1][2]; англ. scrum «схватка») — методология управления проектами, предназначенная для разработки продуктов высокой ценности в запутанной среде.

SCRUM используется как в сфере разработки ПО, так и в других производственных бизнес-областях [3].

Кроме управления проектами по разработке ПО, Scrum может также использоваться в работе команд поддержки программного обеспечения, или как подход к управлению разработкой и сопровождению программ: Scrum of Scrums.

Содержание

Историческая справка[править | править код]

Схватка (Scrum) в регби между Newport и London Welsh в 1904

Подход впервые описали Хиротака Такэути[4] и Икудзиро Нонака[5] в статье The New Product Development Game (Гарвардский Деловой Обзор[6], январь-февраль 1986). Они отметили, что проекты, над которыми работают небольшие команды из специалистов различного профиля, обычно систематически производят лучшие результаты, и объяснили это как «подход регби». В 1991 году ДеГрейс и Шталь в книге «Нечестивые проблемы, праведные решения»[7] ссылались на этот подход, как на Scrum (толкотня; схватка вокруг мяча (в регби)), спортивный термин, приведенный в статье Такэути и Нонакой. Кен Швабер[8] в начале 1990-х использовал подход, который привел Scrum в его компанию. Впервые метод Scrum был представлен на общее обозрение задокументированным, четко сформированным и описанным совместно Швабером и Джефом Сазерлендом[9] на OOPSLA’96[10] (англ.) в Остине. Швабер и Сазерленд на протяжении следующих лет работали вместе, чтобы обработать и описать весь их опыт и лучшие практические образцы для индустрии в одно целое, в ту методологию, что известна сегодня как Scrum. Швабер объединил усилия с Майком Бидлом[11] в 2001 году, чтобы детально описать метод в книге «Agile Software Development with SCRUM»[12].

Определения[править | править код]

Скрам-процессы

SCRUM[править | править код]

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

Спринт[править | править код]

Спринт[13] — итерация в скраме, в ходе которой создается инкремент бизнес-продукта. Жестко фиксирован по времени. Длительность одного спринта от 1 до 4 недель. Тем не менее, считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении. С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а владелец продукта уменьшает издержки на совещания, демонстрации продукта и т. п. Разные команды подбирают длину спринта согласно специфике своей работы, составу команд и требований, часто методом проб и ошибок. Для оценки объема работ в спринте можно использовать предварительную оценку, измеряемую в очках истории. Предварительная оценка фиксируется в бэклоге проекта.

Артефакты SCRUM[править | править код]

Диаграмма сгорания задач (Burndown chart)[править | править код]

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

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

Данные диаграммы необходимо ежедневно обновлять, чтобы в реальном времени показывать подвижки и издержки в работе над спринтом и проектом, доступные для всех членов SCRUM-команды.

Диаграмма сгорания работ для спринта — показывает, сколько же задач сделано и сколько еще остается сделать в текущем спринте.

Журнал пожеланий проекта[править | править код]

Журнал пожеланий проекта (англ. Project backlog) — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются пользовательскими историями (user story) или элементами беклога (backlog items). Журнал пожеланий проекта открыт для редактирования для всех участников скрам-процесса.

Журнал пожеланий спринта[править | править код]

Журнал пожеланий спринта (англ. Sprint backlog) — содержит функциональность, выбранную владельцем продукта из журнала пожеланий проекта. Все функции разбиты по задачам, каждая из которых оценивается скрам-командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения спринта[14].

Канбан-доска[править | править код]

Доска должна состоять как минимум из трех колонок: «сделать» (англ. to-do), «в процессе» (in progress), «сделано»(done). При разработке ПО SCRUM канбан-доска обычно включает следующие колонки в соответствии со статусом задач: обсуждается (backlog), согласовано (ready), кодируется (coding), тестируется (testing), подтверждается (approval) и сделано (done). На доску в соответствующий столбец прикрепляются канбан-карточки. Вместо специальных канбан-карточек, которые обычно обозначают потребность или пропускную способность, вместе с доской используются магниты, пластиковые фишки, цветные шайбы или стикеры для представления рабочих элементов и процессов. Каждый из этих объектов представляет собой этап производственного процесса и движется по доске, по мере прогресса. Такое движение соответствует движению процесса производства.

Дополнительные определения[править | править код]

История спринта (Sprint Story)[править | править код]

Требуемую функциональность, которую добавляют в бэклог, часто называют историей. Зачастую история имеет следующую структуру: «Будучи пользователем <тип пользователя> я хочу сделать <действие>, чтобы получить <результат>». Такая структура удобна тем, что понятна как разработчикам, так и заказчикам.

Остановка спринта (Abnormal Termination)[править | править код]

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

Покер планирования (Planning Poker)[править | править код]

Очки за пользовательскую историю (Story Points)[править | править код]

Абстрактная метрика оценки сложности истории, которая не учитывает затраты в человекочасах. Обычно используют одну из следующих шкал: ряд Фибоначчи (1,2,3,5,8,13,21,34,55); линейную шкалу (1,2,3,4 … n); степень двойки (1,2,4,8 … 2n); размеры одежды (XS, S, M, L, XL).

Задачи истории спринта (Sprint Story Tasks)[править | править код]

Добавляются к историям спринта. Выполнение каждой задачи оценивается в часах. Каждая задача не должна превышать 12 часов (зачастую команда настаивает, чтобы максимальная продолжительность задачи равнялась одному рабочему дню).

Критерий готовности (Definition of Done, DoD)[править | править код]

Критерии, определяющие степень готовности элемента из журнала пожеланий пользователя.

Скорость команды (Velocity)[править | править код]

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

Роли в скрам-процессе[править | править код]

По методике Scrum в производственном процессе есть определенные роли, разбитые на 2 группы «свиней» и «кур». Эти названия были использованы из-за шутки[15]

Свинья идет по дороге. Курица смотрит на нее и говорит: «А давай откроем ресторан!» Свинья смотрит на курицу и отвечает: «Хорошая идея, и как ты хочешь его назвать?» Курица думает и говорит: «Почему бы не назвать „Яичница с беконом“?». «Так не пойдет, — отвечает свинья, — ведь тогда мне придется полностью посвятить себя проекту, а ты будешь вовлечена только частично».

Свиньи создают продукт, тогда как куры заинтересованы, но не настолько — ведь им все равно, будет ли проект удачным или нет, на них это мало отразится. Требования, пожелания, идеи и влияние кур принимаются во внимание, но им не разрешают непосредственно включаться в ход скрам-проекта.

Основные роли (Core roles) в методологии скрам («Свиньи»)[править | править код]

«Свиньи» полностью включены в проект и в скрам-процесс.

  • Скрам-мастер (SCRUM Master) — проводит совещания (Scrum meetings) следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию[неизвестный термин] митингов. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.
  • Скрам-владелец продукта (SCRUM Product Owner) — представляет интересы конечных пользователей и других заинтересованных в продукте сторон.
  • Скрам-команда (SCRUM Team) — кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды в идеале составляет от 5 до 9 человек. Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Никто, кроме команды, не может вмешиваться в процесс разработки на протяжении спринта.

Дополнительные роли (Ancillary roles) в методологии скрам («Куры»)[править | править код]

  • Пользователи (Users)
  • Клиенты, Продавцы (Stakeholders) — лица, которые инициируют проект и для кого проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).
  • Управляющие (Managers) — люди, которые управляют персоналом.
  • Эксперты-консультанты (Consulting Experts)

Пользовательские истории[править | править код]

Обязательные поля[править | править код]

  • ID — уникальный идентификатор, порядковый номер, применяемый для идентификации историй в случае их переименования.
  • Название (Name) — краткое описание истории. Оно должно быть однозначным, чтобы и разработчики, скрам-мастер, и владелец продукта могли понять, о чем идет речь и отличить одну историю от другой.
  • Важность (Importance) — степень важности данной истории, по мнению владельца продукта. Обычно представляет собой иррациональное число, иногда для этой цели используются числа Фибоначчи. Чем больше значение, тем выше приоритет.
  • Предварительная оценка (initial estimate) — начальная оценка объема работ, необходимого для реализации истории по сравнению с другими историями. Измеряется в story point’ах. Приблизительно соответствует числу «идеальных человеко-часов».
  • Как продемонстрировать (how to demo) — краткое пояснение того, как завершенная задача будет продемонстрирована в конце спринта. Данное поле может представлять собой код автоматизированного теста для приемо-сдаточного испытания.
  • Критерии приемки (acceptance criteria) — значимые детали реализации истории, уточняющие требования владельца продукта, собранные всеми участниками SCRUM-команды при планировании спринта.[16]

Дополнительные поля[править | править код]

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

  • Категория (track). Например, «панель управления» или «оптимизация». При помощи этого поля скрам-мастер или владелец продукта может легко выбрать все пункты категории «оптимизация» и установить им низкий приоритет.
  • Компоненты (components) — указывает, какие компоненты (например, база данных, сервер, клиент) будут затронуты при реализации истории. Данное поле состоит из группы checkbox’ов, которые отмечаются, если соответствующие компоненты требуют изменений.
  • Инициатор запроса (requestor). владелец продукта может захотеть хранить информацию о всех заказчиках, заинтересованных в данной задаче. Это нужно для того, чтобы держать их в курсе дела о ходе выполнения работ.
  • ID в системе учета дефектов (bug tracking ID) — если вы используете отдельную систему отслеживания ошибок, тогда в описании истории полезно хранить ссылки на все дефекты, которые к ней относятся.

Собрания[править | править код]

Планирование спринта (Sprint Planning Meeting)[править | править код]

Происходит в начале новой итерации Спринта.

  • Из бэклога проекта выбираются задачи, обязательства по выполнению которых за спринт принимает на себя команда;
  • На основе выбранных задач создается бэклог спринта. Каждая задача оценивается в идеальных человеко-часах;
  • Решение задачи не должно занимать более 12 часов или одного дня. При необходимости задача разбивается на подзадачи;
  • Обсуждается и определяется, каким образом будет реализован этот объем работ;
  • Продолжительность митинга ограничена сверху 8 часами в зависимости от продолжительности итерации, опыта команды и т. п.
    • (первая часть совещания) Участвуют скрам-мастер, владелец продукта и скрам команда: выбирают задачи из бэклога продукта;
    • (вторая часть совещания) Участвует только команда: обсуждают технические детали реализации, наполняют бэклог спринта.

Ежедневное совещание (Daily SCRUM meeting)[править | править код]

  • начинается точно вовремя;
  • все могут наблюдать, но только «свиньи» говорят;
  • длится ровно 15 минут;
  • проводится в одном и том же месте в течение спринта.

В течение совещания каждый член команды отвечает на 3 вопроса:

  • Что я сделал с момента прошлой встречи для того, чтобы помочь Команде Разработки достигнуть Цели Спринта?
  • Что я сделаю сегодня для того, чтобы помочь Команде Разработки достичь Цели Спринта?
  • Вижу ли я препятствия для себя или Команды Разработки, которые могли бы затруднить достижение Цели Спринта? (Над решением этих проблем работает скрам мастер. Обычно это решение проходит за рамками ежедневного совещания и в составе лиц, непосредственно затронутых данным препятствием.)

Скрам над скрамом (SCRUM of SCRUMs)[править | править код]

Если коллектив больше 11 человек то команда больше рекомендуемого SCRUM размера. Тогда коллектив разбивается на несколько SCRUM-команд. В каждой cвой скрам-мастер и скрам-владелец продукта.

Команды проводят Daily SCRUM.

После ежедневного скрам-совещания проводится митинг SCRUM of SCRUMs. Это значит следующее. От каждой команды выбирается по представителю. Представители разбиваются по 5-9 человек. Каждой группе назначается главный скрам-мастер (Chief SCRUM Master) и главный скрам-владелец продукта (Chief SCRUM Product Owner) из числа скрам-мастеров и скрам-владельцев продукта, участвующих в проекте. В таком составе проводят 15-минутный стоячий скрам-митинг - SCRUM of SCRUMs.

SCRUM of SCRUMs позволяет нескольким скрам-командам обсуждать работу, фокусируясь на общих областях и взаимной интеграции. Повестка та же, что и на ежедневном скрам-совещании плюс следующие вопросы:

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

Если SCRUM of SCRUMs не охватывает весь коллектив, может быть проведен митинг SCRUM of SCRUM of SCRUMs, SCRUM of SCRUM of SCRUM of SCRUMs. Такой подход позволяет всего за час организовать работу 4096 человек[17].

Обзор итогов спринта (Sprint review meeting)[править | править код]

Проводится в конце спринта.

  • Команда демонстрирует прирост инкремента business-value всем заинтересованным лицам.
  • Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт).
  • Нельзя демонстрировать незавершенную функциональность.
  • Ограничена четырьмя часами в зависимости от продолжительности итерации и прироста функциональности продукта.

Ретроспективное совещание (Retrospective meeting)[править | править код]

Проводится в конце спринта.

  • Члены скрам-команды высказывают свое мнение о прошедшем спринте.
  • Отвечают на два основных вопроса:
    • Что было сделано хорошо в прошедшем спринте?
    • Что надо улучшить в следующем?
  • Выполняют улучшение процесса разработки (обсуждают варианты решения проблем, фиксируют удачные решения и вызвавшегося владельца решения).
  • Ограничена четырьмя часами для спринта любой длины.

Обучение и сертификация специалистов по SCRUM[править | править код]

В SCRUM важнейшую роль играют квалифицированные SCRUM Master, SCRUM Product Owner и SCRUM Team. Основатели SCRUM и сертифицированные тренеры (CST) проводят обучающие курсы с последующей сертификацией специалистов по SCRUM. Обязательную основу для всех составляют навыки скрам-мастера. Далее идет специализация на SCRUM Master, SCRUM Product Owner и SCRUM Developer (член SCRUM Team). Успешно сдавшим экзамен выдаются сертификаты: Certified SCRUM Master (CSM), Certified SCRUM Product Owner (CSPO), Certified SCRUM Developer (CSD), Professional SCRUM Master (PSM), Professional SCRUM Product Owner (PSPO), Professional SCRUM Developer (PSD).

Возможно дальнейшее обучение с выдачей сертификата тренера по SCRUM - Certified SCRUM Trainer (CST) или Professional SCRUM Trainer (PST). К сертификации на CST допускаются лица, имеющие сертификат CSM или CSPO [18].

В рамках сертификации PST выделяются тренеры скрам-мастеров (PSSMT), скрам-владельцев продукта (PSPOT) и скрам-разработчиков (PSDT) [19][20] [21]. Для допуска к курсам тренеров - train-the-trainer (TTT) и сертификации требуются:

  • на PSSMT - сертификат PSM III
  • на PSPOT - сертификаты PSM I и PSPO I
  • на PSDT - сертификаты PSM I и PSD I.

Примечания[править | править код]

  1. «scrum» перевод английский-русский. Lingvo.abbyyonline.com. Проверено 4 мая 2016.
  2. Как произносится scrum. forvo.com. Проверено 4 мая 2016.
  3. https://www.scrumalliance.org/ScrumRedesignDEVSite/media/ScrumAllianceMedia/Global%20Scrum%20Gatherings/2017%20San%20Diego/Presentations/JusticeJoe_Agile_In_Military_Hardware_SGSD.pdf
  4. en:Hirotaka Takeuchi
  5. en:Ikujiro Nonaka
  6. Harvard Business Review
  7. Leslie Hulet Stahl: Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms Yourdon Press Computing Series, 1990 (первое издание) ISBN 0-13-590126-X
  8. en:Ken Schwaber
  9. en:Jeff Sutherland
  10. OOPSLA 2006
  11. Mike Beedle
  12. Schwaber, Ken. Agile software development with Scrum / Ken Schwaber, Beedle. — Prentice Hall, 2002. — ISBN 0-13-067634-9.
  13. Sprint — рывок; бросок; бег на короткую дистанцию; спринт
  14. Ken Schwaber. Agile Project Management with Scrum. — Microsoft Press, 2004. — 163 с. — ISBN 073561993X.
  15. page 7
  16. Критерии приемки для требований в Agile. Devprom ALM. Проверено 3 апреля 2016.
  17. Agile In Military Hardware. How the SAAB Gripen became the world’s most cost effective military aircraft / Sutherland and Joe Justice, 2017  (англ.)
  18. https://www.scrumalliance.org/get-certified/trainers/cst-certification
  19. https://www.scrum.org/become-professional-scrum-trainer/psd
  20. https://www.scrum.org/become-professional-scrum-trainer/pspo
  21. https://www.scrum.org/become-professional-scrum-trainer/psm

См. также[править | править код]

Ссылки[править | править код]

Литература[править | править код]

  • Хенрик Книберг. Scrum и XP: заметки с передовой = Scrum and XP from the trenches. — C4Media, 2007. — С. 140. — ISBN 978-1-4303-2264-1.
  • Майк Кон. Scrum: гибкая разработка ПО = Succeeding with Agile: Software Development Using Scrum. — М.: «Вильямс», 2011. — С. 576. — ISBN 978-5-8459-1731-7.
  • Джефф Сазерленд. Scrum. Революционный метод управления проектами = Scrum. The art of doing twice the work in half the time. — Манн, Иванов и Фербер, 2016. — 288 с. — ISBN 978-5-00057-722-6.
  • Кеннет Рубин. Основы Scrum: Практическое руководство по гибкой разработке ПО = Essential Scrum: A Practical Guide to the Most Popular Agile Process. — М.: «Вильямс», 2016. — С. 544. — ISBN 978-5-8459-2052-2.