这几年敏捷开发很火，好像谁不敏捷就是跟不上时代落后了，很多公司的项目管理者不管三七二十一照本宣科的按照敏捷开发流程和方法去实施，最后效果不尽然，这是犯了教条主义的错误，在我看来敏捷开发就是一种软件工程思想而已，一种思想方法理论，任何思想方法理论都要结合具体的实际去实践才是有效的，否则适得其反。那么接下来谈谈我对敏捷开发的看法和理解，希望能帮到你在敏捷的路上少走弯路。
首先我们来看看敏捷的核心思想,主要包含如下要点。
敏捷即是灵活快速的意思，敏捷开发宣言——
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
这即是以价值为驱动，以人为本，持续快速迭代交付可运行工作的软件，灵活适应需求的变化，最终提前给客户带来市场价值。而传统的瀑布式的开发模式是以需求文档驱动，项目周期长，交付后的基本很难适应需求变化或适用的成本非常高，所以项目的失败率也高，这是两者的主要区别，见下图一目了然：
瀑布式开发模式流程图
敏捷开发模式流程图
敏捷开发需要把握如下10个原则：
1)目标是通过持续及尽早交付有价值的软件使客户满意。
2)拥抱和适应需求变化。
3)持续小版本迭代交付可工作的软件，项目周期倾向于采取较短的周期。
4)项目开发过程业务或产品人员和开发人员必须合体合作，每一天都不例外。
5)信任和激发个体的战斗力和创造性，从而达成目标。
6)高效沟通，常用面对面交谈。
7)可工作的软件是进度的首要度量标准。
8)以简单为本，坚持不懈地追求技术卓越和良好设计和演变。
9)建立自组织团队。
10)团队定期反思后调整提高成效。
目前业界比较常用的敏捷开发的方法体系有七种：SCRUM、XP（极限编程）、Crystal Methods（水晶方法族）、FDD （Feature-Driven Development，特性驱动开发）、 ASD（Adaptive Software Development，自适应软件开发）、DSDM（动态系统开发方法）和轻量型RUP，其中scrum最为流行。好，接下来就重点聊聊我是如何结合实际去实践scrum，容我娓娓道来。
SCRUM实施前团队必须做到：
1.科普敏捷开发思想，团队能理解并接受敏捷开发，特别是产品人员。
2.个人要掌握自我管理和自组织的能力。
上图是SCRUM开发流程的各个环节，有三个角色、四个会和三个物件，这些环节我们都有实践，只是我们会结合实际条件去做调整。
计划会，即是需求讨论会，可以多次，技术人员跟产品人员讨论最终确定需求迭代开发的版本数及各版本的需求范围；
每日站会，即项目例会，按项目线划分，各pm或pl按项目实际情况1-2天举行；
评审会，即是成产品上线后产品人员和用户使用体验，分析效果数据然后提出优化需求然后按优先级小版本迭代快速开发；
反思会，即项目总结会，所有项目干系人参与总结项目开发过程的优缺点，避免重复踩坑。
三个物件
产品backlog（即需求清单），即需求整体功能清单文档及原型，产品人员动态维护跟进，随时跟技术人员沟通；
Sprint backlog（即每个迭代版本的功能列表），需求迭代版本的功能清单文档及原型，产品人员动态维护跟进，随时跟技术人员沟通；
燃尽图（即每个迭代版本的进度情况），即是项目进度跟踪，各个项目组灵活把握，可以用excel表格也可以用trallo协同工具来跟进。
敏捷估算和开发任务认领这两点我们没有实践，因为我们认为团队的开发人员能力参差不齐，有实习生、应届生、普通开发、高级开发和资深开发组成，当然还有整个公司的架构师提供架构方案支持和技术方案评审，团队人员的能力差异决定了我们还是按照传统的方式分派任务和开发时间的评估，一般由pl或pm做好项目开发计划、任务分派和开发时间评估，当然如果是高级开发以上可以自行评估开发时间（pl和pm审核确认），如果任务自行认领和敏捷估算开发时间，可想而知普通开发以下人员开发经验不足，很难一下子挑战难度大的开发任务和评估把握好自己的任务时间，因此项目的质量和时间几乎是没法保证的，那么就达不到高质效按时完成项目的管理目标。如果团队人员都是资深开发或高级开发以上组成，我认为是可以大胆去实践敏捷估算和开发任务自行认领，尽可能发挥个人的创造性和激情。
总而言之，敏捷开发只是一种软件工程的方法论，一定要结合公司具体的实际情况来调整变通实践，一切教条主义必将会失败。
文/阿青，写代码写诗写职场的程序猿大叔，倾力原创简单实用的硬干货，转载此文请联系阿青。
网友评论