决定开发生命周期

Question

如何确定开发软件的软件开发过程，决定遵循哪个开发过程时要考虑的关键因素是什么(例如敏捷、WaterFall、螺旋等)。

Answer 1

影响这一决定的因素有很多，包括“技术”因素：

• what kind of project是否(例如内部、开源、压缩包装、企业、设备驱动程序等)
• 预测项目规模(例如人年数)和team
• 预测项目生命周期(从一次性原型到预计将在未来100年运行的任务关键型企业应用程序)
• 您可以/期望交付新版本的频率

和社交方面的：

• 是愿意以敏捷的方式与团队合作的用户在organization
• how中的文化是什么，“正常的做事方式”是管理层(和开发人员)对新想法的开放，他们能否被说服采用新的方法(有充分的论据和证据)
• is team colocated or physically

请注意，后者至少与前者一样重要，如果不是更重要的话！

技术因素

项目的性质和大小强烈地限制了您发布新版本的频率，这反过来又会影响您的敏捷程度。例如，一些开源项目可以随心所欲地发布，而according to Joel，收缩包装软件不应该每1,5年升级一次。

随着团队规模的增长，沟通往往变得更加正式，团队变得不那么敏捷。此外，项目越关键，流程就越严格和正式。

社会因素

如果你的用户不愿意，或者不能直接与你的团队合作，那么敏捷性就会受到限制。如果管理层固守传统的思维和方法，那么敏捷性也会受到限制。物理上分离的团队也是如此。

底线是:您不需要一劳永逸地选择一个流程。此外，名字和流行的缩略语并不像你的团队每天真正在做的事情那么重要。你可以用敏捷的风格做瀑布或RUP，就像你可以有效地将XP或SCRUM转变成严格的、正式的过程一样。在一个好的项目中，随着情况和团队需求的需要，流程会被不断地审查、微调和改进。从看起来足够好(尽可能简单)的东西开始，然后定期召开回顾会议，收集关于哪些进展顺利，哪些出错，以及哪些可以改进的反馈。

Answer 2

有许多方法可供选择，但没有一种明确的方法(尽管它会很好)。在我们的环境中，我们使用敏捷。这对我们来说是有意义的，因为有许多因素：

• 典型的时间约束(虽然每个项目都不一样，但确定时间约束的方式是pretty artifact)
• Budget
  • )您能够进行哪种类型的客户交互(它们是响应式的还是un-responsive)
  • Organization的指南(例如，他们是否期望在项目开始之前得到某个文档工件，以及他们是否对该资源中的内容有要求(同样不总是相同的，但在确定预算的方法上是一致的)

我还建议你看看你所在行业的其他公司，看看他们是如何处理事情的。

我要推荐的最重要的一件事是，不要纠结于这个过程，只要构建一些很棒的东西，然后让这个过程开始改进即可。虽然我们使用敏捷方法，但它是一种我们自己的混合，对我们有效。

希望这会有帮助，我相信会有比我更好的答案:-)

Answer 3

就我个人而言，我会考虑项目的总体规模(预计在几天/几周内开发，而不是几年)，复杂性，开发团队的规模(以及在多个地点的共处或分布)……..but最重要的是，看看利益相关者，并考虑他们对项目的期望程度。

所有这些因素都倾向于在粗糙的两极相互吸引。

小而快的项目往往有一个较小的开发团队，较低的仪式要求，并可能适合更“敏捷”的方法。更大的，多年的项目往往有庞大的团队，盛大的仪式，并可能适合更多的瀑布式的方法。记住，没有迭代的瀑布无论如何都不会成功-但这超出了你的问题的范围。