Process 使用敏捷技术规划需求收集会议

我们正计划将敏捷引入到我们的开发过程中（这是我们迄今为止一直使用的瀑布式的转变）。我们倾向于混合模式，因为需求收集会议由业务分析师、主题专家、技术人员和用户界面人员组成。该计划是创建用户故事，开发团队可以在他们的敏捷过程中使用1个月的sprint

---

有人有过混合动力车的经验吗？到目前为止，它是如何为您工作的？

到目前为止，我只对混合模型有过经验：-）到目前为止，我所从事的敏捷项目中没有一个严格按照书中的规定实施任何敏捷方法。你也不必

关键是，任何方法都只是一个起点/你可以用来制定自己的流程的想法集合，针对特定的项目、团队和环境量身定制

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

更新：关于需求过程的轶事

当我写这篇文章的时候，我意识到你可能没有从中得到很多有用的信息。。。但至少它告诉你，项目和流程变化很大

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

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

---

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

我的一位同事（我在一家咨询敏捷工作的公司工作）写过关于需求收集和开发过程之间的这种分离。他描述了如何在实践中很好地工作。

在我看来，如果你将

业务分析师、主题专家、技术人员和用户界面人员标记为“产品所有者”团队，那么你真的没有偏离“纯”敏捷

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

关键的成功因素可能是让产品所有者团队和所有利益相关者真正投资于参与开发团队的一些敏捷过程（展示演示、在sprint过程中回答问题等）

编辑：

此引文记录了产品负责人的非常简单的角色：

产品所有者代表客户的声音。他/她确保Scrum团队从业务角度处理“正确的事情”。产品负责人编写以客户为中心的项目（通常是用户故事），对其进行优先级排序，然后将其放入产品待办事项列表中

Scrum并不是要强制执行产品所有者如何完成工作的流程。Scrum试图概括的只是产品负责人和团队之间的接口（sprint规划和sprint审查）

该计划是创建用户故事，开发团队可以在他们的敏捷过程中使用1个月的sprint

一些评论：


1个月的冲刺时间太长了，