这是敏捷吗？Scrum？如何提高敏捷性？

Question

这是敏捷吗？Scrum？对于在这种情况下如何使它变得更敏捷，有什么建议吗？哪些点是积极的，哪些是可以改进的？

• 该产品是为客户开发的，谁将再出售它，同时支付我们的版税。
• 团队不能直接与最终用户交谈。只卖给经销商。
• 产品需求文档是在开始开发之前创建的。
• 需求是僵化的，不会改变。
• 商定了交付时间表，包括"alpha“、"beta”等里程碑，以及这些里程碑附加的特性/时间。
• Scrum团队中的所有开发人员都向产品所有者(一位软件经理)报告。
• 团队中的测试人员向QA经理报告。
• 产品负责人已经指导团队执行某些高风险的技术任务。最终用户不能使用这些任务的输出，而是一些最终将在产品中使用的技术/代码。
• 产品负责人根据需求创建了一个待办事项。
• 产品负责人无法回答有关产品的一些问题。他指的是其他人或记录在案的要求。
• 团队经历了Scrum的运动。每天的Scrum，Sprint计划，回溯等等。有一个ScrumMaster。
• 每个sprint、产品所有者和管理人员都决定团队处理哪些待办项目。
• 有一张烧毁的图表。有故事和任务的Scrum板。对这些的估计来自于团队。
• 这支队伍坐在一个开放的地板上，“公牛笔”与其他球队共用，所有的都是可见的和可听到的。有交叉队的噪音和有步行的交通周围的团队区域。
• 团队可能被要求参加与冲刺目标没有直接关系的各种会议。
• 有选择某些技术解决方案的压力。规定了一些工具和程序。

Answer 1

看起来你从敏捷开发中拿出了一些花哨的东西，把它们放到瀑布过程中，现在你称它为敏捷。

该产品是为客户开发的，谁将再出售它，同时支付我们的版税。

这样就可以了。

团队不能直接与最终用户交谈。只卖给经销商。

这样就可以了。产品负责人与经销商交谈并收集需求。

产品需求文档是在开始开发之前创建的。

这样不好。我还没有看到明确的需求集可以预先定义的项目。将您的产品需求文档更改为产品远景(简称)，使用一些可能会更改的初始需求集。

需求是僵化的，不会改变。

这是不好的，你将看到在未来，这也是不正确的。

商定了交付时间表，包括"alpha“、"beta”等里程碑，以及这些里程碑附加的特性/时间。

这样不好。从团队进度中可以看到真正的日程安排。您可以创建一般的里程碑，但是分配将在这些里程碑中实现的功能集合并不灵活。在开发过程中，这种情况会发生变化。

Scrum团队中的所有开发人员都向产品所有者(一位软件经理)报告。

这样不好。我不会说开发人员向产品所有者报告。Scrum过程保持了过程的可见性，但是开发人员除了定期的会议之外，什么都不报告。产品负责人有责任与团队保持联系，并作为积极的参与者亲自查看进度。

团队中的测试人员向QA经理报告。

这样不好。测试人员应该是开发团队的一部分，因为用户故事在测试之前是不会完成的(应该有自动测试来验证验收标准)。可以有单独的QA，但是这是额外级别的复杂测试，通常是在客户端进行(但不必这样)来验证SW是否做了客户期望的事情，反馈作为新的待办事项或but收集到现有的已完成的待办事项。

将完整的QA分离到开发团队之外，就会破坏完成定义的全部目的。有些QA必须是团队的一部分，这部分与任何QA经理无关--这一部分是与开发团队的承诺。

产品负责人已经指导团队执行某些高风险的技术任务。最终用户不能使用这些任务的输出，而是一些最终将在产品中使用的技术/代码。

这在每个项目中都会发生，但它应该是针对最终用户的某些产品待办事项的一部分。它可以直接包含在当前迭代中实现的待办事项中，也可以作为一个尖峰(概念的证明)包括进来，以澄清一些将来应该实现的待办事项的复杂性。

产品负责人根据需求创建了一个待办事项。

这是必须的。

产品负责人无法回答有关产品的一些问题。他指的是其他人或记录在案的要求。

这样不好。知道答案是产品负责人的工作。他有责任，他必须做决定。如果他不知道答案，他必须尽快找到答案。

团队经历了Scrum的运动。每天的Scrum，Sprint计划，回溯等等。有一个ScrumMaster。

这是好的，但这并不意味着团队正在进行Scrum。

每个sprint、产品所有者和管理人员都决定团队处理哪些待办项目。

这绝对不行。产品所有者和管理人员可以确定优先级，但是承诺(选择最优先的项目)是团队的责任。

有一张烧毁的图表。有故事和任务的Scrum板。对这些的估计来自于团队。

这样就可以了。

这支队伍坐在一个开放的地板上，“公牛笔”与其他球队共用，所有的都是可见的和可听到的。有交叉队的噪音和有步行的交通周围的团队区域。

如果团队觉得这会降低他们的工作效率，那么结束这一切是Scrum大师的责任。

团队可能被要求参加与冲刺目标没有直接关系的各种会议。

没关系，在这些会议上浪费的时间将导致较小的承诺(团队将做更少的实际工作)。这取决于Scrum主人/管理人员减少这些会议以提高团队的速度。

有选择某些技术解决方案的压力。规定了一些工具和程序。

这部分没问题。对于工具和体系结构，可以有非功能性的需求，也可以定义过程，但最终的实现仍然取决于团队。

Answer 2

看起来像一个小瀑布，而不是完全敏捷的方法

。

这可能是头发裂开了

虽然从表面上看，它看起来像一种敏捷的方法，但我相信它可能与“迷你瀑布”有更多的共同点。迷你瀑布项目假设所有(或大部分)需求可以在设计创建之前被理解，并且编码遵循每个迭代或“阶段”。

这就要求对这些要求具有高度的确定性。敏捷假定，在创建系统的工作版本之前，所有的需求都是不可知的。

时间装箱与功能修复

敏捷倾向于“时间装箱”(使用时间/特性/成本的铁三角隐喻)。瀑布更倾向于“固定特征”。

提供迷你瀑布

的问题

向客户交付“迷你瀑布”的问题是，他们通常得不到他们想要的东西。在查看了工作软件之后，他们意识到他们在需求文档中说的并不是他们想要说的，但为时已晚。

一旦

客户端看到工作软件

，他们可能就会改变需求

这种情况一直在发生，准备在以后的阶段中进行更改，以满足需求的变化。如果您期望需求发生变化，这可能会改变您设计框架的方式。

的一些建议，以使这个更敏捷的

• http://simpleprogrammer.com/2010/04/07/dont-go-chasing-waterfalls-mini-waterfall-vs-agile/

如果您想停止考虑迷你瀑布，开始考虑敏捷…。停止连续地构建软件，并开始考虑并行地构建软件。停止思考：*步骤1:获得需求*步骤2:设计解决方案*步骤3:开发解决方案*步骤4:测试开始思考：*步骤1:找出用户想要的第一件事*步骤2:建立一个小块，确保它是正确的*步骤3:检查如何使它更好*步骤4:继续直到用户满意为止

Answer 3

产品需求文档是在开始开发之前创建的。然后使用Scrum和Sprints构建项目。

这是一个迭代和增量的开发，并不是真正的敏捷。

很多所谓的scrum项目都有一个需求文档(PRD)，并且是预先完成的UI设计，尽管它们没有严格的需求。

至少对于敏捷来说，除了您正在做的工作之外，在sprint end演示产品负责人中，客户和团队应该提供反馈，PO应该能够根据这些反馈更改需求。此外，团队应该是自组织的。