ну мы типа по белому работаем . Есть кое какие доработки, построенные на продукт дискавери (лин стартап) но в целом все остальное - чистый скрам

Интересная ассоциация чистый скрам - белая зарплата. 😂

Я имел ввиду кто считает, что у него в компании скрам в чистом виде без модификации и адаптации под текущие условия в данной конкретной ситуации. У меня есть гипотеза, что не существует никакого чистого скрама на практике. У всех всегда свой собственный мутировавший экземпляр скрама.

срам какой-то)

Я недавно задавался этим вопросом, к сожалению стало ясно что не все синхронизированы в определении самого скрама :)

ну скрам  поэтому и не методология , а фреймворк, но мой опыт показал, что модификации скрама превращают его в срам

ой Сережа, спасибо -)

прям с языка слизал

Я бы это назвал профанация скрама, когда культ карго какой-то устраивают копируя внешние проявления и не понимая самой сути.

Итак, что такое чистый скрам?

)))) главное при отрезание понимать, что и зачем там присутствуют те или иные элементы)

Для меня всегда было проблематично обсуждать риски в некоторых абстракциях. Лучше бы конкретизировать тематику, т.к. риски бывают слишком уж разные. Ошибки в оценке и превышении бюджета, падение серверов или же болезнь сотрудников в день релиза)))

Два главных момента:
1. Нужно из под палки заставить всех работать в трекере. Как личный дневник участника команды. Время только по таймеру.
2. Навесить метрики на узкие места и начать регулярно их мониторить.  (я всегда говорю про метрики, т.к. цифры не врут)

Допустим абстрактный пример:
Есть один проект, который с гос. подачи растет. Большой и известный растет и пухнет.
Там сверху водопад, который едет в 146% случаев. Конечный пользователь хочет то, что сам не понимает. Больше рисков чем там еще видел.  

Первые пару месяцев был полный ад. Пробовали с разных сторон зайти. Накопив минимальный набор данных стали работать, как с системой с постоянно изменяющимися условиями, т.е. определили размеры итераций. Всех подрядчиков и участников нашей части работы тоже втянули в нашу итеративность. На размер итерации закладывали риски на аналитику и каждого подрядчика. Скорректировали ее размер, так чтобы все части системы работали без простоев. Далее прогнозирование величины риска в коэффициент. Про коэффициенты писал выше. Все тоже самое. Сами риски при этом определены по типам и степени угрозы. Такой классификатор дал возможность завершить работу.

Дмитрий, а можете на примере рассказать как получить эти самые коэффициенты, на которые мы умножаем оценки, чтобы заложить риск.

Для команд с которыми работал или работаю у меня есть табличка в экселе, где я определяю лист задач с сырыми оценками и табличка сама считает, т.к. в ней все эти сетрики и коэффициенты счиатются автоматически.
Дело не пару минут, счастья море. Рекомендую для своих процессов иметь такие.

Интересно, но это же печаль - делать оценки, закладывать риски. Всё это время можно было бы с удовольсвтием потратить на исследование проблемы :)

Или на первый релиз

В вышеописанном случае я сказал о проблемном проекте, где риски зашкаливали.
На практике не так много задач подвержены таким рискам, чтобы на них посточнно закладывать что-то еще сверху.

гос. заказчик - это же еще и тендер с нереальными сроками + абстрактное ТЗ на разработку. давление водопада на всех участников. Вообще очень интересно, что за магический классификатор помог.

Как-то в вебинаре Владимира Железняка услышал слово "жопочуй". Вот он со временем хорошо прокачивается и работа с рисками становится проще))))
В целом, конечно же правильно говорит @neemah, лучше исследовать проблему и найти ее корень.

FYI: http://gosagile.ru