Изменения
Новая страница: «На конференцию [http://agiledays.ru/ AgileDays] приезжал Henrik Kniberg, который 2 дня перед началом конференци...»
На конференцию [http://agiledays.ru/ AgileDays-2011] приезжал Henrik Kniberg, который 2 дня перед началом конференции проводил тренинг по Agile, кстати, слайды с тренинга лежат у него [http://www.crisp.se/henrik.kniberg/csm-links на сайте]. Я на тренинге был, вынес много полезного и хочу поделиться впечатлениями.
= Немного истории =
Для начала немного истории - для тех, кто не в курсе. Agile методологии разработки родились в противовес классическим, водопадным моделям, в которых результата пытались достичь за счет процедур и регламентов. Как выяснилось, процедуры и регламенты не дают '''гарантированного''' и '''предсказуемого''' результата разработки. Зато сильно зажимают свободу и творчество программиста. И в противовес им родились легкие практики, которые поменяли парадигму, и достигают приемлемого уровня предсказуемости, но гораздо меньшими усилиями. И сейчас они успешно завоевывают мир, включая крупные компании, типа Microsoft и IBM.
Agile включает в себя множество вариантов процессов, наиболее известные - Scrum, XP, Kanban, и семейство xDD. Из них Scrum и Kanban - управленческие, а остальные - преимущественно разработческие, при этом многие из них можно применять совместно или создавать комбинированный вариант. Что их принципиально отличает от традиционных практик - это категорический отказ от микроменеджмента, явного назначения задач и ставка на самоорганизующуюся команду.
Scrum - это способ решить проблему нехватки руководителей проектов, особенно острую в наукоемких и творческих областях, таких как как в программировании. Программисты обычно не очень горят желанием заниматься организационными буднями руководства, а менеджеры, умеющие лишь управлять не слишком справляются из-за особенностей предметной области. Scrum обеспечивает это за счет деления повседневных обязанностей менеджера на две части: product owner направляет работу, это близко программистам, а организационные будни перекладываются на команду, которую слегка организует scrum master. Дополнительные выгоды - хороший product owner получает возможность руководить большим числом продуктов, а хороший менеджер - присматривать за большим числом команд. Потому что часть организационной рутины с них сняли.
Kanban появился позже и как еще более легкая практика, применимая в областях типа сопровождения и других, в которых идет большой поток слабо предсказуемых задач.
Хенрик Книберг - один из крупнейших практиков Agile. Его книга Scrum and XP from the Trenches описывает практики Scrum и, на мой взгляд, является лучшей по этому вопросу. Во всяком случае, именно она в 2007 вдохновила нас на внедрение Scrum в нашей компании. Сейчас она доступна в [http://scrum.org.ua/wp-content/uploads/2008/12/scrum_xp-from-the-trenches-rus-final.pdf русском переводе].
= О самом тренинге =
Книберг — играющий тренер, который зарабатывает внедрением Scrum, Канбан и композитных процессов в разных проектах, где оценивают достижения по результату — то есть увеличению скорости разработки или просто спасению проваливающихся проектов. Он говорит, что обычно удается поднять скорость в 2-2.5 раза и по историям и вообще общему впечатлению я склонен ему доверять. Вообще Agile и SCRUM, возникшие как противовес традиционному менеджменту сейчас изменились и превратились в эффективный инструмент тех менеджеров, которые умеют его применять. И дальше я буду тезисно излагать те вещи, которые показались мне важными — потому, что они отражают эти изменения, или потому что я их понял более отчетливо.
'''Роли и их разделение'''.
* ''Product Owner'' отвечает за продукт, а ''SCRUM Master'' — отвечает за процесс в команде. И это бьется очень четко и всеобъемлюще.
* PO — продукт целиком, его интересует общая скорость и другие характеристики. Ответственность включает ROI и экономические составляющие, включая выход и стоимость команды. Но внутрь команды он не смотри, для него команда — целиком, в том числе с точки зрения стоимости.
* SM — ответственность за процесс, внутренняя (coach) и внешняя (коммуникации с внешними людьми). Именно он представляет реальный вклад сотрудников команды, смотрит кому и где надо помочь и это организует. Не административно, а предлагая, но в целом — его scope. В том числе — может организовывать привлечение экспертов, если это повысит производительность — согласовав с PO, так как стоимость команды тоже возрастет.
* Деление PO-SM, помимо прочего, позволяет сделать явным поиск компромисса и вовлечь в процесс команду.
* Новые члены — с учетом мнения команды, интервью все или хотя бы один (это уже после HR, естественно).
* За технические решения отвечает команда. Она может инициировать включение в PBL задач, касающихся архитектуры, рефакторинга и прочего, высказывать мнение по приоритетам, которые следуют из техники реализации. Но принятие решения по приоритетам — за PO, он команду слушает, но решает сам.
* Еще есть менеджер, но он — один на много команд. Его задача — зарплата, контракт с сотрудником и подобные вещи. При этом для обратной связи о вкладе человека, его эффективности — он общается со SM. Плюс — может приходить на DSM и прочие мероприятия, беседовать и так далее — для получения нужной ему информации.
* Полной взаимозаменяемости нет, все люди — разные, с разным опытом и по-разному решают задачи. Разделение труда в команде есть или может быть. Жесткость — зависит от конкретного проекта. PO и/или SM могут стремиться к увеличению опыта членами команды за счет непрофильных задач или наоборот, пренебрегать рисками и ориентироваться на то, чтобы каждый брал профильные задачи. В зависимости от этого меняется стратегия оценки при планировании: могут брать оценку для профильного сотрудника, или среднюю, но команда должна договориться. Плюс, когда спринт не сбалансирован с опытом команды — она это учитывает при оценке.
'''Планирование и организация'''.
* Есть ''release plan'' (на 8-10 спринтов, 20-30 недель), который в крупном, в ''feature'' или ''user story'', и он предварительно, в крупном, оценен командой.
* Поскольку есть оценка — то достижение результата в крупном, скорость реализации — контролируется.
* Но спринт — тоже, естественно, оценивается. Оценка может совпасть или нет, по разным причинам. Может быть особенность задачи, а может быть ситуация, когда команда набрала опыт и научилась точнее оценивать. Во второй ситуации PO может понять о коррекции начальных планов и что-нибудь предпринять по этому поводу.
* Исходные данные для формирования SBL итерации — не только PBL, но и цели: ''business'', ''learning'', ''risk'', ''technical dependencies''.
* Важно ограничивать число тем итерации, переключения контекста — дорого. В идеале — один основная тема и одна фоновая. От итерации к итерации темы можно менять.
* Есть мероприятие — ''Backlog workshop'', проводится каждую неделю, PO + команда, оценивается текущее состояние, могут вноситься изменения.
* Окончательно перешли к оценке в попугаях (''story point''). В них меняют ''velocity'' на спринт, а при планировании из нее получают объем спринта в SP (с учетом фактических человеко-дней). Если есть фиксированные по времени мероприятия, то их надо вычесть из длительности спринта. SP оценки спринта и релиза, в общем случае — разные, коэффициент уточняется по прошедшим спринтам.
'''Оценка в SP'''.
* Почему перешли на оценку в SP (''story point'')? Это — опыт. При такой оценке команда быстрее приходит к согласию, чем при оценке в идеальных днях/часах. И легче калибровать разные команды, передавать им подходы к оценке. А точность — не уменьшается. Для рефлексии о причинах падения скорости SP обычно хватает, если какая-то одна-две задачи несоразмерно выросли.
* Как первоначально получают оценку в SP? На начальной оценке release PBL берут простую и понятную всем историю, которую оценивают, например, в 3 SP или 5 SP. Получается начальный масштаб, от которого дальше пляшут. Когда переходят к оценке спринта и оценивают task, на которые поделили user story, то оценка user story задает некоторый масштаб, пока команды не привыкнут. Но при этом укладываться и подгонять не обязательно, более того у многих есть практики не показывать на планировании спринта оценки user story, во всяком случае сначала — чтобы они не влияли на оценки отдельных задач. Но в случае расхождений — разбираться, вопрос в подробностях задачи или более систематично что-то поплыло.
* Новичкам для калибровки оценок полезно посмотреть оценки предыдущих спринтов до первого планирования. И, опять-таки, оценить задачу как «похожую на ту» легче, чем прикинуть часы.
'''О SM'''
* Если кто не разделяет цели — гнать из команды. Движение должно быть сонаправленным. Размер шага (скорость) — не так важны, это тренируется, если человек разделяет цели. Ответственность за фиксацию таких проблем — на SM.
* Про SM, не смотря на много «управляющих» функций по процессу, явный акцент Книберга на самовыдвижении и отсутствии формальной власти. И SM создает условия для самоорганизации, а не управляет. Основне средство — вопрос «А что вы думаете о …» (а не «Давайте решим такую проблему…»).
* Если есть персональные проблемы, например, кто-то систематически не соблюдает стандарт кодирования и на review это вылезает, то задача SM — это выявить. Хотя на ретро об этом могут не говорить. Поговорить до ретро с членами команды, а дальше по обстановки — можно индивидуально, можно на ретро. То, что это в компетенции SM — «по умолчанию».
'''Процесс в целом'''
* Практика, когда задачу заранее готовят к выполнению, например, постановка силами той же команды или согласование с заказчиком — распространенная. И хорошая техника — вместе с DoD сделать ''Definition of Ready'' — check list, что должно быть у задачи, чтобы ее можно было запускать в спринт. Пример DoR: есть bug, grade S/M/L, есть acceptante test.
* Еще раз сформулировали — кросс-функциональная команда — не значит, что каждый заменяет каждого. Но значит, что нет критичного для процесса человека, и в целом компетенции сбалансированы с потоком задач с учетом отклонений. Техника: матрица деятельность (DB/Java/Design/Test, например) — сотрудник, на пересечении — оценка: пусто/точка/звездочка. Должно быть минимум две звездочки и несколько точек, если нет, то включаем в цели их прокачку у конкретных участников в ходе спринта за счет выполнения задач (например).
* Project Manager в смысле CMMI поделен в SCRUM примерно так:
** release plan — PO
** build team — SM
** архитектура — команда
** раздача задач — task board
** набор персонала — за рамками команды
* Надо ограничивать количество задач, находящихся в работе. На это есть мат.модель (правда тут надо смотреть, насколько плюшевая, я готов рассказать подробности). Кратко так. Если дело проходит через несколько стадий, и на каждой имеет некоторую неопределенную трудоемкость (например, от 1 до 3), то с некоторого числа дел в работе мощность выходит на плато, но чем меньше дел в работе — тем быстрее новое дело, вкинутое на вход, появится на выходе. И это — без узкого горла. Если стадий 5, то в работе оптимально 7 начатых дел. Практически это мощное ограничение, особенно с учетом дорогого переключения контекста, и надо этим пользоваться, и того, что люди не могут одновременно держать много целей.
* ''Working smart more important than working hard''. Не рубите деревья бензопилой, а пилите, и вообще не рубите деревья молотком. Используя SCRUM смотрите, насколько подходит.
'''Две команды на одном продукте'''.
* Итерации — рекомендуется синхронно, и общий релиз. Иначе сложно с кодом.
* Задачи на итерации делить можно на общей сессии: все задачи висят на доске, команды у них и высказывают желания, а PO — отдает. Как вариант — в каждой команде свой «локальный PO», который берет задачи от общего, так тоже можно.
'''Разные техники'''.
* Варианты с 2-3 командами на одном продукте с общим кодом и нескольких продуктов для одной команды — вполне рабочие.
* Команды должны быть стабильны. В цифрах это означает устойчивое существование 3-6 месяцев.
* Новая команда по опыту выходит на плато скорости за 1-2 месяца.
* В презентации есть интересные ссылки на исследования психологов — как оценивает команда одну спецификацию в зависимости от разных факторов. Например, от числа листов, полученного увеличением размера шрифта (коэффициент 1.5) или предварительно высказанной оценки стороннего эксперта. Первичку, кто интересуется, думаю, можно найти — ссылка была на ''Simula research lab'', ''Еstimation'' …, ''Oslo 2006''.
* «Не бывает низкой скорости, бывают нереалистичные планы». Потому что скорость сама — не поднимется, над этим надо работать.
* Что мотивирует (это известно, но, тем не менее):
** Autonomy = свобода, самоопределение (да. в рамках, но рамки — они везде есть)
** Mastery = передовые технологии
** Purpose = понятные, осмысленные и ценные задачи, которые делаем
* Если у команды период активной поддержки, то можно резервировать на это некоторую долю времени при планировании спринта, а можно — вставлять в SBL задачи типа «фиксируем 10 самых критичных багов».
* Если возник стресс и запарка — найдите силу воли сделать паузу и проанализировать причины.
* Любопытный пример. Kanban of SCRUM, на 60 человек. Большая доска, слева область для подготовки, потом область выполнения — разбита на 4 части для отдельных scrum-команд — задача уходит на их доску, а после спринта — возвращается на общую. Впечатляет. И, возможно, на проектах с несколькими командами типа ГПБ — может быть полезным.
* Где-то всплыл сайт http://userstories.com - всякие тулы и прочее для поддержки. Может, кому интересно — даю ссылку.
Метафоры и образы.
* Водопад как последовательные выстрелы из лука: облако заказа, Req стреляет — получает требования, Designer — получает проект, разработчики — результат. Все как-то промахиваются, естественно — наводят на одно, получают другое. Ну и Заказчик реально хотел не то, что заказал.
* Водопад как стрельба из пушки по движущейся мишени. Agile (SCRUM) как самонаводящаяся на цель ракета вместо этого.
Повсеместная '''работа с карточками''' меня впечатлила. Техника ведения трека через карточки, которые сначала есть в PBL, потом помещаются на мини-доску Todo/Doing/Done, а потом — в сделанное в рамках спринта может быть полезна на собраниях с повесткой дня. Я, во всяком случае, буду пробовать. Приоритеты — тоже через них. И bring down на планировании — user story на доске, пишем task и вешаем.
'''Общение с другими'''.
* Было много участников, успешно применяющих scrum и приехавших. чтобы улучшить опыт. Сам scrum — разный, в том числе в варианте, когда scrum master близок к менеджеру. У других — упор на PO, есть те, у кого он в команде.
* Была практика, когда один SM ведет две команды, и это — его полная загрузка, а задача его — именно наладить процесс. При этом он знает разряды сотрудников и следит за адекватным вкладу разрядом, говоря о проблемах индивидуально. На ретро или эскалируя.
* Планирование 2-недельной итерации вместе с декомпозицией story на task — полдня, 4 часа.
* SCRUM позволяет делать качественные вещи, вопрос в применяемых практиках. Например, может быть жесткое требование, что по каждой user story — пишем acceptant test (пишет или утверждает PO), который развертывают в test case. И все это делает команда.
* Есть практика тех.лидов, тоже поделенных на 2 команды и занимающихся техническими архитектурными вопросами.
[[Категория:Внешние события]]
= Немного истории =
Для начала немного истории - для тех, кто не в курсе. Agile методологии разработки родились в противовес классическим, водопадным моделям, в которых результата пытались достичь за счет процедур и регламентов. Как выяснилось, процедуры и регламенты не дают '''гарантированного''' и '''предсказуемого''' результата разработки. Зато сильно зажимают свободу и творчество программиста. И в противовес им родились легкие практики, которые поменяли парадигму, и достигают приемлемого уровня предсказуемости, но гораздо меньшими усилиями. И сейчас они успешно завоевывают мир, включая крупные компании, типа Microsoft и IBM.
Agile включает в себя множество вариантов процессов, наиболее известные - Scrum, XP, Kanban, и семейство xDD. Из них Scrum и Kanban - управленческие, а остальные - преимущественно разработческие, при этом многие из них можно применять совместно или создавать комбинированный вариант. Что их принципиально отличает от традиционных практик - это категорический отказ от микроменеджмента, явного назначения задач и ставка на самоорганизующуюся команду.
Scrum - это способ решить проблему нехватки руководителей проектов, особенно острую в наукоемких и творческих областях, таких как как в программировании. Программисты обычно не очень горят желанием заниматься организационными буднями руководства, а менеджеры, умеющие лишь управлять не слишком справляются из-за особенностей предметной области. Scrum обеспечивает это за счет деления повседневных обязанностей менеджера на две части: product owner направляет работу, это близко программистам, а организационные будни перекладываются на команду, которую слегка организует scrum master. Дополнительные выгоды - хороший product owner получает возможность руководить большим числом продуктов, а хороший менеджер - присматривать за большим числом команд. Потому что часть организационной рутины с них сняли.
Kanban появился позже и как еще более легкая практика, применимая в областях типа сопровождения и других, в которых идет большой поток слабо предсказуемых задач.
Хенрик Книберг - один из крупнейших практиков Agile. Его книга Scrum and XP from the Trenches описывает практики Scrum и, на мой взгляд, является лучшей по этому вопросу. Во всяком случае, именно она в 2007 вдохновила нас на внедрение Scrum в нашей компании. Сейчас она доступна в [http://scrum.org.ua/wp-content/uploads/2008/12/scrum_xp-from-the-trenches-rus-final.pdf русском переводе].
= О самом тренинге =
Книберг — играющий тренер, который зарабатывает внедрением Scrum, Канбан и композитных процессов в разных проектах, где оценивают достижения по результату — то есть увеличению скорости разработки или просто спасению проваливающихся проектов. Он говорит, что обычно удается поднять скорость в 2-2.5 раза и по историям и вообще общему впечатлению я склонен ему доверять. Вообще Agile и SCRUM, возникшие как противовес традиционному менеджменту сейчас изменились и превратились в эффективный инструмент тех менеджеров, которые умеют его применять. И дальше я буду тезисно излагать те вещи, которые показались мне важными — потому, что они отражают эти изменения, или потому что я их понял более отчетливо.
'''Роли и их разделение'''.
* ''Product Owner'' отвечает за продукт, а ''SCRUM Master'' — отвечает за процесс в команде. И это бьется очень четко и всеобъемлюще.
* PO — продукт целиком, его интересует общая скорость и другие характеристики. Ответственность включает ROI и экономические составляющие, включая выход и стоимость команды. Но внутрь команды он не смотри, для него команда — целиком, в том числе с точки зрения стоимости.
* SM — ответственность за процесс, внутренняя (coach) и внешняя (коммуникации с внешними людьми). Именно он представляет реальный вклад сотрудников команды, смотрит кому и где надо помочь и это организует. Не административно, а предлагая, но в целом — его scope. В том числе — может организовывать привлечение экспертов, если это повысит производительность — согласовав с PO, так как стоимость команды тоже возрастет.
* Деление PO-SM, помимо прочего, позволяет сделать явным поиск компромисса и вовлечь в процесс команду.
* Новые члены — с учетом мнения команды, интервью все или хотя бы один (это уже после HR, естественно).
* За технические решения отвечает команда. Она может инициировать включение в PBL задач, касающихся архитектуры, рефакторинга и прочего, высказывать мнение по приоритетам, которые следуют из техники реализации. Но принятие решения по приоритетам — за PO, он команду слушает, но решает сам.
* Еще есть менеджер, но он — один на много команд. Его задача — зарплата, контракт с сотрудником и подобные вещи. При этом для обратной связи о вкладе человека, его эффективности — он общается со SM. Плюс — может приходить на DSM и прочие мероприятия, беседовать и так далее — для получения нужной ему информации.
* Полной взаимозаменяемости нет, все люди — разные, с разным опытом и по-разному решают задачи. Разделение труда в команде есть или может быть. Жесткость — зависит от конкретного проекта. PO и/или SM могут стремиться к увеличению опыта членами команды за счет непрофильных задач или наоборот, пренебрегать рисками и ориентироваться на то, чтобы каждый брал профильные задачи. В зависимости от этого меняется стратегия оценки при планировании: могут брать оценку для профильного сотрудника, или среднюю, но команда должна договориться. Плюс, когда спринт не сбалансирован с опытом команды — она это учитывает при оценке.
'''Планирование и организация'''.
* Есть ''release plan'' (на 8-10 спринтов, 20-30 недель), который в крупном, в ''feature'' или ''user story'', и он предварительно, в крупном, оценен командой.
* Поскольку есть оценка — то достижение результата в крупном, скорость реализации — контролируется.
* Но спринт — тоже, естественно, оценивается. Оценка может совпасть или нет, по разным причинам. Может быть особенность задачи, а может быть ситуация, когда команда набрала опыт и научилась точнее оценивать. Во второй ситуации PO может понять о коррекции начальных планов и что-нибудь предпринять по этому поводу.
* Исходные данные для формирования SBL итерации — не только PBL, но и цели: ''business'', ''learning'', ''risk'', ''technical dependencies''.
* Важно ограничивать число тем итерации, переключения контекста — дорого. В идеале — один основная тема и одна фоновая. От итерации к итерации темы можно менять.
* Есть мероприятие — ''Backlog workshop'', проводится каждую неделю, PO + команда, оценивается текущее состояние, могут вноситься изменения.
* Окончательно перешли к оценке в попугаях (''story point''). В них меняют ''velocity'' на спринт, а при планировании из нее получают объем спринта в SP (с учетом фактических человеко-дней). Если есть фиксированные по времени мероприятия, то их надо вычесть из длительности спринта. SP оценки спринта и релиза, в общем случае — разные, коэффициент уточняется по прошедшим спринтам.
'''Оценка в SP'''.
* Почему перешли на оценку в SP (''story point'')? Это — опыт. При такой оценке команда быстрее приходит к согласию, чем при оценке в идеальных днях/часах. И легче калибровать разные команды, передавать им подходы к оценке. А точность — не уменьшается. Для рефлексии о причинах падения скорости SP обычно хватает, если какая-то одна-две задачи несоразмерно выросли.
* Как первоначально получают оценку в SP? На начальной оценке release PBL берут простую и понятную всем историю, которую оценивают, например, в 3 SP или 5 SP. Получается начальный масштаб, от которого дальше пляшут. Когда переходят к оценке спринта и оценивают task, на которые поделили user story, то оценка user story задает некоторый масштаб, пока команды не привыкнут. Но при этом укладываться и подгонять не обязательно, более того у многих есть практики не показывать на планировании спринта оценки user story, во всяком случае сначала — чтобы они не влияли на оценки отдельных задач. Но в случае расхождений — разбираться, вопрос в подробностях задачи или более систематично что-то поплыло.
* Новичкам для калибровки оценок полезно посмотреть оценки предыдущих спринтов до первого планирования. И, опять-таки, оценить задачу как «похожую на ту» легче, чем прикинуть часы.
'''О SM'''
* Если кто не разделяет цели — гнать из команды. Движение должно быть сонаправленным. Размер шага (скорость) — не так важны, это тренируется, если человек разделяет цели. Ответственность за фиксацию таких проблем — на SM.
* Про SM, не смотря на много «управляющих» функций по процессу, явный акцент Книберга на самовыдвижении и отсутствии формальной власти. И SM создает условия для самоорганизации, а не управляет. Основне средство — вопрос «А что вы думаете о …» (а не «Давайте решим такую проблему…»).
* Если есть персональные проблемы, например, кто-то систематически не соблюдает стандарт кодирования и на review это вылезает, то задача SM — это выявить. Хотя на ретро об этом могут не говорить. Поговорить до ретро с членами команды, а дальше по обстановки — можно индивидуально, можно на ретро. То, что это в компетенции SM — «по умолчанию».
'''Процесс в целом'''
* Практика, когда задачу заранее готовят к выполнению, например, постановка силами той же команды или согласование с заказчиком — распространенная. И хорошая техника — вместе с DoD сделать ''Definition of Ready'' — check list, что должно быть у задачи, чтобы ее можно было запускать в спринт. Пример DoR: есть bug, grade S/M/L, есть acceptante test.
* Еще раз сформулировали — кросс-функциональная команда — не значит, что каждый заменяет каждого. Но значит, что нет критичного для процесса человека, и в целом компетенции сбалансированы с потоком задач с учетом отклонений. Техника: матрица деятельность (DB/Java/Design/Test, например) — сотрудник, на пересечении — оценка: пусто/точка/звездочка. Должно быть минимум две звездочки и несколько точек, если нет, то включаем в цели их прокачку у конкретных участников в ходе спринта за счет выполнения задач (например).
* Project Manager в смысле CMMI поделен в SCRUM примерно так:
** release plan — PO
** build team — SM
** архитектура — команда
** раздача задач — task board
** набор персонала — за рамками команды
* Надо ограничивать количество задач, находящихся в работе. На это есть мат.модель (правда тут надо смотреть, насколько плюшевая, я готов рассказать подробности). Кратко так. Если дело проходит через несколько стадий, и на каждой имеет некоторую неопределенную трудоемкость (например, от 1 до 3), то с некоторого числа дел в работе мощность выходит на плато, но чем меньше дел в работе — тем быстрее новое дело, вкинутое на вход, появится на выходе. И это — без узкого горла. Если стадий 5, то в работе оптимально 7 начатых дел. Практически это мощное ограничение, особенно с учетом дорогого переключения контекста, и надо этим пользоваться, и того, что люди не могут одновременно держать много целей.
* ''Working smart more important than working hard''. Не рубите деревья бензопилой, а пилите, и вообще не рубите деревья молотком. Используя SCRUM смотрите, насколько подходит.
'''Две команды на одном продукте'''.
* Итерации — рекомендуется синхронно, и общий релиз. Иначе сложно с кодом.
* Задачи на итерации делить можно на общей сессии: все задачи висят на доске, команды у них и высказывают желания, а PO — отдает. Как вариант — в каждой команде свой «локальный PO», который берет задачи от общего, так тоже можно.
'''Разные техники'''.
* Варианты с 2-3 командами на одном продукте с общим кодом и нескольких продуктов для одной команды — вполне рабочие.
* Команды должны быть стабильны. В цифрах это означает устойчивое существование 3-6 месяцев.
* Новая команда по опыту выходит на плато скорости за 1-2 месяца.
* В презентации есть интересные ссылки на исследования психологов — как оценивает команда одну спецификацию в зависимости от разных факторов. Например, от числа листов, полученного увеличением размера шрифта (коэффициент 1.5) или предварительно высказанной оценки стороннего эксперта. Первичку, кто интересуется, думаю, можно найти — ссылка была на ''Simula research lab'', ''Еstimation'' …, ''Oslo 2006''.
* «Не бывает низкой скорости, бывают нереалистичные планы». Потому что скорость сама — не поднимется, над этим надо работать.
* Что мотивирует (это известно, но, тем не менее):
** Autonomy = свобода, самоопределение (да. в рамках, но рамки — они везде есть)
** Mastery = передовые технологии
** Purpose = понятные, осмысленные и ценные задачи, которые делаем
* Если у команды период активной поддержки, то можно резервировать на это некоторую долю времени при планировании спринта, а можно — вставлять в SBL задачи типа «фиксируем 10 самых критичных багов».
* Если возник стресс и запарка — найдите силу воли сделать паузу и проанализировать причины.
* Любопытный пример. Kanban of SCRUM, на 60 человек. Большая доска, слева область для подготовки, потом область выполнения — разбита на 4 части для отдельных scrum-команд — задача уходит на их доску, а после спринта — возвращается на общую. Впечатляет. И, возможно, на проектах с несколькими командами типа ГПБ — может быть полезным.
* Где-то всплыл сайт http://userstories.com - всякие тулы и прочее для поддержки. Может, кому интересно — даю ссылку.
Метафоры и образы.
* Водопад как последовательные выстрелы из лука: облако заказа, Req стреляет — получает требования, Designer — получает проект, разработчики — результат. Все как-то промахиваются, естественно — наводят на одно, получают другое. Ну и Заказчик реально хотел не то, что заказал.
* Водопад как стрельба из пушки по движущейся мишени. Agile (SCRUM) как самонаводящаяся на цель ракета вместо этого.
Повсеместная '''работа с карточками''' меня впечатлила. Техника ведения трека через карточки, которые сначала есть в PBL, потом помещаются на мини-доску Todo/Doing/Done, а потом — в сделанное в рамках спринта может быть полезна на собраниях с повесткой дня. Я, во всяком случае, буду пробовать. Приоритеты — тоже через них. И bring down на планировании — user story на доске, пишем task и вешаем.
'''Общение с другими'''.
* Было много участников, успешно применяющих scrum и приехавших. чтобы улучшить опыт. Сам scrum — разный, в том числе в варианте, когда scrum master близок к менеджеру. У других — упор на PO, есть те, у кого он в команде.
* Была практика, когда один SM ведет две команды, и это — его полная загрузка, а задача его — именно наладить процесс. При этом он знает разряды сотрудников и следит за адекватным вкладу разрядом, говоря о проблемах индивидуально. На ретро или эскалируя.
* Планирование 2-недельной итерации вместе с декомпозицией story на task — полдня, 4 часа.
* SCRUM позволяет делать качественные вещи, вопрос в применяемых практиках. Например, может быть жесткое требование, что по каждой user story — пишем acceptant test (пишет или утверждает PO), который развертывают в test case. И все это делает команда.
* Есть практика тех.лидов, тоже поделенных на 2 команды и занимающихся техническими архитектурными вопросами.
[[Категория:Внешние события]]