AgileDays-2011: Отчет Гребнева Н.Ю.

Ссылки сюда (2) →

Подстраницы (13) →

• Автор отчета

От посещения конференции впечатление в целом положительное. Организационных накладок я не заметил, место проведения выбрано было удачно (добирался до места проведения и обратно за 20 минут).

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

Не понравилось отсутствие синхронного перевода на докладе Книберга. Мне хотелось полностью погрузиться в то, о чем говорил Книберг, а не прокачивать навык аудирования английской речи (как ни крути, а иностранный язык существенно отвлекает от сути доклада).

Далее подробно по каждому докладу.

Everyone likes change, but nobody likes to be changed

Henrik Kniberg

Доклад на английском языке. В докладе Хенрик рассказывал, как провести необходимые изменения (в достаточно общем смысле, но иллюстрировал на примере внедрения agile) в организации. Немалая часть доклада была посвящена принципам схожим с принципами системы GTD типа выделения конкретных шагов, понимания результата и т. п.

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

1. Понимание того, что должно быть получено в результате (не очень соответствует идеям гибких методологий, на мой взгляд)
2. Понимание того, что есть сейчас
3. Путь перехода от второго к первому

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

В качестве примера, как необходимо менять других людей, Книберг приводит ситуацию с детской, когда необходимо, чтобы ребенок самостоятельно поддерживал порядок в комнате. В качестве плохих стратегий называются положительная и отрицательная мотивация для достижения результата типа «чистая комната», соответственно мороженное за уборку и наказание в ином случае. Хенрик утверждает, что цель «чистая комната» не является истинной, а истинная цель – это приучить ребенка к порядку. И таким образом предложенные стратегии не приводят к желаемой цели. А для ее достижение необходимо мотивировать ребенка на сохранение порядка, например, объяснив ему, что в случае чистой комнаты игрушки будут реже ломаться. И показать путь к достижению этой цели, т. е. взять и убрать какую-либо вещь на свое место.

На мой взгляд, данный пример не очень удачный, т. к. во-первых у меня вызывает сомнения, что с помощью приведенных аргументов можно мотивировать ребенка на уборку комнаты, а во-вторых не очень понятно, почему в качестве цели выбрано именно «поддержание порядка», а не чистая комната. Более того мне неочевидно, почему стандартные методы мотивации (мороженное и наказание) не приведут к желаемому результату, например, в результате того, что ребенок будет вынужден всегда держать комнату в чистоте у него выработается привычка к порядку.

Стратегическое планирование через инновационные игры

Дмитрий Лайер

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

Основная идея заключается в том, что стандартные методы планирования не работают. Невозможно собрать совещание, поставить перед людьми задачу (например, придумать новое направление в компании или разработать новый продукт) и получить ее решение. В качестве альтернативы предлагается решать задачу в игровой форме. Например, если необходимо разработать новый продукт, то для того, чтобы определить какими качествами он будет обладать и, что в него будет входить, то возможно проведение игры под названием «Коробочка».

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

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

В докладе утверждается, что такой способ принятия решений гораздо продуктивнее обычного. Для ознакомления с различными видами игр и темой инновационных игр вообще докладчик рекомендовал книгу Люка Хохмана Innovation Games.

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

Сергей Дмитриев

Интересный доклад. Единственная претензия к нему – плохая презентация, на слайдах были только фотки (не имеющие отношения к делу), слайдов мало и информации они не содержали, лучше слайдов бы не было вообще.

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

Ретроспективы необходимо делать интересными (см. книгу Agile Retrospectives) и полезными. После каждой ретроспективы должен быть результат, т. е. выполнены конкретные действия (пусть даже всего одно действие) направленные на улучшение процесса. Если в результате составляются огромные списки того, что необходимо сделать и что-то делать из этого списка никто не собирается, смысла в такой ретроспективе нет.

На ретроспективе команда должна быть полностью открыта и готова обсуждать любые проблемы. Для этого предлагается не приглашать на ретро руководителя (в случае скрама – product owner), возможны также варианты, когда руководитель присутствует только на некоторых ретроспективах. Крайне желательна неформальная и доброжелательная атмосфера.

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

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

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

Максим Гапонов

Название существенно лучше самого доклада. Рассказ ни о чем. В качестве средства визуализации предлагается использовать майндмапы и картонные интерфейсы.

Kanban vs Scrum — чьё кунг-фу сильнее

Кирилл Климов

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

Шаблоны «Асинхронный фильтр» и «HasValue» в разработке desktop приложений

Дмитрий Ермаков, Олег Клинчаев

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

Доклад мне понравился, Олег рассказывал уверенно и интересно. Первый раз увидел наше боевое приложение на Java — выглядит очень симпатично.

Командный старт

Сергей Дмитриев

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

Какие бывают игры…

Это был мастер-класс посвященный такому процессу как «командный старт». Сергей под командным стартом понимает специально выделенное время, когда собирается вся команда вместе, а также люди имеющие отношение к проекту (типа Product Owner `a и руководства заинтересованного в результате), с целью познакомиться друг с другом и проектом в целом, а также определить общие ценности и видение проекта.

Сергей рекомендует для командного старта отвести один день. Командный старт необходимо проводить когда:

1. Собирается новая команда для проекта
2. В команду приходят новые члены
3. Команда начинает новый проект
4. При внедрении agile.

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

1. Найти общую отправную точку
2. Обозначить общие ценности команды
3. Определить общее видение проекта
4. Увеличить шансы на успех

Во время командного старта необходимо сделать:

1. Понять по какому процессу сейчас работает команда, и определить каким образом команда хочет работать дальше
2. Привести понятие agile к общему знаменателю у всех членов команды. Каждый под гибкой методологией разработки может понимать разные вещи и этот шаг необходим для того, чтобы все четко представляли какую методологию они собираются использовать
3. Познакомиться друг с другом, узнать, кто и какими навыками обладает, какую пользу может принести проекту каждый участник команды и т. д.
4. Создать общее видение проекта. Сергей рекомендует на этот шаг пригласить как можно более высокое лицо, которое заинтересовано в проекте. Идеально, если это будет генеральный директор компании, который расскажет, почему этот проект важен для компании и почему необходимо его успешное завершение.
5. Ознакомиться с предстоящей работой.

Первый и пятый шаги должны занимать большую часть времени командного старта. Сергей придерживается концепции Брюса Такмана по развитию команды (Forming-Storming-Norming-Performing) и считает, что при изменении состава команда вновь оказывается в стадии Forming и из-за этого некоторые команды никогда не выходят на performing. Командный старт направлен именно на то, чтобы сократить стадии forming, storming, norming и выйти на performing. Это необходимо потому, что производительность хорошо сработанной команды может быть выше в несколько раз, чем просто у группы людей собравшихся для выполнения одной работы (по некоторым исследованиям прирост производительности составляет до 400 %).

В качестве инструмента для проведения командного старта докладчик рекомендует использовать игры (в выступлении были приведены в качестве примера, игры «35», «Мне интересно…», «спагетти» и т. д.). Игровая форма расслабляет людей и позволяет быть более открытыми и ускоряет процесс решения задач. Например, для знакомства членов команд друг с другом просить каждого рассказать о себе достаточно бесполезно, так как из рассказа вряд ли удаться понять какими навыками человек обладает и чем он увлекается. А при использовании игры типа «рынок навыков» это получиться сделать легко и непринужденно. Сергей также рекомендует в качестве пособия по играм обратиться к книге Innovation Games.

После мастер-класса была серия вопросов и ответов не всегда по теме, но достаточно интересных. Мне больше всего понравился вопрос про то, как команда должна принимать технические решения. Сергей считает, что команда должна принимать решения только единогласно и пока среди всех членов команды не будет достигнуто взаимопонимание, то должно продолжаться обсуждение. При этом уровень решений, которые принимает команда, должен быть ограничен итерацией. Решения, которые влияют на проект в целом, должны приниматься product owner`ор, причем возможно без учета мнения команды или вопреки ему. Более того команда для product owner`а не является единственным инструментов для выполнения проекта, у него также могут быть люди не входящие в команду, но при этом работающие на проекте. Например, таким человеком может быть системный архитектор, который также в своей работе может не принимать во внимание мнение команды, но при этом должен убедить product owner`а в правильности своего решения. Фактически PO и его люди отвечают на вопросы, что делать, а команда — как делать, причем именно в рамках итерации.

Мастер-класс мне очень понравился, проходил в живой обстановке и с высокой заинтересованностью аудитории. К сожалению, из-за большого числа участников, удалось сыграть лишь в одну игру («35»), но, несмотря на это, теория была изложена доходчиво и обсуждено множество интересных вопросов. В целом считаю, что посетить конференцию стоило только ради одного этого мастер-класса.

Архитектура в Agile: переосмысляя идею модульности и компонентности

Андрей Бибичев

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

Jam session

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

1. Внедрение TDD. Мнения аудитории разделились, кто-то считает, что надо внедрять модульные тесты, а кто-то считает, что достаточно интеграционных. На мой взгляд основная проблема тех, у кого не получается внедрить модульные тесты — это неудачная архитектура системы и отсутствие соответствующего опыта проектирования классов, пригодных для модульного тестирования.
2. Agile и госзаказчик. Переливание из пустого в порожнее. Дискуссия вышла неинтересной.
3. Электронная скрам-доска. Об успешно опыте внедрения рассказал только один мужик, при этом в отличие от всех остальных они купили в комнату здоровый телевизор, который и играл роль доски. Остальные, кто пробовал внедрить доску без телевизора (то есть когда в комнате фактически нет скрам-доски, но каждый имеет к ней доступ со своего ПК) все равно возвращались к бумажкам вновь.

Обсуждались какие-то еще темы, но они мне не запомнились.

Domain Driven Design в условиях разработки распределенных приложений

Николай Гребнев

Презентация

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

Основной задачей моего доклада было донести мысль, что если у вас распределенная система сложнее, чем клиент-сервер, и при этом вы хотите использовать DDD, то вам придется разработать свой инструментарий (на самом деле это далеко не такая очевидная мысль, как кажеться на первый взгляд) и вы должны оценить затраты на разработку этого инструментария и преимущества, которые он даст.

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

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

Принципы Lean и развитие аутсорсинговой компании: теория и практика

Михаил Плискин

Доклад о том, как в компании Ланит-Терком от нечего делать внедрили приципы Lean. Причем рассказ об этих самых принципах докладчик счел излишним, о чем прямо и заявил. Доклад длился 15 минут.

Lean Software Development

Никита Филиппов

Поскольку предыдущий докладчик уложился в 15 минут вместо 45, то Никита за время, оставшееся до своего доклада, успел прочитать введение в Lean. Основная идея Lean — это сделать путь элемента бэклога от начала работ до окончательного внедрения как можно меньше по времени. Это предлагается делать при помощи ограничения задач находящихся в работе (то есть тех работы, по которым уже начаты, но они еще прошли внедрение). Польза от подобных практик понятна в разработке ПО (чем раньше мы увидим результат, тем больше вероятность того, что мы делаем нужные вещи, а не какую-нибудь ерунду), но для меня далеко неочевидна на материальном производстве (основы идеи Lean взяты из производственной системы Toyota).

Lighting talk

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

Итого

Главная мысль, которую я унес с конференции (не главная мысль конференции, а мысль, которую я считаю наиболее важной) это то, что различного рода игры можно применять не только для тимбилдинга или обучения, но и для решения реальных управленческих и производственных задач. Недавно прошедшая стратегическая сессия подтвердила правильность этой идеи.

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

---

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

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