7322
правки
Изменения
Новая страница: «Был на половинке конференции Ag;)leDays’09. Жаль, что не на всей. Пишу краткие резюме по докла…»
Был на половинке конференции Ag;)leDays’09. Жаль, что не на всей.
Пишу краткие резюме по докладам в порядке прослушивания. Если что вызовет интерес, готов расширить — пишите вопросы.
'''Алексей Кривицкий, Наталья Тренина. Обогащение командного взаимодействия.''' Пошел, потому что трек начинался раньше остальных с мыслью уйти, если не интересно. Ушел поздновато. Был перепев западного по стилю тренинга по коучингу — открытые вопросы, политес, уровни слушания, повторение для внимания, подстройка под собеседника интонаций, позы и прочего, и тому подобное. Слайды и слова лично у меня местами вызывали совершенно стебные ассоциации. Интересно, это специальный эффект, или само получилось, или просто особенности моего личного восприятия, а остальные этого не видели? Типа, когда говорят, что «если собеседник говорит спокойно и медленно, то и вам стоит говорить также», очень хотелось добавить «и тогда вы вместе быстро уснете». В конце концов не выдержал и ушел.
'''Роман Юферев. Внедрение Scrum от менеджера — собираем все грабли.''' Попал на конец, и очень жаль. Ожидаю отзывов тех, кто все слышал. Роман послушал тренинг Асхата, проникся и пошел внедрять у себя scrum. Резко и сразу. Команда была сильно не готова, дошло до психологической помощи и выбрасывании фетишей — доски и еще чего-то. А потом потихоньку практики прижились. Так что надо жалеть команду, когда внедряешь.
Из интересного — говорят, у Асхата есть мапинг обязанностей «PMI->должности scrum» (или что-то в этом роде). Интересно это увидеть.
'''Максим Гапонов. Agile глазами менеджера: выбираем правильные очки.''' Опыт внедрения scrum в auto.ru, куда он пришел как менеджер отдела разработки. Проблема была в том, что разработка была сильно непрозрачна для заказчика, и потому было мнение — разработчики работают плохо. А сами они считали, что нормально работают. Внедрение постепенное и итеративное (по практикам), прозрачность была обеспечена. Заодно увеличилась скорость разработки, сначала — в 3 раза. 2 команды, архитектурная команда (как я понял, из тех же людей, супервизоры), продуктовая команда (стратегия и маркетинг). В компетенции менеджера осталось планирование активности и разработки, работа с командой, координация. Когда скорость выросла в 3 раза, выяснилось, что заказчик — не готов выдавать заранее, на итерацию. такой объем работ с достаточной проработкой, и все норовит свалиться к работе по меняющимся требованиям. Плюс срочные задачи. И это даже с недельными итерациями. В целом scrum для менеджера тяжелее, потому что надо больше думать. И требует изменений у смежников. Зато дает эффект.
'''Михаил Ганчиков. Scrum в Fixed-Price проектах: практический опыт.''' Не сначала. Опыт работы scrum в fixed-price разработке с фиксированными сроками на западного заказчика с заказной web-разработкой, интегрированной в его (заказчика) корпоративную систему. Заказчик хотел scrum, но с fixed price и сроками, с рисками на подрядчике. Проект не слишком большой, 4 месяца, 1 команда, 2 недели предварительная оценка. Аналитики были у заказчика, к оценке было 12 usecase, развернутые примерно в 20 историй, разной степени подробности и веса, 50-200 идеальных часов по предварительной оценке в показанных примерах. Они рассчитывали на команду 6 человек — 4 разработчика и 2 тестера. Дальше заказчику удалось продать 6 идеальных часов в день (фактор 0.75!), накладные расходы на scrum (планирование, ретро — 1 день/итерацию), месяц на стабилизацию версии, 10 % на обработку его хотелок по feedback (пытались 30, не вышло), 1.5 человека на управление (PO + 1/2 SM). А в стоимость часа заложили, что если команду придется увеличить в 1.5 раза (до 9) и еще кто-то останется на доводке по гарантии некоторое время, то все равно будет небольшой плюс. Хотя, быть может, что-то из написанного мною как проданное тоже заложили в стоимость часа — эту часть переговоров вел не докладчик. В целом по моим прикидкам заложенный коэффициент к оценке получается 2.5-3. Оценки в идеальных часах заказчик видел и верифицировал у третьих сторон и у себя внутри, в целом нормальные.
В результате на второй месяц команду увеличили до 9 человек, сроки получились на 3 недели больше, но в целом заказчик доволен. Выходных и сверхурочных не было, на команду сильно не давили. Заказчику сделали много дополнительных хотелок, ибо стратегический партнер. Но часть — против уменьшения первоначально заявленного scope. Manager, он ''product owner'', помимо управления и приоритетов писал и поддерживал ''Accept test cases'' — от 2 до 25 на историю. В вики. Адская работа, так как требования уточнялись и плыли, хотя и не сильно. Часть кейсов программировали и проверяли автоматически. Заказчику отгружали релизами, он тоже тестил, посылал баги, feedback («а покрасьте отчет…») и ''change request'' (а еще выгрузку в excel надо). ''Change request'' — это объем работ, который оценивается и расширяет scope, оценки высылались и проверялись заказчиком.
Из практик — помимо ''daily scrum'' с заказчиком были ежедневные вечерние обсуждения (''daily status'') по ходу проекта, по ним — протоколы «минутки» (обязательно нужны!). Заказчику посылались метрики — сжигание оцененных историй. Иерархия разбиения — 3 уровня, ''usecase'' — истории-задачи (уровня реализации). На начальной оценке часть ''usecase'' была совершенно непонятна по объему (например, «перегрузить данные из старой системы»), так как выяснять было некогда, то их оценивали в некоторых допущениях, которые посылались вместе с оценкой. Заказчик или одобрял допущения, или возражал — тогда оценка менялась.
В целом так, может чего забыл. Интересно, но с нашими проектами, по-моему, не слишком соотносится, так как аналитика у нас внутри и это многое меняет. А по эффективности как-то близко получается…
'''Dan Rawsthorne. Who is your Product Owner, and what does he/she do?''' Увы, понимание разговорного английского оставляет желать лучшего… Но в целом было понятно и это интересно. Презентация — тренинг доя PO, но давались фрагменты. Если кратко, то PO — это ''Project Manager''. В полном объеме. Со всеми правами, которыми он не должен злоупотреблять, так как команда — вещь тонкая. Но PO отвечает за продукт (подставляет свою шею). А еще он — ''team lead''. И он — внутри команды. Снаружи есть еще ''Business Owner''. А SM — лишь поддерживает процесс. По итогам итерации различается ''Sprint Review'', которое с PO и ''Retrospective'', которая без него. Дуализм PO — в своей роли и PO как член команды — есть. Но подробностей в эту сторону в голове не осталось. Из явного — он не участвует в некоторых мероприятиях.
Была упомянута [[EnPedia:Responsibility_assignment_matrix|RASCI]]-модель: ''Responsible'' — команда, ''Accountable'' — PO, ''Support'' — SM, ''Consulted'' — внешние эксперты, ''Informed'' — всех вокруг…
Презентовалась конструкция ''Scrum of Scrum'' — с реальной командой менеджеров продукта, в которой свои PO и SM, командами по разработке, и двумя виртуальными командами — PO и SM. Но без подробностей.
Показывалось разделение компетенций ''Business Owner'' (''release goal'', ''product roadmap'', ''vision''), ''Product Owner'' (продукт все внутри условий BO) и SM (организация команды).
Планирование — 4 уровня, ''Product'' — ''Capatibility'' — ''Stories'' — ''Tasks''. ''Backlog'' — ''stories''. Пример ''Capatibility'' для сайта — продавать билеты на самолеты, резервировать отели… Оценка story — size (small/medium/large) с коэффициентами, например, 2/4/8 для перевода в SP. И дальше — по опыту, мощность команды в SP. Для отбора в sprint — баланс ''Scope''/''Effort''/''Debt'' (вроде как новые фичи/исследования/долги). Tasks — на планировании, причем без PO (команда приняла ''Stories'' и сама его делит). Визуальный образ планирования — на доске, слева — ''backlog'', правее карточки с невзятыми задачами. Может, идея прямо так и проводить, но явно это не высказывалось. Оценка задач — в идеальных часах.
В целом — впечатление, что взята классика менедмента и обогащена опеределенными приемами по выделению ответственности вниз и практиками, плюс проведен ребрендинг. В целом сильно похоже на то, что у нас. Хотя это может быть ложное впечатление.
'''Сурен Самарчян. Выявление и решение важнейших проблем компании.''' По исследованиям Гарварда, все сильно успешные компании (лидеры) отличаются от прочих наличием 5 вещей:
* (1) есть система выявления проблем,
* (2) есть подход (процедура) к решению, ориентированный на быстрое решение по низам, позволяющий взять ответственность,
* (3) есть система информации (публикации) успешных решений,
* (4) первые 3 пункта входят в обязанности менеджеров, причем
* (5) на всех уровнях сверху до низу.
Процедуры в разных компаниях — различаются. Тойота 20 (30?) лет назад опубликовала свой, теперь его всячески изучают и пытаются использовать, но повторить с теми же результатми — пока не получилось. Сам Сурен про метод знал, но проникся — только на крутом тренинге в штатах с участием звезд. Метод называется «A3» — в честь специального бланка на формате А3, который надо заполнить по ходу решения и который концентрирует это самое решение. Требования на выходе — за 10 секунд человек, столкнувшийся с такой же проблемой должен опознать ее на бланке, и за 10 минут — понять, как надо решать. Тойота давно хочет перейти на А4, но пока не получается.
Области на бланке по памяти. В презентации все это есть и в инете, говорят, должно быть, но я не нашел.
Лица — владелец проблемы (ответственный) и куратор. Background (задерживаются релизы). Current State (текущий задержан на 2 недели). Корень проблемы. Контрмеры по проблеме в моменте. Изменения стандартов, чтобы исключить проблему в будущем. Заполняется, естественно, по мере решения.
Для поиска корня — искать причину. Можно применять метод «5 почему». Можно — рисовать графы причинно-следственных связей, там будут циклы, а будет — коревое влияние. Пример графов — показывал, но быстро. Контрмеры — всегда эксперимент, сколько бы времени не потратили на планирование. Придумали, не получилось — анализируйте. придумывайте дальше. Когда контрмеры провалились — самый сложный момент для директора и менеджера, всегда найдется пол организации, которые будут говорить «ну вот, мы же говорили — не надо ничего менять, а это — особенно».
Принцип поиска — задавайте вопрос «почему», а не «кто». Даже если этот кто — виноват реально. Потому, что тут же есть вопрос «если этот кто создает такие проблемы, то почему он здесь работает».
При внедрении таких, или аналогичных практик — нужно участие первых лиц, лидеров. Если поручают тому, кто свободен — обречено на провал.
Интересно и полезно. Лист стоит найти.
[[Категория:Конференции]]
Пишу краткие резюме по докладам в порядке прослушивания. Если что вызовет интерес, готов расширить — пишите вопросы.
'''Алексей Кривицкий, Наталья Тренина. Обогащение командного взаимодействия.''' Пошел, потому что трек начинался раньше остальных с мыслью уйти, если не интересно. Ушел поздновато. Был перепев западного по стилю тренинга по коучингу — открытые вопросы, политес, уровни слушания, повторение для внимания, подстройка под собеседника интонаций, позы и прочего, и тому подобное. Слайды и слова лично у меня местами вызывали совершенно стебные ассоциации. Интересно, это специальный эффект, или само получилось, или просто особенности моего личного восприятия, а остальные этого не видели? Типа, когда говорят, что «если собеседник говорит спокойно и медленно, то и вам стоит говорить также», очень хотелось добавить «и тогда вы вместе быстро уснете». В конце концов не выдержал и ушел.
'''Роман Юферев. Внедрение Scrum от менеджера — собираем все грабли.''' Попал на конец, и очень жаль. Ожидаю отзывов тех, кто все слышал. Роман послушал тренинг Асхата, проникся и пошел внедрять у себя scrum. Резко и сразу. Команда была сильно не готова, дошло до психологической помощи и выбрасывании фетишей — доски и еще чего-то. А потом потихоньку практики прижились. Так что надо жалеть команду, когда внедряешь.
Из интересного — говорят, у Асхата есть мапинг обязанностей «PMI->должности scrum» (или что-то в этом роде). Интересно это увидеть.
'''Максим Гапонов. Agile глазами менеджера: выбираем правильные очки.''' Опыт внедрения scrum в auto.ru, куда он пришел как менеджер отдела разработки. Проблема была в том, что разработка была сильно непрозрачна для заказчика, и потому было мнение — разработчики работают плохо. А сами они считали, что нормально работают. Внедрение постепенное и итеративное (по практикам), прозрачность была обеспечена. Заодно увеличилась скорость разработки, сначала — в 3 раза. 2 команды, архитектурная команда (как я понял, из тех же людей, супервизоры), продуктовая команда (стратегия и маркетинг). В компетенции менеджера осталось планирование активности и разработки, работа с командой, координация. Когда скорость выросла в 3 раза, выяснилось, что заказчик — не готов выдавать заранее, на итерацию. такой объем работ с достаточной проработкой, и все норовит свалиться к работе по меняющимся требованиям. Плюс срочные задачи. И это даже с недельными итерациями. В целом scrum для менеджера тяжелее, потому что надо больше думать. И требует изменений у смежников. Зато дает эффект.
'''Михаил Ганчиков. Scrum в Fixed-Price проектах: практический опыт.''' Не сначала. Опыт работы scrum в fixed-price разработке с фиксированными сроками на западного заказчика с заказной web-разработкой, интегрированной в его (заказчика) корпоративную систему. Заказчик хотел scrum, но с fixed price и сроками, с рисками на подрядчике. Проект не слишком большой, 4 месяца, 1 команда, 2 недели предварительная оценка. Аналитики были у заказчика, к оценке было 12 usecase, развернутые примерно в 20 историй, разной степени подробности и веса, 50-200 идеальных часов по предварительной оценке в показанных примерах. Они рассчитывали на команду 6 человек — 4 разработчика и 2 тестера. Дальше заказчику удалось продать 6 идеальных часов в день (фактор 0.75!), накладные расходы на scrum (планирование, ретро — 1 день/итерацию), месяц на стабилизацию версии, 10 % на обработку его хотелок по feedback (пытались 30, не вышло), 1.5 человека на управление (PO + 1/2 SM). А в стоимость часа заложили, что если команду придется увеличить в 1.5 раза (до 9) и еще кто-то останется на доводке по гарантии некоторое время, то все равно будет небольшой плюс. Хотя, быть может, что-то из написанного мною как проданное тоже заложили в стоимость часа — эту часть переговоров вел не докладчик. В целом по моим прикидкам заложенный коэффициент к оценке получается 2.5-3. Оценки в идеальных часах заказчик видел и верифицировал у третьих сторон и у себя внутри, в целом нормальные.
В результате на второй месяц команду увеличили до 9 человек, сроки получились на 3 недели больше, но в целом заказчик доволен. Выходных и сверхурочных не было, на команду сильно не давили. Заказчику сделали много дополнительных хотелок, ибо стратегический партнер. Но часть — против уменьшения первоначально заявленного scope. Manager, он ''product owner'', помимо управления и приоритетов писал и поддерживал ''Accept test cases'' — от 2 до 25 на историю. В вики. Адская работа, так как требования уточнялись и плыли, хотя и не сильно. Часть кейсов программировали и проверяли автоматически. Заказчику отгружали релизами, он тоже тестил, посылал баги, feedback («а покрасьте отчет…») и ''change request'' (а еще выгрузку в excel надо). ''Change request'' — это объем работ, который оценивается и расширяет scope, оценки высылались и проверялись заказчиком.
Из практик — помимо ''daily scrum'' с заказчиком были ежедневные вечерние обсуждения (''daily status'') по ходу проекта, по ним — протоколы «минутки» (обязательно нужны!). Заказчику посылались метрики — сжигание оцененных историй. Иерархия разбиения — 3 уровня, ''usecase'' — истории-задачи (уровня реализации). На начальной оценке часть ''usecase'' была совершенно непонятна по объему (например, «перегрузить данные из старой системы»), так как выяснять было некогда, то их оценивали в некоторых допущениях, которые посылались вместе с оценкой. Заказчик или одобрял допущения, или возражал — тогда оценка менялась.
В целом так, может чего забыл. Интересно, но с нашими проектами, по-моему, не слишком соотносится, так как аналитика у нас внутри и это многое меняет. А по эффективности как-то близко получается…
'''Dan Rawsthorne. Who is your Product Owner, and what does he/she do?''' Увы, понимание разговорного английского оставляет желать лучшего… Но в целом было понятно и это интересно. Презентация — тренинг доя PO, но давались фрагменты. Если кратко, то PO — это ''Project Manager''. В полном объеме. Со всеми правами, которыми он не должен злоупотреблять, так как команда — вещь тонкая. Но PO отвечает за продукт (подставляет свою шею). А еще он — ''team lead''. И он — внутри команды. Снаружи есть еще ''Business Owner''. А SM — лишь поддерживает процесс. По итогам итерации различается ''Sprint Review'', которое с PO и ''Retrospective'', которая без него. Дуализм PO — в своей роли и PO как член команды — есть. Но подробностей в эту сторону в голове не осталось. Из явного — он не участвует в некоторых мероприятиях.
Была упомянута [[EnPedia:Responsibility_assignment_matrix|RASCI]]-модель: ''Responsible'' — команда, ''Accountable'' — PO, ''Support'' — SM, ''Consulted'' — внешние эксперты, ''Informed'' — всех вокруг…
Презентовалась конструкция ''Scrum of Scrum'' — с реальной командой менеджеров продукта, в которой свои PO и SM, командами по разработке, и двумя виртуальными командами — PO и SM. Но без подробностей.
Показывалось разделение компетенций ''Business Owner'' (''release goal'', ''product roadmap'', ''vision''), ''Product Owner'' (продукт все внутри условий BO) и SM (организация команды).
Планирование — 4 уровня, ''Product'' — ''Capatibility'' — ''Stories'' — ''Tasks''. ''Backlog'' — ''stories''. Пример ''Capatibility'' для сайта — продавать билеты на самолеты, резервировать отели… Оценка story — size (small/medium/large) с коэффициентами, например, 2/4/8 для перевода в SP. И дальше — по опыту, мощность команды в SP. Для отбора в sprint — баланс ''Scope''/''Effort''/''Debt'' (вроде как новые фичи/исследования/долги). Tasks — на планировании, причем без PO (команда приняла ''Stories'' и сама его делит). Визуальный образ планирования — на доске, слева — ''backlog'', правее карточки с невзятыми задачами. Может, идея прямо так и проводить, но явно это не высказывалось. Оценка задач — в идеальных часах.
В целом — впечатление, что взята классика менедмента и обогащена опеределенными приемами по выделению ответственности вниз и практиками, плюс проведен ребрендинг. В целом сильно похоже на то, что у нас. Хотя это может быть ложное впечатление.
'''Сурен Самарчян. Выявление и решение важнейших проблем компании.''' По исследованиям Гарварда, все сильно успешные компании (лидеры) отличаются от прочих наличием 5 вещей:
* (1) есть система выявления проблем,
* (2) есть подход (процедура) к решению, ориентированный на быстрое решение по низам, позволяющий взять ответственность,
* (3) есть система информации (публикации) успешных решений,
* (4) первые 3 пункта входят в обязанности менеджеров, причем
* (5) на всех уровнях сверху до низу.
Процедуры в разных компаниях — различаются. Тойота 20 (30?) лет назад опубликовала свой, теперь его всячески изучают и пытаются использовать, но повторить с теми же результатми — пока не получилось. Сам Сурен про метод знал, но проникся — только на крутом тренинге в штатах с участием звезд. Метод называется «A3» — в честь специального бланка на формате А3, который надо заполнить по ходу решения и который концентрирует это самое решение. Требования на выходе — за 10 секунд человек, столкнувшийся с такой же проблемой должен опознать ее на бланке, и за 10 минут — понять, как надо решать. Тойота давно хочет перейти на А4, но пока не получается.
Области на бланке по памяти. В презентации все это есть и в инете, говорят, должно быть, но я не нашел.
Лица — владелец проблемы (ответственный) и куратор. Background (задерживаются релизы). Current State (текущий задержан на 2 недели). Корень проблемы. Контрмеры по проблеме в моменте. Изменения стандартов, чтобы исключить проблему в будущем. Заполняется, естественно, по мере решения.
Для поиска корня — искать причину. Можно применять метод «5 почему». Можно — рисовать графы причинно-следственных связей, там будут циклы, а будет — коревое влияние. Пример графов — показывал, но быстро. Контрмеры — всегда эксперимент, сколько бы времени не потратили на планирование. Придумали, не получилось — анализируйте. придумывайте дальше. Когда контрмеры провалились — самый сложный момент для директора и менеджера, всегда найдется пол организации, которые будут говорить «ну вот, мы же говорили — не надо ничего менять, а это — особенно».
Принцип поиска — задавайте вопрос «почему», а не «кто». Даже если этот кто — виноват реально. Потому, что тут же есть вопрос «если этот кто создает такие проблемы, то почему он здесь работает».
При внедрении таких, или аналогичных практик — нужно участие первых лиц, лидеров. Если поручают тому, кто свободен — обречено на провал.
Интересно и полезно. Лист стоит найти.
[[Категория:Конференции]]
