因此，我的公司正在构建一个广泛的医疗软件，其中有许多移动部件和在一个屏幕上选择的东西可能需要在多达5个其他屏幕上显示。
这里的问题是，当开发团队与产品设计师合作时，他们会清楚地了解如何正确编码软件，但这些信息从未真正写下来并记录下来，以便可以传递给其他人公司里的人员可能不在规划团队或Sprint的一部分。
毕竟，记录某些东西通常被视为“太瀑布，限制太多”，但显然还有其他人需要这些信息 - 尤其是那些无法了解所有细节的测试人员。程序
我的问题是，你们有没有找到一个很好的解决方案？我们怎样才能在中间见面？
答案 0 :(得分：2)
“中间立场”是与敏捷发展的斗争。当你提到测试人员时，你指的是谁？每日冲刺会议发生时，“测试人员”不应该进入会议室吗？
听起来我的公司可能正试图通过敏捷方法运行瀑布项目。
我发现的一个有用的工具是使用Wiki来定义开发人员记录决策的共同点，而其他人可以在页面上提供反馈，是的，如果您愿意，测试人员可能会在未来。
答案 1 :(得分：1)
至少在瀑布式测试中，测试人员可以审查需求并对可测试性做出早期评论，并澄清用例。你实际上做的比直瀑更糟糕。
如果测试不在计划会议或sprint的一部分上，那么您可以选择将它们带入，或者承认您实际上只是在做瀑布并且只需要下载并编写属于的文档瀑布式的方法。 “失败缓慢”通常不被认为是敏捷的原则。这就是你在代码交付之前阻止测试发表任何评论时所做的事情。