Scrum- Скрам процессы разработки интернет сайтов, порталов
= scrimmage (англ.) * 1. существительное: 1) драка, потасовка Синонимы: scuffle, fight 2) спорт. драка за мяч (в регби) 2. глагол: 1) драться, участвовать в потасовке 2) спорт. драться за мяч

Заказать сайт, задать вопрос 

Scrum — методология управления проектами. Scrum чётко делает акцент на качественном контроле процесса разработки.

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


 Определение Scrum

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

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

Главные действующие роли в Scrum:

  • ScrumMaster — тот, кто ведёт Scrum митинги и следит, чтобы при этом соблюдались все принципы Scrum (роль не предполагает ничего кроме корректного ведения самого Scrum-а, руководитель проекта скорее относится к Product Owner и не должен являться ScrumMaster);
  • Владелец Продукта (Product Owner) — человек, который представляет интересы конечных пользователей и других заинтересованных в продукте сторон;
  • кросс-функциональную Команду (Scrum Team), состоящую как из разработчиков, так и из тестировщиков, архитекторов, аналитиков и т. д. (при этом размер команды в идеале составляет 7±2 человека). Команда является единственным полностью вовлечённым участником разработки, и отвечает за результат как единое целое. Никто кроме команды не может вмешиваться в процесс разработки на протяжении итерации-спринта.

На протяжении каждого итерации-спринта[6], 7-15-30 дневного периода (длительность определяется командой), создаётся функциональный рост программного обеспечения.

Набор возможностей, которые реализуются в каждом спринте, происходят из этапа, называемого product backlog (документация запросов на выполнение работ), обладающего наивысшим приоритетом по уровню требований к работе, который должен быть выполнен. Запросы на выполнение работ (backlog items), определенных на протяжении совета по планированию спринта (sprint planning meeting), перемещаются в этап спринта. На протяжении этого собрания Владелец Продукта информирует о заданиях, которые должны быть выполнены. Тогда Команда определяет, сколько из желаемого они могут выполнить, чтобы завершить необходимые части на протяжении следующего спринта[7]. Во время спринта команда выполняет определенный фиксированный список заданий (т. н. sprint backlog). На протяжении этого периода никто не имеет права менять список требований к работе, что следует понимать как заморозку требований (requirements) во время спринта.

Роли в scrum-процессе

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

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

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

«Свиньи»

Свиньи полностью включены в проект, в Скрам процесс, они как бы едины со «своей сущностью» на производственной линии.

  • Владелец Продукта (Product Owner)
  • Руководитель (ScrumMaster)
  • Команда (Scrum Team)

«Цыплята»

  • Пользователи (Users)
  • Клиенты, Продавцы (Stakeholders)
  • Эксперты-консультанты (Consulting Experts)

 

Артефакты

 Product backlog (бэклог)

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

Обязательные поля бэклога

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

Дополнительные поля

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

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

Встречи

Планирование спринта (Planning Meeting)

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

  • Выбирается объём работ, обязательства по выполнению которой за спринт принимает на себя команда
  • Обсуждается и определяется, каким образом будет реализован этот объём работ
  • Каждая запись PBL принятая к реализации разбивается на подзадачи, которые оцениваются в идеальных человеко-часах
  • Ограничен 4-8 часами в зависимости от продолжительности итерации, опыта команды и т. п.

Митинг (Daily Scrum)

Burndown-диаграмма, отображает текущее состояние спринта, степень отставания/опережения плана.

Происходит каждый день в течение спринта. Является «пульсом» хода спринта. Митингу присущи следующие ограничения:

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

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

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

Демонстрация (Demo Meeting)

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

Ретроспектива (Retrospective Meeting)

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

Примечания

  1. Hirotaka Takeuchi, Ikujiro Nonaka
  2. Harvard Business Review
  3. Peter DeGrace, Leslie Hulet Stahl: Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms Yourdon Press Computing Series, 1990 (первое издание) ISBN 0-13-590126-X
  4. OOPSLA 2006
  5. Mike Beedle
  6. Sprint — рывок; бросок; бег на короткую дистанцию; спринт
  7. Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, January 2004, 163pp, ISBN 0-7356-1993-X
  8. page 7