Содержание

1 Общие впечатления
2 День 1
3 День 2

Общие впечатления

Наверное, я больше не пойду на Agile Days. Не потому, что конференция плохая — напротив, очень даже ничего. Просто сами мероприятия «про Agile» становятся все менее и менее интересными для меня, с каждой конференции удается вынести все меньше нового. Я надеюсь, что это просто близится «информационное насыщение» (в положительном смысле), а не усыхание мозга :)

Уже понятно, что «серебряная пуля» Agile блестит как-то подозрительно, больше напоминая оловянную. Понятно, что все проекты настолько индивидуальны в своем неповторимом контексте, что очень сложно давать универсальные советы в действиельно сложных ситуациях. И так можно, и эдак можно, но всегда надо думать головой и смотреть по месту. Давно понятно, что основная сложность не в том, как вешать карточки, а в том, как относиться к работе, как «быть agile», а не «делать agile». И этому на тренингах не учат, и на конференции обсуждают крайне редко.

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

неудачного времени проведения — прямо перед 8 марта, из-за чего я пропустил вторую половину второго дня, предпочтя праздник в офисе;
неоднородной сетки докладов на трех треках, из-за чего перебежки между треками часто оказывались ущербными.

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

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

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

День 1

Хенрик Книберг. Все любят изменения, но никто не любит, чтобы его меняли

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

Доклад был о том, как проводить изменения в жизнь. Вот возникла у вас мысль — «как бы мне внедрить Agile»? (такое ощущение, что это основная мысль, которая до сих пор будоражит умы участников agile-конференций). И как дальше с этой мыслью быть.

Так вот, краткая инструкция от Книберга на такой случай звучит так:

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

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

График счастья: Ну и кто способен его адекватно вести? Погода на мое эмоциональное состояние может влиять гораздо более сильно, чем обстановка на работе.

Дети, уберите комнату: Ха-ха, так я и поверил, что удастся замотивировать ребенка рассказом о том, что «все будет так красиво» :) Как быть, если мотивы (и ценности!) ваши сильно различны, но все-таки это твой ребенок?

Сопротивление из-за перекрестных страхов типа «Они не захотят!»: Рецепт «собрать всех вместе и обсудить» может и сработает, если называемая причина является действительной причиной. А ведь запросто «Они не захотят!» может быть просто отговоркой, скрывающей истиные страхи и нежелания что-то менять, которые вам фиг раскроют. Ведь, как известно, все лгут©.

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

Николай Алименков, Алексей Солнцев. В погоне за качеством: Code Review

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

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

Что хочется отметить из любопытного, что нам непривычно, но, возможно, стоит попробовать:

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

Семен Молотков, Евгений Кобзев. Экстремальный аджайл — танцуют все

Докладчики из команды компании СКБ «Контур», разрабатывающей любопытный сервис — «Электронный бухгалтер Эльба». Идея — предоставить малому бизнесу сервис упрощенной бухгалтерии в интернет. На сайте есть ролик, наглядно объясняющий суть сервиса. Примечательно, что сервис включает также возможность электронного документооборота с органами отчетности. Впрочем, речь не о продукте, а о команде, процессе, и докладе.

Команда довольно большая — 18 человек, и весьма разношерстная (9 ролей!). Там и разработчики (8 шт), и бухгалтеры-аналитики, «интерфесологи», продвиженцы-маркетологи, дизайнер, юзабилист, и я еще парочку забыл.

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

Что удивило:

Они сидят в одной комнате (18 человек!). Считают это за достижение и говорят, что это им сильно помогает, но я реально не понимаю, как это возможно — или они по большей части молча работают.
Если задачу оценили в N, а по ходу дела выясняется, что она скорее 3N, то вместо того, чтобы обозначить это, они начинают «списывать пропорционально». Мне кажется, это искажает раннюю информацию об «успеваемости».

Еще из любопытного:

Они стараются делать такие вещи, как «презентации аналитиков и продвиженцев» — людей, работу которых очень сложно померить и пощупать. Но, стараются, просто чтобы команда была в курсе того, как идут дела.
Вроде бы у них нет формального PM, хотя наверное, все-таки, кто-то такой есть.
Позже, на Jam Session девушка по-моему именно из этой команды спрашивала, то делать с нудными и скучными скрам-митингами. Честно говоря, не удивительно при таком разбросе ролей в одной команде!
Рисуют фичи (user stories) и таски на спринт в виде mind map’а. В любой момент его можно дорисовать, декомпозировав какую-то задачу, и разложив суммарную ожидаемую трудоемкость на части.
Иногда они проводят «день ретроспективы», выезжая на базу отдыха. Думается, это классная практика, и не слишком накладная, на самом деле.

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

Что касается доклада, то он, увы, был довольно занудный. Рассказывали двое, но от обоих хотелось спать.

Борис Вольфсон. Масштабирование Scrum на большую распределенную команду

Масштабирование Scrum на большую распределенную команду (Борис Вольфсон, AgileDays-2011)

Оказывается, в компании SoftLine есть подразделение разработки софта, и весьма немаленькое — с нашу компанию. Причем подразделение это распределенное, рабочие группы сидят в разных городах. На плечах подразделения — несколько (около 10) софтверных проектов, и больших и маленьких.

Организовано это все в достаточно однородную («фрактальную»?) иерархию SCRUM’ов. Есть группы разработчиков, в них — достаточно классические SM и PO. Причем, SM у них вполне похож на руководителя проекта. Тут все как обычно — scrum meeting каждый день.

На втором уровне иерархии (Scrum of Scrum или S2) раз в три дня собираются все SM и PO, и обсуждают вопросы более высокого уровня. Здесь выделяется свой «главный» SM, который называется Program Manager, и который отвечает, по сути, за процессы целого офиса разработки. А для PO появляется Chief product owner, который определяет межпродуктовые приоритеты.

И, наконец, есть третий уровень, S3 или Scrum of Scrum of Scrum, где две управляющие лестницы наконец сходятся в топ-менеджменте. Всех chief product owner’ов координирует CEO, а всех program manager’ов — CTO. Примечательно, что S3 meeting происходит стабильно раз в неделю (из-за распределенности используют Skype и т. п.).

Собственно, основное, что я вынес с этого доклада — «такая конструкция живет». Там было много картинок, но суть, на мой взгляд, именно в этом.

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

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

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

Лидер — это тот, у кого есть последователи (followers), лидер не может быть один в поле (в группе). Или он не лидер.
Харизме, которая обычно присуща лидеру, на самом деле можно научиться (Фрейд)
Лидер дает волю тому, что уже готово двигаться (Юнг)
Современная культура управления постепенно дрейфует в сторону управления через лидерство, и не только в наукоемких отраслях
Теоретические идеи такого управления заложены Херши и Бланшером (Hersey, Blanchard) в теории ситуационного лидерства
Ближе к Agile: классический Scrum-мастер должен быть лидером и коучем
Найти такого SM очень непросто. Всегда проще кого-то просто назначить ;)
Лидером может быть и Product owner, это тоже хорошо работает
Если яркий лидер есть в топ-менеджменте компании, то культура лидерства хорошо внедряется сверху.
Снизу внедрять значительно сложнее.

Далее говорили про ответственность и стили управления.

Ответственность может быть делегирована, но не может быть передана! Делегировав кому-то что-то, ты в то же время оставляешь ответственность на себе.
Делегирование = поручение + полномочия + доверие. Доверие не подразумевает передачу ответственности.
Личная ответственность также поддается воспитанию.

Давно всем известна картинка с четырьмя стилями руководства — от директивного к делегирующему. Но эти ступеньки слишком велики и иногда совсем неясно, как переходить от одного стиля к следующему. Тут докладчик ссылался на книжку «Management 3.0» за авторством Jurgen Apello, которая совсем недавно вышла на английском языке. Jurgen вводит более плавную, семиуровневую модель стилей управления:

Указания
Уговоры и убеждения (продажа идеи, объяснение)
Опрос мнений
Участие
Совет
Обратная связь
Делегирование в чистом виде

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

И напоследок еще несколько разрозненных тезисов из доклада:

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

В общем, рекомендую посмотреть запись, мне понравилось.

Дмитрий Лобасев. Agile с фиксированной стоимостью — это реально!

Дмитрия Лобасева я видел у нас на собраниях сообщества AgileRussia, он рассказывал про DevProm — систему управления проектами, которая «лучше всех». На этот раз доклад был про другое.

Судя по реакции зала, действительно многих волнует вопрос, как совместить разработку по agile с договорами по fix price, и, думается, это очень непросто сделать — заказчики привыкли мыслить в терминах «деньги-товар».

Дмитрий рассказывал не слишком зажигательно (про DevProm у него получается заметно лучше) о том, как участвовал в проекте, который оформлялся по всем канонам fix price, но при этом делался по agile. По масштабу и характеру этот проект, как я понял, был похож на наши типичные проекты с Спортмастером.

Никакой особой магии там не было — в договорах фиксировали только высокоуровневые требования, и регулярно передоговаривались, писали корректировки к договорам. Суть доклада можно было свести к мысли «апеллируйте к разуму заказчика, объясняйте ему, договаривайтесь, ну и иногда можно схитрить».

Константин Гурнов. Enterprise Scale Agile: Lessons learned

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

В проекте было задействовано более 150 человек, расположенных в 4х разных офисах, и длился он порядка 5 лет. Единая кодовая база на весь проект, но 5 разных беклогов (как делились беклоги — не рассказал).

В начале проекта старались работать мини-водопадными этапами, но потом все-таки перешли на более-менее классический scrum, и, вроде зафиксировали значительное снижение трудозатрат от этого.

«Enterprise Scale Scrum», как я понял, характеризуется значительно более формализованными подходами — никуда не деться от кучи метрик, внутренней аналитики, большего числа иерархических структур, и т. п.

Но, тем не менее, автор говорит, что уже даже для больших компаний agile перешел через «пропасть незрелости», и все его уже используют.

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

Из любопытного — на проекте не было выделенных архитекторов, собирались архитектурные workshop’ы, в которых мог поучаствовать каждый желающий. Не представляю, как это было организовано, чтобы не было бардака.

Николай Алименков, Алексей Солнцев. Что означает «Готово!»: применение практики Definition of Done

Что означает «Готово!» — применение практики Definition of Done (Николай Алименков, Алексей Солнцев, AgileDays-2011)

Те же двое, что утром рассказывали про code review. Но на этот раз все было гораздо более скучно почему-то. То ли я просто уже устал?

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

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

День 2

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

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

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

Если попытаться переформулировать тему доклада для большей понятности, то это было бы что-то вроде «Современные хорошие практики объектно-ориентированного проектирования».

Спектр тем, освещенных в докладе, был достаточно широкий:

Ценность модульной архитектуры
Понимание порочного влияния связности
SOLID-принципы проектирования
Закон Деметры
Правильное использование механизмов наследования (принцип Лисков)
Принцип Inversion of Control
Современные паттерны — удачные и неудачные
Программирование по контрактам
Вопросы облегчения кодирования с учетов всего вышеперечисленного
Переход от проектирования системы классов к системе высокоуровневых сервисов

Презентацию можно взять здесь (видеозапись).

В добавок к презентации Андрей рекомендует:

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

В заключение хочется только вздохнуть о том, что

а) Андрей уже не с нами

б) Когда закладывалась основа cis-uni.net, такой полноты понимания проблемы еще ни у кого в ЗИСах не было.

Jam Session

Вместо Антона Бевзюка устроили JamSession. Очень жаль, что Антон не приехал. Формат jam session мне не понравился — народ успевает только высказать свои мнения, при этом комплексного обсуждения не получается, мнения остаются разрозненными, висящими в воздухе. Кто что успел — тот сказал. Полемики как таковой вообще нет, так как времени мало и люди постоянно меняются. Просто поток мнений и крупицы опыта, как всегда оторванного от контекста.

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

Коля бодро и уверенно отчитал доклад. Я этот доклад слушал первый раз, так как на предварительный прогон не попал.

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

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

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

Заходяйченко Андрей. Как внедрить ALM систему управления командами по разработке ПО (Agile (Scrum)) и остаться довольным

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

Дядечка махал каким-то опытом внедрения каких-то проектов и многочисленными сертификатами, но в чем у него точно можно поучиться — так это в том, какне надо делать доклады. При том, что у него, похоже, действительно внушительный багаж знаний (про опыт — непонятно), он не смог остановиться на какой-то обозримой теме, и в результате доклад был про все сразу:

PMO, ROI, PMBOK, Agile в PMBOK, KPI, RUP, Белбин, проекты, SMART, WBS, бета-распределение и PERT, методологии, коучинг, и все-все-все.

Он здорово волновался, неуклюже пытался вовлечь аудиторию, путано задавая вопросы, на которые аудитория не хотела отвечать и вовлекаться, типа «-- Ну, вы знаете, в аджайл у нас для планирования есть что? Что есть у нас? Как называется? Скрам-… Скрам-митинг! Верно? Да!». Смотреть на это было жалко.

Раздал всем тесты по Белбину, которые никто не заполнял (сложно слушать и рефлексировать о своей роли), а потом не успел их собрать и что-то с ними сделать (уж не знаю, что он собирался).

Странным образом сопоставлял роли Scrum’а и командные роли по Белбину: «Scrum-мастер не может быть Координатором». От этого рвало крышу: «Гамлет не может быть Отелло» — что это, черт побери, значит? Эти роли из разных спектаклей!

Он даже показывал картинку с деревом и тарзанкой!!!

Закончилось все это рекламой некоего «симулятора управления проектами», к которому он имеет какое-то отношение.

Финальный слайд-визитка достоин отдельной минуты медитации. В нем все. Вчитайтесь внимательно:

А. Заходяйченко, 
CPMP, MBA, PhD
CIO@BesTTeamKPI.com

В общем, оставил очень неоднозначное впечатление…

Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.

Персональные инструменты

Просмотры

AgileDays-2011: Отчет Беспальчука И.А.

Материал из CustisWiki