Цели, проблемы, решения
Думаю, тут могут быть разные варианты, хотя мне более очевидный именно в такой последовательности. Приведу пример. Цель: сделать мир лучше. Проблема: миру не хватает апельсинов.Решение: перекрасить все яблоки в оранжевый и назвать апельсинами.
Риски и требования (ограничения и атрибуты качества это тоже по сути требования)
Говорить кто из них первее — почти то же самое, что «курица или яйцо». Ибо источниками рисков так же являются требования, архитектура (которая строится на базе требований), команда (которая часто формируется на базе требований и/или архитектуры), и тд и тп. Поэтому идентификация рисков является постоянной рутиной всех членов команды и со Scrum-ом риск менеджмент очень хорошо «дружит».
Аналогично, часть требований (особенно более низких уровней) рождаются рисками, а именно митигацией рисков. Т.е. как это в Scrum: команда видит какой-то архитектурный риск, который надо митигировать, продумывает план митигации, конвертирует его в истории и задачи, берет в один из спринтов.
Согласен с автором. Недавно внедрял Скрам и чуть не наступил на эти грабли излишнего закручивания гаек. Вовремя осознал и остановился. Надо уметь балансировать и иметь подход к разрабам. Тоже слышал такое от Бобука.
Одно из самых сильных что может убить компанию это оторванность менеджмента от земли и незнание, что происходит в цеху. К сожалению, это очень часто в наших компаниях. Западные компании с самого начала внедряют механизмы позволяющие владеть ситуацией.
Отличная статья. Согласен с автором. Жаль голосовать не могу пока — лайкнул бы))
Думаю, можно было бы добавить про российские компании. У них ситуация аналогичная, как понимаю.
Отличная статья! Автору респект!
Одно только замечание, хоть и некоторые активности скрама могут быть возложены на разработчиков, но скрам мастер не должен быть членом команды. Это принципиальный момент и последствиями будут как раз таки «забивание» на скрам практики, когда будет не хватать времени, которого всегда не хватает.
Спасибо за отличную статью! Такие статьи помогают в работе с коллегами.
Да, верное. В проекте не нужен был весь арсенал MVICore, достаточно было и такой версии.
https://habr.com/ru/articles/730368/
https://habr.com/ru/articles/730368/
Готовлю сейчас более детальную статью конкретно по упомянутому кейсу. Давненько на Хабр не писал, отвык.
Цели, проблемы, решения
Думаю, тут могут быть разные варианты, хотя мне более очевидный именно в такой последовательности. Приведу пример. Цель: сделать мир лучше. Проблема: миру не хватает апельсинов.Решение: перекрасить все яблоки в оранжевый и назвать апельсинами.
Риски и требования (ограничения и атрибуты качества это тоже по сути требования)
Говорить кто из них первее — почти то же самое, что «курица или яйцо». Ибо источниками рисков так же являются требования, архитектура (которая строится на базе требований), команда (которая часто формируется на базе требований и/или архитектуры), и тд и тп. Поэтому идентификация рисков является постоянной рутиной всех членов команды и со Scrum-ом риск менеджмент очень хорошо «дружит».
Аналогично, часть требований (особенно более низких уровней) рождаются рисками, а именно митигацией рисков. Т.е. как это в Scrum: команда видит какой-то архитектурный риск, который надо митигировать, продумывает план митигации, конвертирует его в истории и задачи, берет в один из спринтов.
Одно из самых сильных что может убить компанию это оторванность менеджмента от земли и незнание, что происходит в цеху. К сожалению, это очень часто в наших компаниях. Западные компании с самого начала внедряют механизмы позволяющие владеть ситуацией.
Думаю, можно было бы добавить про российские компании. У них ситуация аналогичная, как понимаю.
Приятно общаться с профи!))
Одно только замечание, хоть и некоторые активности скрама могут быть возложены на разработчиков, но скрам мастер не должен быть членом команды. Это принципиальный момент и последствиями будут как раз таки «забивание» на скрам практики, когда будет не хватать времени, которого всегда не хватает.
Спасибо за отличную статью! Такие статьи помогают в работе с коллегами.