敏捷开发(Agile)在国内越来越火

敏捷开发在国内越来越火

敏捷开发(Agile)在国内越来越火 敏捷开发（Agile Development）在国内越来越红火，随着“敏捷”一词出现在越来越多的项目中，于是，敏捷开发本身也被赋与了越来越多的意义，而敏捷的真正内涵反而变得越来越模糊。如何迈出敏捷开发第一步？是按照敏捷宝典、操作指南或是教父语录，还是因地制宜、因项目定方法？完成所有这些工作后，我们就真的“敏捷”了吗？ Agile是指企业能够对外部环境做出速捷、有效的反应，是未来企业的必备素质。21世纪企业面临的竞争环境将是一个不断变化、不可预测的环境。由于高新技术的出现和更迭越来越快，产品的生命周期日益缩短，企业要面对这样的新的竞争环境，抓住市场机遇，迅速开发出用户所需要的产品，就必须实现敏捷反应。 狭义地讲，敏捷企业就是将柔性的先进制造技术、熟练掌握生产技能、有知识的劳动力以及促进企业内部和企业之间的灵活管理三者集成在一起，对千变万化的市场机会做出快速、有效的响应。敏捷企业强调人、组织和技术的有机结合。通过这三者的紧密结合，敏捷企业可以发挥最佳的整体效益。评价一个企业敏捷性的具体指标是时间、成本、稳健性（Robustness）和适应范围。对敏捷企业的广义理性，可以认为敏捷企业是一个CIMS（计算机集成制造系统）、动态联盟、并行工程、拟实制造、高素质员工等多方面的系统集成，是一个基于CIMS、在CMS基础上发展起来的一个更高层次的集成大系统。 敏捷型（agile)(也被称之为“轻量型”lightweight)的软件开发方法，以矫正官僚繁琐过程，许可对过程进行自主调整为特征，在软件业引起了极大的兴趣。敏捷型方法的合理性，着重点并不是放在其“轻重”上，而是于他们的适应性（adaptive)性质和以人优先的理念。你在决定是否要走敏捷之路时需要考虑的因素有: 一． 采用敏捷开发（敏捷开发是否适合您的组织？） 在开发流程和与流程开发相关的问题中，敏捷性已成为热门话题，因为: 1.   企业希望能够更快地对市场变化做出反应。 2.   IT部门希望交付结果而不需要正式（或通常）的六个月发布周期。 3.   开发人员喜欢稳定的开发环境，以便能够在其中集中精力处理正在构建的软件的功能和质量。 二．从敏捷开发中获益 每个软件开发人员或许都经历过梦魇般的编程项目：项目历时长达预期时间的两倍，严重超出成本预算，又远远看不到结果。幸好，现在可以使用敏捷编程来解决这些问题。 三．敏捷带来哪些价值？ 公司需要想办法降低开发成本、提高软件可靠性、缩短开发时间，并且确保应用软件真正有助于用户，而不是有碍于用户。这些方面对任何人来说都是难以实现的，但敏捷编程技术能够在许多应用编程场景做到这一点。敏捷编程可通过减少开发人员在设计及开发应用软件中所犯的错误来降低开发成本。 许多公司期望任何开发项目都能迅速获得投资回报。然而，如果公司等待开发人员完成整个应用软件，大多数项目就会被搁置多年。而敏捷编程技术不是等待整个应用软件完成，而是立即使用应用软件的至少一部分，这意味着用户可以马上从应用软件中受益。 传统的软件开发方式是以预测为主的，而敏捷式开发是以适应性为主的。传统的软件开发方法就是开始把用户所想要的功能详细记录下来，这些需求被固定下来，然后以此作为基础，计划整个项目的开发。敏捷开发的价值衡量从业务实现出发，而不是按时间、按计划完成。敏捷式开发也会在开始做一个详细的计划，但是这个计划是在开发当中不断根据情况来进行调整、变化的。通过敏捷开发，在一个项目开发的过程中，真正给客户带来价值的东西不一定是在项目的初期就已经预测到，或者是定义好的功能。敏捷开发允许一个团队使用一种可以控制的方式来按照这种方法进行开发。 四．敏捷开发为何受阻 敏捷开发对于目前的软件开发人员来说已经不是一个陌生的概念了，国际软件过程领域的敏捷运动是源于2001年的，而敏捷开发被国内的软件人员所了解大概是在2002年前后。不过，总的来说，敏捷开发目前的发展还是相对缓慢的。 敏捷开发最初的目的是为了让大型软件企业更好地完善开发流程。但是今天我们也看到依然有许多公司，它们尽管也在倡导敏捷开发，却并不知道如何使用敏捷开发，甚至主观上并不愿意真正使用敏捷开发。对于很多依靠软件服务获得利润的公司来说，它们为了更多地获取短期利益，始终不愿意让它们的客户接受敏捷开发的模式，而是继续采用它们所习惯的并且所擅长的传统开发模式。对于一个大型软件开发企业来说，如果要从根本上采用敏捷开发模式，那么无疑需要很长时间的调整期，这里将涉及很多的利益。 不同类型和规模的公司适合的开发方法可能是不同的，我们在给用户提供解决方案的时候，就具有一定的灵活度，使得敏捷开发可以很好地应用到各种不同的体系之中。比如说小公司，可能是一个很小的任务;而对于一些大公司，可能是一个很大的需求。我们的工具可以根据企业的需要进行分解，大的模块可以化小，并把它不断地分解下去，以适应各种不同规模的团队。总的来说，我认为可以活用工具和解决方案，以适应各种各样不同规模的团队，只是在不同规模的开发环境上，应用需求不同而已。” 其实，对于很多还不是很成熟的小公司，只要方法得当，一样可以选择敏捷开发方法。而且对于中小型软件开发企业来说，通过敏捷开发方法，将可以获得追赶领先企业的能力。 五．迎难而上需要策略 目前用户在开发流程中面临着一些急需解决的挑战，这些挑战主要包括：在资源有限的情况下，如何开发出更高质量的软件，也就是如何在降低成本的同时开发出高质量的软件;在复杂性不断增加的环境下，如何在降低复杂性的同时保证可靠性和性能。当然，企业还面临着一些额外的挑战，比如如何满足规范和标准、如何面对分布式团队开发所带来的问题等。 面临这些挑战，企业要如何更好地改善自己的开发流程呢?事实上，相比传统的开发过程，敏捷开发更强调快速灵活反应、主动迎接和适应变化，主张客户与开发商更紧密地协作，这样的特点在加快软件开发和降低成本方面具有很多优势。 六．变味的敏捷 敏捷是大家在一起高效率地工作，清楚所有沟通上的障碍，关注于增值的活动，从而使得开发更加成功。敏捷是大家肩并肩地工作，而不是什么都通过文档。敏捷是管理者积极地参加到项目管理中而不是整天去写状况报告，用那个来监督到底发生了什么事情。敏捷是开发人员和涉众（项目开发中涉及的从需求到最后交付的各种人员）在一起制定实际的计划，而不是用复杂的微软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在他的《敏捷项目管理》一书中这样写道：敏捷是指在动荡的业务环境中，适应变化并创造变化，从而获得价值的一种能力。同时敏捷是平衡灵活性和稳定性的一种能力。由此可见，望文生义地把“敏捷”理解为“做得快”也颇可商榷。如果缺乏有效的实施指导、忽视严格的敏捷实践，单凭着高层面的理解甚至“文化”就开始盲目前行，往往会因为缺乏对质量的有力保障而失去平衡，最终欲速则不达。 套用一句比较俗气的话，敏捷不是放诸四海而皆准的通用理论；敏捷不是玄而又玄的文化；敏捷不是在传统项目合作模式下包治百病的金丹；敏捷不是抛开纪律盲目求快。除了这些，敏捷还不是什么？那么，今天你真的“敏捷”了吗？