我们计划将敏捷引入我们的开发流程(从我们迄今为止使用的瀑布式转变)。我们倾向于采用混合模型，其中需求收集 session 由业务分析师、主题专家、技术人员和用户界面人员组成。计划是创建开发团队可以在 1 个月冲刺的敏捷流程中使用的用户故事。
有人有混合模型的经验吗？到目前为止，它对您来说效果如何？
最佳答案
The plan is to create user stories that the development team can use in their agile process with 1 month sprints.
一些评论:
恕我直言，1 个月的 Sprint 太长了，特别是对于采用而言，我更喜欢使用 2 到 3 周的 Sprint。在采用过程中，较短的反馈循环让您有机会更频繁地检查和适应，并且由于您正在进行试验，因此通常会赞赏这一点。
只要目标不是一次性创建细粒度产品待办事项列表项的“最终”列表(待办事项通常具有金字塔结构，细粒度项目位于顶部 - 用于即将到来的迭代 - 粗粒度项目位于底部)。在每次迭代之前举办故事写作研讨会是一种常见的做法。
PS:虽然我尊重 Péter 的观点，但我的观点略有不同。我认为 Scrum(我们正在谈论 Scrum，对吧？)是一个最小且精细平衡的框架，并建议尽可能遵循书本上的 Scrum 做法。当然，我们的目标不是成为 Scrum，而是交付可工作的产品增量。但是，除非您的团队中有 Scrum 经验丰富的人员，否则您(作为组织)并没有真正的资格1来更改框架(并了解其影响)，并且可能无法获得所有好处。 Scrum 很灵活，不存在两种类似的 Scrum 实现。但放弃框架的一部分并不等于灵活。
1我经常介绍Shu Ha Ri敏捷采用的进展模型(大致意味着学习 - 分离 - 超越)。来自 C2 维基:
As the beginner starts to learn, Shu gives them structure. It forces them to adhere to the basic principles (...). Since the beginner knows very little, they can only progress by slavishly adhering to these principles (...).
As the beginner gains experience, they naturally will wonder why?, how?, is there something better? Ha... the separation (much softer word than break) is the experimentation done around the principles... first straying only a little and then more and more as these ideas are tried against the reality of the world.
As the experiments of the Ha stage continue, bit by bit, the successes are incorporated into daily practice... we look for opportunities and use the patterns we have learned and tried out that closely fit those opportunities. This Ha/Ri stage is what makes an art the 'property' of the practitioner rather than the teacher or the community. Eventually, you are able to function freely and wisely.
我当然不是说必须停留在术阶段(目标是超越第一级)，我的意思是学习新的工作方法需要时间，不要忽视实践。正如罗恩·杰弗里斯(Ron Jeffries)曾经说过的“它们被称为练习是有原因的......你必须完成它们。熟能生巧。”
更新:(回答评论)
One of the decisions we would like to take is the role of each person in the 'Product Owner' team.
需要明确的是:应该只有一个产品负责人。他当然可以与团队合作，但团队仍然应该有一个权威的声音。如果我换个说法，就不存在产品负责人团队。
For ex: What would the role of a technical person be?
嗯，对我来说，技术人员在这个团队中没有任何作用(除非他在那里培训或支持人们编写故事，但 ScrumMaster 通常应该这样做)。写故事意味着捕捉面向业务的本质特征，现阶段并不需要技术角度。技术复杂性(甚至可行性)将包含在稍后的估算中。
It seems to me that the end result of the requirements phase would be user stories that the developers will use in the iterations. Will the technical person be estimating the tasks? Traditionally, we've had the programmers estimate their own tasks
从事工作的人员应该估算工作量(如果其他人估算团队的工作量，则不能指望团队会致力于某件事)。换句话说，团队应该评估故事。最重要的是，经验表明 1. 集体估计比个人估计效果更好 2. 我们更擅长进行相对估计。因此，我的建议是相对使用故事点/T 恤尺寸/无单元点来估计故事的大小和复杂性，并在 planning poker 期间进行集体估计。 session 。在我使用它的每个地方，这都非常有效。
关于process - 使用敏捷规划需求收集 session ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3053773/