Документация в среде Scrum - как мы фильтруем информацию людям, не участвующим в Sprint?

Question

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

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

В конце концов, документирование чего-то обычно рассматривается как «слишком водопад, слишком ограничительный», но, очевидно, есть другие, которым понадобится эта информация - особенно тестеры, которые выигралиУ меня нет доступа ко всем тонкостям программы.

Мой вопрос: кто-нибудь из вас нашел хорошее решение для этого?Как мы можем встретиться в середине?

Answer 1

«Срединность» - это борьба с гибким развитием. Когда вы ссылаетесь на тестеров, на кого вы ссылаетесь? Разве «тестеры» не должны находиться в комнате, когда происходит ежедневное спринтерское совещание?

Мне кажется, что ваша компания пытается запустить проект водопада гибкими методами.

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

Answer 2

По крайней мере, в водопаде, тестеры получают возможность пересмотреть требования и заблаговременно прокомментировать тестируемость и прояснить варианты использования. То, что ты на самом деле делаешь, хуже, чем прямой водопад.

Если тест не проводится на совещаниях по планированию или в части спринта, тогда у вас есть выбор между их привлечением или признанием того, что на самом деле вы просто делаете водопад и просто сгибаетесь и пишете документацию, которая относится подход водопада. «Медленный провал» обычно не считается проворным принципом. Это то, что вы делаете, когда вы запрещаете тесту делать какие-либо комментарии, пока код не будет доставлен.