Scrum

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск
Разработка программного обеспечения
Процесс разработки ПО
Шаги процесса

Анализ • Проектирование • Программирование • Документирование • Тестирование

Модели

Итеративная • Спиральная • Каскадная • V-Model • Dual Vee Model

Методологии

Agile (XP, Lean, Scrum, FDD и др.) • Cleanroom • OpenUP • RAD • RUP • MSF • DSDM • TDD

Сопутствующие дисциплины

Конфигурационное управление • Управление проектами • Управление требованиями

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

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

Содержание

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

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

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

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

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

Scrum[править | править вики-текст]

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

Спринт[править | править вики-текст]

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

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

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

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

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

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

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

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

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

Существуют два вида диаграммы:

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

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

История спринта (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 группы «свиней» и «кур». Эти названия были использованы из-за шутки[14]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Скрам над скрамом (Scrum of Scrums)[править | править вики-текст]

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

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

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

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

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

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

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

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

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

  1. «scrum» перевод английский-русский. Lingvo.abbyyonline.com. Проверено 4 мая 2016.
  2. Как произносится scrum. forvo.com. Проверено 4 мая 2016.
  3. en:Hirotaka Takeuchi
  4. en:Ikujiro Nonaka
  5. Harvard Business Review
  6. Leslie Hulet Stahl: Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms Yourdon Press Computing Series, 1990 (первое издание) ISBN 0-13-590126-X
  7. en:Ken Schwaber
  8. en:Jeff Sutherland
  9. OOPSLA 2006
  10. Mike Beedle
  11. Agile software development with Scrum. — Prentice Hall, 2002. — ISBN 0-13-067634-9.
  12. Sprint — рывок; бросок; бег на короткую дистанцию; спринт
  13. Ken Schwaber. Agile Project Management with Scrum. — Microsoft Press, 2004. — 163 с. — ISBN 073561993X.
  14. page 7
  15. Критерии приёмки для требований в Agile. Devprom ALM. Проверено 3 апреля 2016.

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

Ссылки[править | править вики-текст]

Литература[править | править вики-текст]

  • Хенрик Книберг. 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.