7114
правок
Изменения
м
Нет описания правки
{{Conf-Ref}}
В целом конференция ожидаемо живая. К сожалению, активное посещение конференций и долгая работа в 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'''. Блиц про мотивацию, хотелки и типичные ошибки, как сказал докладчик "от кэпа, но делают часто": что мотивация бывает только деньгами или карьерой и когда мотивируют тем, что самого вдохновляет. И о плюшках - их надо раздавать регулярно, тренажерный зал - одноразовая плюшка, хотя пользуются регулярно. Плюшки должны соответствовать списку хотелок человека.
{{wl-publish: 2012-03-24 00:42:14 +0400 | MaksTsepkov }}
В целом конференция ожидаемо живая. К сожалению, активное посещение конференций и долгая работа в 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'''. Блиц про мотивацию, хотелки и типичные ошибки, как сказал докладчик "от кэпа, но делают часто": что мотивация бывает только деньгами или карьерой и когда мотивируют тем, что самого вдохновляет. И о плюшках - их надо раздавать регулярно, тренажерный зал - одноразовая плюшка, хотя пользуются регулярно. Плюшки должны соответствовать списку хотелок человека.
{{wl-publish: 2012-03-24 00:42:14 +0400 | MaksTsepkov }}