我们计划将Agile引入我们的开发过程（从目前为止我们使用的瀑布转变）。我们倾向于混合模型，需求收集会议由业务分析师，主题专家，技术人员和用户界面人员组成。计划是创建用户故事，开发团队可以在敏捷过程中使用1个月的冲刺。
有没有人有混合模型的经验？到目前为止，它对你有用吗？
答案 0 :(得分：3)
计划是创建用户故事，开发团队可以在敏捷过程中使用1个月的冲刺。
一些评论：
1个月Sprint是恕我直言，特别是收养，我更喜欢使用2到3周的Sprint。在采用过程中，较短的反馈循环使您有机会更频繁地检查和适应，并且因为您正在进行实验，所以这一点非常受欢迎。
我真的不明白你的需求收集会话中的混合是什么，只要目标不是一次性创建细粒度产品Backlog项目的“最终”列表（积压通常是顶部有细粒度物品的金字塔结构 - 用于即将进行的迭代 - 底部是粗粒物品。在每次迭代之前进行故事写作研讨会是一种常见的做法。
1 我经常介绍Shu Ha Ri进展模型（大致意味着学习 - 分离 - 超越）以实现敏捷采用。来自C2 wiki：
当初学者开始学习时，Shu给了他们结构。它迫使他们遵守基本原则（......）。由于初学者知之甚少，他们只能通过盲目坚持这些原则（...）来取得进步。
随着初学者获得经验，他们自然会想知道为什么？，怎么样？有更好的东西吗？哈......分离（比休息更柔和的词）是围绕这些原则进行的实验......首先，当这些想法被用来对抗世界的现实时，它们只会稍微偏离，然后越来越多。
随着Ha阶段的实验继续，一点一滴，成功被纳入日常实践......我们寻找机会并使用我们学到的模式并尝试紧密适应这些机会。这个Ha / Ri阶段是使艺术成为从业者而不是教师或社区的“财产”的原因。最终，您可以自由而明智地运作。
我当然不是说必须留在 Shu 阶段（目标是超越第一级），我所说的是学习新的工作方式需要时间，不要忽视实践。正如罗恩杰弗里斯曾经说过的那样，“他们被称为做法是有原因的...你必须做到这一点。实践是完美的。”
更新（回复评论）
我们希望采取的决策之一是每个人在“产品负责人”团队中的角色。
请注意：应该只有 ONE 产品负责人。他当然可以和一个团队合作，但是，团队应该有一个权威的声音。如果我改写，则没有产品负责人团队。
例如：技术人员的角色是什么？
嗯，对我而言，技术人员在这个团队中没有任何作用（除非他在那里训练或支持人们写故事，但ScrumMaster通常应该这样做）。编写故事意味着捕捉面向业务的功能的本质，在这个阶段没有真正需要技术观点。技术复杂性（甚至可行性）将包括在估算的后期。
在我看来，需求阶段的最终结果将是开发人员将在迭代中使用的用户故事。技术人员会估算任务吗？传统上，我们让程序员估计自己的任务
做这项工作的人应该估计工作（如果其他人估计团队的工作，你就不能指望团队做出某些事情）。换句话说，团队应该估计故事。最重要的是，经验表明1.集体估计比个人估计更有效2.我们更擅长相对估计。因此，我的建议是使用故事点/ T恤尺寸/无单位积分估算故事的大小和复杂程度，并在planning poker会话期间进行集体评估。这在我使用它的每个地方都非常有用。
答案 1 :(得分：1)
我的一位同事（我为一家从事敏捷工作的公司工作）撰写了several blogs关于需求收集和开发过程之间的这种分离的文章。他描述了这在实践中如何运作良好。
答案 2 :(得分：0)
到目前为止，我只有混合模型的经验:-)到目前为止，我所使用的敏捷项目都没有严格按照本书的规定实施任何敏捷方法。你也不需要。
关键在于，任何方法论都只是一个起点/一系列创意，可用于制定自己的流程，根据具体项目，团队和环境量身定制。
从一个看起来不错的过程开始，然后看看它在实践中是如何运作的。在每次迭代结束时定期进行回顾，以评估事情的进展情况，最后一次迭代中的工作情况以及未完成的事情，以及如何进一步改进。然后在下一次迭代中实现最重要的想法。换句话说，以敏捷的方式开发开发过程： - ）
更新：关于需求流程的轶事
在我写这篇文章时，我意识到你可能没有太多有用的信息......但至少它告诉你项目和流程变化很大。
在一个项目中，我们有一个相当严格的Scrum流程，产品积压，虽然我们没有真正的客户：产品是新的，而潜在的用户还不知道它存在。此外，它是一个相当具体和标准化的领域，我们公司有很多经验。当时我是团队的一员（这是在第一次发布之前），我们并没有真正收集太多的正式要求，因为许多关键要求都是通过标准强加给我们的。最重要的是，我们有一些自己的想法，如何让产品脱颖而出。
在另一个项目中，我们松散地使用了Scrum流程，但是我们的赞助商和用户并没有真正了解它，所以我们一直在苦苦挣扎。 “需求收集”非常非正式，因为产品很大，不同的人/子团队被分配到不同的区域，相互独立地工作。每个子团队都有自己的联系人来讨论要求，并且联系人在地理上是分开的 - 我们很少看到他们面对面，所以大部分的沟通是通过电子邮件发生的，使用冗长的Word文档。最重要的是，我们有一个领域专家团队，他们经常与用户就具体要求存在激烈的分歧，但他们并不是很有沟通性。因此，需求过程通常包括阅读包含模糊数学内容的冗长文档，然后是包含GUI要求的其他冗长文档，然后试图弄清楚如何将两者结合在一起......然后与领域专家讨论要求，并简要宣布它这是一个小问题，我们试图从他那里取出一些更有用和具体的改进想法......然后根据我们最新的理解和专家的评论重写要求文档，并将其发回给我们的联系人。 ..然后从方块1重复。
在我们目前的项目中，我们再次让很多用户分散在全球的大部分地区。但是，至少我们的IT管理人员对SW开发和敏捷流程更了解。我们研究的是几年前形状相当糟糕的大型遗留系统 - 因此维护和稳定是我们日常工作的重要组成部分，而新的要求平均花费的时间不到我们时间的一半。但是，当我们有一个时，我们通常会进行初步估算会议，我们会尝试对该项目将采取的人数天数进行粗略估算。然后，我们的业务分析师与利益相关者一起制定越来越多的细节，我们的团队正在努力填写技术细节。
答案 3 :(得分：0)
在我看来，如果您将business analyst, subject matter experts, technical person and a user interface person标记为“产品所有者”团队，那么您实际上并没有偏离“纯粹”敏捷。
那就是说，“纯粹的”敏捷有点用词不当，因为大多数敏捷的拥护者都会告诉你，＃1或＃2的卖点是它能够适应你现有组织的业务流程和企业文化。
关键的成功因素可能是拥有该产品所有者团队，并且所有利益相关者真正投资参与您的开发团队的一些敏捷流程（出现演示，在sprint期间可以访问问题等）。 p>
修改
来自Wikipedia的引用记录了产品负责人非常简单的角色：
产品负责人代表客户的声音。他/她确保Scrum团队从业务角度处理“正确的事情”。产品负责人编写以客户为中心的项目（通常是用户故事），对其进行优先排序，然后将其放入产品待办事项中。
Scrum并不意味着强制执行产品所有者如何完成工作的流程。它只是产品负责人和团队之间的接口（sprint计划和sprint审查），Scrum试图概述。
答案 4 :(得分：0)
我们可以称之为“构建后备日志”，因为在我看来这是真的吗？我们的想法是获得那些最重要的部分，然后从那里开始工作。我看过一些不同的敏捷流程，有些工作比其他流程更好，但关键是参与流程的人员的支持程度如何。
我也同意1个月的冲刺时间太长了。尽管我已经看到稍微长一点的冲刺也可以起作用，但是2周冲刺看起来似乎对我有用。另一个问题是团队和项目的规模有多大，因为可能需要多年的工作可能并不容易。我说这是一个在一个持续了一年多的项目中幸存下来的人，许多冲刺和演示后来终于成功完成了这个项目。
我可能会认为技术人员必须密切关注全局，并了解可能合理的事情和不合理的事情，例如。在早上醒来之前让系统读懂我想知道我想要做什么而不必写出任何东西而不仅仅是认为这是不合理的。不要忘记故事将发展成更多的卡片，因为故事只是对最终结果的高级视图，通常不包括它有多容易，需要多少时间以及其他一些方面。
对于sprint本身，开发人员应该估计执行各种任务需要多长时间。虽然确定故事的优先级并不是开发人员所做的事情的一部分。需求收集会议也可以被视为构建项目章程，以便整个项目有一个时间框架，目标和其他高级细节应该在开头说明。