scrum敏捷开发初探

        最近在看一本敏捷开发相关的书《轻松scrum之旅》，它不是一本scrum教科式的书，它采用了以小说的笔触，以主人公参与敏捷开发的过程为主线，将敏捷开发的概念，原则，特点贯穿其中，让人读起来不觉乏味

        scrum敏捷开发对比传统的瀑布软件开发模式确实在很多好的地方，拥抱变化，能很好的应对需求的变化；简化了传统开发中需要编写的众多文档；注重团队的自我管理，不是传统开发过程的命令与控制方式

       敏捷开发将一个项目分解成多个Sprint，每个sprint的时间在2~4周左右，在每个sprint之前都要做一个sprint计划,每个sprint计划包含多个use story，这个story感觉像是功能描述，这样将一个大的过程分解成多个小的迭代周期，如果期间有需求的变化，都可以放到不同的迭代周期里完成。传统的瀑布开发模式，则是注重按部就班，需求，设计，开发，测试，一步做好了，才做下一步，如果上面的环节有变化，或有问题，那下面环节完成的工作很多都白费了，又要重新再来一遍，很多失败的软件项目都有这个问题，需求的变更导致灾难性的后果，所有采用传统开发模式的项目都抵制需求的变化。

      瀑布开发过程非常强调文档的输出，而且规定了详细的格式，甚至细化到每一小节的内容，因为这一开发模式对每一个过程认可的成果就是文档，这一点尤其是那些号称有CMMI资质的公司尤甚，大量的时间耗费在写文档，评审文档，修改文档里面，最后完成的文档却被束之高阁，基本没人再看过，只是为了应付公司的流程，敏捷强调的是可以工作的软件重于面面俱到的文档，过多的文档需要开发人员花费大量时间来维护。文档应该是为程序服务的，因此应当短小精悍、易于维护，而且主题突出。敏捷方法认为最根本的文档就是源码。

      敏捷注重团队的自我管理，敏捷的团队是扁平化的结构，没有上下级之分，只有不同的角色和职责,每个sprint的计划都是由团队来共同制定，backlog里面的任务大多也是由人员自主认领，敏捷强调成员的沟通，敏捷认为人是软件开发中最重要的因素。开发团队成员之间有效的交流、沟通与协作，比单纯的编程能力更为重要。人与人面对面的交流，是最有效、最迅速的交换信息的方式。

       scrum敏捷开发只是提供了敏捷的理念和指导原则，它没有详细的操作说明，如何实践敏捷开法，需要在实际开发过程中不断的学习和总结