AgileDays-2011 — краткая классификация докладов

Ссылки сюда (4) →

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

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

Getting Started

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

• «Для тех, кто в танке — что такое Agile» был задуман, как быстрый ликбез для новых в Agile людей, и как альтернатива открывающему докладу Henrik-а Kniberga. Программный Комитет думал, что те, кто «в теме» обязательно пойдут на «гуру», а оставшихся надо «вводить в тему». Однако неожиданно на доклад набился полный зал народу, из которых «не в теме» было всего человека три, так что ликбез получился вполне глубоким, не стыдно посмотреть, даже если вы практик. Можете рекомендовать тем, кого бы вы хотели заинтересовать Agile-ценностями — новым сотрудникам, старым менеджерам и молодым HR-шам…
• «Lean Software Development» и «Применение принципов Lean в масштабах предприятия» лучше смотреть блоком и в такой последовательности — это введение в новомодную производственную культуру «бережливого производства», в приложении к разработке софта. В некоторым смысле, Agile — это частный случай реализации более глобального подхода LEAN, c которым можно замахиваться на такие задачи, как реформирование и оптимизация всей компании (а не просто внедрение Agile в одном из подразделений).
• «Гибкая теория ограничений» — обзорный рассказ об «Теории ограничений», еще одной философии менеджмента, в некотором смысле дополнительной к LEAN.

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

Процесс

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

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

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

• «Lean Startup — системный подход к разработке новых продуктов», немного сбивающее с толку название, ибо при слове «Lean» мне, например, сразу представляется медленная и методичная оптимизация огромной замшелой компании. Тут же разговор о приоритетах ценностей в стартапах, например, о том, что в стартапах не нужно экономить на мелочах, гнать идеальный код и беспокоится о техническом/организационном масштабировании, а нужно искать потенциальных покупателей. И в целом, доклад о продажах и продвижении.

Оценки и планирование

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

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

Мотивация

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

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

Опыт

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

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

Отдельно выделю целых три доклада о SCRUM в Luxoft:

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

Техническое

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

Архитектура

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

Разработка

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

Тестирование

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

Блиц-доклады

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

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

---

---

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

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2011 — краткая классификация докладов»