Джей Сазерленд - Scrum на практике. Высокая продуктивность и результаты – прямо сейчас

По данным Standish Group, в любом проекте в процессе разработки меняется 67 % требований. Почему? Потому что люди обучаются по ходу работы. Когда мы создаем что-то, то узнаём, что некоторые вещи, казавшиеся важными, на самом деле не так существенны. Нам становится известно, что покупатели, обозначившие задачи и подписавшие пачку требований, на самом деле не были уверены, что меняется рынок и мир.

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

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

Суть в том, чтобы изменения были быстрыми, дешевыми и веселыми. И если не получается – значит, вы что-то делаете не так.

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

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

Scrum 3-5-3.В Scrum всего три роли: владелец продукта, scrum-мастер и член команды. Пять мероприятий: планирование спринта, спринт, ежедневный Scrum, обзор спринта и ретроспектива спринта. И три артефакта: бэклог продукта, бэклог спринта и инкремент продукта, который команда создает за каждый спринт. Это не сложно, но требует дисциплины.

1. Начните внедрять Scrum 3-5-3 на своем рабочем месте.

2. Кто будет заниматься приоритизацией?

3. Кто будет коучем?

4. Кто будет выполнять работу?

5. Составьте бэклог продукта.

6. Составьте план вашего первого спринта.

7. Вперед!

8. Ежедневно встречайтесь, чтобы координировать усилия и вносить изменения в планы.

9. Сделайте что-то полностью готовое к концу спринта.

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

11. Повторите снова.

У вас есть проблема – вы только что о ней узнали.

Это может быть что угодно. Вы создаете что-то и понимаете, что дизайн нужно изменить. Вы наткнулись на то, чего не ожидали, когда планировали работу, и вам нужно решить, что делать. «Мне сейчас решить этот срочный вопрос или подождать и работать над чем-то невероятно важным, что потом станет очень ценным?»

Это совпадает с матрицей Дуайта Эйзенхауэра – известной матрицей принятия решений, позволяющей ранжировать вопросы по степени важности и срочности.

Допустим, вы в замешательстве и вам нужно решить, в какой из этих квадрантов попадает ваша новая, свежая, запутанная проблема.

С кем ее обсудить? Нужно ли ждать, пока соберется комитет для решения проблемы? Есть ли возможность разобраться с ней сегодня или все очень заняты и вам придется отложить вопрос на завтра-послезавтра? Какова будет цена задержки?

Джим Джонсон, основатель и председатель Standish Group, начал интересоваться этим вопросом несколько лет назад. С 1985 года компания в основном занимается исследованиями работы проектов по всему миру с помощью интервью, фокус-групп и опросов. Мы говорим о десятках тысяч проектов. Она регулярно публикует CHAOS Report, содержащий разного рода данные о том, почему проекты преуспевают или терпят неудачу. График, объясняющий всемирное распространение Agile, выглядит так.