Персональные инструменты
 

Участник:StasFomin/AgileDaysDraft — различия между версиями

Материал из CustisWiki

Перейти к: навигация, поиск
м
 
м
Строка 5: Строка 5:
  
 
А тут, конкурируя с «методологиями» «Bardak and Chaos», «Code&Fix(?)», и вместо избавления приносит какие-то странные ритуалы, очень похожие на менеджерский карго-культ, что встречает, скажем так, очень скептический прием у девелоперов. Тут и [http://blogs.yandex.ru/search.xml?text=%D0%A1%D1%82%D1%8B%D0%B4%20%D0%B8%20SCRUM&ft=all детские дразнилки], и даже «антиманифесты» ([http://programming-motherfucker.com/], [http://пиши-код-блять.рф/]).
 
А тут, конкурируя с «методологиями» «Bardak and Chaos», «Code&Fix(?)», и вместо избавления приносит какие-то странные ритуалы, очень похожие на менеджерский карго-культ, что встречает, скажем так, очень скептический прием у девелоперов. Тут и [http://blogs.yandex.ru/search.xml?text=%D0%A1%D1%82%D1%8B%D0%B4%20%D0%B8%20SCRUM&ft=all детские дразнилки], и даже «антиманифесты» ([http://programming-motherfucker.com/], [http://пиши-код-блять.рф/]).
Модно даже обвинять Agile в эпичном Nokia-faile.
+
Модно даже обвинять Agile в эпичном Nokia-фейле.
  
 
Лично я считаю, что в разработке развитие идет постоянно (см. например «[[Культуры программных проектов (Энтони Лаудер)|Культуры программных проектов]]»), потребности пользователей растут наперегонки с техническими возможностями девелоперов, внутри разработки, особенно в зависимости от типа проекта, меняется важность ролей и специализаций: «разработчики», «менеджеры», «тестировщики», «аналитики», «юзабилисты» и «сейлы». И надо понимать, как все это балансировать.
 
Лично я считаю, что в разработке развитие идет постоянно (см. например «[[Культуры программных проектов (Энтони Лаудер)|Культуры программных проектов]]»), потребности пользователей растут наперегонки с техническими возможностями девелоперов, внутри разработки, особенно в зависимости от типа проекта, меняется важность ролей и специализаций: «разработчики», «менеджеры», «тестировщики», «аналитики», «юзабилисты» и «сейлы». И надо понимать, как все это балансировать.
Строка 15: Строка 15:
 
А вместо того, чтобы читать книгу, которую вряд ли напишет «боевой» разработчик или PM (скорее всего это будет западный тренер в запоздалом и кривом переводе), посмотреть и послушать свежий опыт команд разного типа, понять, что «это у нас работать не будет», а «это нужно здесь и сейчас, иначе эти парни-конкуренты нас порвут».
 
А вместо того, чтобы читать книгу, которую вряд ли напишет «боевой» разработчик или PM (скорее всего это будет западный тренер в запоздалом и кривом переводе), посмотреть и послушать свежий опыт команд разного типа, понять, что «это у нас работать не будет», а «это нужно здесь и сейчас, иначе эти парни-конкуренты нас порвут».
  
На московской AgileDays-2011 собрались реальные, практикующие менеджеры и разработчики, и доклады были как на «гуманитарную» тему менеджмента и прочей организации процессов, так и на технические темы эффективных проектирования, разработки и тестирования.
+
На московской AgileDays-2011 собрались реальные, практикующие менеджеры и разработчики. А доклады были как на «гуманитарную» тему менеджмента и прочей организации процессов, так и на технические темы эффективных проектирования, разработки и тестирования.
  
 
Конечно, полезно также общаться и лично, но сейчас летнее затишье после прошедших [http://camp.agiledays.ru/ AgileCamp], [http://dnepr.agilebasecamp.org/ Agile Base Camp], и можно неспешно, совмещая с пассивным отдыхом смотреть и рефлексировать над видео с докладов.
 
Конечно, полезно также общаться и лично, но сейчас летнее затишье после прошедших [http://camp.agiledays.ru/ AgileCamp], [http://dnepr.agilebasecamp.org/ Agile Base Camp], и можно неспешно, совмещая с пассивным отдыхом смотреть и рефлексировать над видео с докладов.
Строка 28: Строка 28:
 
если только она не состоит из односложных двухцветных лозунгов. Последнее часто ОК для «гуманитарных» докладов («менеджмент», «мотивация», «коммуникация»), но что-либо нетривиальное — код, схемы, модели, скринкасты и видео — передать нельзя.
 
если только она не состоит из односложных двухцветных лозунгов. Последнее часто ОК для «гуманитарных» докладов («менеджмент», «мотивация», «коммуникация»), но что-либо нетривиальное — код, схемы, модели, скринкасты и видео — передать нельзя.
  
Да и вообще идея, что твоим вниманием на видеозаписи управляет оператор — глубоко порочная, пришла из кино-телевидения, где учат для возбуждения расслабленной с попкорном аудитории постонно менять планы: «крупный план докладчика», «докладчик издали», «интерьер сцены», «зал крупным планом», «понравившаяся оператору девушка», и иногда, изредка, соизволить снять экран.  
+
Да и вообще идея, что твоим вниманием на видеозаписи управляет оператор — глубоко порочная, пришла из кино-телевидения, где учат для возбуждения расслабленной с попкорном аудитории постоянно менять планы: «крупный план докладчика», «докладчик издали», «интерьер сцены», «зал крупным планом», «понравившаяся оператору девушка», и иногда, изредка, соизволить снять экран.  
  
Но тут же не сериал, не расслабуха — наоборот, нужно активное восприятие, только зритель, сам, решает, надо ли ему, нахмурив брови, вкуривать схему на экране, слушая докладчика, или же на схеме ему все понятно, и пора последить за жестикуляцией автора, поясняющего нетривиальные моменты. Конечно, иногда при этом советуют найти слайды, и пытаться их листать параллельно, но это напряжно и есть куча вещей непредставимых через слайды — живые демонстрации, лайвкодинг.
+
Но тут же не сериал, не расслабуха — наоборот, нужно активное восприятие, только зритель, сам, решает, надо ли ему, нахмурив брови, «вкуривать» схему на экране, слушая докладчика, или же на схеме ему все понятно, и пора последить за жестикуляцией автора, поясняющего нетривиальные моменты. Конечно, иногда при этом советуют найти слайды, и пытаться их листать параллельно, но это напряжно и есть куча вещей непредставимых через слайды — живые демонстрации, лайвкодинг.
  
 
Добавляет страданий и необработанный звук, особенно если приходится слушать тех, кто говорил без микрофона. Человеческое ухо очень чувствительно, и быстро приспосабливается к любой громкости — от грохота до шепота, но микрофоны это сделать не могут, и при приходится слушать, постоянно регулируя громкость — чтобы, например, слышать и докладчика, и вопросы из зала без микрофона.
 
Добавляет страданий и необработанный звук, особенно если приходится слушать тех, кто говорил без микрофона. Человеческое ухо очень чувствительно, и быстро приспосабливается к любой громкости — от грохота до шепота, но микрофоны это сделать не могут, и при приходится слушать, постоянно регулируя громкость — чтобы, например, слышать и докладчика, и вопросы из зала без микрофона.
Строка 42: Строка 42:
 
* Промотать тривиальное,
 
* Промотать тривиальное,
 
* Ускорить или замедлить выступление. Например, в VLC, нажав пару раз на клавишу «]», даже самый скучный и заикающийся докладчик начнет жечь как Стив Баллмер (да, многие доклады я смотрел на «150%» скорости).  И наоборот, можно замедлить (в VLC это «[») и разобрать непонятный момент.
 
* Ускорить или замедлить выступление. Например, в VLC, нажав пару раз на клавишу «]», даже самый скучный и заикающийся докладчик начнет жечь как Стив Баллмер (да, многие доклады я смотрел на «150%» скорости).  И наоборот, можно замедлить (в VLC это «[») и разобрать непонятный момент.
* Можно рассмотреть внимательно экран или наоборот, сконцентрироваться на выразительных, многопоясняющих жестах докладчика.
+
* Можно рассмотреть внимательно экран или наоборот, сконцентрироваться на выразительных, многое поясняющих, жестах докладчика.
 
* В такой записи смотреть даже презентации-слайдоменты, не читаемые даже с третьего ряда, или презентации на черном фоне, которые сделал гордец, решивший уподобится Стиву Джобсу (смотреть их в незатемненном зале — невозможно).
 
* В такой записи смотреть даже презентации-слайдоменты, не читаемые даже с третьего ряда, или презентации на черном фоне, которые сделал гордец, решивший уподобится Стиву Джобсу (смотреть их в незатемненном зале — невозможно).
  
Строка 48: Строка 48:
  
 
Так что, если тема доклада вас заинтересовала, высока вероятность, что вы его  не зря просмотрите.
 
Так что, если тема доклада вас заинтересовала, высока вероятность, что вы его  не зря просмотрите.
Видео опубликовано и в веб-версии, чтобы посмотреть начало, ознакомиться, так же есть ссылки на скачивание оригинальных видеофайлов, чтобы смотреть активно, с перемоткой или ускорением, о чем было выше.
+
Видео опубликовано и в веб-версии, чтобы посмотреть начало, ознакомиться, и даже досмотреть до конца (только нельзя ускорить <tt>:(</tt>), и есть ссылки на скачивание оригинальных видеофайлов, чтобы смотреть активно, с перемоткой или ускорением.
  
Из минусов, надо признать, что не всегда была удачна работа видеооператоров — дело в том, что мы решили снимать видео незадолго до начала конференции, и видеооператорами были наши сотрудники после получасового тренинга за день до начала конференции. Получилась такая вот Agile-кроссфункциональность, не идеально, зато вовремя и дешево!
+
Из минусов, надо признать, что не всегда была удачна работа видеооператоров — дело в том, что мы решили снимать видео незадолго до начала конференции, и операторами были наши сотрудники после получасового тренинга за день до начала конференции. Получилась такая вот Agile-кроссфункциональность, не идеально, зато вовремя и дешево!
  
 
А кроме видео, также опубликованы дополнительные материалы,
 
А кроме видео, также опубликованы дополнительные материалы,

Версия 22:59, 8 августа 2011

Опубликовал видео с конференции AgileDays-2011.

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

Хотя тема уже не новая, в сейчас как раз можно отпраздновать юбилей — 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, и можно неспешно, совмещая с пассивным отдыхом смотреть и рефлексировать над видео с докладов.

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

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

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

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

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

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

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

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

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

Ведь у смотрящего есть власть над видео:

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

Но такой монтаж — это нетривиальная, обычно ручная работа, и когда за нее берутся профессионалы, то и берут за нее очень много. И то, как правило, получается не очень. Так вот, мы, при проведении AgileDays-2011 озаботились этим вопросом, и научились это делать относительно быстро и качественно. Видео высокого-веб разрешения (1280×720), где всегда есть экран с точностью до пискеля, докладчик или зал, в зависимости от активности последних, маркерная доска, если докладчик таки порывался на ней что-то порисовать.

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

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

А кроме видео, также опубликованы дополнительные материалы,

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

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

И наконец — для каждого автора доклада приведена ссылка на его профиль в IT-шной профессиональной сети, т.е. если вы заинтересовались, в пару кликов можно:

  • Посмотреть «кто все эти люди», можно ли доверять их мнению.
  • Связаться с автором, задать вопросы, поблагодарить, или выразить несогласие.

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

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

Такой, несколько субъективный путеводитель, я и предложу ниже. Почти[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. Очевидно, о «спасающих дельфинах» рассказывают только те, кого они толкают в сторону берега