诗特林-sterning

敏捷开发（Agile Development）在国内越来越红火，随着“敏捷”一词出现在越来越多的项目中，于是，敏捷开发本身也被赋与了越来越多的意义，而敏捷的真正内涵反而变得越来越模糊。如何迈出敏捷开发第一步？是按照敏捷宝典、操作指南或是教父语录，还是因地制宜、因项目定方法？完成所有这些工作后，我们就真的“敏捷”了吗？

一、前言

Agile是指企业能够对外部环境做出速捷、有效的反应，是未来企业的必备素质。21世纪企业面临的竞争环境将是一个不断变化、不可预测的环境。由于高新技术的出现和更迭越来越快，产品的生命周期日益缩短，企业要面对这样的新的竞争环境，抓住市场机遇，迅速开发出用户所需要的产品，就必须实现敏捷反应。

狭义地讲，敏捷企业就是将柔性的先进制造技术、熟练掌握生产技能、有知识的劳动力以及促进企业内部和企业之间的灵活管理三者集成在一起，对千变万化的市场机会做出快速、有效的响应。敏捷企业强调人、组织和技术的有机结合。通过这三者的紧密结合，敏捷企业可以发挥最佳的整体效益。评价一个企业敏捷性的具体指标是时间、成本、稳健性（Robustness）和适应范围。对敏捷企业的广义理性，可以认为敏捷企业是一个CIMS（计算机集成制造系统）、动态联盟、并行工程、拟实制造、高素质员工等多方面的系统集成，是一个基于CIMS、在CMS基础上发展起来的一个更高层次的集成大系统。

二、变味的敏捷

敏捷是大家在一起高效率地工作，清楚所有沟通上的障碍，关注于增值的活动，从而使得开发更加成功。敏捷是大家肩并肩地工作，而不是什么都通过文档。敏捷是管理者积极地参加到项目管理中而不是整天去写状况报告，用那个来监督到底发生了什么事情。敏捷是开发人员和涉众（项目开发中涉及的从需求到最后交付的各种人员）在一起制定实际的计划，而不是用复杂的微软Project去制定一些几乎没人看的进度表。

公平地说，很难设想敏捷术能如何发挥作用，尤其是在一些软件开发本身都问题重重的传统组织中，被误导过的敏捷更是难以帮上什么忙。

敏捷开发，看到过这个词时，很多人一直没有什么深刻的体会，也没有仔细去研究到底什么才是敏捷开发。而一直在很多人的思想里，敏捷开发的印象就是，开发速度比较快。没错，做互联网的，快确实是一个制胜的法宝，那么敏捷开发似乎也就是在互联网应用的开发中最适合的方法了。那么敏捷开发中的参与者应该是什么状态？这似乎成了一直以来困扰很多管理者的严重问题。可以说，在敏捷开发中，并没有觉得有多敏捷，进度一拖再拖，问题一个接着一个，让我觉得我们是在进行慌乱开发。为什么会这样？

另外关于实施敏捷的效果也是充满置疑之声。我们经常看到一些号称 Agile 的国内项目，按照菜谱、操作指南和教父语录的提示，采用了许多花哨的技巧和实践（做法），是啊，表面上确实 Agile 了，那么结果呢？项目还是不能按时完成，甚至严重超支和超时，这能叫“敏捷”吗？

三、敏捷十戒

 1．天报制度

就算是进行远程开发或是两地使用开发，项目组的成员每天至少碰一次，不管是当面的，还是通过其它方式，如通过电话、email、Skype或其它。进行敏捷开发的时间，任何团队都不能以任何理由进行孤立的开发。

2．例会制度

即使每天通过Email给主管汇报工作，但有时主管还是无法及时准确的掌握项目组成员的状况及工作量。此时，通过每周一小时左右的例会将会有效的解决此问题。通过例会，大家面对面的就某些问题进行共同的探讨与讨论，找到共同的解决方案。

3．版本控制

如果没有一台干净的电脑来进行团队代码管理的话，则很有可能导致代码的混乱。而每天只须花很少的时间，哪怕一天一次，进行及时的数据提交与代码提交，则可以有效的保证团队之前代码的同步及代码的备份。

4．需求失灵

即使手里拿着30页且客户进行了签字的需求说明，有可能仍然不知所措。相对起那些良好的设计、精确的分析等，与客户持续的沟通、及时的反馈、不断的演示这些工作显得更加的有效果。可以有效的获得需求变化，减少误解，更加准确的把握用户的需求。

5．单元测试是QA的工作

很多开发人员，甚至一些高级的软件开发人员，对于单元测试没有足够的认识，在行动上也没有足够的注意。大家都一致的认为那是QA的事情。就开发人员来讲，单元测试应该是一种白箱测试，能从功能上充分的测试软件的功能性。而对QA来说，只能是一种黑箱测试，无法深入的去分析代码的优势，只是从用户的角度进行功能上的测试而已。

6．质量保证是QA的责任

自从有了质量管理这个词以及后来产生的质量管理部门后，很多开发人员就理所当然的认为质量保证是QA的责任了。其实每一个人都需要对软件的质量负责，特别是开发人员。Bug越最早发现，那么解决它的成本就越低。

7．项目进度风险控制

也许一个项目需要18个月左右才能完成，但在没完成之前，谁也无法进行比较准确的时间估计。无法确定需要多长的时间进行设计、编码及软件组件的组合。但进行项目设计、实现及融合的人应该相对比较准确的掌握与估计项目的时间。因此，需要进行项目进度的风险控制，风险总是存在的，但要进行有力与及时的控制。充分意识到项目中可能会存在的风险因素，在制定计划时预留一定的时间，如果在项目进行中出现了没有想到的问题，根据其重要性，考虑压后解决，要在计划的时间内把计划的事情完成好，并为后续解决问题争取更多的时间。

8．架构师身体力行

很多软件架构师基本上不写代码，这也许是好事。软件架构师嘛，当然是比较高级的，他们对环境、语言、类库方面都可能比软件开发人员要更加在行，但他们一般不编码。这样的架构师是危险的，特别是那些基本上不与首席开发人员进行沟通或咨询的架构师，离项目失败可能已经不远了。

9．牵一发而动全身

很多时间，在功能上做了一个很小的变动，往往导致花费好几天的功夫来进行软件的集成与整合。如果没有持续的整合、及时的回归测试、可靠的整体设计，一些看起来非常微小的修改都有可能导致很大的麻烦。

10．加大管理执行力

目前项目中，开发者或者说参与人的状态是混乱的，或者说是慌乱的。那问题在哪里呢？是工作流程出了问题？不应该啊。在项目启动前已经定了一个看似美好的流程，而且是经过参与人讨论一致通过的。那么问题在哪里呢？原来是沟通、传达出了问题，执行力不够。那么，就必须加大执行力，今日事今日毕，这是必须的。

另外，在一些产品级的软件开发中，觉得要实施敏捷式开发，我觉得也有一个不好解决的问题：没有具体的客户！没有具体的客户，那你的沟通去哪里寻找呢？一般的做法也是给一些有兴趣的用户发布Alpha版本，或者是beta版本的软件。可是当软件都到了Alpha/beta版本的时候，软件还有迭代的余地吗？未必！从我个人理解的角度来看，敏捷开发的适用范围还是很有局限性的。个人认为最适合使用敏捷开发的软件必须要有非常明确的客户才能进行，而有明确客户的情况以定制型软件为主。所以，我觉得最适合用敏捷方式开发的软件应该是——定制软件！

四、小结

记得Jim Highsmith在他的《敏捷项目管理》一书中这样写道：敏捷是指在动荡的业务环境中，适应变化并创造变化，从而获得价值的一种能力。同时敏捷是平衡灵活性和稳定性的一种能力。由此可见，望文生义地把“敏捷”理解为“做得快”也颇可商榷。如果缺乏有效的实施指导、忽视严格的敏捷实践，单凭着高层面的理解甚至“文化”就开始盲目前行，往往会因为缺乏对质量的有力保障而失去平衡，最终欲速则不达。

套用一句比较俗气的话，敏捷不是放诸四海而皆准的通用理论；敏捷不是玄而又玄的文化；敏捷不是在传统项目合作模式下包治百病的金丹；敏捷不是抛开纪律盲目求快。除了这些，敏捷还不是什么？那么，今天你真的“敏捷”了吗？