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

Материал из CustisWiki
Перейти к: навигация, поиск

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

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

Getting Started

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

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

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

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

147747.strip.zoom.gif

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

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

Мотивация

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

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

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

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

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

Техническое

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

Архитектура
Разработка
Тестирование
  • «Тестирование встроенного ПО: альтернатива классическому 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-командообразовании.


  1. ↑ От нескольких докладов видео не сохранилось, я их не смог посмотреть и поэтому не включил в эту классификацию. Но их можно найти в категории, посмотреть слайды или отзывы
  2. ↑ Новомодное конечно у нас. В мире это уже классика.
  3. ↑ Очевидно, о «спасающих дельфинах» рассказывают только те, кого они толкают в сторону берега

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

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

Источник — «http://lib.custis.ru/index.php?title=AgileDays-2011_—_краткая_классификация_докладов&oldid=33714»