Изменения

* Почему перешли на оценку в SP (''story point'')? Это - — опыт. При такой оценке команда быстрее приходит к согласию, чем при оценке в идеальных днях/часах. И легче калибровать разные команды, передавать оим им подходы к оценке. А точность - — не уменьшается. Для рефлексии о причинах падения скорости sp 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"«локальный 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. И все это делает команда.

* Понимание терминов - — разное. Не все считают, что DoD - — это общее для всех задач, некоторые используют его скорее как HowToDemo или Acceptante Test. Это надо иметь ввиду, когда общаетесь.

'''PO в команде''', как это у нас. Не отрицается, что это возможно. И ряд участников рассказывали о положительном опыте, они тоже так делают. Почему сам Генрих не делает, мне понятно - — у него основной профиль - — работа с проблемными проектами, бизнес-часть там разная, соответственно, он ей не занимается, а обеспечивает процесс за счет SM. Поэтому ничего определенного на мой вопрос не сказал. Что касается моих собственных мыслей об этом (с учетом тренинга и прочего), то, думаю, для нас нынешний вариант неизбежен. Потому что заказчик хочет PO у нас, в том числе согласовывающего позиции разных stakeholder'ов stakeholder’ов с его стороны. А для этого PO должен разбираться в архитектуре и уметь давать оценки, для чего, в общем-то быть в команде. И естественно им оказывается самый сильный член команды. Теоретически это не мешает появиться еще сильному SM, и команде будет только лучше, но практически в этом случае фирма просто сделает две команды - — потому что дефицит руководителей проявляется наиболее отчетливо. Однако все это не мешает работе в SM для их роста, как будущих PO, управляющих процессом, или просто сосредоточенных на тех аспектах, на которые PO не хватает.

И авторский checklist по SCRUMу с градацией bottom line/core/recomendedrecommended/scaling/positive indicators, он есть на его сайте.

Засим - — все.