Pull to refresh

К юбилею AgileManifesto — материалы с AgileDays-2011

Agile *
Пользуясь юбилеем — как раз в августе, 10 лет назад был опубликован[1] The Agile Manifesto еще раз предлагаю сейчас, в летнее затишье, загрузить на будущее в себя немного Agile (когда пойдут дедлайны, будет уже не до этого).

А именно, посмотреть-почитать материалы докладов с прошедшей в Москве конференции AgileDays-2011. Далее, будет небольшое пояснение, почему эти материалы интересны, смотрибельны и читабельны, а также аннотированная тематическая классификация докладов, с ссылками на материалы — видеозаписи, слайды, рецензии и т.п.

1 Почему это интересно?

Хотя тема уже не новая, в сейчас как раз можно отпраздновать юбилей — Agile Manifesto стукнул десяток, «продвижение в массы» еще продолжается. Причем если раньше борьба была на фронте корпоративной разработки, в стиле «Agile vs. Some Waterfall Unified Process» и там он нес скорее избавление от лишних регламентов и бессмысленного труда, то то сейчас он добрался до самых широких масс (разработка сайтов, стартапы).

А тут, конкурируя с «методологиями» «Bardak and Chaos», «Code&Fix(?)», и вместо избавления приносит какие-то странные ритуалы, очень похожие на менеджерский карго-культ, что встречает, скажем так, очень скептический прием у девелоперов. Тут и детские дразнилки, и даже «антиманифесты» ([1], [2]). Модно даже обвинять Agile в эпичном Nokia-фейле.

Лично я считаю, что в разработке развитие идет постоянно (см. например «Культуры программных проектов»), потребности пользователей растут наперегонки с техническими возможностями девелоперов, внутри разработки, особенно в зависимости от типа проекта, меняется важность ролей и специализаций: «разработчики», «менеджеры», «тестировщики», «аналитики», «юзабилисты» и «сейлы». И надо понимать, как все это балансировать. И меня достал уже старый риторический баян, что «нет серебряной пули» среди методологий разработки. Конечно нет! Есть куча интересных, эффективных практик, в разработке, аналитике и организации, есть рефлексия, когда, где и как это работает. И все это происходит под лейблом «Agile», наверное потому, что проще объединится под очевидными ценностями Agile-манифеста, чем под прохождением сертификации какого-нибудь Process Management Institute.

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

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

Конечно, полезно также общаться и лично, но сейчас летнее затишье после прошедших AgileCamp, Agile Base Camp, и можно неспешно, совмещая с пассивным отдыхом смотреть и рефлексировать над видео с докладов.

Дальше я пару слов скажу почему наше видео достойно просмотра, а затем предложу тематическую классификацию.

2 Почему это видео надо или хотя бы можно смотреть?

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

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

Да и вообще идея, что твоим вниманием на видеозаписи управляет оператор — глубоко порочная, пришла из кино-телевидения, где учат для возбуждения расслабленной с попкорном аудитории постоянно менять планы: «крупный план докладчика», «докладчик издали», «интерьер сцены», «зал крупным планом», «понравившаяся оператору девушка», и иногда, изредка, соизволить снять экран.

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

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

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

Такое видео, можно с удовольствием посмотреть, получив эффект присутствия, и даже более того!

Ведь у смотрящего есть власть над видео:
  • Можно повторить непонятное,
  • Промотать тривиальное,
  • Ускорить или замедлить выступление. Например, в VLC, нажав пару раз на клавишу «]», даже самый скучный и заикающийся докладчик начнет жечь как Стив Баллмер (да, многие доклады я смотрел на «150%» скорости). И наоборот, можно замедлить (в VLC это «[») и разобрать непонятный момент.
  • Можно рассмотреть внимательно экран или наоборот, сконцентрироваться на выразительных, многое поясняющих, жестах докладчика.
  • В такой записи смотреть даже презентации-слайдоменты, не читаемые даже с третьего ряда, или презентации на черном фоне, которые сделал гордец, решивший уподобится Стиву Джобсу (смотреть их в незатемненном зале — невозможно).
Но такой монтаж — это нетривиальная, обычно ручная работа, и когда за нее берутся профессионалы, то и берут за нее очень много. И то, как правило, получается не очень. Так вот, мы, при проведении AgileDays-2011 озаботились этим вопросом, и научились это делать относительно быстро и качественно. Видео высокого-веб разрешения (1280×720), где всегда есть экран с точностью до пискеля, докладчик или зал, в зависимости от активности последних, маркерная доска, если докладчик таки порывался на ней что-то порисовать.

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

Из минусов, надо признать, что не всегда была удачна работа видеооператоров — дело в том, что мы решили снимать видео незадолго до начала конференции, и операторами были наши сотрудники после получасового тренинга за день до начала конференции. Получилась такая вот Agile-кроссфункциональность, не идеально, зато вовремя и дешево!

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

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


3 Темы докладов

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

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

3.1 Getting Started

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


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



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



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

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


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

3.3 Техническое

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

3.3.1 Архитектура


3.3.2 Разработка


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


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

Особняком выделю блиц-доклады. Для тех, кто привык к краткости 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-командообразовании.








  1. Хотя историческое собрание произошло в феврале 2001 года, опубликован манифест был в августовском выпуске Software Development Magazine
  2. От нескольких докладов видео не сохранилось, я их не смог посмотреть и поэтому не включил в эту классификацию. Но их можно найти в категории, посмотреть слайды или отзывы
  3. Новомодное конечно у нас. В мире это уже классика.
  4. Очевидно, о «спасающих дельфинах» рассказывают только те, кого они толкают в сторону берега
Tags: agile developmentagiledaysконференциявидео докладов
Hubs: Agile
Total votes 35: ↑33 and ↓2 +31
Comments 5
Comments Comments 5

Popular right now

Top of the last 24 hours