SCRUM技术工件

Question

我的公司正在为新的软件开发引入SCRUM。我目前既是产品负责人，也是负责软件技术方面的产品经理。技术经理的角色不是scrum团队的一部分。

我发现scrum团队中有一些将软件开发当作黑匣子的愿望，也就是说，我应该只关心用户故事和业务利益。

这是一个问题，因为需要为客户讨论关于最合适的体系结构、部署机制、主机系统需求等的信息是不可用的(我在我的经理角色中负责这一点)。例如，开发团队可能开发一个只能与特定数据库排序规则一起使用的系统。这不是我所预料到的事情，所以不会创建一个用户故事或与客户讨论，但它可能是一个显示-停止对该产品。

哪些文件和透明度是合理的？整个团队对scrum来说都是新手，所以任何建议都欢迎。

PS:我想知道这个双重角色是不是个好主意。我认为一些团队成员可能认为产品负责人是一只公鸡，这不是我的意图;-)

Answer 1

哪些文件和透明度是合理的？

“合理”？

这个问题不应该是“合理的”。

它应该是关于“可交付的”。

信息..。关于最合适的架构、部署机制、主机系统需求等都不可用。

然后，开发人员认为什么是可交付的和您认为什么是可交付的有问题。

在下一个sprint中，包括这些其他可交付的内容。

别傻了，要一堆传统的“大设计先行”文档。

询问“架构”、“部署”和“平台”的描述。它们很容易制作，而且应该覆盖几页材料。