Просмотр исходного текста страницы AgileEE-2009-Доклады (отчет Андрея Бибичева)

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

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

== [http://agileee.org/schedule/JE/ Jutta Eckstein, «Proximity Over Distance»] ==

Как уже говорилось, Ютта — автор книги «[http://www.jeckstein.com/agilebook/ Agile Software Development in the Large]».

Собственно, она рассказывала о применении Agile как раз для распределенной разработки.
Повествование было в меру скучным, в меру академичным.
Основные мысли:
* надо чаще встречаться (лицом к лицу);
* а когда не получается, то используйте все современные средства (видео для планирования и демонстрации, для Daily Scrum-ов достаточно голосовой связи);
* иногда даже рекомендуют использовать виртуальную реальность (например, митинги в SecondLife), но сама Ютта это не практикует;
* делите команды на ''Feature Team'' (вертикальная нарезка), и ни в коем случае не по специализации (тестирование в Индии, аналитики в Европе, разработчики в России — это жестокий антипаттерн);
* у каждой команды должен быть местный Product Owner, все эти «местечковые» Product Owner-ы синхронизируются и управляются одним (несколькими?) главным(и);
* весь проектный инструментарий должен быть доступен каждому в любой момент времени (поэтому платные тулы с оплатой за каждое клиентское место и/или подключение — это отстой);
* в своей практике Ютта использует [http://ru.wikipedia.org/wiki/Trac Trac].

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

<html><center>
<object id="__sse2061417" width="477" height="510"><param name="movie" value="http://static.slidesharecdn.com/swf/doc_player.swf?doc=proximityoverdistance-090924125425-phpapp01&stripped_title=proximity-over-distance-by-jutta-eckstein&userName=agileee" /><param name="allowFullScreen" value="true"/><param name="allowScriptAccess" value="always"/><embed name="__sse2061417" src="http://static.slidesharecdn.com/swf/doc_player.swf?doc=proximityoverdistance-090924125425-phpapp01&stripped_title=proximity-over-distance-by-jutta-eckstein&userName=agileee" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="477" height="510"></embed></object>
</center></html>

== [http://agileee.org/schedule/RDJDS/ Robin Dymond and Jurgen De Smet, «Cooking the Product Stew»] ==

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

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

[[Файл:Robin Dymond and Jurgen De Smet, «Cooking the Product Stew».jpg|center]]

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

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

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

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

Вопросы из зала:
* Вопрос: ''Есть ли формальные показатели улучшения производительности/качества и т. д.?''
Ответ: Нет. Формальных нет. Только соблюдение ключевых сроков и т. п.
* Вопрос: ''Сколько человек осталось недовольными изменениями?''
Ответ: Наши опросы показывают, что все довольны. Ну есть пара, которые сейчас на необитаемом острове, но остальные все довольны.

В общем, не смотря на захватывающее начало, ничего интересного узнать не удалось. Из забавного для себя отметил, что:
* проблемы в подобных больших IT-компаниях, пишущих монструозный корпоративный софт, очень похожи (см. видеозаписи встречи «[[Agile «по-крупному» (встреча AgileRussia.ru 2009-04-21)|Agile по-крупному!]]» сообщества AgileRussia);
* докладчики несколько раз допустили оговорки, исходя из которых можно заключить, что внедренный ими процесс очень напоминает именно [http://en.wikipedia.org/wiki/Feature_Driven_Development Feature-Driven Development] (FDD), а вовсе не <tt>Scrum</tt>

{{vimeoembed|7848658|640|480}}

== [http://agileee.org/schedule/JA/ Jurgen Appelo, «So Now You’re an Agilist. What’s Next?»] ==

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

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

{{slideshareembed|sonowyoureanagilist-whatsnext1-0full-090407155054-phpapp02|640|480}}

== [http://agileee.org/schedule/DP/ Денис Петелин, «Самый непонимаемый принцип в Agile Manifesto»] ==

Как вы думаете, какой это принцип? Лично я догадаться не смог, пока не прочитал [http://www.agile.by/2009/05/06/samyj-neponimaemyj-princip-v-agile-manifesto.html статью Дениса]. А вы догадались? :)

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

{{slideshareembed|agileee-petelin-agilemanifesto-091012152833-phpapp01|640|480}}

== [http://agileee.org/schedule/SS/ Сурен Самарчян, «Опыт внедрения enterprise level agile»] ==

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

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

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

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

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

{{slideshareembed|enterpriselevelagile-theartofstart-091020094556-phpapp01|640|480}}

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

== [http://agileee.org/schedule/AUNF/ Асхат Уразбаев и Никита Филиппов, «Организация самоорганизации»] ==

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

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

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

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

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

— Я просто её уговорил…
</blockquote>

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

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

{{slideshareembed|agileee-selforgfin-last-090924140605-phpapp01|640|480}}

P.S. Если вы действительно серьезно интересуетесь данными вопросами (самоорганизация, совместное принятие решений и (само)мотивация) настоятельно рекомендую прочитать следующие книги:
* [http://www.ozon.ru/context/detail/id/2285107/ «Мифы мотивации» Райнхарда Шпренгера];
* [http://www.ozon.ru/context/detail/id/2326789/ «5 пороков команды» Патрика Ленсиони].

== [http://agileee.org/schedule/BB/ Bartosz Bankowski, «Pitfalls of TDD Adoption»] ==

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

Про этот доклад хотелось бы написать много, но возьму себя в руки и ограничу перечислением основных моментов:
* в unit-тестах бывают свои «запахи» (''smells'');
* самый основной — это сценарий, тестирующий работу одного метода (или даже всю функциональность, реализованную в рамках одной итерации);
* а тесты должны называться в стиле функциональных требований: «при действии таком-то должно происходить то-то» — в этом случае unit-тесты особенно полезны и действительно начинают играть роль спецификации;
* поэтому при написании теста важно придерживаться шаблона (заучите как мантру):
 @Test
 public void '''should'''...() throws Exception() {
   // '''given'''
   ... (создание необходимого окружения)
   ...
   // '''when'''
   ... (конкретные действия с конкретными значениями параметров)
   ...
   // '''then'''
   ... (проверка правильности результата действия)
   ...
 }


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

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

{{slideshareembed|pitfallsoftddadoption-bartoszbankowski-090921044659-phpapp02|640|480}}

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

== [http://agileee.org/schedule/SF/ Szczepan Faber, «Java: tools & techniques for TDD»] ==

{{important}} Szczepan, you are the best!!!

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

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

Степа жжог нереально! По экспрессивности и эффектности подачи материала сильно напомнил мне [http://belonesox.moikrug.ru/ Стаса Фомина] (моего коллегу) и даже в чем-то превзошел его. Думаю, здесь без [http://ru.wikipedia.org/wiki/%D0%9D%D0%BE%D0%BE%D1%82%D1%80%D0%BE%D0%BF%D1%8B ноотропов] или чего-то подобного не обошлось, так как подобные энергетику, остроумие и скорость нажатия на кнопки в одном флаконе встретишь не часто. Да, вторую часть доклада Стёпка лайвкодил и делал это с невиданной мной доселе скоростью и четкостью (почти без опечаток и ошибок).

[[Файл:Szczepan Faber, «Java- tools & techniques for TDD».jpg|center]]

Что касается содержания, то это было прямое развитие предыдущего доклада сразу в двух направлениях:
# как учить (приучать?) писать правильные Unit-тесты;
# живые примеры создания тестов в реальном времени.

Второе пересказать достаточно тяжело :) Единственно, отмечу, что очень рекламировал и нахваливал библиотеку [http://code.google.com/p/fest/ FEST].

А вот несколько моментов из первого перечислить можно:
* чтобы начать писать правильные тесты, надо вначале перестать писать тесты, а вместо этого начать описывать поведение;
* обучение TDD сравнивалось с обучением восточным единоборствам;
* в частности, муссировался принцип [http://cgm.computergraphics.ru/content/view/14 Shu-Ha-Ri] (что русскоговорящая часть аудитории тут же прочитала как «су-ха-ри» :)) — только на стадии ''Ri'' становятся настоящими практиками, а до этого приходится пройти через трудные (и зачастую долгие) ''Shu'', то есть начальное обучение, и ''Ha'', то есть применение в боевых условиях того, чему научили;
* опять же говорилось о полезности шаблона для тестового метода (''should… given … when … then …''), а его эффективность объяснялась при помощи гипотезы [http://ru.wikipedia.org/wiki/%D0%93%D0%B8%D0%BF%D0%BE%D1%82%D0%B5%D0%B7%D0%B0_%D0%A1%D0%B5%D0%BF%D0%B8%D1%80%D0%B0_%E2%80%94_%D0%A3%D0%BE%D1%80%D1%84%D0%B0 лингвистической относительности] (aka гипотеза Сепира-Уорфа), согласно которой структура языка определяет мышление.

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

{{slideshareembed|agileee-toolstechniquesfortdd-final-090924132300-phpapp01|640|480}}

== [http://agileee.org/schedule/JBR/ J.B. Rainsberger, «An Introduction to Agile Through the Theory of Constraints»] ==

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

[[Файл:Rainsberger, «An Introduction to Agile Through the Theory of Constraints».jpg|center]]

<div> Во-вторых, пару месяцев назад у нас в компании проходил открытый семинар «[[«Управление производством на основании численных данных» и «Теория ограничений и линейное программирование» (2009-08-03)|Управление производством на основании численных данных» и «Теория ограничений и линейное программирование]]», на котором как раз обсуждались подобные вопросы. 

Для тех, кто не в курсе: 
* [http://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B8%D1%8F_%D0%BE%D0%B3%D1%80%D0%B0%D0%BD%D0%B8%D1%87%D0%B5%D0%BD%D0%B8%D0%B9 Теория ограничений] = [http://en.wikipedia.org/wiki/Theory_of_Constraints Theory Of Constraints] = TOC
* разработана вначале 80-ых годов прошлого века доктором [http://www.koob.ru/goldratt_e/ Элияху (aka Элия) Голдраттом] (см. также [http://en.wikipedia.org/wiki/Eliyahu_M._Goldratt Eliyahu M. Goldratt])
* настоятельно рекомендую прочитать его книги, в особенности следующие две (по ссылкам можно скачать электронные версии на русском языке):

** [http://www.koob.ru/goldratt_e/kritich_cep Критическая цепь]
** [http://www.koob.ru/goldratt_e/process_sovershenstvovaniya Цель]

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

== [http://agileee.org/schedule/JG/ Janet Gregory, «Seven Key Success Factors for Agile Testing Success»] ==

<div> Обе женщины-докладчицы на конференции оказались авторами книг. Джанет в соавторстве с Лизой Криспин написала «[http://www.amazon.co.uk/Agile-Testing-Practical-Addison-Wesley-Signature/dp/0321534468 Agile Testing: A Practical Guide for Testers and Agile Teams]». «Сам книгу не читал»©, но видел на просторах сети вполне позитивные отзывы. 

Джанет прилетела аж из Канады. Видимо, чтобы ROI от такой дальней дороги был повыше, ей выделили не час времени, как всем остальным, а целых два. Лично я с трудом выдержал только час и с большим удовольствием слинял на доклад Артема Марченко (см. ниже). Почему с трудом? Джанет рассказывала очень медленно и плавно, несколько приглушенным голосом. «[http://absurdopedia.wikia.com/wiki/%D0%93%D0%B8%D0%BF%D0%BD%D0%BE%D0%B6%D0%B0%D0%B1%D0%B0 Гипножаба]» постоянно крутилось у меня в голове, пока я отчаянно боролся с накатывающей невыносимой сонливостью. 

Что касается содержания, то оно у меня настойчиво ассоциируется с прописными истинами из серии «Хорошо быть здоровым! Хорошо быть счастливым!» и «Твори добро на всей земле»… Например: 
* ''Trust ''— это очень важно, обязательно создавайте в команде ''Trust'';
* автоматизация тестирования — это очень правильно, обязательно автоматизируйте всё, что только можете;
* надо постоянно совершенствоваться и развиваться, читать книги и быть проактивными;
* и т. д. и т. п.

Судите сами: 

{{slideshareembed|agileee-gregory-sevenkeyfactors-091012163558-phpapp02|640|480}}

== [http://agileee.org/schedule/AM/ Artem Marchenko, «Agile Planning»] ==

Артем — уроженец Украины, давным-давно перебравшийся в Финляндию, где работает ''Product Owner''-ом в компании Nokia:
* программное обеспечение для новых моделей смартфонов;
* 20 человек, разбитых на три команды.

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

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

{{slideshareembed|agileee-marchenko-agileplanning-091012164427-phpapp01|640|480}}

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

[[Файл:Agile Planning-Снеговик.jpg|center]]


Артем эту картинку не приводил, но тоже говорил о различиях. Например:
* при планировании версии хорошо работает оценка в ''Story Point''-ах при известной ''Velocity'';
* при планировании же итерации лучше использовать ''Commitment-driven'' планирование:

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

== [http://agileee.org/schedule/MPDH/ David Hussman, «Agile Journeys: How Did We Get Here and Where are We Going?»] ==

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

[[Файл:David Hussman, «Agile Journeys- How Did We Get Here and Where are We Going».jpg|center]]

Его рассказ был достаточно пространный. Отдельные моменты:
* конференция AgileEE Дэвиду понравилась больше, чем Agile-2009, прошедшая месяцем ранее в Чикаго;
* Agile-сообщество развивается за счет того, что каждый рассказывает свою историю;
* сильно рекламировал книги Алана Купера (и его товарищей): «[[Психбольница в руках пациентов]]» и «[[Алан Купер об интерфейсе. Основы проектирования взаимодействия]]» (по ссылкам — ''наши'' рецензии);
* применение персонажей и ''User Stories'' — это очень кульно;
* только ''User Stories'' получаются слишком мелкими, поэтому умные люди сообразили их укрупнять в целые блоки, связанные одной «темой»;
* такие блоки назвали «Эпосами» (''Epic'');
* когда у зала Дэвид спросил: «С чем у вас ассоциируется слово EPIC» — кто-то выкрикнул: «FAIL» ''— я полностью поддерживаю [http://lurkmore.ru/Fail такую ассоциацию] :)''
* нынче в моде [http://ru.wikipedia.org/wiki/%D0%91%D0%B5%D1%80%D0%B5%D0%B6%D0%BB%D0%B8%D0%B2%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B8%D0%B7%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE Lean]!
* также PR-ил новомодную технику для персонального time-менеджмента — [http://www.pomodorotechnique.com/ Pomodoro] (по указанному адресу можно бесплатно скачать PDF-книжку);
* даже передал в зал один «помидорчик» (кухонный таймер в виде красного пластмассового помидора, у которого верхняя половинка поворачивается относительно нижней и начинает тикать, как бомба).

<html><center>
<object id="__sse2029404" width="477" height="510"><param name="movie" value="http://static.slidesharecdn.com/swf/doc_player.swf?doc=agilejourneys-090921045802-phpapp02&stripped_title=agile-journeys-by-david-hussman-2029404&userName=agileee" /><param name="allowFullScreen" value="true"/><param name="allowScriptAccess" value="always"/><embed name="__sse2029404" src="http://static.slidesharecdn.com/swf/doc_player.swf?doc=agilejourneys-090921045802-phpapp02&stripped_title=agile-journeys-by-david-hussman-2029404&userName=agileee" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="477" height="510"></embed></object>
</center></html>

{{replicate-from-custiswiki-to-lib}}
[[Категория:AgileEasternEurope-2009]]