Agile Days-2012, день первый

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

Теперь о докладах.

Что сильно понравилось

Илья Кузнецов и Асхат рассказывали о конкретных практиках, в несколько неожиданном для меня разрезе.

Илья Кузнецов. История кратного роста эффективности за 2 месяца. Это история о том, как работу одного человек организовывали с помощью Канбан-доски. но без произнесения слова Канбан, через внедрение конкретных практик, благо их мало. Очень неожиданная и конкретная история. Успешная, задача снижения leak-time — достигнута за счет ограничения на задачи в работе. При этом получился жесткий отбор на входе в работу — потому перестали брать слабо нужные задачи. А еще — работа стала прозрачной для руководства. В общем, это кейс, который можно делать выводы. Еще из интересного — как организовывать доску под нужды конкретного проекта. Об этом подробнее было в кейсе, плюс несколько разных досок показано в конце.

Асхат Уразбаев. Секреты Lean в разработке ПО. Я слушал кусочек доклада — потому что параллельно был доклад Ильи. Асхат сказал, что не будет рассказывать о всех методах Lean, а ограничится одним — Value Stream Mapping, который они в последнее время много применяют. И разобрал его достаточно подробно. Я надеюсь, что будет выложена запись и я посмотрю доклад полностью.

Linda Rising. The Power of an Agile Mindset. Доклад про два вида людей — консерваторов (fixed) и подвижных (effort). Известный эксперимент с тестами студентов, в котором их делят на effort and fixed. В общем-то он экспериментально доказывает известную вещь — что надо активно работать и пытаться. Но он численно померил разницу: по сравнению с началом effort улучшились на 30% а fixed — ухудшились на 20%, что неожиданно.

Потом перещла к mindset fixed vs agile. Перые просят помощи и плывут по течению, а вторые — видят вызовы. Все очевидно. Может, это агитация тех вторых, которые не решаются: «встань и иди!».

В конце доклада был тезис, что fail — это урок, поэтому fail’ите и учитесь. Хотя это какой-то сюр — ищите, где бы еще сделать fail, чтобы научиться.

Dan Rawsthorne. Scrum: the Big Picture. Дэн рассказывал, как в рамках Agile отстроили «общепринятую» иерархию уровней от Software Development до Portofolio management. Как брендинг и структурирование — понятно, полезно и нужно.

• Agile Software Dvevelopment (ASD) — получаем качество, его обеспечивают многочисленные XP-практики — тестирование, code review and so on. Для бизнеса agile — цена качества кода.
• Agile Product Development (APD) — здесь max value for money за счет SCRUM-цикла разработки, PO, demo for stakeholders.Необходимо, чтобы бизнес принимал team’s velosity as reality
• Agile Project Management (APM) — Coordinate, Cooperate… Здесь бизнес не должен мелочно толкать команду, но может сделать новую, если необходимо.
• Agile Portofolio Management (APortM) — В терминах проектов. В целом — те же ценности и формы управления. Постоянные улучшения по анализу проектов добавлены на этом уровне, естественно. Не успокаивайтесь (don’t dreams). Я: тема до конца не раскрыта, НО вынесен стратегический уровень, который НЕ ЕСТЬ планирование и следование плану, он адаптивен. В вопросах явно спросили, видел ли Дэн этот уровень на практике, он сказал, что да, и больше одного раза.

Интересна форма — мини-обсуждения (2.5 мин) во время доклада с соседями по очередному тезису, чтобы люди прониклись и осознали.

В вопросах. Интересно позиционирование Scrum Master — он проводник изменений в процессе (команде).

А что было в остальных докладах

Естественно, здесь только те доклады, на которых я был.

Евгений Злобин, Александр Яковлев. Новые возможности для управления проектами в TFS2011 — по сути, бесплатная консультация по новой версии инструмента. Для тех, кто пользуется — содержательно, наверное, хотя на мой непросвещенный взгляд вопросы для профи — поверхностны. Но с мест их задавали…

Дмитрий Снисарь. Как правильно решать конфликты на разных фазах проекта? Доклад про фазы формирования команды Forming-Storming-Norming-Performing и детали разных стадий. Практика.

Борис Вольфсон. Agile Death March Projects: путь ниндзя Анонсировано как рассказ про смертельный марш, но реально он о том, как сложный проект (по признакам Йордана) все-таки сделать. При этом проект небольшой (полгода) — напишите бэклог, оцените вместе с командой, соберите хорошую команду. Выбить ресурсы и прочее. И чтобы все понимали — по краю ходим. Правда, если такой проект по собственной глупости (или от конкурентов) — то далеко не все знать будут. В общим, как-то очевидно все и по Йордану это совсем не смертельный проект.

Евгений Кривошеев. Как нужно уметь думать техническим и процессным специалистам Развернута стандартная лестница Бизнес-Процессы-Требования-Design-Разработка. Но при этом процессы — у нас, а не у заказчика, и бизнес — это как наша компания зарабатывает разработкой. И дальше как из этой иерархии принимать решения, например, если заказ — сделать здесь и сейчас, то не вкладывайтесь в гибкий дизайн, делайте hardcode. И о том, что бизнес-модель компании будет влиять и на процесс разработки и на дизайн. То есть мысли понятны, но в целом, с моей точки зрения, достаточно путано получилось.

Дмитрий Лобасев. Что делать, если команде все равно? Советы скрам-мастеру В общем, как заявлено, консалтинг как практически внедрять SCRUM.

Дмитрий Безуглый. Что должен еще уметь делать Product Owner, чтобы стать Product Manager Даже к замечательному продукту люди не придут сами… Нужен маркетинг и многое другое, включая поддержку и доставку продукта. В общем, понятно, качественно, но лично для меня это — совсем другая область. И, наверное, для начинающих — вещи очевидные.

Максим Коробцев. Применение принципов «бережливости» в процессном управлении компании Positive Technologies Доклад о построении процессов компании на основе BPMN-модели процессов в Visio, с помощью которой специальным планировщиком порождаются задачи в task tracker (отдельная задача на каждый шаг модели), а далее планировщик отслеживает выполнение задач и порождает следующие. Доклад сделан на основе двух внедрений этой идеи вместе с разными системами task tracker’а. При этом agile внедрялся в части процесса, в не-agile окружении. А для стандартизации процессов использовались «lean-шаблоны»: стандарты входных и выходных документов, ссылка на документ в задаче, стандартное описание.

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