使用敏捷计划需求收集会话

Question

我们正计划将敏捷引入到我们的开发过程中(与我们到目前为止一直使用的瀑布有所不同)。我们倾向于混合模型，其中需求收集会议由业务分析师、主题专家、技术人员和用户界面人员组成。我们的计划是创建用户故事，开发团队可以通过一个月的冲刺在他们的敏捷过程中使用。

有没有人有过混合模式的经验？到目前为止，它对你来说是如何工作的？

Answer 1

我的一位同事(我在一家提供敏捷工作咨询的公司工作)写了一篇关于需求收集和开发过程之间的分离的several blogs。他描述了如何在实践中很好地发挥作用。

Answer 2

到目前为止，我只有混合模型的经验:-)到目前为止，我从事的敏捷项目都没有严格按照书中的规定实现任何敏捷方法。你也不需要。

重点是，任何方法都只是一个起点/一个想法的集合，你可以用它来制定自己的过程，为特定的项目、团队和环境量身定做。

从一个看起来不错的过程开始，然后看看它在实践中是如何工作的。在每次迭代结束时保持定期回顾，以评估事情是如何进行的，在上一次迭代中哪些工作有效，哪些没有，以及如何进一步改进。然后在下一次迭代中实现最重要的想法。换句话说，以敏捷的方式开发开发过程本身:-)

更新:关于需求流程的轶事

在我写这篇文章的时候，我意识到你可能从中得不到太多有用的信息...但至少它向您展示了项目和流程有很大的不同。

在一个项目中，我们有一个相当严格的Scrum流程，产品积压，尽管我们没有真正的客户:产品是新的，潜在用户还不知道它的存在。此外，这是一个相当具体和标准化的领域，我们公司在这方面有很多经验。当时我是团队的一员(这是在第一次发布之前)，我们真的没有太多正式的需求收集，因为许多关键需求都是由标准强加给我们的。最重要的是，我们有一些自己的想法，如何让产品脱颖而出。

在另一个项目中，我们有一个松散的Scrum过程，但我们的赞助商和用户并不真正了解它，所以我们相当挣扎。“需求收集”是相当非正式的，因为产品是巨大的，不同的人/子团队被分配到不同的领域，彼此相当独立地工作。每个子团队都有自己的联系人来讨论需求，而且联系人在地理上是分开的-我们很少看到他们中的任何一个人面对面，所以大多数交流都是通过电子邮件进行的，使用冗长的Word文档。最重要的是，我们有一个领域专家团队，他们经常与用户在具体需求上存在严重分歧，但他们并不是很善于沟通。因此，需求过程通常包括阅读包含晦涩数学内容的冗长文档，然后阅读包含GUI需求的其他冗长文档，然后尝试找出如何将两者结合在一起……然后与领域专家讨论需求，他简短地宣布这是一段sh*t，我们试图从他那里梳理出一些更有用和更具体的改进想法……然后根据我们最新的理解和专家的意见重写需求文档，并将其发送回我们的联系人...然后从正方形1开始重复。

在我们目前的项目中，我们又有许多用户分散在全球大部分地区。然而，至少我们的IT管理人员对软件开发和敏捷流程有更多的了解。我们在一个大型的遗留系统上工作，几年前它的状况非常糟糕-所以维护和稳定是我们日常工作的一大部分，而新的需求平均只占我们时间的不到一半。然而，当我们有一个项目时，我们通常会举行初步评估会议，在那里我们试图提出一个粗略的估计，这个项目将需要多少人天。然后，我们的业务分析师与利益相关者一起制定了越来越多的细节，我们的团队致力于填写技术细节。

Answer 3

在我看来，如果你给business analyst, subject matter experts, technical person and a user interface person贴上“产品负责人”的标签，你真的没有偏离“纯粹的”敏捷。

也就是说，“纯粹的”敏捷有点用词不当，因为大多数敏捷倡导者会告诉你，#1或#2的卖点是它适应现有组织的业务流程和企业文化的能力。

关键的成功因素可能是让产品所有者团队，以及所有的利益相关者，投资于参与您的开发团队的一些敏捷过程(出现在演示中，在冲刺期间可以访问问题，等等)。

编辑：

以下引用自Wikipedia，说明了产品负责人的简单角色：

产品负责人代表客户的声音。他/她确保Scrum团队从业务的角度处理“正确的事情”。产品负责人编写以客户为中心的项目(通常是用户故事)，确定它们的优先级，然后将它们放在产品待办事项中。

Scrum并不意味着强制执行产品负责人如何完成其工作的流程。Scrum试图勾勒出的只是产品负责人和团队之间的接口(冲刺计划和冲刺评审)。