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

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

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

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

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

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

Everyone likes change, but nobody likes to be changed

Henrik Kniberg

HernikKniberg.jpg

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

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

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

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

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

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

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

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

LukeHohmanInnovationGames.jpg

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

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

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

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

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

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

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

EstherDerbyAgileRetrospectives.jpg

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

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

Ретроспективы необходимо делать интересными (см. книгу 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

DmitvievTeamStart1.jpg
DmitrievTeamStart2.jpg
Какие бывают игры…

Это был мастер-класс посвященный такому процессу как «командный старт». Сергей под командным стартом понимает специально выделенное время, когда собирается вся команда вместе, а также люди имеющие отношение к проекту (типа 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».