Scrum (часть 2)

Скрум собрание, практики и ценности, ссылки…

Скрум собрание: Детали

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

  1. Что ты сделал со времени последнего Скрума?
  2. Что ты будешь делать начиная с текущего момента до следующего Скрума?
  3. Что происходит на пути к достижению целей итерации?
  4. Есть ли задания для добавления в спринт резерв? (пропущеные задания, не новые требования)
  5. Изучил или решил что нибудь новое, важное для кого нибудь из команды? (технические детали, требования, …)

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

Другие важные моменты:

  • Собрание идеально проводить стоя в кругу, чтобы показать его краткость.
  • В среднем, 15 или 20 минут для 7-10 человек. Более длинные собрания бывают в начале итерации.
  • Не члены команды (цыплята) стоят за кругом.
  • Он происходит около доски на которой написанны и докладываются все проблемные блоки. Скрум Мастер только стирает блок как только он разрешился.
  • Должен быть спикерфон для участия офсайт людей—это обязательно.
  • Скрум Матстер следит чтобы все шло по правилам, и готовит место для эффективного собрания.
  • Должен начинатся во время. 
  • Применяется правило Цыплят и Свиней: Не члены команды не говорят и не задают вопросов.
  • Не допускается других дисскусий между 3 (или5) вопросом. Скрум Мастер обладает власью сменить фокус дисскусии.
  • Если другие проблемы требуют обсуждения, происходит второе собрание сразу после Скрум собрания, обычно с частью команды. Например во время собрания я могу сказать Джо во время его отчета, “Мы должны поговорить об этом, давай встретимся после Скрума.”

Ценность Скрум собрания

1: Так как мы имеем, на время итерации, самоорганизующуюся команду, без менеджера, направляющего работников или решающего проблемы (пока не попросят), Скрум митинг создает ежедневный механизм, для быстрого информирования команды о состоянии проекта и людей. Затем люди могут действовать. Внешние люди могут присутсвовать на ежедневном Скруме для получения точного, временного и богатого информацией измерения прогресса и проблем. Это поддерживает активность.
2: Когда человек говорит, что он делает на следующий день, он дает в в некотором виде обещание команде. Это увеличивает ответсвенность и доведение дел до конца.
3: Скрум основывается на понимании, что разработка ПО это креативный и непредсказуемый процесс, и необходимы скорее эмпирические чем предопределенные методы. Скрум собрание обеспечивает часто измеримый и адаптивный механизм отклика, что и требуют методики основанные на опыте.
4: Риски проекта включают в себя учет не всех заданий, плохие прогнозы, и медленное разрешение проблем. Скрум митинг обеспечивает ежедневный обсуждение обновлений заданий, определение и удаление помех.
5: Постоянное улучшение и изучение людей и команд очень важно. Скрум митинг помогает в этом, особенное добавление 5-го вопроса. Невысказанная (или подразумеваемая) информация и знания становятся высказанной и общей.
6: Общий язык, ценности и практики помогают команде разработчиков. Это создается и укрепляется ежедневным скрумом.

Скрум также допускает комбинацию с другимим методологиями, например с унифицированными процессами (UP). Он допускает создание видения проетка (vision) или списка рисков.

Другие практики и ценности

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

Общие ошибки и недопонимания или как завалить Скрум проект

Не самонаправляемые команды; менеджер или Скрум Мастер направляет или организовывает команду— У менеджеров часто возникает желание приставать к команде, во время итерации, с советами как работать, как решать проблемы. Многие менеджеры делают упор на задании направления и планировании, чем на их роли в Скрум: быстро решать проблемы, обеспечивать ресурсами, буть фильтром между командой и компанией, но однако не стоять на пути. Это особенно справедливо для Скрум Мастера во время скрум митинга, когда естественная тенденция, чтобы выглядить лидером для команды определяющим направления и решения.
Не ежедневное обновление Спринт резерва разработчиками.
Новая работа добавляется к итерации или индивидуму
—В море постоянных изменений требуется некоторая стабильность. Не изменять требования для однажды начатой итерации, это точка контроля Скрума.
Владелец продукта не вовлечен или не принимает решений—Скрум это мотодология управляемая заказчиком. Владелец продукта должен решить как приотизоровать бэклог продукта, и выбрать требования для следующей итерации.
Нет Спринт оценки (review)—Скрум строится на обратной связи и адаптации; демонстрация и оценка(review) необходима, чтобы проинформировать заказчика, чтобы он мог откоректировать следующую итерацию.
Много хозяев—Скрум требует один голос для требований из резерва свойств продукта, расставление приоритетов и выбор работ для следующей итерации обязанности владелца продукта.
Проектирование и создание диаграмм— Скрум более прогматичный в вопрсое командного подхода к проектированию: Если команда находит полезным некоторое пред-программное проектирование или создание диаграмм, во время итерации, они это делают
Вся команда (включая заказчиков и менеджмент) обрезают Скрум методологию и ее ценноости — что недопустимо.
Скрум собрание слишком длинное или не сфокусированно – Держите его в рамках 20 минут, и в рамках Скрум вопросов.
Каждая итерация заканчивается выпуском продукта в жизнь (production)—Хотя Скрум итерация может заканчиватся выпуском в жизнь (production release), это не требование. Это может потребовать несколько итераций перед выпуском ПО готового для исспользования пользователями.
Будущее планирование; планирование Перт диаграммами—Это неправильное понимание, создавать планы описывающие в точности, как много будет итераций для длинного проекта, и что будет происходить в каждой, или создавать Перт диаграммы показывающими много заданий, их порядок и предпологаемую длительность.

Вы не понимаете Скрум если…

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

“Agile and Iterative Development: A Manager’s Guide” — Craig Larman

Ссылки по теме:
http://en.wikipedia.org/wiki/SCRUM — Скрум в википедия.
http://scrumwiki.org/ — вики для Скрума
http://www.scrumalliance.org/ — Скрум альянс
http://www.controlchaos.com/ — сайт одного из создателей скрума Кена Швабера
http://groups.yahoo.com/group/scrumdevelopment/message/2116 — Tools, Tools, Scrum Tools!

One Comment

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

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