Scrum方法Agile (敏捷) 开发和 vs 传统的软件开发

传统的软件开发

各类大中小型企业所运用的传统软件构建方法，即是众人在很多变体，但其典型性是在开发初期制定详细的计划，计，并且一切详细资料都记录在案。任务已设计制定，并工具和Microsoft Project 项目管理软件。开发团队预计开发而得出的。当项目管理者(stakeholder)全面审核开发计划并团队成员完成他们所专长的部分工作，即刻转交给其他成工作都已完成，成品将会转交给产品质量控制部门，在这的全面检测。在整个流程中，所有相对于原始计划的分歧成品与原始设计保持一致。

此种模式有优点但也有不足之处。它的最大的优点是非常记录下来，按照计划实施，保持各项事务尽可能的有组织参与,人对于此种工作方式并不适合。

比如：此种方式要求所有的建议和想法都要在开发周期的可以被容入开发计划之中。但是众所周知，好的想法和建开发最启始阶段，在开发中期，有时可以在产品交付使用许变化的产生，那么将会遏制创新的产生。在使用“瀑布新将不是好的征兆，而是对整个产品开发产生的危机。

瀑布型开发方式特别注重将事件记录在案，以此作为传递重要信息的首要方法。因此最合理的假定是如果我可以把我的想法尽可能都记录下来，这样将会使信息更可靠的传输到团队每一个
成员的头脑中；另外，因为所有东西都记录在案，这将是我完成任务的最实际的证据。但是实
际上，在大多数情况下，没人会读这些100 页左右的详细规格要求资料。同样，如果有人读取
该资料，那么将会产生许多的误解。记录的资料只是我头脑中想法的抽象提取；当你阅读此资
料时，你将会产生另一个抽象的概念，此时与我的真正想法已经相距甚远了。所以严重误解的
产生也就不足为奇了。

当人参与时,还有一种情况会发生——“实际应用中产生的灵感”——在第一次实际应用产品
时，你可能会立刻产生20 种方法以使产品更加完美的灵感。但是遗憾的是，这些非常有价值的
想法通常会在产品开发的末期产生，这时创新是最困难和最具有分裂性的——换句话说，是做
正确抉择最昂贵的时刻。

人的预知未来的能力是有限的。比如，某场比赛的最终结果是出人意料的。不可预测的技术问题的突然出现，会强制开发方向的转变。此外，人们往往非常欠缺对于未来作出长远计划的能
力——今天猜测未来八个月中每周你如何工作将如幻觉般渺茫，这正是Gantt (根特)图表的衰败
表现。

另外，瀑布型方式将会促使团队成员在交接工作时产生敌对的关系。“他要求我构建在规范要
求中不存在的东西。”“她经常改变主意。”“我不可能对我不能控制的东西负任何的责任。”这些指引我们对瀑布方式的另一思考——在此种方式中工作毫无兴趣可言。事实上，进一步说，瀑布型方式是造成产品开发人员苦恼的根源，并且最终产品将不会体现出他们的创造力，技能和开发创造者的激情。人不是机器人，此种将人认为是机器人的流程将会造成人们工作激情的丧失。

一个僵硬的，拒绝变革的流程也会造成低劣产品的产生。客户可能会得到根据他们第一需求所生产的产品，但是在产品在形成阶段时还是客户真正需要的吗？在开发之前收集所有的需求并
将它们嵌入毫无改变可言的顽石般的计划中，此产品将被宣告只会和最起始的想法保持一致，
而不是开发团队在实践中不断发现可能性而使其尽善尽美。

许多使用瀑布型方式的团队不断的体验到了它的缺陷，但是它看起来是一个极其付有逻辑性的方式，所以第一的自然反应就是对内部工作的谴责：“如果我们尝试更好的使用它，它将会发
挥作用”——如果我们计划的更详尽，记录更详细，更严格的拒绝任何变革，一切将会很顺利
地进行。遗憾的是，许多开发团队只得到的相反的效果：他们越竭尽全力尝试此方法，得到的
结果越差！

Agile (敏捷) 开发和Scrum

Agile (敏捷)开发整体概念的产生是基于一种方法更接近人类活动现实情况, 以便取得更好效果的信念上。Agile 强调构建可以即时操作的软件，相对于在构建前花费许多时间记录规格要求。
Agile 注重授于小型多职能的团队决策权，相对于大型层次和部门职能的划分，Agile 注重快速
迭代，并且其中结合尽可能多的客户反馈。在学习了解Agile 的时候，经常会有这样的公认——感觉非常像回到了开发启始的阶段，我们曾经”做过”。

Scrum 是众多快速发展的Agile 方式之一。Scrum 是在十多年前由Ken Schwaber 和Jeff
Sutherland 博士共同提出的，现在此方式已被众多大中小型企业使用，其中包括Yahoo! ,
Microsoft, Google, Lockheed Martin, Motorola, SAP, Cisco, GE Medical, CapitalOne 和 US Federal Reserve. 许多使用Scrum 的团队取得了重大的改进，其中更有个别在生产效率和职业道德方面得到了彻底地改革。对于产品开发者——许多曾受到“管理层每月的一时狂热”的伤害——这
是非常重要的。Scrum 是简单的，强有力的，并立足于常识之中的。