MaksTsepkov: Массовая правка: замена Категория:Конференции на Категория:AgileDays

2023-04-24T09:47:32Z

Массовая правка: замена Категория:Конференции на Категория:AgileDays

MaksTsepkov в 14:11, 31 мая 2022

2022-05-31T14:11:49Z

MaksTsepkov: Новая страница: «Был на половинке конференции Ag;)leDays’09. Жаль, что не на всей. Пишу краткие резюме по докла…»

2018-05-17T15:55:27Z

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

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

При внедрении таких, или аналогичных практик — нужно участие первых лиц, лидеров. Если поручают тому, кто свободен — обречено на провал.

Интересно и полезно. Лист стоит найти.

[[Категория:Конференции]]

← Предыдущая		Версия 09:47, 24 апреля 2023
Строка 52:		Строка 52:
	Интересно и полезно. Лист стоит найти.		Интересно и полезно. Лист стоит найти.

−	[[Категория:~~Конференции~~]]	+	[[Категория:AgileDays]]

@@ Строка 21: / Строка 21: @@
 '''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'' — всех вокруг…
+Была упомянута [https://en.wikipedia.org/wiki/Responsibility_assignment_matrix RASCI]-модель: ''Responsible'' — команда, ''Accountable'' — PO, ''Support'' — SM, ''Consulted'' — внешние эксперты, ''Informed'' — всех вокруг…
 Презентовалась конструкция ''Scrum of Scrum'' — с реальной командой менеджеров продукта, в которой свои PO и SM, командами по разработке, и двумя виртуальными командами — PO и SM. Но без подробностей.

AgileDays-2009 - История изменений

MaksTsepkov: Массовая правка: замена Категория:Конференции на Категория:AgileDays

MaksTsepkov в 14:11, 31 мая 2022

MaksTsepkov: Новая страница: «Был на половинке конференции Ag;)leDays’09. Жаль, что не на всей. Пишу краткие резюме по докла…»