Scrum (часть 1)

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

Глоссарий


Предопределенный процесс (Defined process)
Предопределенный процесс ведущий к получению предсказуемого результата.

Эмпирический процесс (Empirical process)
Частая проверка и адаптация деятельности, чтобы удовлетворить желаемым результатам.

Итеративная разработка (Iterative development)
Разработка ПО которая представляет собой короткие и повторяемые циклы, с обратной связью от заказчика после каждой итерации.

Скрум Мастер (Scrum Master)
Менеджер проекта

Свинья (Pig)
Явный член проекта.

Цыпленок (Chicken)
Внешний наблюдатель Скрум проекта.

Спринт (Sprint)
30 дневная итерация с заранее определенным набором функциональности.
Результат Спринта это рабочее и демонстрируемое ПО.

Резерв свойств продукта (Product Backlog)
Репозитарий функционала ПО

Резерв свойств Спринта (Sprint backlog)
Функционал и требования в границах Спринта

Активность Зонта (Umbrella activity)
Администратиывные задания, которые не относятся на прямую к текущему программному продукту.

История

Корни Скрума произростают из статьи суммирующей общие лучшие практики в 10 инновационных японских компаниях, “The New New Product Development Game,” Harvard Business Review, январь 1986, написанной Такеши (Takeuchi) и Нонака (Nonaka). Они ввели термин Sashimi (slices) для IID (итеративной инкрементной разработки), и Скрум (Scrum) для адаптивных и само направляемых командных практик.

Название было взято из игры регби, из-за командного поведения передвигающего по полю мяч. Джеф Сазерленд (Jeff Sutherland) один из создателей Скрума и бывший вице-президентом в Easel Corp., в 1994-ом он представил свои методы, под влиянием отчета о гипер-продуктивных проектах в Borland Corp, которые эффективно использовали структурированные ежедневные митинги В 1996 Сазерленд перешел в Individual Inc., и попросил Кена Швабера (Ken Schwaber) помочь в адаптации идей Скрума. Швабер и Сазерленд отшлифовали и расширили Скрум.

Scrum – с англ. драка за мяч (в регби)

Введение

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

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

Основные характиристики:

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

Роли

Заказчик

Владелец продукта (Product Owner)
  • один человек кто отвечает за создание и расстановку приоритетов в “Резерве свойств продукта”
  • выбирает цели (из “Резерве свойств продукта”) для следующего Спринта
  • совместно с другими заинтересованными лицами проверяет систему в конце каждого Спринта

Разработка

Скрум Команда (Scrum Team)
  • работает над “Резервом свойств Спринта”
  • нет других явных позиций кроме «член команды «

Управление

Скрум Мастер (Scrum Master)
  • следит чтобы Скрум ценности и практики применялись
  • буфер между менеджментом и Скрум командой
  • следит за прогрессом и удаляет помехи
  • руководит ежедневным Скрумом
  • решает неразрешенные вопросы во время ежедневного Скрума
  • проводит рецензию Спринта

 

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

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

Открытость—Открыто доступный “резерв свойств продукта” делает видимым объем работ и приоритеты. Ежедневные Скрумы делают видимым общий и индивидуальный вклад и состояние дел. Рабочий курс (Work trend) и скорость становиться видимым при помощи графика резерва свойств.

Уважение—Командная ответсвенность предпочтительее козлов отпущения. Отдельные члены команды отвечают за различные сильные и слабые стороны, но нет отвественного за провал итерации. Целая команда, а не менеджер, бросает свои силы, для решения “индивидуальных” проблем в группе, а также команда обладает властью и ресурсами реагировать на трудности, например нанимать консультанта-специалиста чтобы компенсировать отсутсвие экспертов.

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

Основные практики

Спринт (Sprint)

Работа организовывается итерациями по 30 календарных дней, каждая из которых называется Спринт.

Самонаправляющиеся и самоорганизующиеся команды

Во время итерации, руководство и Скрум Мастер не направляют команду как выполнить цели итерации, не решают их проблем (кроме как принять решение когда запросить и удалить выполненный блок), не планируют и сортируют работу. Команда наделена правами, властью и ресурсами в поисках своего пути, и решении собственных проблем. Подход “руки прочь” на 30 дней, за исключением обеспечения ресурсами и удаления блоков, это возможно наиболее трудный аспект для руководителей адоптирующих Скрум.

Скрум собрание (Scrum Meeting)

Каждый рабочий день в одно и то же время на одном и том-же месте, собирается собрание членов команды, на котором даются ответы на специальные Скрум вопросы каждым членом команды.

Не добовлять к итерации (Don’t Add to Iteration)

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

Скрум мастер экран (Scrum Master Firewall)

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

Решение за час

Блоки определенные на скрум митинге которые требуют решения Скрум Мастера идеально его сразу же и получают, или в течении 1 часа. Пропогандируеся ценность “плохое решение лучше чем никакое, и также обратное”.

Блок уходит за 1 день

Блоки определенные к разработке на Скрум собрании идеально удаляются на следующем митинге.

Цыплята и свиньи

Во время Скрум собрания, только Срум Команда может говорить (свиньи). Все остальные кто присутствует на митинге, должны молчать (цыплята), даже CEO.

Пред игровое планирование

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

Планирование Спринта

Перед началом каждой итерации—или Спринта—проводится два последовательных митинга. На первом, заинтересованные стороны встречаются чтобы детализировать и расставить приоритеты резерву свойств продукта и резерву свойств текушего выпуска, выбрать цели для следующей итерации, обычно руководствуясь важнейшими бизнес задачами и рисками. На втором митинге, Скрум команда и владелец продукта встречаются чтобы обсудить как достичь поставленых целей и создать резерв заданий Спринта (в 4-16 часовом разбиении). Если оцененный усилия превышают ресурсы, происходит другой цикл планирования. Резерв Спринта коректируется, часто ежедневно на ранней стадии итерации, как только обнаруживаются новые задания и когда итерация заканчивается. С ростом истории по многим спринт резервам, команда улучшает качество создания своих новых спринтов.

Команда Семерых

Скрум можно масштабировать до больших проектов, но рекомендуют в одной команде иметь максимум до 7 человек. Большие проекты это несколько команд.

Общая комната

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

Ежедневные билды

Как минимум ежедневная интеграция и регрессионное тестирование всего нового кода для проекта. XP практика непрерывной интеграции (Continuous Integration) еще лучше.

Проверка Спринта (Sprint Review)

В конце каждой итерации, проводится собрание для проверки (максимум 4 часа) проводимое Скрум Мастером. Команда, Владелец Продукта, и другие заинтересованные лица присутсвуют на собрании. Показывается демо продукта. Цели собрания включают информирование о фунциях системы, дизайне, сильных и слабых сторонах, достижений команды и обнаруженных будущих проблемных местах. Собираются отзывы и проводится мозговой штурм будущих направлений, но не дается ни каких обязательств во время митинга. Позже на следующем собрании планировании Спринта, команда и заказчики принимают на себя обязательства. “PowerPoint” презентации запрещены. При подготовке делается акцент на показе продукта.

Продолжение следует: Scrum (часть 2)

One Comment

  1. Коллеги! нужна консультация. С планированием спринта ситуация более менее ясна!
    но как быть, когда проект инвестиционный и долгосрочный? как оценить такой проект? ведь даты конца нет, да и количество итераций не известно…

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *