Софт за 30 дней. Как Scrum делает невозможное возможным

А. Размер команды разработки. Оптимальная по численности команда разработки достаточно мала, чтобы оставаться простой в управлении, и в то же время достаточно велика, чтобы выполнять значительный объем работы в течение спринта. Если в команде разработки менее трех человек, взаимодействие уменьшается, что приводит к снижению продуктивности. Небольшой команде может не хватить навыков в течение спринта, что помешает завершить работу над потенциально готовым к выпуску инкрементом продукта. Если же в команде более девяти человек, потребуется больше усилий для координации их работы. Большие команды разработки создают слишком много сложностей для управления эмпирическим процессом. Роли владельца продукта и Scrum-мастера не учитываются при подсчете размера команды разработки, за исключением случаев, когда они также выполняют работу из бэклога спринта.

Раздел 5.03. Scrum-мастер

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

Scrum-мастер – методический лидер для Scrum-команды.

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

А. Scrum-мастер на службе владельца продукта. Помощь Scrum-мастера владельцу продукта заключается в следующем:

• находит практические методы эффективного управления бэклогом продукта;

• проясняет путем общения видение, цели и пункты бэклога продукта для команды разработки;

• учит Scrum-команду создавать лаконичные и понятные элементы бэклога продукта;

• помогает достичь понимания долгосрочного планирования в эмпирической среде;

• помогает понять гибкие методы разработки и управления;

• содействует проведению событий Scrum по просьбе владельца продукта или по необходимости.

Б. Scrum-мастер на службе команды разработки. Обязанности Scrum-мастера на службе команде разработки:

• проводит тренировки команды разработки по самоорганизации и кросс-функционалу;

• обучает команду разработки создавать продукты высокой ценности;

• устраняет помехи, мешающие прогрессу команды разработки;

• содействует проведению событий Scrum по просьбе команды или по необходимости;

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

В. Scrum-мастер на службе организации. Обязанности Scrum-мастера на службе организации:

• направляет и тренирует организацию на ее пути адаптации к Scrum;

• планирует этапы внедрения Scrum в организации;

• помогает сотрудникам компании и заинтересованным лицам понять и принять Scrum и принципы эмпирической разработки продуктов;

• выступает инициатором изменений, которые повышают продуктивность Scrum-команды;

• работает совместно с другими Scrum-мастерами для повышения эффективности использования Scrum в организации.

Статья VI. События Scrum

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

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

Раздел 6.01. Спринт

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

Спринты состоят из планирования, Scrum-митингов, разработки, обзора спринта, а также ретроспективы спринта.

Во время спринта:

• не допускается внесение никаких изменений, которые могли бы поставить под угрозу цель спринта;

• состав команды разработки остается неизменным;

• цели относительно качества не должны сокращаться;

• объем работ может быть уточнен и повторно обговорен между владельцем продукта и командой разработки по мере накопления знаний.

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