4-5.03.2011 прошла конференция AgileDays 2011. Я на ней присутствовал и выступал с докладом о модели системы как архитектуре в Agile, презентация. Он посвящен весьма интересной теме - какими средствами можно итеративно строить архитектуру системы, обеспечивая при этом ее целостность.

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

А здесь - мои впечатления о конференции.

Конференцию снимали на видео наши сотрудники (компания CUSTIS), так что если Вас заинтересовал какой-то из докладов - через некоторое время можно будет посмотреть видео и презентации.

Содержание

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

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

Кстати, среди участников активно появляется in house. Не только Дойч, но и Альфа-банк и Сбер, и из ВНИИХТ (вроде) Росатома тоже были. То есть в эту сторону смотрят. А еще - была пара компаний, работающих на запад с продуктовой разработкой, поставляющих решения для крупных заказчиков - хедж-фондов и страховых компаний, и общение - достаточно любопытно.

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

Доклады можно разделить на две больших категории. Один - доклады достаточно опытных людей, которые имеют большой опыт и в своем докладе осмысливают и обобщают его, взяв определенный аспект - потому что объем ограничен и изложить опыт можно лишь сузив тему. И вторая категория - это доклады людей с гораздо меньшим опытом, которые рассказывают о своих успехах. Это менее интересно для опытных людей, тут нет обобщений, зато есть детали и конкретные случаи, из которых можно делать выводы. Кстати, докладчик может обладать большим опытом в целом, и только предметом доклада заниматься относительно недавно. Заметки по докладам у меня поделены именно так.

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

И еще несколько совершенно общих замечаний

Доклады опытных

Итак, доклады опытных - тех, кто обобщил опыт многих проектов и делится им с иллюстрациями.

Хенрик Книберг. Everyone likes change, but nobody likes to be changed

Презентация в блоге Хенрика.

Доклад был интересен для меня, несмотря на тренинг. Потому что дал обзор верхнего уровня по очень разным областям и подвел итоги. В целом - хороший обзорный доклад профессионала и в предмете и в докладах. Россыпь практик: тезис - объяснение - пример, коротко и просто. С моей точки зрения, можно учиться как делать доклады и презентации.

Дальше - записанные тезисы.

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

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

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

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

Андрей Бибичев. Пуассоновое горение сроков

При оценках сроков закладываемся в 2-3 раза. Почему это правильно? Мы оцениваем наиболее вероятный срок, но, естественно, можем ошибаться. Интересный вопрос - как распределена вероятность сроков с учетом ошибки. Вовсе не по нормальному закону.

Если распределение нормальное, то девиация примерно как оценка. Значит с вероятностью 16% мы это уже сделали и должны денег. А это не так, сроки обычно оказываются больше. Значит, распределение другое.

Модель первая - поток случайных задержек, сроки отодвигаются из-за него. Пуссоновское распределение.

Модель 2 - броуновское движение. Нас бомбардируют отклонения от пути. Дрожание. Общая траектория становится длиннее. логнормальное распределение (логарифм распределен нормлаьно).

Модель 3 - PERT. Бета-распределение. Правда докладчику непонятно почему, но он читал работы. А кривая похожая получается.

Общее - кривая не симметрична. Меньше - почти не бывает. А больше - большая область. И из-за не симметрии вероятность успеть до максимума оценки всего 10-15%. Так что правильно оценивать - X плюс X или 2X. И еще останется 5% что не прав. А 5% - это не так мало, каждый двадцатый. Посчитайте, при недельной итерации - как оно.

Антон Кекс. Недостающая часть Scrum: как стать успешным инженером в Agile?

Из Эстонии. Основатель и глава фирмы. Хороший обзор, но для новичков.

-- но без оговорки Эванса? - работает из предположения, что добавить потом также просто и что не можешь угадать

вроде для новичков - ушел потом вернулся - когда игры кончились

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

Я был недолго. Изложение не слишком системно, он не успел.

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

Я слушал не сначала. Народ не влезал. Изложение не слишком гладко, зато паузы и шутки. Но где-то на 2/3 доклада народ начал уходить, правда, может потому что начинался другой доклад. Но, в любом случае Максиму не хватило репетиции изложения и это весьма сказалось на докладе.

Доклад был о проблемах понимания, вернее, неверного понимания с разных сторон, моделях и историях вокруг этого. И, особенно - средствах визуализации.

Заметки.

Анна Обухова. Agile Distribution Risk Score - планируйте распределенность осознанно

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

Заметки.

Сергей Дмитриев. Командный старт

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

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

Заметки.

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

Руководит развитием agile в люксофт. В целом понятный доклад обернутого в науку agile - не примеры, а общие слова и хорошие метрики.

Заметки.

Люксофт success story хорошей разработки. Развитие от функциональных команд к кроссфункциональным и далее к бизнес-командах.

Рассказ что применяют крутой agile (Enterprise Scale) - масштаба предприятия. Процесс непрерывного улучшения - главное. Через метрики. Три группы - требования, дизайн+архитектура+техника, инфраструктура. Проблема идентифицируется, гипотеза по исправлению, эксперимент, метрики результата и решение по нему.

Пример истории - 100% автоматизация в одной группе дала кучу плюсов, и не оверхед.

Источники - поддержка менеджмента с одной стороны и системное мышление - с другой.

Говорит, что все осознали и он прошел пропасть. Только Книберг при этом говорит, что реально не итеративно.

Слова - надо решать. И не свои проблемы, а проблемы заказчика. Если заказчик - ит-департамент заказчика, то ему не интересны проблемы с подрядчиком, ему надо решить проблемы бизнес департаментов.

Все коммуницируют примерами, аналитик по ним создает user story, по которым команда создает свои а тестеры свои. spec by example настаивает на использовании примеров пользователя. У них - хорошо. Из зала пошли вопросы с завалом - мол, пользователи не знают что делают.

Успешный 5-летний проект с инвестбанком (интересно, с каким, дойч?). Начали tm, потом перешли на fixprice потому что заказчик менял у себя процессы в эту сторону.

Основная штука успеха - системное мышление. Чтобы оптимизировать где надо, а не где видны возможности. И работать на результат, а не локальную оптимизацию - я: это как у Голдратта.

Второе - уважение к людям. Не только к своим сотрудникам, но и к культуре заказчика.

Дамир Тенищев. Предварительная оценка и планирование Agile проектов

Менеджер больше старой школы. Знает как надо. Новые книги читал, с частью согласен, с другим ему не очень комфортно. И доклад достаточно конфронтационный с интерпретацией пионерами и экстремистами новых веяний. Интересны проекты 50-100 человеко-лет.

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

Заметки.

Доклад - первый из трех, сейчас часть - проблемы.

Фикс price. Регулярные активности всякие - помнить (говорит 12%, из зала - 30%). Поддержка старого кода (девелопер на полставке не более 100 тыс.строк). И так далее. Объем кода - нарастает постепенно, но это не видно. Трекинговые системы - но не более 20 задач на человека. Опыт: если больше - зачем-то чистят, меньше - накидывают. Хреново... Но если за первый год много налепили, то буксует - почему - потому что разработчики гибнут под кодом. Важно, чтобы с ростом числа фич объем кода рост не экспотенциально, а логарифмически - новые фичи во многом за счет старого кода. Метрика.

Он утверждает, что девелопмент сам по себе - 10% кода. Не 30, как любят писать. Но это Брукс. а не он. Хотя он говорит о своих вычислениях - интересно посмотреть. Но к заказчику он выходит. Плюс риски неопределенности, например, неточные или неопределенные требования. (По Талебу это не слишком оцениваемо). Я: На самом деле эти риски нельзя снять - неоклассический контракт.

Еще - любовь разработчиков закапываться. полировать детали. Средство борьбы - жесткий deadline. Из зала: но это не agile. Ответ: я попробую, как повернуть, но не уберу со слайда.

Баян про документацию против общения.

Периоды тишины - например, до 12 - никто не трогает. Оно разумно.

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

Станислав Калканов. В чем счастье заказчика? Готовые фичи вместо гант чарта!

Как-то докладчики от Люксофт однообразны и излагают известные вещи...

Заметки.

Известные вещи.

Попробовал уйти. Но Бевзюка не было...

Вопросы

Борис Вольфсон. Гибкая теория ограничений

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

Заметки.

Роман Юферев. И все-таки программисты - дети!

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

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

Сейчас - нет. Программисты - самостоятельны спортивны понимают цели продукта и прочее.

Что, программисты изменились? Нет, изменилось их восприятие менеджерами.

Анна Фрейд. Изучение детской психологии.

Основные отличия.

Но эта разница не слишком существенна. Итого - воспринимаем программистов как детей, которых менеджеры воспитывают.

10 заповедей для родителей. На самом деле менеджеру очень применимо. Я не переписываю - но полезно в презентации посмотреть.

TED 5 вещей, которые надо разрешить ребенку. Потрясно. Дает водить авто и работать с электоринструментами.

Доклады о новом опыте

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

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

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

Заметки.

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

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

Речь идет о продуктовой разработке и они включили в команду всю цепочку, включая маркетинг. А начали с разработчиков.

Команда 18 человек, все в одной команте: 2 аналитика (грызут нормативку) + 1 инж.психолог + 2 проект.интерфейсов + 1 граф.дизайнер + 8 разр + 2 тестера + 1 менеджер + 1 документатор + 3 продвиженца.

Что интересно, в этой конструкции нет PO - поскольку есть много источников для задач, и как-то это совместно решается.

Владимир Бахов. Непрерывная интеграция при разработке баз данных

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

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

Заметки.

Кирилл Климов. Kanban vs Scrum – чьё кунг-фу сильнее

Слушал с середины. Мое впечатление: докладчики внедрили scrum, он в силу разных особенностей получился урезанным и по этому поводу были комплексы. Поэтому теперь у них Канбан с дополнительными практиками и психологически это комфортнее. Плюс, в таком варианте им легче проявлять и объяснять различную гибкость. В докладе это было менее четко, мысль была "заменим scrum на канбан, потому что scrum жесткий и много лишнего", но меняли, скорее, название чем процесс. Доклад интересен как опыт конкретной и успешной реализации процесса с разными особенностями, тем более, что многие из них для меня, например, узнаваемы.

Заметки.

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

Слушал очень немного. Докладчик не понимает, что команда креативных лидеров загибается - они дерутся. И это экспериментально проверено Белбиным. А еще лидерство и личная отвественность - вещи разные, хотя и пересекаются.

Из заметок. Лидер Стив Джобс может сделать во всей компании agile. Лидерство идет из личной ответственности - я с этим сильно не согласен.

Юля Нечаева. Как сервисному отделу не стать бутылочным горлышком

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

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

Из позитивных практик - выявлять те тесты, где работа наиболее неустойчива и начинать с них. Например, web тестирвоать под chrome.

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

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

Заметки. Как-то они примитивно про скрам - мол в середине никто не смотрит за процессом... А как же движение по доске? И про канбан - что только одна задача в разработке. В целом по-разному оно.

Ну и дальше - no commitment, no undestanding какие-то известные штуки. Надо искать способы договоренности, всякая демократия и прочее...

Не согласие двух вариантов: без аргументов и с аргументами. Если с аргументами - обсуждаем. Если без - решаем с менеджером (Хенрик сказл бы - гнать из команды).

Всеволод Леонов. Стихийный Agile во внутрикорпоративной среде

Из embarcadero. Я квалифицировал как новый для докладчика опыт - все-таки обобщений тут нет. Довольно сумбурный доклад. Из достаточно большой кучи баек. Попытка уложить в одну канву не слишком получилась, но сами фрагменты достаточно интересны. Но там очень много негатива про внутрикорпоративную разработку: есть и правильные вещи и передергивания.

Заметки.

А в конце - реклама delphi и delphiPHP