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

        传统开发是假设“人之初，性本恶”，而敏捷开发是假设“人之初，性本善”，即人是靠得住。但是呢，如果人靠得住，又为什么会有那些质量管理体系呢？？事实是，人经常都靠不住。即便是机器也有蓝屏宕机的时候，更何况是人。

         拿上楼梯来举例，传统开发是一格一格踏踏实实走上去，而敏捷开发是两格两格跳上去。如果你能力足够强，你倒是可以跳着上去。如果你能力不强，那你就会摔跤，得不偿失。这也是为什么有些软件工程教材认为应当在掌握了传统的开发方法后，再实践敏捷开发。甚至软件行业的一些咨询公司认为组织应当达到CMMI 2级，再实施敏捷开发。

        敏捷开发对人的综合素养要求极高，有较高的智商和情商，有扎实的专业知识和丰富的的工作经验。直白的说就是人人都是高手，人人都是精英。但是这样的团队是很难建立起来的。很多企业招聘数月也遇不到一个合适的人才。而且敏捷开发其实和中国的职场大环境是矛盾的。绝大多数企业倾向于招聘年轻人，但是年轻人的知识和经验是很有限的，这就注定了敏捷开发失败的命运。为什么国外的敏捷运动相对要更成功一些呢？？因为国外招聘不卡年龄，甚至60岁也可以奋斗在技术一线，这样企业才有更大的可能性吸收到人才。

        敏捷对于大部分团队来讲，是一种逃避流程和文档的借口。真正能成功实施敏捷的团队寥寥无几。什么叫成功呢？？有一个公式，用户满意度=合格的产品+好的质量+按照预期的进度和成本交付。敏捷会提高项目失败的几率。

        敏捷还真不一定能敏捷得起来，我举一个例子。传统开发里面有一种技术叫需求跟踪矩阵，通过多个矩阵能把用户需求、功能需求、设计元素、程序模块以及测试用例关联起来。有了这些追踪链接，当你要更改一个用户需求时候，你能快速的定位要修改哪些功能需求、哪些设计元素、哪些程序模块，以及哪些测试用例。也就是做变更的影响分析。然而如果没有这种技术方法，你就需要用肉眼扫描所有的工作制品。其一是扫描速耗时长，其二是容易有遗漏。而一旦有遗漏，有会产生缺陷，之后会引发返工的问题，势必浪费不少时间。如果在开发的过程中逐步建立起跟踪矩阵，那么这样的投资回报率是很高的。

        敏捷开发对文档的要求很少，甚至把用户测试当做是用户需求。对于用户故事中的一系列场景，敏捷只是做一些口头沟通或者在白板上潦潦草草的画画，并不要求形成正式且规范的文档。这样会形成“知识真空区”，即人员流失后，若你需要解决问题，你既没有文档也找不到合适的人员可以帮忙，从而使项目的进度搁置。

        或许在敏捷和传统开发之间找到一个平衡点更合适。我个人更推崇RUP（统一过程）。RUP和UML结合得很紧密，既提供了过程框架，也提供了文档方法。比敏捷更严格更科学更规范。并且RUP是可以裁剪的，可以调整成适合自己组织的方式。例如省去部分流程和文档，因地制宜。

        敏捷实践方法少，但是每一条都难以做到。比如其中一条就是每周工作40个小时，也就是说不加班。而这和中国的企业文化是背道而驰的。在亚洲，许许多多的公司都崇尚加班文化。不过不得不承认，敏捷中的有些方法是可取的，是能产生时效的，比如站立会议。

        敏捷开发还存在其它一些问题，就拿Scrum的角色分配来说。

        1、Scrum Master承担如下细分角色：

        （1）会议主持人；

        （2）牧羊犬；

        （3）雷锋；

        （4）外交官；

        （5）教练；

        （6）清道夫。

        2、Product Owner承担如下细分角色：

        （1）领域专家；

        （2）需求决策人；

        （3）需求讲师；

        （4）测试人员；

        （5）验收人。

        3、团队成员承担如下细分角色：

        （1）设计人员；

        （2）实现人员；

        （3）自我管理人员。

        如此多的角色，势必会造成一个人同时担任多种角色的情况。这样的人本身就不好找。就算有，不同的角色所需要的知识和经验是不同的，而任务间的切换势必会降低工作效率。即便是假设多个人分摊多个角色，也应当确保这些人要协调一致，对需求的理解与解释是一致的。

        敏捷特别强调用户全程参与，其实这是很难做到的。如果你有参加与定制开发的项目，那么你很可能听到过这样的声音：“需求我不是已经告诉你了吗？为什么还不去做？”用户是没有那么多精力和时间来参与项目的，并且他们还缺乏相关的意识和技能。能全程参与项目是一种奢侈。

        总之，敏捷开发的适用范围窄，不仅需要全员都是精英大佬，还需要企业文化做支撑。