AgileDays-2011:Отчет Никитина В.В.

Материал из CustisWiki

Перейти к: навигация, поиск

В целом конференция понравилась: место, инфраструктура, организация. Были, конечно, и недочеты, но их я уже записал в опросник организаторов. Очень порадовали два доклада и два тренинга Сергея Дмитриева (Норвегия) и Тимофея Евграшина (Украина) (о них скажу ниже).

Для меня основной положительной мыслью, которую я еще раз освежил в памяти, была такая: нам надо наращивать agile'вскую гибкость, самоорганизацию и взаимное доверие в командах.

Доклады

Everyone likes change, but nobody likes to be changed. Henrik Kniberg

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

  • Не пытайся менять людей -> мотивируй их на то, чтобы они сами хотели меняться
  • Дай человеку направление, а не укажи решение.

Стратегическое планирование через инновационные игры. Дмитрий Лайер

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

Есть у него книга «Innovation Games: Creating Breakthrough Products Through Collaborative Play». Нашел в инете, где скачать, только усеченный вариант книги: http://agilegames2011.com/images/stories/downloads/innovationgames_3games.pdf

И есть еще сайт http://innovationgames.com/

Вроде бы все это очень помогает в сплочении команд.

Ретроспективы. Настраиваем наш процесс разработки. Сергей Дмитриев

Очень хороший доклад и в плане содержания, и в плане подачи материала. Очень понравился! Смотреть всем!

Его сайт http://www.agilecoach.ru


Основные мысли:

  • Ретроспектива — «коллективное рассказывание историй»
  • Доверяй своим подчиненным
  • Менеджеры боятся доверять, но страх — это хорошо, это значит, что есть экперимент, проба что-то улучшить.
  • Фокус ретроспективы должен быть обращен на то, чтобы что-то произошло — поменялось
  • Ретро ~ 1 час на неделю работы

Структура:

  • открытие 5 %
  • сбор данных 30-50 %
    • у всех есть чувства
    • по списку красными и зелеными точками отмечают «за» и «против»
  • приникновение в суть 20-20 %
    • анализ данных
  • решение о дальнейших действиях 10 %
    • что реально можем сделать в ближайший спринт
  • закрытие 10 %
  • PO — гнать с ретро. Либо пускать хотя бы через раз.
  • Если команда в отсутвии PO может «вывесить грязное белье», то это уже команда. Иначе — не команда.
  • И здесь есть игры для ретроспектив — читать книгу Esther Derby, Diana Larsen «Agile retrospectives»
  • Каждый обязательно должен что-то сказать
  • Основная директива: ретроспектива — это не место, где мы ищем виновных. Мы ищем, что сделать, чтобы стало лучше.
  • Рабочий уговор — внутренние правила поведения (например, никто никого не перебивает, никто за другого не говорит и т. п.)
  • На ретро должен присутствовать модератор. Лучше не из команды.

Анекдот по теме ретро: Мужик пилит дерево, а оно пилится с трудом. К нему подходит другой и говорит: «Ты бы пилу поточил — сразу бы дело быстрее пошло!». «Да, что ты, — отвечает другой — некогда, пилить надо!» Зачастую мы похожи на первого мужика.

Иду по приборам! Практические советы по визуализации работ. Максим Гапонов

Видел его и на прошлых AgileDays. Материал во многом старый. Такое ощущение, что лишь бы поучаствовать. Сказать нечего.

Agile Distribution Risk Score. Анна Обухова

Презентация на английском - рассказ на русском. ЗАЧЕМ? Предлагала способ оценивания команд по рискам, связанным с распределенными командами. Ничего интересного для нас.

Культура лидерства в Agile. Тимофей Евграшин

Сайт http://tim.com.ua

Очень толковый доклад и по содержанию, и по подаче материала. Я внимательно слушал, поэтому мало что записал, поэтому ВСЕМ рекомендую видео к просмотру.

Книга Jurgen Appelo «Managment 3.0»

Командный старт (мастер-класс). Сергей Дмитриев

Очень понравилось. Знаю, что некоторые наши, кто присутствовал, применяли уже у нас тут в деле.

e-mail: sergey@agilecoach.ru

Фотографии flipchart’а с мастер-класса: http://www.dropbox.com/gallery/3490871/4/Documentation/Conferences/AgileDays%20Msk%202011/Team%20startup?h=06ae92#/

Всё, что мы написали на тренинге, мы развешивали на стенах в зоне видимости, чтобы можно было в любой момент посмотерть + чтобы был виден объем проделанной нами работы.

Началось все с представления тренера
Дмитриев 03.jpg
Затем Сергей озвучил план мероприятия:
Дмитриев 04.jpg
Затем мы все вместе написали наши ожидания от мероприятия (мы говорили — он писал)
Дмитриев 01.jpg
Дмитриев 02.jpg
Командный старт занимает ~1 день. Когда проводится и зачем:
Дмитриев 05.jpg
Почему необходимо проводить командный старт, даже если в команду добавился всего один человек:
Дмитриев 11.jpg
Есть исконный agile, как он описан в книжках. Назовем его «Сердце agile» (слева вверху).

Есть Первая команда, которая подкрутила его под себя, добавив командный опыт и ритуалы (справа вверху).

Есть вторая команда, тоже подкрутившая его под себя, но в другом напрвлении (слева внизу).

В итоге по компании получаются команды, у которых только в некоторых аспектах agile пересекается.

Поэтому при переходе из одной команды в другую, происходит нестыковка в понимании agile, поэтому нужен командный старт.

Это затратно, но дает большие плюсы в дальнейшем: команда будет работать продуктивнее.

Повторили еще раз про 4 стадии развития команды:

Дмитриев 14.jpg
Новая команда формируется, проходя в этом процессе кульминацию (storming) и выходя на нормализацию процесса. После этого идет только совершенствование.

Если же хотя бы один человек добавился в команду — это уже новая команда, и она снова сваливается на стадию Forming.

Что нужно, чтобы командный старт состоялся
Дмитриев 06.jpg
Основная структура командного старта: слева указаны соотношения по времени, которое надо отводить на каждый пункт (3:1:1:1:3).

Отдельно пункты разбираются ниже.

Дмитриев 07.jpg
Далее он говорил, что в его практике встречались случаи, когда просили улучшить ситуацию в одной команде, но оказывалось, что проблемы не только в ней, но во всем процессе, в который встроена команда, поэтому улучшение в команде незначительно повлияет на процесс в целом и будет мало заметно. Надо в этом случае улучшать процесс в целом.

Для этого используют value stream mapping. Рисуют процесс от старта до отгрузки продукта/версии/релиза и на всех переходах и узлах ставят время, которое он занимает. Потом анализируют. Утверждается, что менеджеры удивляются результатам.

Дмитриев 15.jpg
И далее вывод: локально оптимизировать нельзя

И откровение про PO. Он должен все делать с такой позиции: «Что я сегодня могу сделать, чтобы команде было лучше» (сравните с вашим подходом!)

Итак, освежаем процесс:
Дмитриев 08.jpg
Знакомимся поближе
Дмитриев 09.jpg
Группа людей должна учиться думать как команда — должен появляться командный разум, не сосредоточенный в одной чьей-либо голове, а распределенный по команде.

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

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

Другие игры, помогающие сплочению команды и решению некоторых задач, описаны в книге «Innovation games» by Luke Hohmann

Дмитриев 16.jpg
Далее команда обсуждает предстоящую работу:
Дмитриев 10.jpg
После этого можно приступать к работе.

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

Дмитриев 12.jpg
Наш скрам

Каждому дается в распоряжение флипчарт и он должен нарисовать скрам (модель), такой, каким он его себе представляет. Потом обсуждение или рефликсирование. Преследуется все та же цель: общее понимание общего процесса.


Мне интересно…

Каждый по кругу спрашивает, начиная фразу словами «Мне интересно, как в скраме …». Ответы, обсуждения. Цель та же: общее понимание общего процесса.


Что такое самоорганизация

Индекс-карточки: как ощущается самоорганизация. Это все, что было сказано.


35

Играется, если есть несколько наших формулировок чего-то, и нам трудно выбрать одну. Каждый пишет свою на отдельной бумажке. После этого все передвигаются по комнате в произвольных направлениях — перемешиваются, меняются карточками. После сигнала любые двое, находящиеся рядом, образуют пары. Они должны прочитать вдвоем обе карточки и совместно проставить на обратной стороне каждой из карточек баллы так, чтобы в сумме на обеих карточках было 7 баллов. Такая процедура проводится 5 раз. Нетрудно догадаться, что максимум, который может набрать карточка при такой процедуре, 35 баллов (правда, такого еще никогда не было — оно и понятно: если бы была очевидная формулировка-лидер, то и не пришлось бы проводить эту процедуру). Отсюда и название игры. Побеждает формулировка(формулировки), набравшая больше всего баллов. Однако рассматриваются также и отстающие на 1-2 балла. Из них берутся мысли (или не берутся), для дополнения основной формулировки.


Спагетти

Участвует 8 человек. Они берутся за руки и запутываются в «узел». Менеджер должен распутать, но не может. А команда сама легко и быстро распутывается. Играется, чтобы убедить менеджера, что команда и сама способна на многое, а менеджер иногда очень даже мешает.


Рынок навыков

Рисуется стол — витрина. На витрине рисуются навыки и интересы, которые могут пригодиться в проекте — то, что человек предлагает как вклад в команду. Под витриной рисуются навыки и интересы, которые не нужны в проекте, но которыми человек готов поделиться. Пример Сергей нарисовал сам про себя:

Дмитриев 13.jpg
Над столом все читаемо, под столом: семья, есть ребенок, дайвер, из спорта любит сноуборд, футбол, лыжи, байкер.


Жизненное путешествие

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


Угадай-ка

Каждый пишет про себя стикеры двух цветов: на одних то, что 100 % не он — на других то, что 100 % он. Плюс на тот момент уже нарисованы портреты членов команды (это игра, когда каждый дорисовывает в портрет рисуемого члена команды свою деталь: команда ходит по кругу и каждому дается по 3 секунды на дорисовывание). Далее эти бумажки развешивают общими силами/обсуждением на портреты.


Успели поиграть только в 35. Формулировали, зачем нужен командный старт. Вот победившие бумажки.

Дмитриев 23.jpg
Дмитриев 24.jpg
Дмитриев 25.jpg
Дмитриев 26.jpg
По окончании написали плюсы, которые дал нам этот мастер класс:
Дмитриев 27.jpg
По окончании написали «дельта»-плюсы: что может сделать Сергей, чтобы следующий мастер-класс прошел лучше этого:
Дмитриев 28.jpg
Далее были ответы на вопросы, одним из которых был: что делать, если в команде есть эксперт, который очень влияет на решения команды и вносит дисбалланс. Ответ был такой:
Дмитриев 17.jpg
PO — это король. В его ведении находится вопрос «ЧТО делать», а в ведении команды находится вопрос «КАК делать». Этого самого эксперта, который давлеет над командой, надо выводить на уровень PO, чтобы он не мешал команде. Его место именно там. Пусть PO советуется с ним и спускает уже готовое решение, чтобы у команды не складывалось впечатление, что их мнение игнорируется. Надо отметить, что в этой ситуации страдает не только команда, но сам этот эксперт, поэтому это решение в корне меняет настроения в коллективе.


Закончился мастер-класс далеко за 19:00, но эти два с лишним часа пролетели незаметно, все остались довольны, зарядились энергией, получили знания.

Agile-игры: Business Value Game. Тимофей Евграшин

Имея вечерний опыт хорошего мастер-класса, я понял, что мне сюда. И не прогадал. Была интересная модельная игра. Наша команда выиграла!

Заключается она в том, что есть Заказчики, они дают задачи, за которые мы получаем деньги, если релизим версию. При этом у задачи есть показатель «счастья» клиента: то, насколько повысится счастье (в баллах), если задачка будет отгружена. Изначально у всех заказчиков по 5 баллов счастья. Каждый ход, если заказчику ничего не отгружается, его счастье уменьшается на 1. Если оно становится равным нулю, то команда теряет заказчика, более того, все деньги, которые на нем заработаны до этого, не идут в зачет.

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

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

В целом, хоть игра и модельная, но в ходе нее чувствуешь некоторые моменты.

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

Также Тимофей поделился ссылкой на сайт с играми: http://blog.tastycupcakes.com/all-games/


BE AGILE, EVERYONE!


Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2011:Отчет Никитина В.В.»

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».