”敏捷“是时下的IT圈子里一个非常吸引眼球的词汇。很多人误认为敏捷就是一种软件开发的流程或者实践，而其实敏捷是一组开发流程和实践的方法论。这种方法论的背后是2001年由17位资深软件开发专家在美国犹他州的一个会议上总结出的敏捷思想。时至今日，敏捷思想激活逐渐成为了软件开发业的主流。全球不同规模、模式的IT组织已经从实施敏捷开发流程及实践中取得了巨大的成功。而我国不少的IT组织也开始了解、学习敏捷思想，希望自己的组织能从实施敏捷中获益。

    然而，一个组织要接受一种新的开发模式并不容易。笔者对近期参与的一些敏捷项目进行了总结，在此与大家分享组织实施敏捷的方法以及组织实施敏捷过程中需要注意的一些问题。

    为帮助大家理解，文中使用的敏捷词汇简单解释如下。

    ●  故事： 描述一个有价值的需求的文档。

    ●  迭代： 一个开发周期，往往是一组故事完成的周期。

    ●  XP: 敏捷倡导者Kent Beck提出的一组软件开发的方法。

    ●  Scrum: 一种敏捷项目管理方法

    组织保证

    在谈论怎样在一个IT组织、企业实施敏捷之前，首先从组织架构上予以保证。那么，什么样的组织架构最适合敏捷？

    很多IT企业采用矩阵式组织结构，其中既有按职能划分的垂直领导系统，又有按产品（项目）划分的横向领导关系。一个项目团队的成员来自不同部门，隶属关系仍在原单位。很多时候一人同时参加数个项目，其中尤以质量管理人员（质量分析师、测试员等）最为普遍。这样的组织结构下，每个项目成员一般受双重管理（所在项目及隶属部门），这种组织结构存在的问题是明显的： 首先，双重管理容易破坏项目团队的整体性，部门领导和项目管理者容易产生步调上的不一致； 其次，由于团队管理的复杂化，项目透明度不高，很少有融入客户（业务部门）的机制，其后果是不能围绕客户和市场的真实需求来展开开发工作。

    对比上面提到的矩阵式组织结构，敏捷组织需要弱化职能部门的划分，更多由跨职能、面向价值交付的团队构成。大家可能会立刻问： 这样的组织结构价值在哪里？下面我们就从三个方面来分析其价值。

    敏捷组织价值一：    统一的团队

    在传统结构下，团队采取”会战“方式组成，人员之间很容易因职能隔离，导致团队内垂直划分，从而不能成为一个统一团队。各职能成员容易各自为政、目标不一。一个典型的现象是，开发人员常常在内心抵触质量管理人员提出的要求，而质量管理人员又总是对开发的系统缺乏信心，项目管理者很多时候感到力不从心，不能激励团队成员，更无法谈到融入客户、拥抱变化了。

    由于敏捷组织弱化了职能部门，敏捷团队成员全职投入到项目组中，增加了每人的团队归属感。原来一个人同时被分派多个项目的做法显然是不利于团队建设的，与之相反，敏捷组织要求员工积极参加到自己团队的日常活动中，鼓励员工参与不同职能的工作。

    图 1简单展示了一个迭代过程中业务分析人员、开发人员、质量管理人员及项目管理人员的日常工作。我们可以看到，除了每个职能例行的工作之外（如质量管理人员要完成上个迭代的故事测试，然后投入到这个迭代新故事的测试工作中），作为一个团队，大家要共同参与如”迭代开题“、”上迭代回顾“等集体活动。以”下个迭代计划“为例，项目管理人员需要安排组织会议、控制会议时间； 业务分析人员要解释下一个迭代故事的选择； 开发人员及质量管理人员则要了解相关需求，同时提出可能要进一步细化或要求重新评估的故事。通过这样一系列的活动，项目管理达到了高度的透明。同时我们可以看到客户（客户代表）被融入到团队中。远离客户的团队不可能是一个敏捷的团队，客户的参与是保证最终价值交付的关键。

    从上面的讨论中，不难想象如果不是具有高度自组织能力、统一的团队，是无法贯彻敏捷开发思想的。这样的参与度，也让每一个团队成员很快拥有项目的主人翁精神。一言以蔽之，敏捷组织通过强调集体共有及发挥每个成员主观能动性来打造统一团队。

    敏捷组织价值二：    价值驱动

    谈到价值，首先就要明确什么是价值。对于软件开发项目而言，答案其实就在下面这个问题里。

    假设在两个项目开发过程中市场都在不停变化： 项目A按时、按预算交付所有计划功能，不幸的是项目本身未能给客户带来任何帮助； 项目B因为响应变化，所以延时、超出预算交付了部分功能，但却帮助客户取得了盈利。传统项目管理方式下我们说项目A是成功的，项目组完成了计划。现实却恰恰相反，项目A没有带来任何的价值，因为它对使用者没有帮助。在现今IT市场需求快速变化的时代，按时、按预算交付已经不能成为衡量项目成败的唯一标准。

    然而，要用价值作为驱动力就必须先有感知价值变化的能力。一个团队要有感知价值变化的能力就必须是一个有高度协作精神、步调统一的团队。正如GE前总裁韦尔奇所说： ”如果我们穿着四件毛衣，那么我们就感觉不到寒冷了。“传统组织下的团队就像穿上了一件件”职能“的”毛衣“，很难感受到价值的所在。更无从谈起将客户（或业务部门）的需求转换为团队共识的价值、拥抱需求的变化了。

    敏捷团队在项目管理上的高度透明及全程的客户融入实际是将最终的客户需求植入到了每一个成员的心里，让不同职能的团队成员都能用价值来衡量自己的工作，从而使价值成为我们各种开发活动的驱动力。

    敏捷组织价值三：    减少浪费

    时下很流行把敏捷与精益制造相对比，这里我们无意讨论精益，但精益的一个重要原则”减少浪费“在敏捷的组织结构里却得到了体现。

    韦尔奇在20世纪80年代曾经用”零管理层“、”无边界行动“等理念将GE打造成美国最伟大的公司之一。在GE一个8000名员工的航空发动机工厂，只有一个厂长和全厂职工两个阶层，没有任何中间管理层。一般工厂常见的车间、工段、班组、工会、人事、财务、计划、技术、材料、供销等所有部门全部取消。在生产过程中所必需的管理职务由工人轮流担任。而一些临时性的工作，如招收新工人，就由各岗位老工人临时组成人事部门，完成之后即解散。这种扁平组织的思想与敏捷组织结构不谋而合！当我们弱化职能划分的时候，相应地那些为职能部门设立的各种烦琐的管理细节也被同时精简； 当我们打造一个统一的敏捷团队时，相应地按职能来管理人员的机制也就不再需要了。

    在参与的敏捷项目中，我们经常听到传统组织团队中资深开发领导者这样说： ”我很喜欢技术，真想跟大家一起开发。可惜日常的上下汇报、文档邮件占去了我所有的时间。根本没法参与开发！“我们不由得慨叹这种人员上的双重浪费。由于烦琐的管理细节，扼杀了团队宝贵技术资源的使用，同时也扼杀了资深人员进一步学习的可能。要消除烦琐的管理工作就必须打造有自组织能力的统一团队，这正是敏捷思想所追求的。

    敏捷实施路线图

    实施敏捷是一个组织长期自我改善的过程。根据实际情况往往可以分为三个阶段来帮助一个组织实施敏捷（参见图2）。

    实施敏捷的过程中，组织管理者往往非常关心怎样去评估一个组织的敏捷程度。由于IT企业的多样性，评估一个组织的”敏捷成熟度“不能用一刀切的标准。图3展示了我们评估一个企业敏捷实施情况的一系列维度。红条为现状，蓝条为设定的目标。每一个维度实际又从不同的角度来考查。比如”测试质量“，我们考查使用测试的种类、测试环境、自动化程度、测试运行频率及测试用户。到达尺标5则要求各种层级的测试（单元、功能、集成等）都被分级自动化，并且融入到一个故事的开发周期中由不同人员（开发、测试、客户等）实施。

    这里值得提起大家注意的是： 我们的目标是不是要所有维度都达到最优化（即到达尺度5）？或者说是不是只有各个维度最优化才能说敏捷实施成功了？答案是否定的。首先，要提高一个维度的指标必然需要一定的投入，比如想要更多地自动化测试，就会涉及选用或购买新工具，对相关人员进行培训。运用敏捷思想，衡量是否需要的标准就是价值，如果我们开发一个简单的网络应用，自动化所有测试带来的质量提高也许就远远小于我们的投入。所以，评估一个组织的敏捷程度绝对不能一概而论，一定要结合开发项目的实际情况。

 

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。