Scrum应该取代传统瀑布项目的哪些阶段？
我和我的团队正在使用Scrum来管理软件开发项目。在我的公司中，使用瀑布方法的所有IT项目都出现了向更多结构发展的趋势。这对我来说很好，因为有很多非软件开发项目将从中受益，而且它不会威胁到我们对Scrum的使用。
然而，我们需要弄清楚我们的Scrum过程(它在将产品负责人的需求转化为工作软件方面做得很好)如何适应更广泛的项目过程。
我们的新瀑布项目流程包括以下方面的明确活动(不一定按顺序进行，也不一定按此顺序进行)：
- 业务案例的制作和批准。
- 资源配置。
- 需求分析。
- 设计。
- 构建。
- 测试。
- 训练。
- 通讯。
- 去现场直播。
- 风险与发行管理。
- 利益实现。
请记住，项目可能需要交付的不仅仅是软件。它还可以包括承载软件的服务器基础结构和网络/桌面基础结构，以使用户可以使用。
我认为Scrum将愉快地管理3，4，5和6，但可能只对那些发现它增加价值的团队，这可能只是软件开发.
我们可以让其他团队使用它来生产基础设施交付品，但是他们没有看到需求或好处，我也没有(Scrum对大型、高风险的项目很好，他们正在构建一堆标准PC)。
同样，我们可以在Product中为项目经理(通常不是Scrum团队的成员)提供一个用户故事，以生成一个利益实现计划。
我们的做法正确吗？是否有更好的方法将这两种工作方式结合起来，还是说它们是排他性的，我们应该使用其中一种？
回答 1
Software Engineering用户
发布于 2013-01-09 14:27:18
Scrum是一种完整的项目管理方法，它处理项目生命周期的所有方面。与使用顺序流程管理的项目不同的是，在项目进展过程中，事情通常会发生一次，然后在必要时被重新访问，Scrum采用了一种更迭代的方法--每一次迭代都会解决所有问题。
在您确定的清单中，在项目开始时，可能会发生的唯一一件事是创建业务案例。某种目的、愿景和范围很可能只确定一次，然后只在必要时重新讨论。其他一切都发生在每次迭代中，Scrum通常负责确保项目有足够的资源，促进内部实体之间的沟通，以及管理项目风险。需求通过产品负责人提供和排序，团队负责估算实现每个需求所需的工作量，然后在整个项目中不断地改进设计、实现、测试和文档化工作产品。理论上，每一次迭代都会产生一个可以部署到客户的产品(一个“潜在的可移植产品”)。
该流程本身并不能准确地解决培训和“运行”或部署活动是如何发生的。显然，如果您的开发团队负责支持任何这些活动，那么您将希望在每次迭代中为它们构建时间，并在执行sprint计划活动时记住它们。如果它们是由不同的团队处理的，那么没有什么可以说明他们必须使用Scrum。然而，他们应该期待一个包含新特性和/或bug定期修复的工作产品(在每一个时间装箱的迭代结束时)，但是如果他们对该工作产品做了什么，就取决于他们了。
对于每个项目来说，使用相同的生命周期可能并不合适，特别是如果它不增加价值，或者从当前流程过渡到新的和不同的过程太困难或费时。例如，生成和维护基础结构的团队可能无法在单个软件开发迭代中生成所有硬件。您需要根据这些活动来规划您的新部署--您不能部署未完成的硬件，也不能发布不完整的软件。
如果软件开发将受益于使用迭代和增量方法，那么即使其他人仍然在使用顺序方法，使用它也没有什么问题。当然，只要它不对业务产生负面影响--你是否仍在按预算及时发布高质量的软件，为客户增加价值？你的进程是否会以导致人们无所事事的方式发生冲突？考虑这些，尽量减少停机时间，同时最大限度地提高交付给客户的价值。
https://softwareengineering.stackexchange.com/questions/182032
复制相似问题
腾讯云开发者
