在Scrum敏捷开发兴起之前，最开始的软件行业普遍采用的是瀑布式开发，瀑布式开发分5 个阶段：需求分析、设计、编码、测试和维护。
--需求分析阶段通常定义系统的需求，明确系统的目标；
--设计阶段通常确定系统使用什么数据库、系统模块的划分、各个模块的功能；
--编码阶段用编程语言实现设计阶段的任务；
--测试阶段分黑盒和白盒测试，测试系统的功能是否能实现、是否准确；
--维护阶段是根据用户新的需要重新修改系统，使系统更加稳定，更符合用户的要求。
瀑布式开发比较大的缺点在于产品投放市场的时间太慢，对变化及变更的响应难度大、成本高，员工士气、动力和责任感方面都很低，投资回报率低，经常失败。
瀑布式开发现在正逐步被“迭代增量式开发”所取代，Scrum是一个迭代式增量软件开发过程，通常用于敏捷软件开发，Scrum最初只应用于软件开发，后来也可以被成功地应用于其他产业。
现在Scrum通常被认为是一种用于开发任何产品或管理人和工作的迭代式的、增量的过程。
Scrum敏捷开发宣言主要有4 条，分别突出和强调个体与交互、可用的软件、客户协作和响应变化。
1．个体和交互胜过过程和工具
企业能不能做大、做强，不是说拥有一流的商业模式就可以成功，现代企业之间的竞争是人才的竞争，人才是关键因素，人是项目获得成功最重要的因素，没有人来执行，即使有再好的工具和资源，也不起作用。人的合作能力、沟通能力以及交互能力比单纯的编程能力和工具更重要，其实质是强调团队的价值，好的团队，凝聚力强，扬长避短，成员之间互相信任、有激情、合作默契，能够解决很多复杂的交互问题，这样的团队沟通效率高，再复杂的问题，可能一两句话就沟通清楚了。人要是出了问题，再强大的工具和先进的方法都没有用，人是工具和方法的主体，人要胜过工具和方法，只有人结合强大的工具和先进的方法才能提高生产率。
2．可用的软件胜过完备的文档
在第一个原则中也提到了好的团队，彼此信任、沟通效率高，复杂的问题可能一两句话就沟通清楚，这个时候，面面俱到的书面文档就显得有点多余，甚至有的时候还不如没有文档，这就好比本来用手机通话沟通就能解决的问题，偏偏选择写书信的方式来进行沟通，但是这并不是说就不要编写文档，而是在迫切需要并且意义重大时，才进行文档编制，编制的内部文档应尽量精简并且主题突出，容易理解。
3．客户合作胜过合同谈判
在产品实践中，经常会碰到与甲方客户签订合同的情况，对于一个项目的情况，产品人员能将所有的需求细节都考虑到是较困难的，所以不可能做到一次性将甲方客户的需求完整、清晰地表述在合同中，何不如在彼此信任的基础上，建立互助合作式关系，积极、快速地响应甲方提出的需求，为开发团队和客户的协同工作方式提供指导的合同才是最好的合同，而不是在合同里追究所谓的“违约”造成彼此要承担的责任义务。
4．响应变化胜过遵循计划
变化是现实中客观存在的，需要积极应对变化。在产品实践中也一样，计划安排必须有足够的灵活性，太死板不利于调整，不能盲目地按照计划执行，需灵活应变，短期的迭代计划比中长期计划更加有效。
网友评论