|
Персональные инструменты |
![]() |
||
|
![]() |
![]() AgileDays-2011: Отчет Гребнева Н.Ю.Материал из CustisWikiВерсия от 16:23, 2 июня 2011; StasFomin (обсуждение | вклад) Это снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений. От посещения конференции впечатление в целом положительное. Организационных накладок я не заметил, место проведения выбрано было удачно (добирался до места проведения и обратно за 20 минут). Как обычно не понравились обеды. Все-таки шведский стол на несколько сотен человек — это унижение человеческого достоинства. Вначале приходиться стоять в очереди за едой, потом с занятыми руками искать свободное место и далее приходиться ходить за едой еще несколько раз, опять стоять в очереди и т. д. Еда сама по себе была так себе. Не понравилось отсутствие синхронного перевода на докладе Книберга. Мне хотелось полностью погрузиться в то, о чем говорил Книберг, а не прокачивать навык аудирования английской речи (как ни крути, а иностранный язык существенно отвлекает от сути доклада). Далее подробно по каждому докладу. Содержание
Everyone likes change, but nobody likes to be changedHenrik Kniberg Доклад на английском языке. В докладе Хенрик рассказывал, как провести необходимые изменения (в достаточно общем смысле, но иллюстрировал на примере внедрения agile) в организации. Немалая часть доклада была посвящена принципам схожим с принципами системы GTD типа выделения конкретных шагов, понимания результата и т. п. Суть заключается в том, что прежде, чем начать что-то менять, необходимо понять, что же мы хотим получить в итоге, затем разобраться с тем, что у нас уже и есть и сделать первый конкретный шаг к достижению цели. Т. е. необходимо определить конкретные действия, которые можно сделать прямо здесь и сейчас и от которых будет виден результат. Акцент делается на важности трех вещей:
Если же вам необходимо провести какие либо изменения, то Хенрик советует вначале измениться самому (а заодно и понять, что вы хотите изменить). А для того, чтобы изменить организацию, то не нужно пытаться изменить других людей, а дать им мотивацию меняться самим. В качестве примера, как необходимо менять других людей, Книберг приводит ситуацию с детской, когда необходимо, чтобы ребенок самостоятельно поддерживал порядок в комнате. В качестве плохих стратегий называются положительная и отрицательная мотивация для достижения результата типа «чистая комната», соответственно мороженное за уборку и наказание в ином случае. Хенрик утверждает, что цель «чистая комната» не является истинной, а истинная цель – это приучить ребенка к порядку. И таким образом предложенные стратегии не приводят к желаемой цели. А для ее достижение необходимо мотивировать ребенка на сохранение порядка, например, объяснив ему, что в случае чистой комнаты игрушки будут реже ломаться. И показать путь к достижению этой цели, т. е. взять и убрать какую-либо вещь на свое место. На мой взгляд, данный пример не очень удачный, т. к. во-первых у меня вызывает сомнения, что с помощью приведенных аргументов можно мотивировать ребенка на уборку комнаты, а во-вторых не очень понятно, почему в качестве цели выбрано именно «поддержание порядка», а не чистая комната. Более того мне неочевидно, почему стандартные методы мотивации (мороженное и наказание) не приведут к желаемому результату, например, в результате того, что ребенок будет вынужден всегда держать комнату в чистоте у него выработается привычка к порядку. Стратегическое планирование через инновационные игрыДмитрий Лайер Очень интересная тема, но, к сожалению, очень плохой доклад. Докладчик излагал мысли бессвязно, непонятно и в середине выступления выяснилось, что у него не та презентация. Основная идея заключается в том, что стандартные методы планирования не работают. Невозможно собрать совещание, поставить перед людьми задачу (например, придумать новое направление в компании или разработать новый продукт) и получить ее решение. В качестве альтернативы предлагается решать задачу в игровой форме. Например, если необходимо разработать новый продукт, то для того, чтобы определить какими качествами он будет обладать и, что в него будет входить, то возможно проведение игры под названием «Коробочка». Игра заключается в том, что люди участвующие в решение данной задачи разбиваются на команды и каждой команде выдается бумажная коробочка и различные канцелярские принадлежности. Участники должны за фиксированное время коробку, которая будет представлять будущий продукт. Затем каждая команда делает небольшую презентацию и пытается продать свою коробочку. Докладчик утверждает, что подготовка к игре, ее проведение и обработка результатов – это достаточно трудоемкий процесс. В качестве примера, Дмитрий сказал, что на обработку результатов четырех игр у него уходит две недели. В докладе утверждается, что такой способ принятия решений гораздо продуктивнее обычного. Для ознакомления с различными видами игр и темой инновационных игр вообще докладчик рекомендовал книгу Люка Хохмана Innovation Games. Ретроспективы. Настраиваем наш процесс разработкиСергей Дмитриев Интересный доклад. Единственная претензия к нему – плохая презентация, на слайдах были только фотки (не имеющие отношения к делу), слайдов мало и информации они не содержали, лучше слайдов бы не было вообще. Доклад был посвящен тому, как надо проводить ретроспективы и зачем. Сергей считает, что ретроспективы нужны обязательно, причем как ретроспективы по командам в конце итерации, так и всего проекта (когда собираются все люди, имеющие какое-либо отношение к проекту) после его завершения. Ретроспективы необходимо делать интересными (см. книгу Agile Retrospectives) и полезными. После каждой ретроспективы должен быть результат, т. е. выполнены конкретные действия (пусть даже всего одно действие) направленные на улучшение процесса. Если в результате составляются огромные списки того, что необходимо сделать и что-то делать из этого списка никто не собирается, смысла в такой ретроспективе нет. На ретроспективе команда должна быть полностью открыта и готова обсуждать любые проблемы. Для этого предлагается не приглашать на ретро руководителя (в случае скрама – product owner), возможны также варианты, когда руководитель присутствует только на некоторых ретроспективах. Крайне желательна неформальная и доброжелательная атмосфера. На ретроспективе необходимо собирать не только факты, но и эмоции участников команды. В частности к одним и тем же фактам у разных людей может быть совершенно разное отношение. В качестве примера Сергей приводит ситуации, когда после составления списка фактов он просил участников отметить, к каким фактам они относятся положительно, а к каким отрицательно. В результате оказалось, что есть несколько вещей, к которым одни члены команды относятся положительно, а другие отрицательно. Сергей утверждает, что на любых собраниях (и в частности ретроспективе) присутствие модератора (facilitator) существенно увеличивает результативность совещания. Причем будет оптимально, если этот человек является внешним и не разбирает в обсуждаемой теме, тогда он сможет провести обсуждение в рамках намеченного плана и не даст дискуссии уйти в сторону. Иду по приборам! Практические советы по визуализации работМаксим Гапонов Название существенно лучше самого доклада. Рассказ ни о чем. В качестве средства визуализации предлагается использовать майндмапы и картонные интерфейсы. Kanban vs Scrum — чьё кунг-фу сильнееКирилл Климов Кирилл рассказал, как они в скрам-процессе внедрили канбан-доску и, что она позволила выявить некоторые проблемы. Доклад ниже среднего. Шаблоны «Асинхронный фильтр» и «HasValue» в разработке desktop приложенийДмитрий Ермаков, Олег Клинчаев
Доклад мне понравился, Олег рассказывал уверенно и интересно. Первый раз увидел наше боевое приложение на Java — выглядит очень симпатично. Командный стартСергей Дмитриев Фотографии флит-чартов с мастер-класса: http://www.dropbox.com/gallery/3490871/4/Documentation/Conferences/AgileDays%20Msk%202011/Team%20startup?h=06ae92 Это был мастер-класс посвященный такому процессу как «командный старт». Сергей под командным стартом понимает специально выделенное время, когда собирается вся команда вместе, а также люди имеющие отношение к проекту (типа Product Owner `a и руководства заинтересованного в результате), с целью познакомиться друг с другом и проектом в целом, а также определить общие ценности и видение проекта. Сергей рекомендует для командного старта отвести один день. Командный старт необходимо проводить когда:
Проведение командного старта позволяет:
Во время командного старта необходимо сделать:
Первый и пятый шаги должны занимать большую часть времени командного старта. Сергей придерживается концепции Брюса Такмана по развитию команды (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Поскольку Антон Бевзюк не смог приехать, то вместо его доклада была проведена джейм-сессия. Обсуждались следующие вопросы:
Обсуждались какие-то еще темы, но они мне не запомнились. 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».
|
![]() |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
![]() |