2011-03-03: Тренинг Книберга - день второй
м (Новая страница: «Итак, сегодня был второй день тренинга Генриха Книберга. Тоже очень полезный. Фиксирую впе...») |
м |
||
Строка 2: | Строка 2: | ||
'''Оценка в SP'''. | '''Оценка в SP'''. | ||
− | * Почему перешли на оценку в SP (story point)? Это | + | * Почему перешли на оценку в SP (''story point'')? Это — опыт. При такой оценке команда быстрее приходит к согласию, чем при оценке в идеальных днях/часах. И легче калибровать разные команды, передавать им подходы к оценке. А точность — не уменьшается. Для рефлексии о причинах падения скорости SP обычно хватает, если какая-то одна-две задачи несоразмерно выросли. |
− | * Как первоначально получают оценку в SP? На начальной оценке release PBL берут простую и понятную всем историю, которую оценивают, например, в 3 SP или 5 SP. Получается начальный масштаб, от которого дальше пляшут. Когда переходят к оценке спринта и оценивают task, на которые поделили user story, то оценка user story задает некоторый масштаб, пока команды не привыкнут. Но при этом укладываться и подгонять не обязательно, более того у многих есть практики не показывать на планировании спринта оценки user story, во всяком случае сначала | + | * Как первоначально получают оценку в SP? На начальной оценке release PBL берут простую и понятную всем историю, которую оценивают, например, в 3 SP или 5 SP. Получается начальный масштаб, от которого дальше пляшут. Когда переходят к оценке спринта и оценивают task, на которые поделили user story, то оценка user story задает некоторый масштаб, пока команды не привыкнут. Но при этом укладываться и подгонять не обязательно, более того у многих есть практики не показывать на планировании спринта оценки user story, во всяком случае сначала — чтобы они не влияли на оценки отдельных задач. Но в случае расхождений — разбираться, вопрос в подробностях задачи или более систематично что-то поплыло. |
− | * Новичкам для калибровки оценок полезно посмотреть оценки предыдущих спринтов до первого планирования. И, опять-таки, оценить задачу как | + | * Новичкам для калибровки оценок полезно посмотреть оценки предыдущих спринтов до первого планирования. И, опять-таки, оценить задачу как «похожую на ту» легче, чем прикинуть часы. |
− | '''О SM''' | + | '''О SM''' |
− | * Если кто не разделяет цели | + | * Если кто не разделяет цели — гнать из команды. Движение должно быть сонаправленным. Размер шага (скорость) — не так важны, это тренируется, если человек разделяет цели. Ответственность за фиксацию таких проблем — на SM. |
− | * Про SM, не смотря на много | + | * Про SM, не смотря на много «управляющих» функций по процессу, явный акцент Книберга на самовыдвижении и отсутствии формальной власти. И SM создает условия для самоорганизации, а не управляет. Основне средство — вопрос «А что вы думаете о …» (а не «Давайте решим такую проблему…»). |
− | * Если есть персональные проблемы, например, кто-то систематически не соблюдает стандарт кодирования и на review это вылезает, то задача 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 примерно так: | + | * Project Manager в смысле CMMI поделен в SCRUM примерно так: |
− | ** release plan | + | ** release plan — PO |
− | ** build team | + | ** build team — SM |
− | ** архитектура | + | ** архитектура — команда |
− | ** раздача задач | + | ** раздача задач — task board |
− | ** набор персонала | + | ** набор персонала — за рамками команды |
− | * Надо ограничивать количество задач, находящихся в работе. На это есть мат.модель (правда тут надо смотреть, насколько плюшевая, я готов рассказать подробности). Кратко так. Если дело проходит через несколько стадий, и на каждой имеет некоторую неопределенную трудоемкость (например, от 1 до 3), то с некоторого числа дел в работе мощность выходит на плато, но чем меньше дел в работе | + | * Надо ограничивать количество задач, находящихся в работе. На это есть мат.модель (правда тут надо смотреть, насколько плюшевая, я готов рассказать подробности). Кратко так. Если дело проходит через несколько стадий, и на каждой имеет некоторую неопределенную трудоемкость (например, от 1 до 3), то с некоторого числа дел в работе мощность выходит на плато, но чем меньше дел в работе — тем быстрее новое дело, вкинутое на вход, появится на выходе. И это — без узкого горла. Если стадий 5, то в работе оптимально 7 начатых дел. Практически это мощное ограничение, особенно с учетом дорогого переключения контекста, и надо этим пользоваться, и того, что люди не могут одновременно держать много целей. |
− | * Working smart more important than working hard. Не рубите деревья бензопилой, а пилите, и вообще не рубите деревья молотком. Используя SCRUM смотрите, насколько подходит. | + | * ''Working smart more important than working hard''. Не рубите деревья бензопилой, а пилите, и вообще не рубите деревья молотком. Используя SCRUM смотрите, насколько подходит. |
− | '''Две команды на одном продукте'''. | + | '''Две команды на одном продукте'''. |
− | * Итерации | + | * Итерации — рекомендуется синхронно, и общий релиз. Иначе сложно с кодом. |
− | * Задачи на итерации делить можно на общей сессии: все задачи висят на доске, команды у них и высказывают желания, а PO | + | * Задачи на итерации делить можно на общей сессии: все задачи висят на доске, команды у них и высказывают желания, а PO — отдает. Как вариант — в каждой команде свой «локальный PO», который берет задачи от общего, так тоже можно. |
'''Разные техники'''. | '''Разные техники'''. | ||
− | * Если у команды период активной поддержки, то можно резервировать на это некоторую долю времени при планировании спринта, а можно | + | * Если у команды период активной поддержки, то можно резервировать на это некоторую долю времени при планировании спринта, а можно — вставлять в SBL задачи типа «фиксируем 10 самых критичных багов». |
− | * Если возник стресс и запарка | + | * Если возник стресс и запарка — найдите силу воли сделать паузу и проанализировать причины. |
− | * Любопытный пример. Kanban of SCRUM, на 60 человек. Большая доска, слева область для подготовки, потом область выполнения | + | * Любопытный пример. Kanban of SCRUM, на 60 человек. Большая доска, слева область для подготовки, потом область выполнения — разбита на 4 части для отдельных scrum-команд — задача уходит на их доску, а после спринта — возвращается на общую. Впечатляет. И, возможно, на проектах с несколькими командами типа ГПБ — может быть полезным. |
− | * Где-то всплыл сайт http://userstories.com - всякие тулы и прочее для поддержки. Может, кому интересно | + | * Где-то всплыл сайт http://userstories.com - всякие тулы и прочее для поддержки. Может, кому интересно — даю ссылку. |
− | Повсеместная '''работа с карточками''' меня впечатлила. Техника ведения трека через карточки, которые сначала есть в PBL, потом помещаются на мини-доску Todo/Doing/Done, а потом | + | Повсеместная '''работа с карточками''' меня впечатлила. Техника ведения трека через карточки, которые сначала есть в PBL, потом помещаются на мини-доску Todo/Doing/Done, а потом — в сделанное в рамках спринта может быть полезна на собраниях с повесткой дня. Я, во всяком случае, буду пробовать — если не забуду. Приоритеты — тоже через них. И bring down на планировании — user story на доске, пишем task и вешаем. |
'''Общение с другими'''. | '''Общение с другими'''. | ||
− | * Было много участников, успешно применяющих scrum и приехавших. чтобы улучшить опыт. Сам scrum | + | * Было много участников, успешно применяющих scrum и приехавших. чтобы улучшить опыт. Сам scrum — разный, в том числе в варианте, когда scrum master близок к менеджеру. У других — упор на PO, есть те, у кого он в команде. |
− | * Была практика, когда один SM ведет две команды, и это | + | * Была практика, когда один SM ведет две команды, и это — его полная загрузка, а задача его — именно наладить процесс. При этом он знает разряды сотрудников и следит за адекватным вкладу разрядом, говоря о проблемах индивидуально. На ретро или эскалируя. |
− | * Планирование 2-недельной итерации вместе с декомпозицией story на task | + | * Планирование 2-недельной итерации вместе с декомпозицией story на task — полдня, 4 часа. |
− | * SCRUM позволяет делать качественные вещи, вопрос в применяемых практиках. Например, может быть жесткое требование, что по каждой user story | + | * SCRUM позволяет делать качественные вещи, вопрос в применяемых практиках. Например, может быть жесткое требование, что по каждой user story — пишем acceptant test (пишет или утверждает PO), который развертывают в test case. И все это делает команда. |
* Есть практика тех.лидов, тоже поделенных на 2 команды и занимающихся техническими архитектурными вопросами. | * Есть практика тех.лидов, тоже поделенных на 2 команды и занимающихся техническими архитектурными вопросами. | ||
− | * Понимание терминов | + | * Понимание терминов — разное. Не все считают, что DoD — это общее для всех задач, некоторые используют его скорее как HowToDemo или Acceptante Test. Это надо иметь ввиду, когда общаетесь. |
− | '''PO в команде''', как это у нас. Не отрицается, что это возможно. И ряд участников рассказывали о положительном опыте, они тоже так делают. Почему сам Генрих не делает, мне понятно | + | '''PO в команде''', как это у нас. Не отрицается, что это возможно. И ряд участников рассказывали о положительном опыте, они тоже так делают. Почему сам Генрих не делает, мне понятно — у него основной профиль — работа с проблемными проектами, бизнес-часть там разная, соответственно, он ей не занимается, а обеспечивает процесс за счет SM. Поэтому ничего определенного на мой вопрос не сказал. Что касается моих собственных мыслей об этом (с учетом тренинга и прочего), то, думаю, для нас нынешний вариант неизбежен. Потому что заказчик хочет PO у нас, в том числе согласовывающего позиции разных stakeholder’ов с его стороны. А для этого PO должен разбираться в архитектуре и уметь давать оценки, для чего, в общем-то быть в команде. И естественно им оказывается самый сильный член команды. Теоретически это не мешает появиться еще сильному SM, и команде будет только лучше, но практически в этом случае фирма просто сделает две команды — потому что дефицит руководителей проявляется наиболее отчетливо. Однако все это не мешает работе в SM для их роста, как будущих PO, управляющих процессом, или просто сосредоточенных на тех аспектах, на которые PO не хватает. |
От тренинга остались 2 книги, напечатанные и на пружинке. | От тренинга остались 2 книги, напечатанные и на пружинке. | ||
* SCRUM и XP из окопов с автографом, так что только на почитать. | * SCRUM и XP из окопов с автографом, так что только на почитать. | ||
* SCRUM и Kanban: выжимаем максимум. | * SCRUM и Kanban: выжимаем максимум. | ||
− | И авторский checklist по SCRUMу с градацией bottom line/core/ | + | И авторский checklist по SCRUMу с градацией bottom line/core/recommended/scaling/positive indicators, он есть на его сайте. |
− | Засим | + | Засим — все. |
{{wl-publish: 2011-03-03 22:19:13 +0300 | MaksTsepkov }} | {{wl-publish: 2011-03-03 22:19:13 +0300 | MaksTsepkov }} |
Версия 01:44, 4 марта 2011
Итак, сегодня был второй день тренинга Генриха Книберга. Тоже очень полезный. Фиксирую впечатления тезисами.
Оценка в 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», который берет задачи от общего, так тоже можно.
Разные техники.
- Если у команды период активной поддержки, то можно резервировать на это некоторую долю времени при планировании спринта, а можно — вставлять в SBL задачи типа «фиксируем 10 самых критичных багов».
- Если возник стресс и запарка — найдите силу воли сделать паузу и проанализировать причины.
- Любопытный пример. Kanban of SCRUM, на 60 человек. Большая доска, слева область для подготовки, потом область выполнения — разбита на 4 части для отдельных scrum-команд — задача уходит на их доску, а после спринта — возвращается на общую. Впечатляет. И, возможно, на проектах с несколькими командами типа ГПБ — может быть полезным.
- Где-то всплыл сайт http://userstories.com - всякие тулы и прочее для поддержки. Может, кому интересно — даю ссылку.
Повсеместная работа с карточками меня впечатлила. Техника ведения трека через карточки, которые сначала есть в 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 команды и занимающихся техническими архитектурными вопросами.
- Понимание терминов — разное. Не все считают, что DoD — это общее для всех задач, некоторые используют его скорее как HowToDemo или Acceptante Test. Это надо иметь ввиду, когда общаетесь.
PO в команде, как это у нас. Не отрицается, что это возможно. И ряд участников рассказывали о положительном опыте, они тоже так делают. Почему сам Генрих не делает, мне понятно — у него основной профиль — работа с проблемными проектами, бизнес-часть там разная, соответственно, он ей не занимается, а обеспечивает процесс за счет SM. Поэтому ничего определенного на мой вопрос не сказал. Что касается моих собственных мыслей об этом (с учетом тренинга и прочего), то, думаю, для нас нынешний вариант неизбежен. Потому что заказчик хочет PO у нас, в том числе согласовывающего позиции разных stakeholder’ов с его стороны. А для этого PO должен разбираться в архитектуре и уметь давать оценки, для чего, в общем-то быть в команде. И естественно им оказывается самый сильный член команды. Теоретически это не мешает появиться еще сильному SM, и команде будет только лучше, но практически в этом случае фирма просто сделает две команды — потому что дефицит руководителей проявляется наиболее отчетливо. Однако все это не мешает работе в SM для их роста, как будущих PO, управляющих процессом, или просто сосредоточенных на тех аспектах, на которые PO не хватает.
От тренинга остались 2 книги, напечатанные и на пружинке.
- SCRUM и XP из окопов с автографом, так что только на почитать.
- SCRUM и Kanban: выжимаем максимум.
И авторский checklist по SCRUMу с градацией bottom line/core/recommended/scaling/positive indicators, он есть на его сайте.
Засим — все.