|
Персональные инструменты |
|||
|
AgileEE-2009-Доклады (отчет Андрея Бибичева)Материал из CustisWikiЭто снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений. В качестве основной темы конференции была заявлена «распределенная Agile разработка». По факту же большинство докладов было посвящено самоорганизации, кроссфункциональности и (само)мотивации. Это и не удивительно — именно с этим возникают основные проблемы при внедрении и следовании дзену Agile. Итак, доклады. Содержание
Jutta Eckstein, «Proximity Over Distance»Как уже говорилось, Ютта — автор книги «Agile Software Development in the Large». Собственно, она рассказывала о применении Agile как раз для распределенной разработки. Повествование было в меру скучным, в меру академичным. Основные мысли:
Заключительная часть доклада касалась «культурных различий». Здесь Ютта эффектно сорвала овации, предложив концентрироваться на схожести, а не разнице, тонко подметив, что зачастую дизайнер UI и разработчик отличаются друг от друга значительно больше, чем, скажем, Китаец от Корейца (а вы их, вообще, отличаете? :-)). Robin Dymond and Jurgen De Smet, «Cooking the Product Stew»Свой доклад Робин и Юрген начали как настоящее шоу — это надо было видеть! Одевшись поварами, ребята разыграли забавную сценку, в которой наглядно, хоть и иносказательно, описали некую большую софтверную компанию, в которую им довелось внедрять Agile (у этой компании один основной монструозный продукт). Если будет опубликованная видеозапись — смотреть обязательно! Несколько фотографий: Выдержка из «истории болезни»:
И всё это приправлено секретным соусом — собственным супер-секретным процессом разработки. Кастрюлю со всем этим «блюдом» показательно выплеснули в зал. Первые ряды даже успели испугаться (курица, какая-то красная жидкость — бррр). Однако, это был фокус: кастрюлю успели незаметно подменить и в зал посыпались только разноцветные бумажки. После такого захватывающего начала ожидалось столь же внушительное конструктивное предложение: что же с этим удалось сделать, к каким хитростям и know-how прибегнуть, сколько граблей оттоптать. Но дальше ничего волшебного, к великому сожалению, не было:
Последнее показалось уж как-то совсем мелким и очевидным… Вопросы из зала:
Ответ: Нет. Формальных нет. Только соблюдение ключевых сроков и т. п.
Ответ: Наши опросы показывают, что все довольны. Ну есть пара, которые сейчас на необитаемом острове, но остальные все довольны. В общем, не смотря на захватывающее начало, ничего интересного узнать не удалось. Из забавного для себя отметил, что:
Видео в HD-качестве, смотрите в полноэкранном режиме. HTML-код включения <iframe src="http://player.vimeo.com/video/7848658?byline=0&portrait=0" width="640" height="480" frameborder="0"></iframe> Jurgen Appelo, «So Now You’re an Agilist. What’s Next?»На этот доклад я пошел по рекомендации Сурена Самарчяна. И действительно оказался очень хороший качественный доклад, который было приятно слушать. Узнал ли я при этом что-то новое? Скорее, нет. Вынес ли я при этом для себя что-то полезное? Пожалуй, тоже нет. Подтвердились ли в этом докладе мои личные ощущения, соображения, представления? Вот здесь однозначно да. Делать какой-либо пересказ подобных докладов — дело весьма неблагодарное. Это как раз тот случай, когда важно присутствовать лично и наслаждаться происходящим. Скажу только, что основная тема — это применение теории сложности к процессу разработки ПО. Полистайте слайды (их больше сотни — как я люблю!):
Денис Петелин, «Самый непонимаемый принцип в Agile Manifesto»Как вы думаете, какой это принцип? Лично я догадаться не смог, пока не прочитал статью Дениса. А вы догадались? :) На доклад Дениса попасть не смог, а коллеги отзывались позитивно: «есть над чем подумать и что переосмыслить». Смотрим слайды (хотя статья не менее информативна):
Сурен Самарчян, «Опыт внедрения enterprise level agile»Очень интересный доклад о том, как многие Agile-практики работают на уровне top-менеджмента и помогают в управлении и преобразовании компании в целом. Эту тему я впервые услышал весной этого года. Дело было на AgileCoachCamp, который прошел в Москве. Услышал, конечно же, от Сурена. Почему «конечно же»? Да потому, что нет на просторах СНГ больше людей с подобным опытом. Так вот, еще тогда весной я очень зажегся этой идеей. Мне показалось, что именно это (enterprise level agile) будет весьма полезно в CustIS. Для меня это больная тема: не раз попадал (и продолжаю попадать) в передряги из-за того, что на уровне высшего руководства нет единого согласованного мнения по массе вопросов, а каждый top-менеджер склонен отстаивать свои интересы (зачастую в ущерб интересам Компании в целом). Факты, которые произвели на меня самое сильное впечатление:
После доклада, уже в «кулуарах», я поинтересовался: «Сурен, а что будет с компанией, когда ты из неё уйдешь?». Ничего не ответила золотая рыбка, только махнула хвостом и уплыла в синее море. Это так я воспринял уклончивый ответ с улыбкой: «Всё будет хорошо…». Во время презентации по экрану прикольно летали буковки, что кого-то забавляло, а кого-то нервировало. Вся эта анимация потерялась при загрузке на SlideShare, что, надеюсь, не помешает (а, может, даже и поможет) насладиться содержанием:
Примечание: материал опубликован из-под моей «учетки» с личного разрешения Сурена. Асхат Уразбаев и Никита Филиппов, «Организация самоорганизации»Асхата и Никиту я тоже знаю достаточно хорошо. Но всё же напишу свое мнение максимально откровенно: лично мне доклад не очень понравился, показавшись поверхностным и местами даже циничным. Тема сложная и важная и негоже её столь сильно упрощать и уплощать (ИМХО). В какой-то момент (в опубликованной презентации я этого слайда не нашел…) я даже не выдержал и вступил в дискуссию. Она кончилась ничем — каждый остался при своем. В тему той дискуссии хочу рассказать известный анекдот:
Так вот, при принятии решений, даже на уровне top-менеджмента, важно спасать людей от изнасилования, то есть хотя бы уговаривать (если уж не получается убедить). Стоит отметить, что слушателей пришло даже больше, чем мог вместить зал — стояли в дверях. После презентации от вопросов отбоя не было, так что и Асхата, и Никиту окружила туча страждущих пообщаться. Посему, стоит ли вам (читателям этого поста) принимать во внимание мое скромное мнение — не знаю, то есть решайте сами :)
P.S. Если вы действительно серьезно интересуетесь данными вопросами (самоорганизация, совместное принятие решений и (само)мотивация) настоятельно рекомендую прочитать следующие книги: Bartosz Bankowski, «Pitfalls of TDD Adoption»Обожаю доклады на технические темы. В особенности, дающие действительно полезные практические советы и ссылки для самостоятельного изучения. Это именно такой случай. Очень в жилу: сильно резонирует с теми проблемами, которые встречаются в нашей практике. Про этот доклад хотелось бы написать много, но возьму себя в руки и ограничу перечислением основных моментов:
@Test public void should...() throws Exception() { // given ... (создание необходимого окружения) ... // when ... (конкретные действия с конкретными значениями параметров) ... // then ... (проверка правильности результата действия) ... }
Вокруг последнего разгорелась живая дискуссия. Я так понял, что некоторые специально используют в тестах датчики случайных чисел, чтобы проверить работу алгоритма в некоторой случайной точке пространства входных данных — типа, так сложнее написать имплементацию, которая просто обманывает тест, подстраиваясь под конкретные условия и проверки. Я же полностью согласен с автором доклада: случайные данные в тестах очень опасны, так как конкретные условия получаются невоспроизводимыми (если только их не журналировать специальным образом), а значит непонятно, как отлаживать тест в случае его ошибки.
Обращаю внимание, что на последнем слайде есть важные «ссылки» из серии Must Read для тех, кому по долгу службы приходится писать/читать/ревьювить unit-тесты. Szczepan Faber, «Java: tools & techniques for TDD»Szczepan, you are the best!!! Это действительно был лучший доклад (на мой предвзятый вкус). Степан является не только автором данного доклада, но и основным автором достаточно распространенной open-source библиотеки для создания mock-объектов — mockito. Степа жжог нереально! По экспрессивности и эффектности подачи материала сильно напомнил мне Стаса Фомина (моего коллегу) и даже в чем-то превзошел его. Думаю, здесь без ноотропов или чего-то подобного не обошлось, так как подобные энергетику, остроумие и скорость нажатия на кнопки в одном флаконе встретишь не часто. Да, вторую часть доклада Стёпка лайвкодил и делал это с невиданной мной доселе скоростью и четкостью (почти без опечаток и ошибок). Что касается содержания, то это было прямое развитие предыдущего доклада сразу в двух направлениях:
Второе пересказать достаточно тяжело :) Единственно, отмечу, что очень рекламировал и нахваливал библиотеку FEST. А вот несколько моментов из первого перечислить можно:
И было много шуток. Уместных шуток. Например: mock-объект — это как резиновая женщина (подменяет реальный объект, воспроизводя важные для тестового сценария характеристики).
J.B. Rainsberger, «An Introduction to Agile Through the Theory of Constraints»Этот доклад особо примечателен по двум причинам. Во-первых, у JB накануне сгорел винчестер в ноутбуке — соответственно, презентация безвозвратно потерялась. Так что докладчик взял планшетный ПК и прямо по ходу презентации рисовал пером по экрану планшета, а слушатели разглядывали эти письмена на экране проектора. Вот один из художественных слайдов, родившихся по ходу выступления: Во-вторых, пару месяцев назад у нас в компании проходил открытый семинар «Управление производством на основании численных данных» и «Теория ограничений и линейное программирование», на котором как раз обсуждались подобные вопросы.
Для тех, кто не в курсе:
У меня даже жена зачиталась — так здорово раскрыта сюжетная линия, касающаяся драматизма в личной жизни главных героев. Поверьте, по уровню эти книги на несколько порядков превосходят нынче столь популярных Тома ДеМарко и Патрика Ленсиони. Так что это будет не только полезное, но и весьма приятное и захватывающее чтение. Janet Gregory, «Seven Key Success Factors for Agile Testing Success» Обе женщины-докладчицы на конференции оказались авторами книг. Джанет в соавторстве с Лизой Криспин написала «Agile Testing: A Practical Guide for Testers and Agile Teams». «Сам книгу не читал»©, но видел на просторах сети вполне позитивные отзывы.
Джанет прилетела аж из Канады. Видимо, чтобы ROI от такой дальней дороги был повыше, ей выделили не час времени, как всем остальным, а целых два. Лично я с трудом выдержал только час и с большим удовольствием слинял на доклад Артема Марченко (см. ниже). Почему с трудом? Джанет рассказывала очень медленно и плавно, несколько приглушенным голосом. «Гипножаба» постоянно крутилось у меня в голове, пока я отчаянно боролся с накатывающей невыносимой сонливостью. Что касается содержания, то оно у меня настойчиво ассоциируется с прописными истинами из серии «Хорошо быть здоровым! Хорошо быть счастливым!» и «Твори добро на всей земле»… Например:
Судите сами:
Artem Marchenko, «Agile Planning»Артем — уроженец Украины, давным-давно перебравшийся в Финляндию, где работает Product Owner-ом в компании Nokia:
Из забавного: рассказ велся на английском (как и положено для первой секции), вопросы из зала задавали тоже на английском, ломая себе язык и мозг остальным, хотя все вопросы были от русскоговорящих. Видимо, никто не решился проверить: забыл ли докладчик родной язык или нет :) По содержанию: очень качественный доклад ровно по теме. Уверен, что в Nokia именно так всё и работает. Пересказывать что-либо не нужно, так как слайды очень информативные:
На тему различного планирования (нужно отличать планирование версии от планирования итерации и т. п.) мне очень нравится концепция снеговика:
David Hussman, «Agile Journeys: How Did We Get Here and Where are We Going?»Дэвид выступал на закрытии. Как и полагается бывшему рок-музыканту, выглядел очень харизматично: длинные волосы, шлепки на босу ногу и т. п. Его рассказ был достаточно пространный. Отдельные моменты:
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
|
||