AgileEE-2009-Доклады (отчет Андрея Бибичева) — различия между версиями

Текущая версия на 22:23, 28 декабря 2010

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

Итак, доклады.

Jutta Eckstein, «Proximity Over Distance»

Как уже говорилось, Ютта — автор книги «Agile Software Development in the Large».

Собственно, она рассказывала о применении Agile как раз для распределенной разработки. Повествование было в меру скучным, в меру академичным. Основные мысли:

• надо чаще встречаться (лицом к лицу);
• а когда не получается, то используйте все современные средства (видео для планирования и демонстрации, для Daily Scrum-ов достаточно голосовой связи);
• иногда даже рекомендуют использовать виртуальную реальность (например, митинги в SecondLife), но сама Ютта это не практикует;
• делите команды на Feature Team (вертикальная нарезка), и ни в коем случае не по специализации (тестирование в Индии, аналитики в Европе, разработчики в России — это жестокий антипаттерн);
• у каждой команды должен быть местный Product Owner, все эти «местечковые» Product Owner-ы синхронизируются и управляются одним (несколькими?) главным(и);
• весь проектный инструментарий должен быть доступен каждому в любой момент времени (поэтому платные тулы с оплатой за каждое клиентское место и/или подключение — это отстой);
• в своей практике Ютта использует Trac.

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

Robin Dymond and Jurgen De Smet, «Cooking the Product Stew»

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

Если будет опубликованная видеозапись — смотреть обязательно! Несколько фотографий:

Выдержка из «истории болезни»:

• 12 лет легаси-кода (его, естественно, олицетворяли спагетти);
• одна единая База Данных (курица, за которой пришлось сходить за кулисы, так как её держат специальные люди — админы — и никому не дают);
• один собственный язык программирования (его тоже что-то олицетворяло — не запомнил);
• одна команда продавцов, которая никак не отвечает за свои обещания;
• 12 аналитиков, которые пытаются сформировать четкое представление о продукте, который нужен;
• 1 PMO, который в одиночестве описывает все use case-ы (их высыпали в кастрюли в виде кучи маленьких разноцветных бумажек);
• 26 команд по всей Европе (5 офисов);
• 460 разработчиков.

И всё это приправлено секретным соусом — собственным супер-секретным процессом разработки. Кастрюлю со всем этим «блюдом» показательно выплеснули в зал. Первые ряды даже успели испугаться (курица, какая-то красная жидкость — бррр). Однако, это был фокус: кастрюлю успели незаметно подменить и в зал посыпались только разноцветные бумажки.

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

• поделить всю разработку на Feature Team-ы;
• общий единый на всю компанию Backlog (ведь всего один монструозный продукт);
• оценка трудоемкости самими командами;
• известная Velocity для каждой команды;
• оценка риска по каждому элементу Backlog-а, наиболее рисковые элементы — наверх;
• единая версия продукта (минимизация кастомизации под разных крупных клиентов за счет переговоров с ними и сведения функциональности к общей);
• измерение прогресса: синхронизированные по всей компании демонстрации (и всё!);
• и обязательно нужно использовать Continuous Integration (CI): сборка в один клик, для всех конфигураций, для инсталляции с 0-ля и upgrade-а с предыдущей версии.

Последнее показалось уж как-то совсем мелким и очевидным…

Вопросы из зала:

• Вопрос: Есть ли формальные показатели улучшения производительности/качества и т. д.?

Ответ: Нет. Формальных нет. Только соблюдение ключевых сроков и т. п.

• Вопрос: Сколько человек осталось недовольными изменениями?

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

В общем, не смотря на захватывающее начало, ничего интересного узнать не удалось. Из забавного для себя отметил, что:

• проблемы в подобных больших IT-компаниях, пишущих монструозный корпоративный софт, очень похожи (см. видеозаписи встречи «Agile по-крупному!» сообщества AgileRussia);
• докладчики несколько раз допустили оговорки, исходя из которых можно заключить, что внедренный ими процесс очень напоминает именно Feature-Driven Development (FDD), а вовсе не Scrum

Jurgen Appelo, «So Now You’re an Agilist. What’s Next?»

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

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

Денис Петелин, «Самый непонимаемый принцип в Agile Manifesto»

Как вы думаете, какой это принцип? Лично я догадаться не смог, пока не прочитал статью Дениса. А вы догадались? :)

На доклад Дениса попасть не смог, а коллеги отзывались позитивно: «есть над чем подумать и что переосмыслить». Смотрим слайды (хотя статья не менее информативна):

Сурен Самарчян, «Опыт внедрения enterprise level agile»

Очень интересный доклад о том, как многие Agile-практики работают на уровне top-менеджмента и помогают в управлении и преобразовании компании в целом. Эту тему я впервые услышал весной этого года. Дело было на AgileCoachCamp, который прошел в Москве. Услышал, конечно же, от Сурена. Почему «конечно же»?

Да потому, что нет на просторах СНГ больше людей с подобным опытом. Так вот, еще тогда весной я очень зажегся этой идеей. Мне показалось, что именно это (enterprise level agile) будет весьма полезно в CustIS. Для меня это больная тема: не раз попадал (и продолжаю попадать) в передряги из-за того, что на уровне высшего руководства нет единого согласованного мнения по массе вопросов, а каждый top-менеджер склонен отстаивать свои интересы (зачастую в ущерб интересам Компании в целом).

Факты, которые произвели на меня самое сильное впечатление:

• за полтора года радикальным образом удалось преобразить компанию, которая наняла Сурена;
• очень сильно не хватает грамотных PM-ов, но, не смотря на это, планку очень высоких требований на входе не опустили: за год отсобеседовали более 300 кандидатов, взяли всего трех, при этом один не прижился;
  • например, даже у нас, где весьма аккуратно и тщательно подходят к подбору персонала, особо горячие вакансии стараются всё же закрыть побыстрее (ес-но, жертвуя уровнем)
• по мнению Сурена, для успешного управления необходимо знать много дисциплин, включая НЛП;
• Сурену всего 26 лет…

После доклада, уже в «кулуарах», я поинтересовался: «Сурен, а что будет с компанией, когда ты из неё уйдешь?». Ничего не ответила золотая рыбка, только махнула хвостом и уплыла в синее море. Это так я воспринял уклончивый ответ с улыбкой: «Всё будет хорошо…».

Во время презентации по экрану прикольно летали буковки, что кого-то забавляло, а кого-то нервировало. Вся эта анимация потерялась при загрузке на SlideShare, что, надеюсь, не помешает (а, может, даже и поможет) насладиться содержанием:

Примечание: материал опубликован из-под моей «учетки» с личного разрешения Сурена.

Асхат Уразбаев и Никита Филиппов, «Организация самоорганизации»

Асхата и Никиту я тоже знаю достаточно хорошо. Но всё же напишу свое мнение максимально откровенно: лично мне доклад не очень понравился, показавшись поверхностным и местами даже циничным. Тема сложная и важная и негоже её столь сильно упрощать и уплощать (ИМХО). В какой-то момент (в опубликованной презентации я этого слайда не нашел…) я даже не выдержал и вступил в дискуссию. Она кончилась ничем — каждый остался при своем.

В тему той дискуссии хочу рассказать известный анекдот:

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

— Представляете, я вчера вечером девушку спас от изнасилования!

— Ну, ты герой! Молодца! Как это было? Рассказывай скорей!

— Я просто её уговорил…

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

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

P.S. Если вы действительно серьезно интересуетесь данными вопросами (самоорганизация, совместное принятие решений и (само)мотивация) настоятельно рекомендую прочитать следующие книги:

• «Мифы мотивации» Райнхарда Шпренгера;
• «5 пороков команды» Патрика Ленсиони.

Bartosz Bankowski, «Pitfalls of TDD Adoption»

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

Про этот доклад хотелось бы написать много, но возьму себя в руки и ограничу перечислением основных моментов:

• в unit-тестах бывают свои «запахи» (smells);
• самый основной — это сценарий, тестирующий работу одного метода (или даже всю функциональность, реализованную в рамках одной итерации);
• а тесты должны называться в стиле функциональных требований: «при действии таком-то должно происходить то-то» — в этом случае unit-тесты особенно полезны и действительно начинают играть роль спецификации;
• поэтому при написании теста важно придерживаться шаблона (заучите как мантру):

@Test
public void should...() throws Exception() {
  // given
  ... (создание необходимого окружения)
  ...
  // when
  ... (конкретные действия с конкретными значениями параметров)
  ...
  // then
  ... (проверка правильности результата действия)
  ...
}

• длинные SetUp методы — зло; вместо этого следует создавать вспомогательные классы-builder-ы и при помощи них создавать и конфигурировать необходимое окружение в каждом тесте;
• кроме того, builder-ы сильно помогают для упрощения логики самих тестов, делают тела тестов более читаемыми (очищают от «шума»);
• умеренное дублирование кода в тестах — вовсе не зло, так как важнее, чтобы тесты легко читались и воспринимались;
• используйте кастомные assert-ы и вспомогательные библиотеки, чтобы ваши проверки выглядели лаконично и понятно (в особенности это касается работы с коллекциями и словарями);
• тесты должны быть воспроизводимыми, поэтому всячески следует избегать зависимости от случайных чисел, текущего времени и т. д.

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

Обращаю внимание, что на последнем слайде есть важные «ссылки» из серии Must Read для тех, кому по долгу службы приходится писать/читать/ревьювить unit-тесты.

Szczepan Faber, «Java: tools & techniques for TDD»

Szczepan, you are the best!!!

Это действительно был лучший доклад (на мой предвзятый вкус).

Степан является не только автором данного доклада, но и основным автором достаточно распространенной open-source библиотеки для создания mock-объектов — mockito.

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

Что касается содержания, то это было прямое развитие предыдущего доклада сразу в двух направлениях:

1. как учить (приучать?) писать правильные Unit-тесты;
2. живые примеры создания тестов в реальном времени.

Второе пересказать достаточно тяжело :) Единственно, отмечу, что очень рекламировал и нахваливал библиотеку FEST.

А вот несколько моментов из первого перечислить можно:

• чтобы начать писать правильные тесты, надо вначале перестать писать тесты, а вместо этого начать описывать поведение;
• обучение TDD сравнивалось с обучением восточным единоборствам;
• в частности, муссировался принцип Shu-Ha-Ri (что русскоговорящая часть аудитории тут же прочитала как «су-ха-ри» :)) — только на стадии Ri становятся настоящими практиками, а до этого приходится пройти через трудные (и зачастую долгие) Shu, то есть начальное обучение, и Ha, то есть применение в боевых условиях того, чему научили;
• опять же говорилось о полезности шаблона для тестового метода (should… given … when … then …), а его эффективность объяснялась при помощи гипотезы лингвистической относительности (aka гипотеза Сепира-Уорфа), согласно которой структура языка определяет мышление.

И было много шуток. Уместных шуток. Например: mock-объект — это как резиновая женщина (подменяет реальный объект, воспроизводя важные для тестового сценария характеристики).

J.B. Rainsberger, «An Introduction to Agile Through the Theory of Constraints»

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

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

Для тех, кто не в курсе:

• Теория ограничений = Theory Of Constraints = TOC
• разработана вначале 80-ых годов прошлого века доктором Элияху (aka Элия) Голдраттом (см. также Eliyahu M. Goldratt)
• настоятельно рекомендую прочитать его книги, в особенности следующие две (по ссылкам можно скачать электронные версии на русском языке):

• • Критическая цепь
  • Цель

У меня даже жена зачиталась — так здорово раскрыта сюжетная линия, касающаяся драматизма в личной жизни главных героев. Поверьте, по уровню эти книги на несколько порядков превосходят нынче столь популярных Тома ДеМарко и Патрика Ленсиони. Так что это будет не только полезное, но и весьма приятное и захватывающее чтение.

Janet Gregory, «Seven Key Success Factors for Agile Testing Success»

Обе женщины-докладчицы на конференции оказались авторами книг. Джанет в соавторстве с Лизой Криспин написала «Agile Testing: A Practical Guide for Testers and Agile Teams». «Сам книгу не читал»©, но видел на просторах сети вполне позитивные отзывы.

Джанет прилетела аж из Канады. Видимо, чтобы ROI от такой дальней дороги был повыше, ей выделили не час времени, как всем остальным, а целых два. Лично я с трудом выдержал только час и с большим удовольствием слинял на доклад Артема Марченко (см. ниже). Почему с трудом? Джанет рассказывала очень медленно и плавно, несколько приглушенным голосом. «Гипножаба» постоянно крутилось у меня в голове, пока я отчаянно боролся с накатывающей невыносимой сонливостью.

Что касается содержания, то оно у меня настойчиво ассоциируется с прописными истинами из серии «Хорошо быть здоровым! Хорошо быть счастливым!» и «Твори добро на всей земле»… Например:

• Trust — это очень важно, обязательно создавайте в команде Trust;
• автоматизация тестирования — это очень правильно, обязательно автоматизируйте всё, что только можете;
• надо постоянно совершенствоваться и развиваться, читать книги и быть проактивными;
• и т. д. и т. п.

Судите сами:

Artem Marchenko, «Agile Planning»

Артем — уроженец Украины, давным-давно перебравшийся в Финляндию, где работает Product Owner-ом в компании Nokia:

• программное обеспечение для новых моделей смартфонов;
• 20 человек, разбитых на три команды.

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

По содержанию: очень качественный доклад ровно по теме. Уверен, что в Nokia именно так всё и работает. Пересказывать что-либо не нужно, так как слайды очень информативные:

На тему различного планирования (нужно отличать планирование версии от планирования итерации и т. п.) мне очень нравится концепция снеговика:

Артем эту картинку не приводил, но тоже говорил о различиях. Например:

• при планировании версии хорошо работает оценка в Story Point-ах при известной Velocity;
• при планировании же итерации лучше использовать Commitment-driven планирование:

• • разбить каждый Backlog Item (story) на Task-и;
  • каждый Task оценить в днях/часах;
  • посмотреть, сможем ли мы сделать с учетом доступных ресурсов и их специализации (на практике-то она встречается!).

David Hussman, «Agile Journeys: How Did We Get Here and Where are We Going?»

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

Его рассказ был достаточно пространный. Отдельные моменты:

• конференция AgileEE Дэвиду понравилась больше, чем Agile-2009, прошедшая месяцем ранее в Чикаго;
• Agile-сообщество развивается за счет того, что каждый рассказывает свою историю;
• сильно рекламировал книги Алана Купера (и его товарищей): «Психбольница в руках пациентов» и «Алан Купер об интерфейсе. Основы проектирования взаимодействия» (по ссылкам — наши рецензии);
• применение персонажей и User Stories — это очень кульно;
• только User Stories получаются слишком мелкими, поэтому умные люди сообразили их укрупнять в целые блоки, связанные одной «темой»;
• такие блоки назвали «Эпосами» (Epic);
• когда у зала Дэвид спросил: «С чем у вас ассоциируется слово EPIC» — кто-то выкрикнул: «FAIL» — я полностью поддерживаю такую ассоциацию :)
• нынче в моде Lean!
• также PR-ил новомодную технику для персонального time-менеджмента — Pomodoro (по указанному адресу можно бесплатно скачать PDF-книжку);
• даже передал в зал один «помидорчик» (кухонный таймер в виде красного пластмассового помидора, у которого верхняя половинка поворачивается относительно нижней и начинает тикать, как бомба).

---

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

Репликация: База Знаний «Заказных Информ Систем» → «AgileEE-2009-Доклады (отчет Андрея Бибичева)»