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

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

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

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

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


qa methodology
person KC - QA San Diego    schedule 29.06.2010    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

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

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

person Jupe    schedule 29.06.2010
comment
+1 - если ваших тестировщиков нет в комнате на встрече, какой в ​​этом смысл? - person testerab; 28.02.2011

arrow_upward
1
arrow_downward

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

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

person testerab    schedule 27.02.2011