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

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

Илья Кузнецов. История кратного роста эффективности за 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. Блиц про мотивацию, хотелки и типичные ошибки, как сказал докладчик "от кэпа, но делают часто": что мотивация бывает только деньгами или карьерой и когда мотивируют тем, что самого вдохновляет. И о плюшках - их надо раздавать регулярно, тренажерный зал - одноразовая плюшка, хотя пользуются регулярно. Плюшки должны соответствовать списку хотелок человека.

[ Хронологический вид ]Комментарии