论文部分内容阅读
编者按：
敏捷软件开发又称敏捷开发，是在一个既定的时段内将本应由一个项目组完成的独立产品开发任务切分成若干个有关或无关的任务，并行或迭代开发。相对于“非敏捷”而言，“敏捷”开发更强调程序开发团队与业务专家之间的紧密协作、面对面的沟通、紧凑而自我组织型的团队、能够很好地适应需求变化的团队组织方法。因其更注重软件开发过程中“人”的作用，人们也将敏捷开发的理念应用于组织管理当中。
许多数码公司通过在业务部门实行敏捷软件开发方法，迅速设计与开发出产品的新功能，引入消费者参与测试，并在快速迭代中完成产品更新。但是，若想将敏捷开发推行到多个业务单元，则需要重新思考基础步骤、公司结构以及各部门间的关系。
相反，只有极少数同时拥有线上及线下业务的公司，会在其主要的产品和应用开发团队中采用敏捷开发方式。尽管许多银行已经成立数字部门以加速推出移动端应用及网站功能，但是这些数字部门从行政结构及策略布局上，通常与IT部门以及公司其他部门相对独立。
阻止传统型公司推行敏捷开发模式的原因有很多，但我们认为最主要的障碍是其现存的运营模式及组织结构。大部分传统型公司的产品开发依旧保持着分散和复杂的状态：一家需要在网站上搭建新功能的公司，会启动一个涉及多部门的开发流程，而每个部门都只能负责流程中的几项任务。比如：一支团队专注于前端应用开发，另一支团队负责更新相关服务器和数据库，可能还有一支团队负责协调系统前后端对接。
对大部分公司来说，敏捷开发的试运行都极为成功，但如果不对公司结构进行调整，便很难将敏捷管理从小范围推广到所有业务单元。
扩大敏捷开发的实践范围
为了更好地理解大规模部署敏捷开发的障碍，我们对13家公司进行了深入调研，它们涉及金融服务、医疗保健、电子通信等多个行业，且正处于大规模部署敏捷开发的不同进程中，部分推进较快的公司已在其60%或更多的创新活动中采用了敏捷开发。
这些公司针对一个或是多个运营模型进行了调整，主要集中在以下四个方面：调整组织结构，使之转变为以产品为主导；改进业务部门与 IT部门的交流；重新定义业务部门及IT部门的角色与职能；反思现有预算及规划模型（如表1）。
敏捷开发的优越性已广为人知。在敏捷开发方式下，IT部门、产品开发者与业务部门共同创造产品和服务，而非简单地将功能要求汇总起来，直接丢给后方。不同团队可以利用极简版的可行性产品进行实验、测试并从中学习，最终在几天或几周内便开发出新的软件功能，而无需花费几年时间。
传统型企业倾向于根据应用及项目来组织分配IT资源，最终形成之前提到的那种分裂式的产品开发过程。实际上，公司应当以产品为中心来分配IT资源，并将业务单元领头人、开发人员以及公司内其他成员，以一种稳定的、面对面的团队组织形式集中起来，为同一个业务结果而努力。
采用以产品为导向的组织结构
在大规模的敏捷开发环境中，“产品”不应被狭隘地定义为商业产品，它们也包括不同产品的组合，比如薪资管理服务，或者客户体验，或者一个产品团队共用的IT系统。因此对业务部门和IT部门的领导者来说，重新定义部门承担的责任非常重要。当产品被重新归类后，公司必须派出一支或是几支专门的敏捷开发小组，来负责这些产品的开发与维护。
一家大型的医药设备制造商通过调整组织结构，显著地缩短了产品上市的时间。如果想在其原有基础上开发一个新的软件或是在现有软件上增加新功能时，业务部门与技术部门所共享的规格和技术要求，可能会有多达20项的交接。领导层意识到，只在单个业务单元或特定的几个产品组里部署敏捷开发是完全不可行的。
2015年，该公司调整了产品所有权模式，使来自业务部门的产品负责人可以直接向敏捷开发团队提出软件要求，而无需通过多个部门来传递。结构上的调整促进了好几个敏捷操作团队的形成。这些根据角色或话题组织起来的小组，对公司大规模推行敏捷开发起着至关重要的作用。他们能够鼓励团队成员分享各自擅长的专业知识，促进团队与职能部门的合作，并且持续推进团队成员的业务进步。
加强业务部门与IT部门的交流
大部分传统企业中，来自业务部门的负责人在软件开发过程中参与有限，仅在被问及时才提出意见。为了弥补该负责人的参与不足，IT部门通常会派出一个代表作为产品负责人。这种安排在短期内会比较有效，但是会损害产品和项目的长期成功。
由于组织结构的原因，IT部门的负责人通常并不直接与用户打交道，也无最终决定权。由于项目缺少方向性指导，工作项目优先级不明确以及责任人缺失，敏捷开发便无法进行下去，整个团队也面临着重复工作和资源浪费的问题。
相反，一个强大的产品负责人对产品相关问题、与客户的关系以及客户本身都有深入的了解，并有权做出快速决策，以便提高效率，减少在开发过程中遇到的瓶颈。
一家提供“软件即服务”的公司一直被如何将产品更快地推向市场困扰。这家公司存在着IT部门与业务部门决策缓慢、沟通不畅的问题，经常一年才能推出一到两个产品。2014年，该公司实施了一个三层的产品拥有权架构，由一个首席产品负责人带领一个产品区块，一个高级产品负责人带领一条产品线，以及多个产品负责人与迭代式增量软件开发团队合作。
在这个新的结构下，IT部门和业务部门之间的交流有了显著改善。沟通更加清晰，公司也能够更快地做出决策，并保持产品团队间的一致性以及紧密合作。也是由于结构上的调整，这家公司每个季度都能向市场推出新的软件产品，有时甚至每月都推出新产品。
重新定义管理层角色与职责
在被调研的公司中，有半数公司都针对敏捷开发的独特要求，重新定义了原有开发模式下经理层的角色以及职责。在原来的开发模式下，项目经理通常要在应用开发团队、数据库团队及其他团队间协调不同的任务。而在敏捷开发操作下，涉及的任务以及需要协调的事务都被最小化。问题会被产品负责人或是敏捷开发团队自行解决。原来由直线经理所负责的与开发流程相关的任务，现在都由自我管理、以产品为中心的敏捷开发团队自行解决了。 这些在大范围内推行敏捷开发并取得成效的公司，流程都极为透明公开。他们向团队成员提供了清晰的指导，详细说明决策的达成方式。责任界限划分清晰，团队成员被赋予适当责任，同时也避免恶意行为或是全权委托造成过大的风险。
重新制定预算以及规划模式
IT部门通常都会有年度预算以及规划周期，在不同项目之间平衡预算极为痛苦，也有可能带来很大程度的重复劳动以及资源浪费。这种模式对于想要大规模实施敏捷管理的公司来说几乎就是个诅咒。
欧洲一家大型保险公司重新调整了预算制定的过程，将预算用途分成三类：一个由业务部及IT部门经理组成的开发委员会，每月定期会面，以决定新项目是否该执行；首席产品负责人负责资金的具体分配和调整，以便在新的商业机遇出现时能够快速做出决定；产品负责人的主要职责是滚动式地审查预算，保证软件开发能够在40小时的工作框架中得到执行，维护任务及产品待办列表得到管理。预算制定过程调整后，该公司在预算方面的灵活性大大提高，并且加快了对市场的反应速度。
有不少公司甚至尝试风投模式的预算。初始资金能够极快地批准给极简的可行产品，然后根据客户的初级反馈进行调整后再次推向市场。而接下来是否继续提供资金支持，则要根据这些极简可行产品在市场上的表现来决定。风投模式的预算使公司能在早期就消灭掉那些没有潜力的产品。
选择正确的方式
改革运营模式是一项大工程，需要考虑一些较大的风险以及短期内对日常工作的干扰。就像其他的管理行为调整一样，向敏捷管理转变也需要不同级别、不同职能的部门与业务单元的长期付出与承诺。
一种极端的情况是，部分公司采用了实验室方式。 这种方式对那些暂时只有部分高层支持实行敏捷管理的公司来说比较明智，它能够迅速证明其商业理由，以便让敏捷管理获得更大规模的推广。然而，为采用实验室方式而单独建立起来的敏捷开发部门，依旧倾向于自成一派，未能在整个公司内部形成更大的影响。
另外一种极端就是采取爆发式重组方式。公司将职能部门和业务单元规划到新的组织结构及新角色中，建立自我管理的敏捷开发小组，并同时加速业务流程。
两个极端方式之间则为棘波方式。在这种方式下，小团队被分批次转化为敏捷开发团队，而公司整个运营模式按照不同阶段进行转化。举例来说，一家大型技术服务公司想要快速提高其数字化能力，决定将产品开发团队分为5个批次转化为敏捷开发团队。第一批次培训并部署了5个团队，而第二批次安排了20个团队。当这些团队接连被转化至敏捷开发操作后，收到的反馈以及培训资料将被改进并用于下一批次团队。
在完成敏捷开发转化6个月后，这家公司采用了以产品为中心的组织架构，将业务部门领导、开发者、工程师以及IT部门的其他成员组织到不同的“部落”中。又过去几个月后，公司运营模式开始又一层级的调整，重点调整IT部门与业务部门的交流。由于运行模式发生改变，使得产品开发组能够与IT操作团队紧密合作。经过上述一系列调整之后，产品推向市场的速度显著提高，更因为不同团队共同参与和创造了产品，产品缺陷以及返工现象也明显减少。 责编/张晓莉
来源：麦肯锡网站
敏捷软件开发又称敏捷开发，是在一个既定的时段内将本应由一个项目组完成的独立产品开发任务切分成若干个有关或无关的任务，并行或迭代开发。相对于“非敏捷”而言，“敏捷”开发更强调程序开发团队与业务专家之间的紧密协作、面对面的沟通、紧凑而自我组织型的团队、能够很好地适应需求变化的团队组织方法。因其更注重软件开发过程中“人”的作用，人们也将敏捷开发的理念应用于组织管理当中。
许多数码公司通过在业务部门实行敏捷软件开发方法，迅速设计与开发出产品的新功能，引入消费者参与测试，并在快速迭代中完成产品更新。但是，若想将敏捷开发推行到多个业务单元，则需要重新思考基础步骤、公司结构以及各部门间的关系。
相反，只有极少数同时拥有线上及线下业务的公司，会在其主要的产品和应用开发团队中采用敏捷开发方式。尽管许多银行已经成立数字部门以加速推出移动端应用及网站功能，但是这些数字部门从行政结构及策略布局上，通常与IT部门以及公司其他部门相对独立。
阻止传统型公司推行敏捷开发模式的原因有很多，但我们认为最主要的障碍是其现存的运营模式及组织结构。大部分传统型公司的产品开发依旧保持着分散和复杂的状态：一家需要在网站上搭建新功能的公司，会启动一个涉及多部门的开发流程，而每个部门都只能负责流程中的几项任务。比如：一支团队专注于前端应用开发，另一支团队负责更新相关服务器和数据库，可能还有一支团队负责协调系统前后端对接。
对大部分公司来说，敏捷开发的试运行都极为成功，但如果不对公司结构进行调整，便很难将敏捷管理从小范围推广到所有业务单元。
扩大敏捷开发的实践范围
为了更好地理解大规模部署敏捷开发的障碍，我们对13家公司进行了深入调研，它们涉及金融服务、医疗保健、电子通信等多个行业，且正处于大规模部署敏捷开发的不同进程中，部分推进较快的公司已在其60%或更多的创新活动中采用了敏捷开发。
这些公司针对一个或是多个运营模型进行了调整，主要集中在以下四个方面：调整组织结构，使之转变为以产品为主导；改进业务部门与 IT部门的交流；重新定义业务部门及IT部门的角色与职能；反思现有预算及规划模型（如表1）。
敏捷开发的优越性已广为人知。在敏捷开发方式下，IT部门、产品开发者与业务部门共同创造产品和服务，而非简单地将功能要求汇总起来，直接丢给后方。不同团队可以利用极简版的可行性产品进行实验、测试并从中学习，最终在几天或几周内便开发出新的软件功能，而无需花费几年时间。
传统型企业倾向于根据应用及项目来组织分配IT资源，最终形成之前提到的那种分裂式的产品开发过程。实际上，公司应当以产品为中心来分配IT资源，并将业务单元领头人、开发人员以及公司内其他成员，以一种稳定的、面对面的团队组织形式集中起来，为同一个业务结果而努力。
采用以产品为导向的组织结构
在大规模的敏捷开发环境中，“产品”不应被狭隘地定义为商业产品，它们也包括不同产品的组合，比如薪资管理服务，或者客户体验，或者一个产品团队共用的IT系统。因此对业务部门和IT部门的领导者来说，重新定义部门承担的责任非常重要。当产品被重新归类后，公司必须派出一支或是几支专门的敏捷开发小组，来负责这些产品的开发与维护。
一家大型的医药设备制造商通过调整组织结构，显著地缩短了产品上市的时间。如果想在其原有基础上开发一个新的软件或是在现有软件上增加新功能时，业务部门与技术部门所共享的规格和技术要求，可能会有多达20项的交接。领导层意识到，只在单个业务单元或特定的几个产品组里部署敏捷开发是完全不可行的。
2015年，该公司调整了产品所有权模式，使来自业务部门的产品负责人可以直接向敏捷开发团队提出软件要求，而无需通过多个部门来传递。结构上的调整促进了好几个敏捷操作团队的形成。这些根据角色或话题组织起来的小组，对公司大规模推行敏捷开发起着至关重要的作用。他们能够鼓励团队成员分享各自擅长的专业知识，促进团队与职能部门的合作，并且持续推进团队成员的业务进步。
加强业务部门与IT部门的交流
大部分传统企业中，来自业务部门的负责人在软件开发过程中参与有限，仅在被问及时才提出意见。为了弥补该负责人的参与不足，IT部门通常会派出一个代表作为产品负责人。这种安排在短期内会比较有效，但是会损害产品和项目的长期成功。
由于组织结构的原因，IT部门的负责人通常并不直接与用户打交道，也无最终决定权。由于项目缺少方向性指导，工作项目优先级不明确以及责任人缺失，敏捷开发便无法进行下去，整个团队也面临着重复工作和资源浪费的问题。
相反，一个强大的产品负责人对产品相关问题、与客户的关系以及客户本身都有深入的了解，并有权做出快速决策，以便提高效率，减少在开发过程中遇到的瓶颈。
一家提供“软件即服务”的公司一直被如何将产品更快地推向市场困扰。这家公司存在着IT部门与业务部门决策缓慢、沟通不畅的问题，经常一年才能推出一到两个产品。2014年，该公司实施了一个三层的产品拥有权架构，由一个首席产品负责人带领一个产品区块，一个高级产品负责人带领一条产品线，以及多个产品负责人与迭代式增量软件开发团队合作。
在这个新的结构下，IT部门和业务部门之间的交流有了显著改善。沟通更加清晰，公司也能够更快地做出决策，并保持产品团队间的一致性以及紧密合作。也是由于结构上的调整，这家公司每个季度都能向市场推出新的软件产品，有时甚至每月都推出新产品。
重新定义管理层角色与职责
在被调研的公司中，有半数公司都针对敏捷开发的独特要求，重新定义了原有开发模式下经理层的角色以及职责。在原来的开发模式下，项目经理通常要在应用开发团队、数据库团队及其他团队间协调不同的任务。而在敏捷开发操作下，涉及的任务以及需要协调的事务都被最小化。问题会被产品负责人或是敏捷开发团队自行解决。原来由直线经理所负责的与开发流程相关的任务，现在都由自我管理、以产品为中心的敏捷开发团队自行解决了。 这些在大范围内推行敏捷开发并取得成效的公司，流程都极为透明公开。他们向团队成员提供了清晰的指导，详细说明决策的达成方式。责任界限划分清晰，团队成员被赋予适当责任，同时也避免恶意行为或是全权委托造成过大的风险。
重新制定预算以及规划模式
IT部门通常都会有年度预算以及规划周期，在不同项目之间平衡预算极为痛苦，也有可能带来很大程度的重复劳动以及资源浪费。这种模式对于想要大规模实施敏捷管理的公司来说几乎就是个诅咒。
欧洲一家大型保险公司重新调整了预算制定的过程，将预算用途分成三类：一个由业务部及IT部门经理组成的开发委员会，每月定期会面，以决定新项目是否该执行；首席产品负责人负责资金的具体分配和调整，以便在新的商业机遇出现时能够快速做出决定；产品负责人的主要职责是滚动式地审查预算，保证软件开发能够在40小时的工作框架中得到执行，维护任务及产品待办列表得到管理。预算制定过程调整后，该公司在预算方面的灵活性大大提高，并且加快了对市场的反应速度。
有不少公司甚至尝试风投模式的预算。初始资金能够极快地批准给极简的可行产品，然后根据客户的初级反馈进行调整后再次推向市场。而接下来是否继续提供资金支持，则要根据这些极简可行产品在市场上的表现来决定。风投模式的预算使公司能在早期就消灭掉那些没有潜力的产品。
选择正确的方式
改革运营模式是一项大工程，需要考虑一些较大的风险以及短期内对日常工作的干扰。就像其他的管理行为调整一样，向敏捷管理转变也需要不同级别、不同职能的部门与业务单元的长期付出与承诺。
一种极端的情况是，部分公司采用了实验室方式。 这种方式对那些暂时只有部分高层支持实行敏捷管理的公司来说比较明智，它能够迅速证明其商业理由，以便让敏捷管理获得更大规模的推广。然而，为采用实验室方式而单独建立起来的敏捷开发部门，依旧倾向于自成一派，未能在整个公司内部形成更大的影响。
另外一种极端就是采取爆发式重组方式。公司将职能部门和业务单元规划到新的组织结构及新角色中，建立自我管理的敏捷开发小组，并同时加速业务流程。
两个极端方式之间则为棘波方式。在这种方式下，小团队被分批次转化为敏捷开发团队，而公司整个运营模式按照不同阶段进行转化。举例来说，一家大型技术服务公司想要快速提高其数字化能力，决定将产品开发团队分为5个批次转化为敏捷开发团队。第一批次培训并部署了5个团队，而第二批次安排了20个团队。当这些团队接连被转化至敏捷开发操作后，收到的反馈以及培训资料将被改进并用于下一批次团队。
在完成敏捷开发转化6个月后，这家公司采用了以产品为中心的组织架构，将业务部门领导、开发者、工程师以及IT部门的其他成员组织到不同的“部落”中。又过去几个月后，公司运营模式开始又一层级的调整，重点调整IT部门与业务部门的交流。由于运行模式发生改变，使得产品开发组能够与IT操作团队紧密合作。经过上述一系列调整之后，产品推向市场的速度显著提高，更因为不同团队共同参与和创造了产品，产品缺陷以及返工现象也明显减少。 责编/张晓莉
来源：麦肯锡网站