Agile в Беларуси

Полностью согласен, что большинство тестов имеют чисто статистическое значение.

Во всяком случае Comparative Agility так и заявлен как некий сравнительный срез, между командами, которые “заявляют”, что они работают по Agile (Scrum). Собственно об этом я и писал в своем посте, который вы процитировали.

В тоже время, Scrum-Checklist, согласно его автору Хенрику Книбергу (кстати, автору мини-книги “Scrum&XP from the trenches”), задумывался как личный инструмент СкрамМастера и/или членов скрам-команды. Думаю, что они смогут его применить только имя предствление о концепциях и вообще “зачем нам весь этот Scrum”. Иначе пользоваться этим инструментом абсолютно бесполезно.

День добрый, Юрий.

Я автор цитируемой Вами статьи о чеклисте Scrum. Хотел бы заметить, что суть этого чеклиста отнюдь не “сбор статистики”. По сути это просто краткий список основных требований или практик Scrum. Возможно знаете, что у пилотов есть несколько карт проверок: карта на взлете, рулении, перед посадкой и пр. и пилоты используют их не для сбора статистики, а для того, чтобы проверить, нет ли чего такого, что они ЗАБЫЛИ сделать. В принципе, эта карта проверок Scrum служит тем же целям - не ЗАБЫЛИ ли вы реализовать какие-либо важные практики или пропустили их реализацию. И Хенрик и я подчеркивали в своих постах, что не нужно рассылать эту карту сотрудникам с требованием проставить галочки, а затем посмотреть как все хорошо (или плохо).
Если угодно, эту карту проверок можно считать содержанием ваших семинаров

Кстати, именно поэтому я перевел “checklist” как “карта проверок”, а не как “тест”, “исследование”, “статистическая карта” или еще как-нибудь.

Ну как со всеми референс моделями - если бездумно насаждать, то добиться соответствия легко, но вот смысла не будет
В то же время я помню как сам камрад Швабер потрясал листом с практиками и акцентированно говорил - “если что пропустите - не говорите что делаете скрам: я не хочу чтоб его ассоциировали с вашим провалом”

LaWay, чтобы не забыть чего-то сделать подошел бы и короткий список типа того, что делал Швабер.
Когда несколько сотен вопросов с довольно субъективными оценками (1-5) это уже статистика.
Кроме того, чек-листы занятие еще более безумное, нежели статистика. Я об этом писал выше — бездумное внедрение без понимания дает непредсказуемый эффект — возможно положительный, но более нулевой или отрицательный.

Ну, во-первых я говорил ТОЛЬКО о чеклисте, так что не очень понял к чему тут “несколько сотен вопросов”.
Во-вторых, с каких пор статистика стала безумной? Например, составляя план релизов вы пользуетесь статистикой по velocity команды, измеренной во время предыдущих итераций. Во время спринта вы пользуетесь статистикой в виде Burndown Chart. Так что могу сказать, что и этого высказывания я тоже не понял
Насчет размера чеклиста: в случае чеклиста Хенрика - да, он довольно большой, но структурированный и у вас есть выбор как им пользоваться: либо пройтись по всем пунктам, либо только по верхнему уровню. В случае коротких списков такого выбора у вас нет.
Ну и последнее: без понимания вообще никогда и ничего не получится, какую бы форму не принимало знание - семинары, чеклисты, книги и т.п. И здесь на сцену должен выйти Scrum Master, у которого ДОЛЖНО быть понимание всех процессов и деталей, а потому форма знаний, которой он будет пользоваться становится вообще не важной.

Какой вы серьезный человек! Не чувствуете иронии в словах. Помните старую шутку о том, что есть правда, есть ложь, а есть статистика? Ну вот это про тоже. Я статистику очень уважаю и люблю, но уже как-то сталкивался с тем, что люди начинали собирать какую-то всеобъемлющую статистику, которую выкидывали на помойку. Ну да ладно.
Про понимание. Если уж у SM нет понимания, то это вообще труба. Но в скрам-команде понимание должно быть у всех — на разном уровне, но у всех. Иначе вы не найдете и не отстроите консенсуса внутри команды. Скрам предполагает итерационное улучшение не просто продукта, но также и процессов, а процессы содержатся в коммуникациях, а следовательно в команде, в людях. Если эти люди не понимают как эти процессы встраиваются в них, а они в процессы, то нихрена никакого итерационного улучшения не будет.