Professional Scrum Master (PSM)

Professional Scrum Master (PSM)
Professional Scrum Master (PSM)

понедельник, 17 августа 2015 г.

У вашей собаки нет будущего

 3027516083_a070ba35ef_z 
В предыдущем блог-посте я писал о том, как можно провести необычную Ретроспективу в формате Futurespective, отправив команду на машине времени в будущее. Теперь мне хочется рассказать о том, почему же такой подход работает.

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

65847_original (1)

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

Мышление, ориентированное на результат. Нас научили аналитически мыслить в школе и ВУЗе. Мы привыкли решать задачи, параллельно оценивая, что происходит не так в той или иной ситуации. Но это не лучший подход.
Пока фокусируешься на проблеме, сама проблема визуализируется (работает наш “визуальный мозг”). Такой “хронический” взгляд на жизнь рождает негативные чувства. Притягивается новый негатив, а в жизни возникает все больше неприятных ситуаций и переживаний.

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


Поэтому коучинг предлагает фокусироваться на привлекательной картинке будущего. И делает это с помощью “волшебных” вопросов, перенесения в будущее, ассоциативного видения и прочих инструментов.

Мозг не понимает отрицательных формулировок.
Несмотря на всю сложность мозга, он понимает лишь позитивные формулировки. Тяжело представить то, чего нет. Поэтому такие фразы, как “не делать”, “не прыгать”, “не бегать” представляются ему как “делать”, “прыгать” и “бегать”.

Подумайте об этом в следующий раз, когда будете давать наставление ребенку о том, чтобы он “не ел мороженое”. Может произойти обратное.


10621683376_0ec741413c_z

Хотите попробовать силу коучинга на себе? До 24 сентября 2015 года вы можете записаться на 5 бесплатных коуч-сессий со мной. Это очень просто.

Чтобы договориться о коуч-сессии:
11248035_823782774324873_1958747892_o
Свяжитесь по скайпу: pavlichenko.ilya
Либо пишите: ilya@unusual-concepts.ru

понедельник, 13 июля 2015 г.

Коуч сессии для Вас

Дорогие друзья!
У меня неожиданные новости для вас. Совсем недавно я пошел учиться на программу “Наука и искусство трансформационного коучинга” в Эриксоновском Международном Университете Коучинга. “Ага, молодец, а мне что с этого?” - спросите вы.
Все дело в том, что я очень серьезно отношусь к учебе, поэтому решительно настроен получить “золотой” сертификат по завершению курса.
9348a974c6637f46b0bc1b4bf8815a42
Одно из обязательных условий - 25 часов коучинга с клиентами.
У Вас есть отличная возможность поработать со мной и найти решения на вопросы, на которые вы сами пока не находите эффективного ответа. Для этого вам нужно стать моим клиентом или Чемпионом.

Что вы получите?

Большое количество сильных “открытых” вопросов, с помощью которых вы сможете найти решение к своему запросу и продвинуться к своей цели.

Что вы НЕ получите?

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

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

В двух словах: Кто такой Коуч?
  • Коуч и Коучинг – не даёт советов и рекомендаций, а ищет решения совместно с Вами.
  • Коуч работает с Вами над определением ваших задач и конкретных результатов, которые связаны с вашими целями, созданием эффективного плана действий. Он помогает вам нести ответственность за те обязательства, которые Вы сами на себя берете.
  • Коуч мотивирует, вдохновляет и верит в Ваши возможности.
  • Коуч – это ваш проводник к вашим новым вершинам.
В двух словах: Кем Коуч не является?
  • Коуч – это не понимающий ваши проблемы и сочувствующий вам психолог.
  • Коуч - не психотерапевт, он не копается в вашем прошлом и не исследует детские травмы. Коуч работает только с будущим и фокусируется на результате. Он может вернуться с Вами в прошлое только за позитивным ресурсом.
Сколько это будет стоить для Вас?
  • Абсолютно бесплатно. Вы получаете результаты, я - часы, так необходимые мне для сертификата.
Чтобы договориться о коуч-сессии:

11248035_823782774324873_1958747892_o
Свяжитесь по скайпу: pavlichenko.ilya
Либо пишите: ilya@unusual-concepts.ru

понедельник, 6 июля 2015 г.

"Коуч или не коуч" - вот в чем вопрос

6355384323_c72345f677_b

Скрам Мастер удивительная и одновременно очень сложная роль. В зависимости от ситуации, он одевает разные шапки – учительскую, тренерскую, фасилитаторскую или коучерскую. При этом каждое из направлений настолько широко, что можно потратить всю свою профессиональную жизнь, занимаясь лишь одним из них.

Cкрам Мастер - коуч?

Коучинг является необходимым и уже “встроенным” навыком для Скрам Мастера. Поэтому нет необходимости наделять Скрам Мастера дополнительными полномочиями или давать ему новые названия (например, “Аджайл Коуч”).Скрам Мастер:
Коучит Команду Разработки в самоорганизации и кросс-функциональности.
Коучит Команду Разработки в организационных окружениях, где Скрам еще не до конца адаптирован и понят.
Ведет и коучит организацию на ее пути адаптации к Скраму. 
(Скрам Гайд, июль 2013)

 Скрам Мастер уже коуч по определению.


Что такое коучинг?
Давайте посмотрим на два определения. Первое из них общее Международной Федерации Коучинга:
Коучинг - это партнерство с клиентом в креативном и стимулирующем мысли процессе, который воодушевляет клиента и помогает ему максимально раскрыть свой личностный и профессиональный потенциал.
Коучинг - это конфиденциальный, на сто процентов сфокусированный на клиенте разговор, эффект которого длится, так как клиент понимает и осознает свою цель и шаги для ее достижения.
Во время коучинговой сессии коуч задает клиенту вопросы и помогает ему создавать ясность собственных целей. Каждый разговор, независимо от длины, завершается определением конкретных действий, которые клиент (он же “чемпион” или “коучируемый”) намерен предпринять в ближайшее время, чтобы приблизиться к поставленной цели.
Интересно, что эффект после коучинговой сессии продолжается и после ее завершения. В этом и заключается волшебство коучинга.

Зачем командам и организациям коучи?

Ни один серьезный исполнитесь в конкурентном мире, ни один спортсмен высокого уровня не ожидает достижения быстрых результатов без учителя или тренера. Спортсмены, музыканты, писатели, талантливые актеры и успешные менеджеры знают, что им нужен кто-то еще, человек, который профессионально поможет просмотреть свои цели, выбрать направление работы и определить конкретные шаги.
Скрам Мастер, используя навыки коуча, помогает Скрам Команде, а также всей организации, спокойно концентрироваться на главном направлении - движении к совершенству. Коучинг фокусируется на будущем и поиске решения проблем, а не на их обозначении. Скрам Мастер достигает необходимых результатов с помощью особых подходов к формулированию вопросов (так называемых “открытых вопросов”), визуализации будущего, различных техник НЛП и других инструментов.

teamcoaching2
Коуч - это тот, кто помогает вам поддерживать ответственность за свою жинь; помогает убедиться, что вы действительно реализовываете свой жизненный потенциал (Томас Леонард).
Scrum ON!

четверг, 8 января 2015 г.

Video Scrum


Видео Скрам – уникальная в своем роде и необычайно захватывающая симуляция Скрама. Команды в течение нескольких Спринтов создают и демонстрируют видео фильмы на свободную или заданную фасилитатором тему.
Мы (компания Unusual Concepts) откатали Видео Скрам множество раз в течение последних двух лет на наших сертификационных тренингах Certified Scrum Master (CSM) и Professional Scrum Master (PSM) (дополнительный 3-й день). Мы считаем игру настолько успешной и эффективной для обучения и демонстрации Скрама, что приняли решение подробно описать этот инструмент для Аджайл Сообщества.
Авторство.
Оригинальная идея принадлежит Stacia Viscardi, которая затем была значительно развита и дополнена нами. Описание Видео Скрама в настоящем виде создано под брендом Unusual Concepts и защищено лицензией Attribution-ShareAlike 4.0 International. Вы можете свободно использовать Видео Скрам и даже изменять его, но мы просим вас ссылаться на нас, как компанию, которой принадлежит авторство игры :).
Почему Видео Скрам.
Действительно, сейчас существует множество симуляций Скрама. В первую очередь, приходит на ум популярная Scrum Lego City симуляция, созданная компанией Agile42. Не смотря на это, мы считаем, что Видео Скрам обладает рядом преимуществ перед другими симуляциями:
  • Команды создают реальный, а не «игрушечный» продукт – Видео Клип. Мы знаем о том, что некоторые люди (сразу говорим, что это не мы :)) относятся скептически к симуляции с помощью Лего, считая ее «детской» (мы так не считаем :)).
  • Видео Скрам подходит представителям профессий вне IT (marketing, sales), для которых не подойдут симуляции, предполагающие создание программного продукта (например, сайта).
  • Сложность игры абсолютно отвечает вызовам, которые встречают Скрам Команды в повседневной работе. Например, отсутствие компетенций («мы не умеем пользоваться программой для монтажа») и необходимость их выработки командой «на лету», неумение создания потенциально готового к релизу инкремента продукта («мы отсняли материал, но не успели смонтировать фильм»), коллективная ответственность и командная работа («что мне делать, ведь у нас только одна камера, мне нечем заняться»).
  • Игра очень наглядно демонстрирует философию итеративно-инкрементной разработки, используя в качестве продукта видео фильм. Для команд не интуитивен тот факт, что на выходе каждого Спринта необходимо демонстрировать готовый продукт, а не скатываться в Водопадное мышление (сценарий, затем съемка, а потом монтаж).
  • Видео Скрам отлично показывает важность и критичность обратной связи и присутствия конечных пользователей на Обзоре Спринта («другие команды смотрят фильм и дают нам обратную связь»).
  • Видео Скрам очень наглядно показывает важность создания «Готового» продукта («мы забыли проверить наличие кодеков на демонстрационной машине и теперь нам нечего показать»).
Количество участников
Мы заметили, что игра с несколькими командами - не менее двух (2), но не более четырех (4)  по 4-6 человек в каждой, является наиболее эффективной, потому что:
  • Создает бОльший фан.
  • Дает возможность для более полной обратной связи во время Обзора Спринта, когда команды по очереди друг за другом демонстрируют видео ролики и дают друг другу обратную связь.
  • Дает возможность представления в последнем Спринте командам задачи по интеграции инкрементов (фильмов).
  • Создает соревновательный момент.
Базовая игра (руководство для фасилитатора)
Участники игры должны иметь общее представление о концепциях Скрама (роли и их ответственности, мероприятия, артефакты, прозрачность артефактов). Мы используем для этого заранее нарисованные флип-чарты.
scrum
1.1 Фасилитатор представляет командам легенду ( 5 мин):
 «Я - представитель инвестора, который является заядлым поклонником Аджайла и, особенно, Скрама. В скором времени состоится кинофестиваль в Торонто, где в конкурсной программе будут представлены фильмы на Аджайл (или указываете другую) тематику. Мой клиент готов инвестировать средства в съемку нескольких фильмов Скрам командами. Инвестор нанял меня как специалиста по Скраму. Я буду консультировать вас по теоретическим вопросам, а также помогать фасилитировать сам процесс создания фильмов».
 Иногда мы предпочитаем заказывать командам “сериал”, что означает - все фильмы должна объединять какая-то общая линия, например, одни персонажи и так далее. Мы это делаем в том случае, если хотим симуляцию совместной работы нескольких команд над одним продуктом.
Фасилитатор на свой выбор может дать НЕСКОЛЬКО или ВСЕ ограничения из списка, указанного ниже:
  1. Тема фильма должна быть связана с Аджайл или Скрам тематикой (или же указываете свою тему для кино).
  2. Фильм должен описывать один из 11 официальных элементов Скрама (Владелец Продукта, Скрам Мастер, Команда Разработки, Планирование Спринта, Ежедневный Скрам, Обзор Спринта, Ретроспектива Спринта, Беклог Спринта, Беклог Продукта, Инкремент).
  3. У каждой команды есть 3-4 Спринта (в зависимости от времени, которым вы располагаете) для разработки фильма. Каждый Спринт команды демонстрируют новую версию на Обзоре Спринта.
  4. Фильм может быть на любом языке - русском, английском, немецком и т.д.
  5. На Обзоре Спринта фильмы демонстрируются на машине фасилитатора, подключенной к экрану проектора или же рабочей машине команды (выбирает фасилитатор).
  6. В фильме могут присутствовать звуковые эффекты.
  7. Фильм может иметь титры.
  8. Фильм может иметь вступление, среднюю часть и завершение.
1.2 Команды выбирают Владельца Продукта и Скрам Мастера, а также тему для своего фильма (5 мин). Фасилитатор сам может играть роль Скам Мастера для одной или нескольких команд.
1.3 Команды формируют Критерии Готовности продукта (DoD), учитывая ограничения, поставленные фасилитатором игры (5-7 мин).
1.3 Команды совместно с Владельцем Продукта создают первоначальный Беклог Продукта (10 мин), который затем используется на первом Планировании Спринта. Допольнительно команды могут провести релизное планирование (еще 10 мин), пытаясь “раскидать” работу по Спинтам. На этом шаге выявляются Водопадные команды, которые в первом Спринте планируют делать сценарий, в следующем монтаж и т.д. Если таких команд много, то имеет смысл намекнуть, что в Скраме работают по другому. Но фасилитатору всегда стоит оставить 1-2 Водопадных команды, чтобы поднять вопрос на Ретроспективе.
1.4 Начинаем первый Спринт:
  • Планирование Спринта (5 - 10 мин).
sprint_planning
  • Работа внутри Спринта, непосредственная съемка фильма (20 - 30 мин)
sprint_executing
  • Обзор Спринта (10 – 20 мин) в зависимости от количества команд. Фасилитатор должен следить за тем, чтобы вся работа по съемке фильма была строго прекращена всеми. Команды по очереди выходят и демонстрируют «Готовый» ролик на рабочей станции фасилитатора, подключенной к экрану проектора или на своей рабочей машине в зависимости от Критериев Готовности (DoD). После презентации очередного ролика у каждой команды есть 3 минуты на то, чтобы собрать обратную связь у своих коллег, записать все замечания, рекомендации и советы по улучшению фильма. Обычно на 3-4 команды приходится одна, которая не способна продемонстрировать готовый инкремент продукта. Обязательно вернитесь к этому моменту на общей Ретроспективе.
15837008552_1f6312c9cb_z
  • Ретроспектива Спринта в командах (5 мин).
sprint_retrospective
  • Общая Ретроспектива (5 - 20 мин). Поделитесь с командами своими нейтральными наблюдениями и обязательно обратите внимание на факты несоблюдения правил Скрама и к чему они привели. Обратите внимание на Водопадные команды, если такие у вас имются. Здесь происходит разбор полетов, иногда необходим возврат в теорию, если команды чего то не понимают. Это самая важная часть игры.
 1.5 Спринты 2, 3 4 проводим аналогично Спринту №1, следуя шагам, описанным в пункте 1.4
Вот примеры нескольких видео роликов, которые были созданы в результате игры “Видео Скрам”:







На видео ниже вы можете посмотреть на сам процесс игры, то, как создавались ролики.

1.6 Интересные моменты. Вы можете разнообразить игру, вводя небольшие изменения в игру:
  • Можно объявить о том, что команды будут работать 4 Спринта, но неожиданно прервать из после третьего (3), заявив, что источники финансирования иссякли. Это так похоже на реальную жизнь, не так ли?
  • Фасилитатор может брать на себя роль Скрам Мастера для нескольких или всех команд.
  • Возможно проведение в конце игры финальной Ретроспективы для получения обратной связи от участников.
1.7 А каким образом можно улучшить симуляцию Видео Скрам? Есть ли у вас какие-либо идеи, которыми вы готовы поделиться с нами? Мы будем рады получить от вас обратную связь.

среда, 15 октября 2014 г.

Рассказываем истории с Кубиками Рори


Люди любят истории.  Мы любим рассказывать и слушать интересные истории. Потребность в этом заложила в нас природа. Первые истории, рассказанные нашими предками, можно увидеть в сохранившихся наскальных рисунках, которые находят палеонтологи в пещерах по всему миру. На них изображены животные, сцены охоты и быт наших далеких предков из каменного века.

Fotor0101515554

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

воскресенье, 28 сентября 2014 г.

Что такое неудачный Спринт?


qnnxflfarfhyhpeaqwyz

Недавно между тренерами Scrum.org разгорелась дискуссия относительно вопроса, какой Спринт можно считать неудачным. Мы почти сразу пришли к одному мнению.
А, по вашему мнению, что такое неудачный Спринт:
  • Если команда не выполняет свой прогноз на Спринт?
  • Если команда не достигает Цели Спринта?
  • Что-то другое?
Вопрос действительно очень интересный и я предлагаю разобраться в нем.

Скрам для продукта, а не проекта. Итак, начну с самого банального вопроса – что же такое Скрам и какая его цель?
Скрам – это фреймворк для разработки и поддержки функционально сложных ПРОДУКТОВ. Скрам – это фреймворк, в рамках которого возможно решать сложные адаптивные проблемы и в то же время продуктивно и креативно разрабатывать ПРОДУКТЫ наивысшего качества (Скрам Гайд, 2013).
Я привел цитату из Скрам Гайда для того, чтобы напомнить нам о том, что Скрам фокусируется на разработке креативных ПРОДУКТОВ, а не ПРОЕКТОВ.

понедельник, 22 сентября 2014 г.

Ищем гребешок для причесывания Беклога


Скрам Гайде версии 2011 года присутствовал термин Grooming. Это неофициальная встреча Скрама, во время которой Команда Разработки вместе Владельцем Продукта старательно «причесывают» Беклог, готовя его к следующим Спринтам. В последней версии встреча не изменила своего назначения, просто сменила вывеску и теперь называется Product Backlog Refinement (PBR).
Зачем? Откройте английский жаргонный словарь, и вы сразу поймете, почему многие англичане раньше смущенно качали головой.
Тем не менее, давайте считать, что во время Product Backlog Refinement (PBR) Беклог, как и прежде, отправляется в парикмахерскую для того, чтобы команда и Владелец Продукта могли:
  • Добавить, убрать или разбить Элементы Беклога Продукта (PBI).
  • Уточнить или дать новые оценки.
  • Изменить порядок следования элементов Беклога Продукта.
  • Обсудить и прояснить требования.
Поддержка Беклога Продукта – это активность по добавлению деталей, оценок и упорядочивания элементов в Беклоге Продукта. Это непрерывный процесс, во время которого Владелец Продукта и Команда Разработки работают над требованиями Беклога Продукта. Во время обработки требования проверяются и пересматриваются. Скрам Команда решает, как и когда должна производиться Поддержка Беклога Продукта. Обычно это занимает не более 10% времени Скрам Команды. Однако Владелец Продукта в любое время может изменить требования на свое усмотрение (Scrum Guide, july 2013).
PBR одна из самых загадочных встреч, и у команд возникает много вопросов. Мы постараемся разобраться в этом, но для этого сначала давайте пробежимся по определению Беклога Продукта.
Беклог Продукта. Последняя версия Скрам Гайда дает нам определение:
Беклог Продукта – это УПОРЯДОЧЕННЫЙ список всего, что может быть нужным в продукте, он является ЕДИНСТВЕННЫМ источником требований для любых изменений, которые может потребоваться внести в продукт. ОТВЕТСТВЕННОСТЬ за Беклог Продукта несет Владелец Продукта, включая его содержимое, доступность и упорядочение.
Беклог Продукта никогда не является полным. Начальная версия этого документа содержит только первоначально известные и наиболее понятные требования. Беклог Продукта постоянно обновляется по мере обновления самого продукта и среды, в которой он разрабатывается. Беклог Продукта является ДИНАМИЧЕСКИМ, постоянно изменяющимся для соответствия требованиям продукта, его конкурентоспособности и пригодности. Беклог Продукта существует ровно до тех пор, пока существует и сам продукт. Беклог Продукта содержит все ФИЧИ, ФУНКЦИИ, ТРЕБОВАНИЯ, УСОВЕРШЕНСТВОВАНИЯ и ДЕФЕКТЫ, то есть те данные, которые и определяют изменения, необходимые в следующих релизах продукта. Каждому Элементу Беклога Продукта присваиваться ОПИСАНИЕ, ПОРЯДКОВЫЙ НОМЕР, ОЦЕНКА и ЦЕННОСТЬ.
backlog.png
Я выделил некоторые слова большими буквами. Давайте быстро пробежимся по ним:
  • УПОРЯДОЧЕННЫЙ. В течение многих лет Беклог Продукта был приоритезированным списком. Но приоритезация – лишь частный случай упорядоченности. Современная редакция Скрама требует от Владельца Продукта проставлять каждому элементу Беклога (PBI) свой порядковый номер, тем самым избегая синдрома «для нас все фичи важные» и «нам все нужно сделать. Подробнее об этом изменении в Скраме можно почитать в статье «Ordered, not Prioritized».
  • Беклог Продукта является ЕДИНСТВЕННЫМ источником требований для продукта. Что это значит? Не должно быть никаких дублирующих Technical Debt, Defects и других Беклогов, в которых мы храним нечто, к чему хотим вернуться после, но на практике вряд ли это когда-либо произойдет. Логичнее было бы назвать такие артефакты «Never will do Backlog». Во-первых, подобные практики нарушают прозрачность и могут ввести в заблуждение Владельца Продукта, который строит план релиза исходя из Беклога Продукта. Он и не догадывается, что команда задумала грандиозный рефакторинг, план которого хранится в другом документе. Во-вторых, никто, даже CEO вашей компании,  не может заставить Команду Разработки работать над требованиями, которых нет в Беклоге Продукта. Для того, чтобы это случилось, CEO должен убедить в этом сначала Владельца Продукта.
  • ОТВЕТСТВЕННОСТЬ за Беклог Продукта несет один человек - Владелец Продукта. Он может делегировать те или иные активности членам команды. Иногда их называют «группой Владельца Продукта», в которую могут входить тестировщики, бизнес аналитики, разработчики и т.д. Но за все отвечает лишь один человек. Этого правило родилось из жизненной практики, ведь часто необходимо разрубить «гордиев узел» и принять быстрое бизнес решение.
  • ДИНАМИЧНОСТЬ Беклога заключается в том, что он постоянно меняется и эволюционирует. Беклог Продукта – не толстая спека, которую набивают в течение нескольких месяцев бизнес аналитики, а живой артефакт. Владелец Продукта может вносить в него изменения когда угодно. Ключевое мероприятие, после которого мы ожидаем, что Беклог будет обновлен – Обзор Спринта. Мы получаем обратную связь о продукте от конечных пользователей, заказчиков и других заинтересованных лиц, и обновляем Беклог.
  • Так как Беклог Продукта – единственный источник требований, но в нем хранятся элементы различного типа: ФИЧИ (features), ДЕФЕКТЫ (defects), ТРЕБОВАНИЯ (requirements), УСОВЕРШЕНСТВОВАНИЯ (enhancement), ФУНКЦИИ (functions). Беклог может включать как функциональные, так и нефункциональные требования продукта.
  • Каждый элемент Беклога Продукта имеет 4 атрибута: ОПИСАНИЕ, ПОРЯДКОВЫЙ НОМЕР, ОЦЕНКУ и БИЗНЕС ЦЕННОСТЬ. С первыми двумя, вроде бы, все понятно. Что же касается оценок, то они отражают стоимость разработки и часто даются Командой Разработки в относительных величинах или «попугаях». Скрам не требует от нас использования относительных величин, но я видел мало Скрам Команд, которые бы ими не пользовались. Главная причина – люди не умеют оценивать  в абсолютных величинах, поэтому стори-поинты лучше, чем часы. Что касается четвертого атрибута (бизнес ценность), то, к сожалению, лишь некоторые Владельцы Продукта пользуются им. Современный Скрам требует явно проставлять бизнес ценность для каждого Элемента Беклога Продукта (PBI). Можно пользоваться практикой Business Value Point (BVP), о которой пишет Джим Хайсмит в книге Adaptive Leadership или проставлять условные High, Medium, Low оценки для каждого элементов. Важно одно – мы хотим, чтобы между Владельцем Продукта и Командой Разработки состоялся разговор о ценности каждого элемента Беклога.
 Ключ к эффективному планированию. Не все команды, к сожалению, понимают, что ключ к удачному планированию и, соответственно, к самому Спринту, лежит как раз в проведении эффективных Product Backlog Refinement встреч.
Нет ничего более болезненного для команды, чем плохо подготовленные Пользовательские Истории, с которыми она сталкивается на Планировании Спринта. Обсуждение затягивается на часы, команда погружается в бесконечные дискуссии и дебаты. Я видел такие встречи, и это ужасно. Хороший Владелец Продукта должен делать все возможное, чтоб избежать подобного сценария (Galen, Robert, Scrum Product Ownership).
Как часто нам нужно проводить PBR. В отличие от других обязательных мероприятий (Планирование, Ежедневный Скрам, Обзор Спринта, Ретроспектива), Скрам дает вам право самим решать как, когда и сколько раз проводить Product Backlog Refinement.
Готового рецепта нет, вы можете создать свой собственный. Но мы выработали хорошую, на наш взгляд, практику, которая хорошо прижилась во многих командах, с которыми мы работали. Мы рекомендуем командам посвящать 15-20 минут после Ежедневного Скрама подробному обсуждению одной истории. У всех появляется возможность заняться разведкой и до следующей встречи посмотреть на историю, покопаться в ней индивидуально, и, тем самым, подготовиться к планированию, чтобы чувствовать себя более комфортно.
Таким образом, планирование превращается в простой выбор того, что мы будем делать, и может занимать не более 10 минут. Такой подход позволяет сразу перейти к распилу историй на задачи и вовлечь всех в работу незамедлительно. Потом команда инспектирует и подстраивается соответствующим образом каждый день. При двухнедельной продолжительности спринтов у вас получится 2 часа (15 минут * 8 дней), которые вы сэкономили от планирования спринта.
pbr_collage.png
Готовность элементов требований. Мы должны стремиться к тому, чтобы к моменту начала Планирования Спринта все элементы Беклога были «подготовленными» для их взятия в Спринт, чтобы избежать неприятных сюрпризов:
Требования Беклога Продукта, которые можно выполнить в течение одного Спринта считаются “Подготовленными” для следующего Планирования Спринта. Элементы Беклога Продукта обычно приобретают эту степень прозрачности при помощи описанных активностей по детализации (Scrum Guide, 2013).
ОК, это понятно. А теперь вопрос, насколько тщательно следует причесывать требования? Ведь совершенству нет предела. С одной стороны, чем больше мы потратим времени на разбор историй, тем более ясным и точным будет будущий Спринт и тем меньше рисков и неопределенностей нас ждет. С другой стороны, каждый лишний час, на который отвлекается Команда Разработки, можно считать потерей. Бесконечные статус митинги, мультизадачность – разве это не против чего мы боролись? Единственно правильного ответа нет. Мы находимся в запутанной среде. Но мне нравятся несколько моделей, которые могут помочь ответить на этот вопрос.
 Кривая стоимости. Эту модель я обнаружил в книге «Real Life Scrum» (оттуда же украл и картинку).
pbr_curve.png
 Автор книги удачно подметил, что цена, которую мы платим за встречи и анализ требований возрастает примерно пропорционально времени. С другой стороны, цена имплементации требований падает нелинейно. Существует некая точка, в которой есть пересечение и после которой общая цена начинает резко расти. Наша задача как раз и заключается в том, чтобы найти эту пресловутую точку. Как это сделать? В этом может помочь вторая модель.
Правило 70/30. Эта модель предлагает Роберт Гален, и я не раз убеждался в ее правдивости. Представьте, что 100%  - это абсолютно вылизанная и проанализированная история, от которой не стоит ждать каких-либо сюрпризов. Роберт предлагает подготавливать истории примерно на 70%.
Я рекомендую определять историю лишь на 70%. У нас должны оставаться открытые вопросы, сомнения и определенная доля неизвестности. Просто не слишком много, и не в самых критических местах. Когда же заполняются остальные 30%? Во время Спринта. Команды устраняют их, выполняя работу. Это и является одной из главных причин, почему Владелец Продукта должен быть доступен для Команды в течение всего Спринта (Galen, Robert, Scrum Product Ownership).
Примеры определения готовности элемента Беклога Продукта. Скрам - гибкий фреймворк и не отдает предпочтения какому-либо формату для определения элементов Беклога. Но большинство команд используют Пользовательские Истории. Поэтому я приведу пример готовности, используя этот формат:
  1. История ясно написана и имеет ни менее 5 приемочных критериев.
  2. История не превышает 8 Story Points.
  3. Историю обсуждали на нескольких PBR встречах, и она понятна команде.
  4. Команда понимает как функциональные, так и нефункциональные части истории.
  5. Определены все зависимости от других историй и это отражено в Беклоге Продукта.
  6. История имеет определенную бизнес ценность для конечных пользователей и поддерживает Цель Спринта.
 Чем еще Скрам Мастер может помочь Владельцу Продукта и Команде Разработки? Не надо объяснять, как разработчики «любят» лишние встречи. И пусть. Это удел менеджеров. Дайте возможность разработчикам максимально фокусировано проводить встречи и заниматься их любимым делом - разработкой. Заранее распечатайте на бумаге истории, которые вы хотите обсудить и раздайте по экземпляру каждому. Настройте связь, видео, звук, подготовьте помещение, стикеры, маркеры, флип-чарты и остальные необходимые инструменты. Совершенствуйте свои навыки в фасилитации и коучинге. Избавьте свою команду от рутины, и команда ответит вам благодарностью и доверием.
pbr_prep.jpg

вторник, 2 сентября 2014 г.

Много работать вредно


Однажды Резерфорд зашел поздно вечером в свою лабораторию и увидел там, несмотря на неурочный час, одного из своих подававших надежды сотрудников.
«Что вы делаете здесь так поздно?» — удивился ученый.
«Работаю», — ответил тот.
«Что же вы, в таком случае, делали днем?»
«Разумеется, работал».
«А утром? Неужели и утром вы тоже работали?»
«И утром тоже».
«Позвольте, — неподдельно изумился Резерфорд, — а когда же вы думаете?» — и перестал возлагать на этого сотрудника особые надежды.

Давайте посетим темную сторону луны и обсудим то, с чем каждый из нас хоть раз, но сталкивался в своей жизни - овертаймы. Мы выясним:
  • Какое же оптимальное количество часов работы в неделю?
  • Как зависит производительность от времени, проведенного за работой?
  • Как относиться к тем, кто стоически перерабатывает в команде?
  • Что говорит нам об этом Аджайл и Скрам?
Почему Резерфорд перестал возлагать надежды на своего сотрудника?
Приведенная выше история с известным британским физиком Резерфордом не выдумка, это реальный факт из его биографии. Почему же Резерфорд негативно относился к тому, чтобы сотрудники его лаборатории перерабатывали и оставались  там вечером? Для этого предлагаю заглянуть на один из самых интересных курсов на портале Coursera, который называется Learning how to learn. Авторы курса утверждают, что у человека есть два основных режима мышления: фокусированный (Focused) и рассеянный (Diffuse).
focused_diffuse.png
Авторы курса приводят аналогию с машиной для пинбола. Фокусированный режим нужен нам для того, чтобы проводить анализы, высчитывать формулы и решать сложные задачки во время экзаменов. Сдвинутые брови и сморщенный лоб – явные признаки того, что наш мозг перешел в фокусированный режим. Рассеянный же режим может застать нас совсем в неожиданных местах: как за рулем машины, так и в душе. Это может случиться даже во сне в кровати. Вспомните про знаменитую таблицу Менделеева, которая явилась ученому именно ночью. Рассеянное мышление позволяет посмотреть на вещи с новой стороны. Как это относится к случаю с Резерфордом? В ряде профессий, а исследовательская работа относится именно к этому типу, человеческому мозгу необходимо определенное время для того, чтобы отстраниться и увидеть большую картину происходящего. За деревьями можно не увидеть леса, как говорится в известной пословице. Инновационные идеи и научные прорывы как раз случаются чаще всего в режиме рассеянного мышления. Если же работать с утра до вечера, то этого может просто никогда не произойти. Мне кажется, Резерфорд имел в виду именно это.
Итак, принцип первый:

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

220px-Il_pomodoro.jpg
Связь между продуктивностью и временем. Давайте посмотрим, как количество рабочих часов в неделю отражается на продуктивности человека. В книге “Scrum: A revolutionary approach to building teams” Джефф Сазерленд приводит слова Джона Казенбаха, который в 90-х годах работал в известной консалтинговой компании McKinsey, где в то время закрепилась практика 7-дневной недели. Работники компании соревновались между собой по количеству переработанных часов. Лояльность сотрудников к компании определялась именно количеством сверхурочного времени, которое они проводили в стенах офиса. Вот что говорит по этому поводу Джон:
По религиозным причинам я мог работать только 6 дней в неделю. И затем я кое-что заметил. Хотя я работал меньше, я успевал делать больше, чем мои коллеги. А ведь это были ребята, которые работали практически каждый день. Затем я попробовал перейти на пятидневку и обнаружил, что мои результаты еще улучшились.
Слова Джона прекрасно иллюстрирует кривая Максвелла, которая показывает зависимость между количеством проработанных за неделю часов и продуктивностью человека (см. фото ниже).
hours.png
Как мы видим, максимальная продуктивность соответствует количеству часов немного меньшему, чем 40. Далее идет быстрый спад продуктивности, который стремится к нулю в точке 60 часов. Очень важно понимать, что эти цифры лишь примерные. Все очень индивидуально. Ощущали ли вы что-то подобное? Однажды (в то время я был программистом), мне пришлось работать без выходных несколько месяцев подряд. Ощущения были ужасными. Я чувствовал, что вошел в заколдованный круг, из которого не было сил вырваться. Я чувствовал, что моя продуктивность резко упала и стал невнимательным, раздраженным. Я много работал, но все равно патологически не успевал.
Поэтому, второй принцип работы гласит:

Пик продуктивности достигается при 36-40 часах работы в неделю. После этого продуктивность резко падает. Не обманывайте себя. Работая дольше, вы не станете делать больше.

Пагубная организационная культура. Как в компаниях относятся к людям, которые перерабатывают, днеют и ночуют в офисе? Это же герои. Им выплачиваются премиальные, их ставят в пример другим сотрудникам. Это пагубная практика стимулирует и поощряет выгорание людей. Подумайте, фактически, компании людям доплачивают за то, чтобы те теряли свою продуктивность и, как результат, приносили меньше дохода компании!
Я часто вспоминаю интересную историю, которую Кен Швабер описал в своей книге “The Enterpise and Scrum”:
Adventure Works была куплена японской компанией. Скрам и 8-часовой рабочий день не принимались новым менеджментом. Они требовали 12-часового рабочего дня, и компания была вынуждена пойти на это. За несколько Спринтов количество дефектов увеличилось на 60 процентов. Их появлялось больше, чем нового функционала. В конце концов, американский менеджмент вернул команды к 40-часовой рабочей неделе. Японцы решили избавиться от компании. Через два месяца Adventure Works выпустила на рынок свой продукт, который стал очень успешным. Имело ли смысл японцам продавать компанию? Конечно же, нет, но люди и культура тесно переплетены. У людей различные чувства, верования, убеждения, и они часто затуманивают рациональное восприятие действительности.
 И поэтому, третий принцип гласит:

 Никогда не поощряйте сверхурочную работу. Вынесите это в обязательные рабочие договоренности.

Постоянный темп работы. Один из 12-ти принципов Аджайл Манифеста гласит:
Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
Эти простые и интуитивно понятные всем ценности и принципы были написаны еще в 2001 году. И даже тогда они не являлись каким-то откровением или чем-то совершенно новым. Мы часто осознаем, что работаем неправильно, но организационная культура многих компаний настолько устоялась и впиталась в нас, что мы воспринимаем дисфункции, как должное. IT индустрия не понаслышке знает, что такое «death march» и «deadline». Добегаем до некой линии, а затем падаем замертво? Именно так команды и работали десятилетия до подписания Аджайл Манифеста. Пора бы уже меняться, не правда ли?
Получить добавку и дополнительную порцию советов о здоровой работе можно  здесь.

четверг, 28 августа 2014 г.

Игра с Burndown/Burnup



Хороший Скрам Мастер ежедневно обновляет Спринт Burndown, чтобы освободить команду от лишней работы. Отличный же Скрам Мастер помогает команде самоорганизовываться при помощи визуальных инструментов (Geodoff Watts, Scrum Mastery).
Burndown и Burnup – хорошо знакомые нам инструменты, которыми пользуются многие Скрам команды. Но, не смотря простоту, я сталкиваюсь с большим количеством недопониманий. Давайте рассмотрим некоторые из них, а затем я расскажу о том, каким образом можно увеличить эффективность использования этих инструментов.
Миф №1. Каждая Скрам Команда обязана строить Burndown. Действительно, еще десять лет назад Burndown был неотъемлемой частью Скрама, обязательным его артефактом (некоторые до сих пор считают так). Но сейчас это не так. В Скрам Гайде четко написано, что:
Возможно использование различных практик для прогнозирования прогресса, как, например, берндаун, бернап чарты или коммулятивные диаграммы. Эти техники полезны (Scrum Guide, july 2013).
Итак, современному Скраму безразлично, используете ли вы Burndown, Burnup, или же коммулятивные диаграммы для отображения прогресса. Существует большое количество различных практик и подходов. Скрам не навязывает конкретные решения. Скрам – фреймворк, внутри которого у команд возникают собственные практики, процессы и инструменты. Важно другое:
В любое время можно суммировать оставшуюся работу в Спринте. Команда Разработки отслеживает ее, по меньшей мере, на каждом Ежедневном Скраме, чтобы понять вероятность достижения Цели Спринта. Отслеживая оставшуюся работу, Команда Разработки видит и управляет прогрессом (Scrum Guide, july 2013)
Вы можете использовать Burndown, а можете «зарядить» Burndown. А, возможно, ни один из этих графиков вам не приглянулся, и вы решили, что визуальная Скрам доска прекрасно отображает прогресс к Цели Спринта. И знаете что? Скрам ОК с этим.
Миф №2. Скрам Мастер должен обновлять Burndown/Burnup. Часто, когда я говорю командам о том, что они сами должны обновлять свои графики, я ловлю на себе недоумленные взгляды, а затем обычно кто-то спрашивает: «а Скрам Мастер тогда нам зачем?». У меня есть встречные вопросы:
  • Для чего вообще Burndown/Burnup?
  • Кто отвечает за достижение Цели Спринта?
 Burndown/Burnup существуют для того, чтобы давать обратную визуальную связь тем, кто отвечает за достижение Цели Спринта, и заставлять их рефлексировать, корректировать свои действия в зависимости от видимого прогресса. Так как именно Команда Разработки отвечает за достижение Цели Спринта (а НЕ Скрам Мастер), то она и должна отслеживать свой процесс сама. Частый негативный паттерн, который я вижу в Скрам командах, где Скрам Мастер ведет графики – команде глубоко побоку вся эта информация. Ну, меняются какие то циферки, и что дальше? Поверьте, если вы введете правило, что каждый по очереди должен обновлять график на стене во время или после Ежедневного Скрама, команда начнет реагировать на прогресс лучше.
Поведение людей является функцией от человека (Person) и его окружения (Environment). Вывел эту знаменитую формулу психолог Курт Левин:

B=f(P,E)

self_organization_boundary.png
Для того, чтобы воздействовать на поведение людей, вместо того, чтобы менять самих людей (что очень тяжело), можно просто изменить окружение и тем самым заставить их самоорганизоваться внутри границ (How to Change the World, Yurgen Apello).
Какая же роль в этом случае отводится Скрам Мастеру? Объяснить команде, зачем нужен Burndown, научить его строить, задавать открытые вопросы и фасилитировать процесс, добиваясь самоорганизации.
Миф №3. Нужно стремиться к тому, чтобы фактическая линия на графике совпадала с идеальной.
Иногда менеджеры с гордостью демонстрируют идеальный Burndown, где зеленая линия (идеальная) совпадает с красной (фактической). У меня в голове возникают сразу две мысли:
  • Этого не может быть.
  • А если это действительно так, то зачем тогда им Скрам?
Чаще всего оказывается верным первое. В запутанной среде разработки ПО нельзя запланировать задачи на Спринт вперед так, чтобы исключить непредсказуемость. Беклог Спринта динамически меняется. Цветные стикеры двигаются по доске, оценки на задачи меняются, разработчики тратят на задачи больше или меньше времени, чем они изначально рассчитывали. В Запутанной среде (читаем Путешествие по Кеневину, часть 1) невозможно в конце получить то, что было запланировано в начале. А если ваша команда, все таки, занимается разработкой ПО и имеет подобные графики, то, скорее всего, отсутствует доверие. Разработчики завышают свои оценки, чтобы обезопасить себя.
Если же в команде доверительные отношения и мы не страхуемся завышенными оценками, а графики выходят идеальными, то я бы рекомендовал задуматься – а зачем здесь нужен Скрам вообще? Скорее всего, вы находитесь в Очевидном или Сложном доменах. Скрам – не серебряная пуля, возможно, вам подойдет «старый добрый Водопад».
Теперь я хочу поделиться своим собственным опытом в использовании Burndown и Burnup. Я приведу примеры конкретных практик, которые работали в моих командах.
Практика 1. Использование Burndown (часы) и Burnup (story points) одновременно. Долгое время я довольствовался лишь одним Burndown-ом, построенным на часах, но потом мне его стало не хватать. И вот почему. Он не отображает реальную бизнес ценность, доставленную командой. Если команда одновременно работает над большим количеством Историй (это плохая практиа, нужно ограничивать WIP), то, несмотря на то, что работа кипит – Истории не закрываются. В итоге можем придти к парадоксальной ситуации – Burndown почти «сгорел», а ничего, по сути, не сделано. Я начал пользоваться Burnup-ом, построенном на Стори Поинтах, который отображал доставленную ценность, но столкнулся с другой проблемой – иногда этот график сильно демотивировал некоторые команды. Представьте себе, что работа кипит, люди закрывают таски, а на графике унылая горизонтальная черта. И тогда я решил пользоваться двумя графиками одновременно.
burn_down.jpg
Подобная практика убивает сразу двух зайцев:
  • Показывает, насколько здоров ваш процесс и как быстро вы можете доставлять бизнес ценность на уровне Стори Поинтов (Burnup).
  • Отображает общий прогресс на уровне часов (Burndown).
Не забывайте использовать визуальную Канбан доску и ограничивать работу в прогрессе (WIP), иначе можно остаться у разбитого корыта к концу Спринта (см. фото ниже):
SAM_0479.jpg
Практика 2. Сделайте так, чтобы графики обновляла сама команда. Возможно, каждый день это будет новый человек. Поймите, что работает для вас и пользуйтесь этим.
Практика 3. Сделайте ваши графики визуальными и составной частью информационного радиатора. Каждый должен иметь возможность увидеть их и почесать голову в задумчивости, если там не все ОК. В отличии от информационных холодильников, дверцу которых нужно специально открывать (к примеру, электронные инструменты вроде Jira, Greenhopper), радиаторы излучают информацию и служат прекрасным источником коммуникации. И когда менеджер в очередной раз зайдет в комнату , возможно, все, что вам нужно будет сделать – проводить его к радиатору.
Практика 4.  Меняйте время от времени расположение ваших графиков. Человеческий глаз быстро привыкает к новому и скоро команда может перестать обращать на них внимание. Они станут просто обоями. А обои время от времени следует переклеивать.
Практика 5. Обновляйте графики во время Ежедневного Скрама, чтобы вся команда видела их актуальное состояние и рефлексировала. После Ежедневного Скрама можно спросить: «ОК, кажется, мы не успеваем. Что мы можем сделать?»
Практика 6. Используйте геймификацию. Подкиньте команде идею добавить что-то новенькое в Burndown. Ведь скучно же каждый Спринт наблюдать за однообразными осями и цифрами. Удобно сделать это на Ретроспективе. И вот к чему можно придти:
_MG_4930.png
_MG_4931.png
Одна команда, состоящая из большого количества любителей пива, решила сделать свой Burnup чарт, используя пивные наклейки. Каждый пивной бокал равнялся 3 S.P.
В другой команде много ребят занимались зимними видами спорта. Burndown напомнил им лыжную горку, которой спускается лыжник, минуя препятствия.
А бывает просто вот так:
img_01071.jpg
Практика 7. Никогда не стойте на месте и старайтесь разнообразить практики, пробуйте что-то новое. Начинайте, ошибайтесь и вновь пробуйте.
А как вы помогаете командам отслеживать прогресс к Целям? Делимся своим опытом в комментариях.