Да, это личный опыт. Внедрял скрам как технарь в двух компаниях. В первой наделал много ошибок, потом исправлял, набил шишки. Во второй, где работаю по сей день, внедрил скрам вполне успешно, уже более трех лет несколько команд работает.
Product Owner — это роль в скраме, которую часто берут на себя существующие проектные менеджеры.
Лидер и скрам-мастер понятия не взаимоисключающие, непонятно почему вы так отреагировали. И уж тем более непонятно ваше удивление, что скрам-мастер следит за тем, чтобы задачи в спринте выполнялись в порядке их проритета. Приоритет, если что, определяет product owner.
По поводу scrum.org, «примите его буквально» и про чеклист. Это всё хорошо до первого внедрения. Все команды разные и vanilla-scrum заходит не у всех. Точнее, почти ни у кого не заходит, особенно если вы не Асхат Уразбаев, а простой разработчик.
Вы просто обязаны учитывать эти детали если хотите внедрить процесс, а не остаться наедине со своим чек-листом.
Есть ли смысл так заморачиваться с детектированием газа, если буквально через секунду банкомат взорвется и исчезнет из сети: это уже является причиной для тревоги.
Рад что понравилось.
Вообще, тема мокирования в функциональных тестах в рунете освещена плохо, хотя это очень важно для полноценных тестов. Я планирую продолжить развивать её.
В частности, есть идея рассказать про опыт мокирования API на нестандартных протоколах, когда такие инструменты как Mountebank уже не справляются. Например, api на websocket'ах.
В таких случаях, конечно, приходится писать свой сервис, но если использовать подход «mock-API as test enviroment» + использовать высокоуровневые языки, то получается вполне красиво и не сложно.
Product Owner — это роль в скраме, которую часто берут на себя существующие проектные менеджеры.
Лидер и скрам-мастер понятия не взаимоисключающие, непонятно почему вы так отреагировали. И уж тем более непонятно ваше удивление, что скрам-мастер следит за тем, чтобы задачи в спринте выполнялись в порядке их проритета. Приоритет, если что, определяет product owner.
По поводу scrum.org, «примите его буквально» и про чеклист. Это всё хорошо до первого внедрения. Все команды разные и vanilla-scrum заходит не у всех. Точнее, почти ни у кого не заходит, особенно если вы не Асхат Уразбаев, а простой разработчик.
Вы просто обязаны учитывать эти детали если хотите внедрить процесс, а не остаться наедине со своим чек-листом.
Вообще, тема мокирования в функциональных тестах в рунете освещена плохо, хотя это очень важно для полноценных тестов. Я планирую продолжить развивать её.
В частности, есть идея рассказать про опыт мокирования API на нестандартных протоколах, когда такие инструменты как Mountebank уже не справляются. Например, api на websocket'ах.
В таких случаях, конечно, приходится писать свой сервис, но если использовать подход «mock-API as test enviroment» + использовать высокоуровневые языки, то получается вполне красиво и не сложно.