Просмотр исходного текста страницы AgileDays-2011 — краткая классификация докладов

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

Такой, несколько субъективный путеводитель, я и предложу ниже.
Почти<ref>От нескольких докладов видео не сохранилось, я их не смог посмотреть и поэтому не включил в эту классификацию. Но их можно найти в [[:Категория:AgileDays-2011 (наша запись)|категории]], посмотреть слайды или отзывы</ref> все доклады классифицированы, плюс краткая, в twitter-стиле аннотация.
Кстати, свои впечатления о докладах я составил только по просмотру видео, ибо на самой конференции был так загружен оргвопросами, что не был почти ни на одном докладе.

==== Getting Started ====
В этом блоке я собрал вводно-обучающие доклады, впрочем, уровень был не вполне детский, так что даже если вы слышали об Agile/Lean/TOC, посмотреть вполне будет полезно.

* «[[Для тех, кто в танке — что такое Agile (Асхат Уразбаев, AgileDays-2011)|Для тех, кто в танке — что такое Agile]]» был задуман, как быстрый ликбез для новых в Agile людей, и как альтернатива открывающему докладу Henrik-а Kniberga. Программный Комитет думал, что те, кто «в теме» обязательно пойдут на «гуру», а оставшихся надо «вводить в тему». Однако неожиданно на доклад набился полный зал народу, из которых «не в теме» было всего человека три, так что ликбез получился вполне глубоким, не стыдно посмотреть, даже если вы практик. Можете рекомендовать тем, кого бы вы хотели заинтересовать Agile-ценностями — новым сотрудникам, старым менеджерам и молодым HR-шам…
* «[[Lean Software Development (Никита Филиппов, AgileDays-2011)|Lean Software Development]]» и «[[Применение принципов Lean в масштабах предприятия (Асхат Уразбаев, AgileDays-2011)|Применение принципов Lean в масштабах предприятия]]» лучше смотреть блоком и в такой последовательности — это введение в новомодную<ref>Новомодное конечно у нас. В мире это уже классика.</ref> производственную культуру «[[RuPedia:Бережливое производство|бережливого производства]]», в приложении к разработке софта. В некоторым смысле, Agile — это частный случай реализации более глобального подхода LEAN, c которым можно замахиваться на такие задачи, как реформирование и оптимизация всей компании (а не просто внедрение Agile в одном из подразделений).
* «[[Гибкая теория ограничений (Борис Вольфсон, AgileDays-2011)|Гибкая теория ограничений]]» — обзорный рассказ об «[[EnPedia:Theory_of_Constraints|Теории ограничений]]», еще одной философии менеджмента, в некотором смысле дополнительной к LEAN.

==== Менеджерское ====

===== Процесс =====

* «[[Что означает «Готово!» — применение практики Definition of Done (Николай Алименков, Алексей Солнцев, AgileDays-2011)|Что означает «Готово!» — применение практики Definition of Done]]» — почему DoD должен быть? Потому, что только за счет таких жестких элементов и можно строить гибкие процессы. Без введения бинарности состояний задач бессмысленно считать любые метрики («100 задач готовы на 99%»), что-то оценивать, прогнозировать и корректировать. «Если у вас нет DoD — то у вас что угодно, только не SCRUM». Какой DoD должен быть, как его формулировать для задач разного уровня, где хранить, и т.п.

* «[[Ретроспективы. Настраиваем наш процесс разработки (Сергей Дмитриев, AgileDays-2011)|Ретроспективы. Настраиваем наш процесс разработки]]» — ретроспективы один из старейших и эффективных методов улучшения любого процесса, они есть не только в программировании, но и в производстве, и даже в армии («ретроспектива после боя»). Но как сделать их интересными и эффективными, чтобы они не превратились в «мероприятие для галочки», и наоборот, чтобы активная критика не привела к развалу команды, что, кроме простых фактов, можно зафиксировать (может эмоции?), как это не потерять выявленные факты. Кстати, все это может быть интересно не только в связи с Agile, но и тем, кто интересуется практиками мозговых штурмов.

* «[[Иду по приборам! Практические советы по визуализации работ (Максим Гапонов, AgileDays-2011)|Иду по приборам! Практические советы по визуализации работ]]» — по названию и аннотации представляется что-то о визуализированных метриках, но доклад чуть более общий. О том, что есть важная проблема единого понимания (процесса, ожидаемого результата, сроков), и обычно все дают советы по форсированию коммуникации («надо больше общаться»), в то же время правильная визуализация сделает все (процесс, артефакты, требования) прозрачными и это будет гораздо эффективней.

* «[[Lean Startup — системный подход к разработке новых продуктов (Никита Филиппов, AgileDays-2011)|Lean Startup — системный подход к разработке новых продуктов]]», немного сбивающее с толку название, ибо при слове «Lean» мне, например, сразу представляется медленная и методичная оптимизация огромной замшелой компании. Тут же разговор о приоритетах ценностей в стартапах, например, о том, что в стартапах не нужно экономить на мелочах, гнать идеальный код и беспокоится о техническом/организационном масштабировании, а нужно искать потенциальных покупателей. И в целом, доклад о продажах и продвижении.

http://www.dilbert.com/dyn/str_strip/000000000/00000000/0000000/100000/40000/7000/700/147747/147747.strip.zoom.gif

===== Оценки и планирование =====
Хотя в Agile все подходы к планированию делаются максимально простыми и надежными (как правило, «жадные алгоритмы» приоритезации задач и т.п.), сложности остаются.
Ведь планировать нужно на разных уровнях (баги, задачи, story, marketing features, релиз, и т.п.) и разным потребителям (разработчикам, маркетологам, заказчикам, пользователям). А планирование невозможно без оценок, и хотя уже не все верят в мантру «You Can't Manage What You Don't Measure», тут обсуждаются также и надежные метрики, которых можно получать дешево и без «побочного влияния» на измеряемый объект.

* «[[Трехуровневое планирование в Agile (Дмитрий Овечкин, AgileDays-2011)|Трехуровневое планирование в Agile ]]» — опыт планирования на уровнях «квартал → Релиз → Спринт» и борьбы с технодолгами и изменением требований.
* «[[Agile с фиксированной стоимостью — это реально! (Дмитрий Лобасев, AgileDays-2011)|Agile с фиксированной стоимостью — это реально!]]» — что делать, когда самый неудобный для Agile-разработки случай: заказчик, который готов платить только фиксированную цену и за определенный объем. К сожалению, ничего волшебного, в основном, как страховать себя от рисков, как документально это оформлять («change request только за отдельные большие деньги») и т.п.
* «[[Предварительная оценка и планирование Agile проектов (Дамир Тенищев, AgileDays-2011)|Предварительная оценка и планирование Agile проектов]]» — Взгляд на Agile матерого oldschool менеджера, очень много разнородного личного опыта по большим и долгоживущим проектам (не только планирование и оценка). Все под девизом «Лучше два раза встать на взрослые грабли, чем один раз на детские» (это о кейсе «Agile & FixedPrice», развивая тему «[[Agile с фиксированной стоимостью — это реально! (Дмитрий Лобасев, AgileDays-2011)|Agile с фиксированной стоимостью — это реально!]]»).
* «[[Agile Distribution Risk Score — планируйте распределенность осознанно (Анна Обухова, AgileDays-2011)|Agile Distribution Risk Score — планируйте распределенность осознанно]]» — «распределенность» еще одно известное неудобство для Agile-разработки (для любой, но для Agile — особенно). Но насколько это неудобно? Имеет ли смысл «слать на помощь» распределенной команде еще «один отряд», или это окончательно уронит КПД? Тут предлагается эмпирически выработанная на десятках проектов формула.
* «[[Планирование релизов в методологиях быстрой разработки (Дмитрий Никонов, AgileDays-2011)|Планирование релизов в методологиях быстрой разработки]]» — инсайдерский опыт релиз-менеджмента из таких крупных компаний, как Amazon и Microsoft.

===== Мотивация =====
Работа в приказном стиле «я начальник, ты дурак» в Agile, где максимизировано делегирование и самоорганизация, невозможна, поэтому архиважны: мотивация, лидерство и отбор правильных людей.

* «[[Everyone likes change, but nobody likes to be changed (Henrik Kniberg, AgileDays-2011)|Everyone likes change, but nobody likes to be changed]]» — Доклад (на английском, без перевода!) о проведении изменений от гуру-аджайла. Важность личного лидерства при проведении изменений, как определить истинную цель и выбрать конкретные шаги, ведущие к ней.
* «[[Культура лидерства в Agile (Тимофей Евграшин, AgileDays-2011)|Культура лидерства в Agile]]» — лидерство, как новый тип менеджмента, в замен обычному иерархично-директивному. Менеджер должен быть харизматичный лидер и терпеливый учитель, да еще «в ответе за тех, кого приручил» — ведь даже делегирование не снимает ответственности!
* «[[И все-таки программисты — дети! (Роман Юферев, AgileDays-2011)|И все-таки программисты — дети!]]» — Интеграция (по Адизесу) и People Management — очень схожи с воспитанием детей, и современные (именно продвинутые!) взгляды на детское развитие дают ключ и к пониманию и эффективному управлению командой. «Свобода и наставничество» вместо «Няньки, которая развращает команду».
* «[[В поисках гибкого разработчика (Роман Юферев, AgileDays-2011)|В поисках гибкого разработчика]]» — Альтернативой мучениям по воспитанию эффективного командного игрока является правильный отбор. Какие качества желать от кандидатов, что реально важно и нельзя починить после покупки? А как организовать эту входную «выбраковку»?

===== Опыт =====
Положительный и отрицательный опыт разных компаний и проектов.

* «[[Стихийный Agile во внутрикорпоративной среде (Всеволод Леонов, AgileDays-2011)|Стихийный Agile во внутрикорпоративной среде]]» — как оно внутри Embarcader'о (кстати, они maintener'ы Delphi). Немного сумбурно, «обо всем», куча разных кейсов.
* «[[Принципы Lean и развитие аутсорсинговой компании (Михаил Плискин, AgileDays-2011)|Принципы Lean и развитие аутсорсинговой компании]]» — у них счастливая ситуация, так много новых проектов, что приходится оптимизировать их запуск и разгон. ''Марья Ивановна, всем бы ваши проблемы...''
* «[[Экстремальный аджайл — танцуют все (AgileDays-2011)|Экстремальный аджайл — танцуют все]]» — «SCRUM-беспредел»! Всех участвующих в разработке продукта, включая маркетологов, аналитиков, юзабилистов, в одну команду! Более того, в одну комнату! Всех 18 человек! Продукт (SAAS-бухгалтерия) получается весьма интересным.
* «[[Наследие капитана Флинта — трудности и ошибки внедрения Scrum на примере компании Промедичи (Александр Лесневский, AgileDays-2011)|Наследие капитана Флинта — трудности и ошибки внедрения Scrum на примере компании Промедичи]]» — вот, тот самый пример отрицательного опыта, чтобы не говорить, что Agile, как и дельфины<ref>Очевидно, о «спасающих дельфинах» рассказывают только те, кого они толкают в сторону берега</ref>, спасают всех тонущих. Тут же все было давно запущено, и внедрение SCRUM оказалось эвтаназией. «Ужасный конец лучше, чем ужас без конца».
* «[[Kanban vs Scrum – чьё кунг-фу сильнее (Кирилл Климов, AgileDays-2011)|Kanban vs Scrum – чьё кунг-фу сильнее]]» — Если SCRUM для вас слишком жесткий и перегружен ритуалами, то лучше не кастрировать его насмерть, комплексуя от того, что у вас «не настоящий SCRUM», а перейти сразу на полноценный Kanban (всего три правила!).
* «[[Jam session (AgileDays-2011)|Jam session]]» — свободное обсуждение тем «Внедрение TDD», «Agile и госзаказчик», «Электронная скрам-доска», «Длинный скучный Daily Scrum команды из 18 человек» (догадайтесь у кого ^_^).

Отдельно выделю целых три доклада о SCRUM в Luxoft:
* «[[В чем счастье заказчика? Готовые фичи вместо гант-чарта! (Станислав Калканов, AgileDays-2011)|В чем счастье заказчика? Готовые фичи вместо гант-чарта!]]» — гимн Agile от Luxoft, три года как начавший внедрять Agile в ряде своих проектов.
* «[[Agile in Investment Banking (Сергей Евтушенко, AgileDays-2011)|Agile in Investment Banking]]» — внедрение в самой сложной ситуации: распределенная команда, фикспрайс, финансовый хайлоад (трейдинг) с дорогими ошибками — как выжить, какие практики работают, а что, нужно отбросить.
* «[[Enterprise Scale Agile. Lessons learned (Константин Гурнов, AgileDays-2011)|Enterprise Scale Agile. Lessons learned]]» — «корпоративный Agile такой корпоративный», весь обвешанный графиками и метриками.

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

===== Архитектура =====
* «[[Архитектура в Agile — переосмысляя идею модульности и компонентности (Андрей Бибичев, AgileDays-2011)]]» — Лучший технический доклад конференции, квинтессенция двух десятков лет опыта от самого крутого из моих знакомых разработчиков. По сути — каким должно быть правильное ООП.
* «[[Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011)]]» — Удачный опыт так называемой «моделеориентированной» системной инженерии, когда вместо размазанной в коде бизнес-логики, четко выделяется всегда актуальная модель предметной области и механизмы ее реализации. Тут для предметной области учета удалось придумать компактную и полную модель, представимую в специальных диаграммах («диаграммы плана счетов»). Ее напрямую проектируют и изменяют со временем совместно с заказчиком, а специальный интерпретатор этой модели («учетная машина») гарантирует безошибочность.
* «[[Domain Driven Design в условиях разработки распределенных приложений (Николай Гребнев, AgileDays-2011)]]». «[[EnPedia:Domain Driven Design|Domain Driven Design]]» как раз одно из направлений «моделеориентированной разработки», популярной среди корпоративных .NET-разработчиков. Однако с таким подходом к разработке распределенных приложений возникает куча сложностей, о чем и был этот доклад.
* «[[Все в ваших руках — быть готовым к изменениям в системах БД (Андрей Совцов, AgileDays-2011 )]]» — Производитель инструментов для работы с реляционными СУБД напоминает, что издревне, скелетом информационных систем (а также архитектурой и моделью) являлись реляционные базы данных, и что ''правильные'' инструменты работы (<tt>ER/studio</tt>, <tt>DB Aristan</tt>, <tt>Performing center</tt>, <tt>DB optimizer</tt>, <tt>Change manager</tt>) — сильно облегчат развитие вашей информационной системы.
* «[[Модель принятия инженерных решений — ключ к ответам на технические вопросы (Евгений Кривошеев, AgileDays-2011)]]» — «Что такое хорошо и что такое плохо в проектировании, аналитике и документировании». Изначально доклад даже назывался вызывающе просто — «42», намекая на то, что это и есть окончательный ответ на все эти вопросы.

===== Разработка =====
* «[[В погоне за качеством. Code Review (AgileDays-2011)]]» — Зажигательное шоу, что-то среднее между парным конферансом («Привет Бим! Привет Бом!») и проповедью среди неверных от двух известных евангелистов практик экстремального программирования.
* «[[Непрерывная интеграция при разработке баз данных (Владимир Бахов, AgileDays-2011)]]» — Скорее не про ''Continuous Integration'', а про совокупность практик ведения, тестирования, и деплоймента реляционных СУБД.
* «[[Практики «Экстремального Программирования» в оффшорном проекте (Сергей Андржеевский, AgileDays-2011)]]» — добротный рассказ об eXtreme Programming на основе своего опыта. Ибо SCRUM/Kanban штуки весьма общие, хоть в личной жизни используй, хоть в строительстве, а XP — именно программистские практики. И если даже не применять, то хотя бы знать о них обязательно.
* «[[Шаблоны «Асинхронный фильтр» и «HasValue» в разработке desktop приложений (Олег Клинчаев, AgileDays-2011)]]» — Как развязать хитрозапутанную логику перегруженных данными «бизнес-форм»? Об этом подход дополнительной абстракции «HasValue» от разработчиков GWT. А как сделать эти формы <s>удобными</s>, ну хотя бы не зависающими? Асинхронность! Работающие примеры продемонстрированы вживую.

===== Тестирование =====
* «[[Тестирование встроенного ПО: альтернатива классическому TDD (Дмитрий Овечкин, AgileDays-2011)]]» — в разработке для девайсов, если нет симулятора и перед запуском каждого бинарника нужно заново прошивать сборку на маленькую флеш-память — места для классических юнит-тестов нет. Зато у девайса (в отличие от сложного GUI), есть четкие интерфейсы, и пользуясь ими можно написать кучу дешевых и гибких скриптовых автоматических тестов.
* «[[Почему я не люблю огурцы и фитнес — плюсы и минусы BDD и ATDD (Алексей Баранцев, AgileDays-2011)]]» — Атака на инструменты <tt>Fitnesse</tt> и <tt>Cucumber</tt>, которые вроде как должны облегчить жизнь тестировщикам (и уволить многих из них), а на практике, как «морская свинка» — не облегчают жизнь аналитикам-заказчикам, и не заменяют тестировщиков. Интересен не только доклад, но и жаркая дискуссия после — в зале было много активно несогласных, имеющих удачный опыт использования этих инструментов.
* «[[Как сервисному отделу не стать бутылочным горлышком (Юля Нечаева, AgileDays-2011)]]» — В Agile-принято, что тестировщики внутри команд, а отдельные «отдел тестирования» или «департамент документирования» являются классическим антипаттернами, «как создать deadlock на пустом месте» (ни у кого в зале, например, такого уже не было). Ну а что делать тем, у кого это тем не менее так? («…Мы сами знаем, что она не имеет решения, — сказал Хунта, немедленно ощетинившись. — Мы хотим знать, как ее решать.©»). Полезные практики — как тестировать еще до разработки, как бить в слабые стороны разработчиков, чтобы завертывать сборки с багами обратно максимально быстро и т.п. И кстати, только на нетестерской конференции от тестера можно услышать правду, что «тестирование не самодостаточно».

==== Блиц-доклады ====
Особняком выделю блиц-доклады. Для тех, кто привык к краткости YouTube-роликов, 8-10 минутные доклады, которых можно просмотреть на одном дыхании.

* «[[Пуассоновое горение сроков (Андрей Бибичев, AgileDays-2011)]]» — Лучший (IMHO) блиц-доклад. Почему все ошибаются в оценках? Почему оценки надо умножать на PI? Строгая математика докажет, что вы не виноваты в срыве сроков! (Близко к «Черному Лебедю», для тех, кто в курсе).
* «[[Agile. Путь от хаоса к потоку (Николай Алименков, AgileDays-2011)]]» — «Сначала был Хаос, … затем он сгустился и появился Agile, началась эволюция, и Авраам родил Исаака… Agile породил Lean…». Взгляд на эволюцию методологий со стороны тех, у кого в «доаджайлный» период был не «RUP/CMMI 5 уровня/SixSigma», а реальный <s>бардак</s>Хаос, и наконец-то появились какие-то вменяемые процессы.
* «[[Agile — вид из окна тренажёрного зала (Алексей Солнцев, AgileDays-2011)]]» — «Хочешь похудеть и внедрить SCRUM — спроси меня как!»© Автор попал в ситуацию, когда осознал, что потерял форму, а компания — что теряет последних заказчиков. → … →  И результат → -15кг, +девушка→жена, +компания, в которой не стыдно работать.
* «[[Ахиллес и черепаха. Разумный подход к работе над крупными клиентскими проектами (Юрий Гугнин, AgileDays-2011)]]» — Дизайнер-менеджер про ужасы гигантомании крупных заказчиков, приводящих либо к epic failам, либо к очередному УГ в едином корпоративном стиле. Альтернатива — «есть слона по частям», в каждой из частей максимизируя и креативность, и ''customer satisfaction''.
* «[[Agile и жизнь (Александр Калугин, AgileDays-2011)]]» — как аджайлизировать рабочие, но непроектные задачи — инфраструктурные или личное карьерное развитие. И предлагалось не городить параллельно два скрама («проектный и непроектный»), а засунуть все это в основной, проектный «Скрам»: и персональный бэклог сотрудника, и стратегический бэклог компании.
* «[[Зачем нам это надо? или Как продать Agile команде! (Михаил Карпов, AgileDays-2011)]]» — Автор тоже заметил, что движуха к Agile идет с двух сторон: от измученных <s>нарзаном</s> жестким «CMMI»-водопадом компаний, когда их освобождают от кучи бессмысленной работы — но такое в основном на Западе, у нас только в очень крупных компаниях. А в России же движение идет от бардака, и продавать «Agile-свободу» бессмысленно, надо продавать решение проблем («лишняя работа из-за бардака с требованиями и т.п.»), и делать это постепенно.
* «[[Поведенческая модель DISC в Agile проектах (Кирилл Климов, AgileDays-2011)]]» — Yet Another (в дополнении к MBTI/Майерс-Бриггс/Адизесу/Белбину/Юнгу...) [[RuPedia:DISC_(психология)|DISC-классификация]] людей, тоже, как и большинство других (включая теорию групп крови…), из середины прошлого века, когда казалось, что если разложить многомерного человека по какому-нибудь базису — то дальше простейшей линейной алгеброй и арифметикой можно этими людьми эффективно рулить. Плюс практические выводы, как это использовать в SCRUM-командообразовании.


----
[[Категория:AgileDays-2011]]
<noinclude>
<references/>
{{replicate-from-custiswiki-to-lib}}
</noinclude>