<?xml version="1.0"?>
<api>
  <query-continue>
    <allpages gapcontinue="Scrum_Master_(курс)_:_Лекция_11" />
  </query-continue>
  <query>
    <pages>
      <page pageid="51" ns="0" title="Scrum Master (курс) : Лекция 1">
        <revisions>
          <rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">= Цели лекции =

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

= Тезисы = 

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

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

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

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

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

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

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

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

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

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

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

== Inspection ==

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

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

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

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

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

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

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

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

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

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

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

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

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

Inspection!

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

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

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

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

== Transparency ==

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

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

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

Вопросы

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

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

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

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

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

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

== Adaptation ==

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

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

Adaptation!

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

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

== Проверка == 

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

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

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

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

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

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

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

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

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

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

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

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

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

== Summary == 

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

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

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

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

= Задание = 

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

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

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

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

[[Category:Scrum Master (курс)]]</rev>
        </revisions>
      </page>
      <page pageid="70" ns="0" title="Scrum Master (курс) : Лекция 10">
        <revisions>
          <rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">= Цели = 

Понять цели, ограничения и способ проведения daily scrum

= Тезисы = 

Из всех возможных &quot;фитбэков&quot; в скраме, именно daily scrum является самым коротким.

На него отводится 15 минут, не больше (жесткий timebox). Это сделано намеренно, чтобы не терять фокус митинга.

Присутствует только dev team. PO и скрам-мастера могут пригласить.

Обсуждается ровно 3 вопроса:

1) что мы сделали за сегодня, чтобы достичь цели спринта (например, &quot;теперь наш продукт может ... и это приблизило нас к цели спринта&quot;)

2) что в нашем продукте появится завтра, чтобы приблизить нас к цели спринта

3) что нам препятствует достижению цели

Daily Scrum НЕ ДЛЯ ТОГО, чтобы:

1) сформировать и предоставить отчетность (узнать, что люди работают)

2) обсудить иное, чем 3 вопроса, преведенные выше (причины: участники слушают информацию, которая им может быть не нужна; отвлекает от фитбэка в скраме)

Daily Scrum ИСКЛЮЧИТЕЛЬНО ДЛЯ ТОГО, чтобы проверить, насколько команда за сегодня приблизилась к цели спринта. 

Для скрам-мастера этот митинг хорошее место сделать 2 вещи:
* отследить, как проходит обсуждение (команда сфокусирована на целях или отвлекается);
* визуализировать текущий прогресс, что является стимулом для участников завершать свою часть работы до начала daily scrum таким образом, чтобы они могли показывать реально работающий продукт ежедневно, приближаясь каждый день к целям спринта.

Типичные ошибки:

* На dailyscrum должна присутсвовать только devteam, это митинг для них и о них. Если так окажется руководство или заказчик - то митинг превратится в доклад и людям будет сложнее обсуждать реальное положение дел. 

* На dailyscrum не должны обсуждаться никакие вопросы кроме приведенных выше. Все технические и возникшие проблемы если не могут быть кратко обсуждены в рамках timebox - должны выноситься в отдельные митинги. И чаще всего часть команды, особенно если команда большая - на этих митингах просто не нужна.  

[[Category:Scrum Master (курс)]]</rev>
        </revisions>
      </page>
    </pages>
  </query>
</api>