Scrum Master (курс) : Лекция 1

Цели лекции

• Понять откуда появились Agile методы
• Выявить и понять предназначение каждой из основ (pillars) Scrum

Тезисы

Преодоление сложности

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

Вопрос. Почему именно в 90-е годы стали возникать итеративные и далее agile методы разработки?

• Доступность техники - более многообразные задачи
• Появилась возможность решать задачи с часто изменяющимися условиями
• Возросли возможности техники - а значит возросла сложность решаемых проектов

Вопрос. А какой прием мы используем для уменьшения сложности? Декомпозиция!

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

Все началось с Rational Unitifed Process и уже он имел многие свойства которые мы определяем как agile.

Сложность требований

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

RUP выделил 4 источника требований

• Опрос заказчиков, пользователей и экспертов (старый метод);
• Личное наблюдение и участие в автоматизируемом процессе;
• Анализ решений конкурентов;
• Прототипирование.

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

Inspection

Scrum guide называет каждый sprint экспериментом "проверкой гипотезы".

Вопрос. Что такое гипотеза?

Утвреждение требующее доказательства.

Вопрос. Что является гипотезой в нашем случае?

Наше предположение что именно устроит заказчика.

Вопрос. Что является проверкой гипотезы в нашем случае?

Реакция заказчика что устраивает (подтверждение) и что не устраивает (опровержение).

Вопрос. Что нужно чтобы заказчик дал опровержение?

Он должен практически воспользоваться хотя бы частью функций в реальных условиях!

Это дает нам одно из важнейших понятий в SCRUM - releasable increment

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

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

Вопрос: Какой из scrum pillar поддерживается созданием releasable increment?

Inspection!

Еше важно: помимо возможности проверсти проверку - важна еще и мотивация. Все я думаю многократно сталкивались с тем, что заказчик не хочет смотреть прототип.

Вопрос. Как вы считаете - о чем это может говорить?

Заказчику неинтересен прототип поскольку его он не касается, никакого облегчения ему не приносит и не обещает принести!

Нет мотивации, а это тоже признак того, что с releasable проблемы - зачем релизить то, что никому не нужно и не интересно?

Transparency

В первую очередь из андрагогики (наука об обучении взрослых) нам известно что люди делают что-от наилучшим образом если знают зачем они это делают.

Проведем эксперимент. Возьмем лист бумаги, разделим на две части - в одной нарисуем круг, в верхней трети круга два круга поменьше, симметрично относительно центральной линии, из нижней трети круга нарисуем прямоугольник вниз примерно высотой как круг и шириной как 1/4 круга, а справа и слева нарисуем примыкающие к большому кругу полукруги.

А справа нарисуем морду слоника вид спереди.

Вопросы

1) где получилось лучше

2) где я потратил больше усилий чтобы "объяснить задачу"

3) в случае если человек минимально умеет рисовать - где он сможет нарисовать лучше чем мой "алгоритм".

А во втором случае я всего лишь объяснил чего я хочу получить в итоге (ответил на вопрос "зачем"!)

В этом ничего нового - см. "цели и задачи" которые используются во всем и везде.

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

Adaptation

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

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

Adaptation!

Не задача и команда для процесса, но процесс для решения задачи и облегчения работы команды!

Важно - adaptation НЕ изменяет сам Scrum - в нем ничего лишнего. Поэтому мы не можем взять и выкинуть скажем adaptation pillar решив что он нам не нужен :-). Но инструменты, методы и способы - все это должно адаптироваться чтобы в рамках Scrum обеспечить наилучшее решение задачи.

Проверка

Вопрос. Вы как scrum master пришли в новый проект и хотите узнать поддерживается ли в проекте inspection pillar. Что следует выяснить в первую очередь?

Мой ответ: Посмотреть sprint backlog и выяснить есть ли там sprint goals и определены ли они как "в результате sprint наш заказчик сможет... и далее конкретные бизнес действия имеющие ценность".

Вопрос. Вы как scrum master пришли в новый проект и хотите узнать поддерживается ли в проекте transparency pillar. Что следует выяснить в первую очередь?

Мой ответ: Надо спросить зачем выполняется каждая конкретная задача?

Почему? Потому что если есть понимание зачем - то человек понимает как решение задачи привязано к успеху проекта!

Важно: Ответ "потому что так решили", "потому что так сказал начальник", "потому что так сказал заказчик" не является знанием "зачем".

Вопрос. Вы как scrum master пришли в новый проект и хотите узнать поддерживается ли в проекте adaptation pillar. Что следует выяснить в первую очередь?

Мой ответ: Надо спросить зачем вы используете каждый конкретный инструмент?

Почему? Ответ на этот вопрос позволяет понять ведется ли вообще учет того как инструмент способтвует достижению целей проекта и есть ли критерии по которым такой учет можно произвести. Если этого нет - то условий для адаптации тоже нету.

Важность основ

Основы не зря названы основами. Именно относительно основ проверяется любое действие, любой артефакт, любое утверждение.

• Все что обеспечивает основы - хорошо для Scrum
• Все что препяствует реализации основ - плохо для Scrum
• Все что не имеет отношения к основам - не имеет отношения к Scrum.

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

Summary

• Agile - ответ на очень сложные (за пределами способности человека изначально дать внятные требования) и динамично изменяющиеся проекты

• Inspection нужна для того, чтобы мы могли проверять наши предположения о том, что нужно заказчику. Для этого мы делаем releasable (реально применимое в жизни) incremenet (улучшение по сравнению с предыдущим состоянием) и только на основе наблюдений за этим инкрементом принимаем решения касающиеся проекта.

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

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

Задание

Цель: проверить понимание зачем в Scrum есть 3 pillar и в чем они выражаются.

Написать эссе в котором на основе своего собственного проекта по каждой из pillars выделить одно что максимально поддерживает этот pillar и что максимально препяствует.

Примечание: так как задание касается команды - это может вызвать внутреннее сопротивление, как это писать про команду плохое. Дать позитивный шаблон "моя замечательная команда замечательная потому что делает ____ и _____ поддерживая ________. Моя замечательная команда станет еще лучше если мы поможей перестать делать (начать делать) _____ для поддержки _______".

Примечание: "предложенный (мой) ответ" не является единственным правильным ответом. Дискуссия может выявить и выявит всё многообразие возможных ответов, многие из которых являются правильными. Предложенный вариант относится исключительно к поддержке дискуссией целей данной лекции.