关于敏捷软件开发的一些思考

从瀑布流开发转为敏捷开发已有两年多，从最初的照猫画虎到现在能够结合实际情况做定制化的敏捷开发流程，期间的经历改变了我对敏捷开发的一些认知，实践才能出真知。

敏捷开发不是快，而是灵活

• 小步快跑，最小化验证并不是强调迭代节奏要快，很多人都误解了，而是强调灵活，船小好调头；

• 快的意思是单个迭代周期短，能够快速交付（相比于瀑布流开发）和验证；

• 灵活的前提是每个迭代的技术债务尽量在当周或者次周清理，技术债务积累后会导致项目无法灵活，所以清理技术债务也应该算作是迭代的一部分，属于技术性需求；

• 为了足够灵活，就应该尽量减少人员的复用，所以只要是需要消耗时间的工作都应该放在迭代中，比如改bug、程序设计和评审、代码评审、性能优化、市场反馈问题改善等和技术强相关的工作；

敏捷开发是让项目尽量透明

• 敏捷开发可以理解为是将瀑布流开发拆分为若干个小的瀑布流开发，这样做的目的是让项目足够灵活，即使有需求变动也能够快速调整，在迭代中消化；

• 如果不能做到项目透明，会导致技术债务堆积、存在潜在的问题、项目进度的延迟，如果不能保证产品的稳定和迭代进度，那脱离了目标的敏捷就没什么意义了；

• 瀑布流开发并不是一无是处，它很适合于大型软件的开发，如果能够做到项目透明，其实也是非常棒的；

敏捷开发对人的要求高（是意愿而不是技能）

• 当敏捷开发失败或者不顺畅时，往往会得出敏捷开发对人的要求很高导致不可抗力的结论，的确，敏捷开发对人的意愿要求很高，因为需要团队协作和根据实际项目情况随时改变，但对人的技能要求并不会很高，即使刚毕业的大学生也是可以参与到敏捷开发中的；

敏捷开发同样需要规范和流程

• 要相信规范和流程对人的约束比每个人对自己的约束更有效，你见到过没有红绿灯的交叉路口的交通场景吗？

• 有明确的规范和流程有助于提高迭代效率，减少不必要的沟通和无意义的工作；

• 所以敏捷宣言中的“个体和互动高于流程和工具”要看你自己如何理解，好的流程和工具可以提高工作效率、减少沟通成本，并且可以实现敏捷开发并不一定对人要求高；

• 敏捷宣言中“工作的软件高于详尽的文档”可能适合于整个敏捷团队，但不适合于开发人员，关于程序设计、流程图、数据结构、ReadMe等还是有必要有详细的文档的，起码能够让自己加深对需求的理解、方便他人接手工作。

关于晨会内容

• 晨会的目的是让项目透明，组员之间知道相互的进度，有问题尽早暴露；

• 晨会中每个人只叙述昨天做完了什么？遇到了什么问题？今天要做什么？

• 晨会中一个领域（产品、软件前端、测试、软件后端等）只派一个代表参加就可以了，没有必要都参加，浪费时间；

• 晨会上不做问题的讨论（要讨论就在会后拉上相关干系人讨论就好了），只叙述项目的实际情况；

• 晨会多半都会是流于形式，意义并不大，所以平时保持沟通比特意开晨会更有意义。

敏捷开发是非常好的一种软件开发方法，他能够调用各个岗位对工作的积极性，也能够提高项目的成功率，但千万不要被敏捷宣言和一些表面上的叙述误导，在真正的实践中总结、定制化会有助于项目真正地实现敏捷。