Comments 5
хочу поделиться с вами новым подходом, основанным на неопределенности в требованиях
В общем то это всегда преподносится как плюс. А есть ли в этом реальная необходимость? Сколько у нас тут стартапов делающих рокетсайнс или хотя бы что-то новое? Большинство тех, кто исповедует скрам делают типичный еком или давно уже изученный продукт. И "неопределенность в требованиях" это способ бизнесу сэкономить денег на дискавери и нормальному техническому анализу. Сделать побыстрее хоть как-то, спихнуть все на разработчика. Пускай бегает, выясняет что там нужно и как лучше. Заработать здесь и сейчас, а потом все пускай сгорит огнем, "это уже проблемы завтрашнего Гомера". Сколько компаний реально готовы быть гибкими и менять регламенты и подходы, чтобы быть действительно гибкими как того требует аджайл? Ответ - очень мало.
Отличный комментарий! Действительно, не каждая организация занимается "рокетсайнс". Важно понимать, что "неопределенность в требованиях" не должна стать оправданием для отсутствия планирования и анализа. И когда возникает настоящая неопределённость, такая с которой надо работать через Agile-практики, вы правы, многие компании не готовы быть адаптивными, потому что это требует серьезной культурной смены. Для изменения культуры требуется изменить организационный дизайн, что не всегда легко достижимо.
А чем новая модель применимости принципиально отличается от Cynefin фреймворка, простите? Там все уже сформулировано, waterfall по сути для Clear домена "Sense-categorize-respond", для остальных подойдут Agile практики.
Более того, Киневин учитывает ещё и среду, в которой продукт будет жить и развиваться. Мы можем ничего не знать о том, как в результате должен выглядеть продукт и с чем столкнемся по дороге, но если продукт будет жить в "высоко зарегулированной среде", например, в государственном секторе здравоохранения или авиаперевозок, то Agile неправильный выбор.
Замечательный комментарий вы дали. Чтобы дать лучший ответ почему появилась представленная мной модель, то напишу немного подробнее откуда появилась модель Cynefin.
Модель Cynefin была создана Дэвидом Сноуденом, академиком и консультантом по управлению. Это произошло в начале 2000-х годов, когда он работал в IBM Institute for Knowledge Management.
Дэвид Сноуден, создатель модели Cynefin, не разрабатывал ее специально для Agile или любого другого конкретного подхода. Однако его модель оказалась полезной в контексте Agile, поскольку она помогает любым командам лучше понимать и категоризировать проблемы, с которыми они сталкиваются, и выбирать наиболее эффективные стратегии для их решения.
Модель Cynefin была разработана как фреймворк для помощи в принятии решений и управления сложностью. Главная идея заключается в том, что разные типы проблем и ситуаций требуют разных подходов к управлению и решению.
Когда изменения являются неизбежными и неопределенность велика работают Agile-команды, а понимание того, какие проблемы и задачи являются простыми, сложными, сложными или хаотическими, может помочь команде определить наиболее эффективные стратегии для их решения.
Сноуден разделил проблемы на пять категорий: простые, сложные, сложные, хаотические и бесформенные. Для каждой категории он предложил свой подход к решению проблем.
Простые проблемы: здесь причинно-следственная связь очевидна, и лучшие практики применяются для решения проблем.
Сложные проблемы: в этой области требуется анализ экспертов для выбора наилучшего курса действий, поскольку существует несколько правильных ответов.
Комлексные проблемы: в этой области необходим эксперимент и обучение, поскольку причинно-следственные связи не предсказуемы, и решения возникают в процессе.
Хаотические проблемы: здесь действия предпринимаются для установления стабильности, прежде чем оценивать и вводить порядок.
Беспорядочные проблемы: в этой области требуется определение правильного домена и декомпозиция проблемы. Это область, где не ясно, какой тип проблемы перед нами, и поэтому необходимо уточнение.
Если большинство ваших проблем комплексные, то лучше всего подойдут практики Agile. Но нужно понимать, что просто выбрать подход к решению проблемы - это только малая часть всей работы. Ведь мир не состоит только из задач и проблем. Более того команды часто сталкиваются с проблемами сразу из разных областей.
Модель, о которой я писал в статье, появилась из моего практического опыта работы по "кикофу" команд и проведения тренингов по основам Agile/Scrum. Когда то я пытался использовать только модель Cynefin для объяснения, когда лучше всего применять Agile, но многие не принимали её и воспринимали исключительно как теорию. Возможно, потому что Cynefin была создана для помощи в решении проблем, а не для выбора подхода Waterfall или Agile.
Жизнь сложна и многогранна. Модели помогают нам лучше понять ее. И выбор, какую модель использовать и в какой ситуации, всегда остается за вами.
Нужен ли вам Agile? Новая модель применимости всё объясняет