---

Что вызывало хаос и разочарование до Scrum? Ответ может вас удивить!

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

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

За несколько дней до написания этих строк мы обедали с бывшим коллегой, с которым работали почти 20 лет назад.

Маркус получил сертификацию Scrum-мастера и сертификацию Владельца продукта Scrum в International Scrum Institute™. Сейчас он работает Scrum-мастером в одной из ведущих компаний, создающих программное обеспечение для гибкого управления проектами.

Как Scrum-мастер Маркус поддерживает Agile- и Scrum-команду, участники которой расположены в разных местах по всему миру.

За обедом Маркус признал, что у распределённых Agile- и Scrum-команд много типичных трудностей. Среди проблем именно его проекта он назвал:

• Различия стилей работы участников,
• Разницу часовых поясов,
• Культурную несогласованность и
• Языковые ограничения.

Несмотря на это, Маркус добавил: вести программный проект с гибким процессом Scrum интереснее, продуктивнее и содержательнее, чем работать так, как мы работали 20 лет назад. По сравнению с временами без процессов разработки и поставки программного обеспечения Scrum.

Слова Маркуса стали убедительным свидетельством пользы Scrum от очень успешного и опытного руководителя, Scrum-мастера и Владельца продукта.

Спасибо, Маркус!

Затем мы рассказали ему о своём прошлом проекте до внедрения Scrum. Уверен, многие Scrum-мастера узнают похожий опыт до получения своих сертификаций.

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

В то время это был довольно сложный ИТ-проект, требовавший нескольких взаимозависимых аппаратных и программных команд. Нам пришлось выполнить огромный объём исследований и разработок (R&D) для создания полностью работоспособной аппаратно-программной системы.

Помните: в том проекте мы ещё не использовали подход « минимально жизнеспособный продукт (MVP) » для экспериментов, создания, обучения и новых экспериментов.

Без Scrum создать такую сложную инфраструктуру с множеством аппаратных и программных элементов было настоящим испытанием.

Вот три серьёзные трудности с которыми мы сталкивались без Scrum-мастеров и людей с сертификацией Scrum-мастера в командах.