一种提高组织内敏捷采用的方法

白皮书 一种改善组织内敏捷采用的方法 Abstract 敏捷方法在希望缩短上市时间并更快执行变更的组织中越来越受欢迎。但是，实施敏捷需要在整个组织范围内改变思维方式和工作方式 ifitistosuccessful.Thispaperexaminesthetopmostbusiness,technicalandoperationalchallengestoimplementingagileinorganizationsusingcomplexpackedERPslikeSAP.Italsoprovidesclearstepstoove 这些挑战，从而帮助组织从敏捷转型的投资中获得最大价值。 Introduction 许多组织正在采用敏捷，因为它具有缩短上市时间，及早观察，快速失败以及在产品开发过程中更深入的利益相关者参与等优点。尽管这些结果对企业具有吸引力，但实施 由于几个原因，敏捷是一个挑战。 敏捷更像是一种哲学，而不是一种过程或工具。因此，它具有明显的变化阻力。旧的工作方式，思维方式，感知的技术挑战以及时间或能力的限制必须用新思维代替。敏捷团队的结构非常不同 ，利益相关者扮演不同的角色。软件开发过程也会发生变化，开发团队必须适应这一点。例如，现有的流程（如需求文档及其可追溯性）在敏捷团队中无关紧要，因为敏捷团队的重点是以“足够”的信心迭代地做事。这与传统模式大相径庭，传统模式的重点是在开始开发之前获得完全的清晰度。 为了接受敏捷思维，利益相关者必须在三个不同的层面上改变他们的工作方式和理念： •Business •技术 •Operational 以下各节将深入研究这三个级别中的每个级别所涉及的挑战，并建议解决这些挑战的步骤。这些建议基于Infosys在为全球领先组织实施敏捷项目时的经验和最佳实践。 为了接受敏捷思维，利益相关者必须在三个不同 的层面上改变他们的工作方式和理念： •Business •技术 •Operational 外部文档©2020InfosysLimited 1.改变业务视角 实施敏捷时面临的最重要的业务挑战可以大致分为五个方面： A.抵抗变化 B.业务参与度低 C.“敏捷只适用于IT”的神话 D.不正确的切片要求 E.变革成本高 1.A.抵抗变化 大多数IT项目的发起人和用户都有预设的工作方式，这使得难以适应变化。风险厌恶和对敏捷的好处缺乏明确性使这一点更加复杂。还有一种错误的想法，即在提供业务需求后退出项目可以节省时间。 我们的经验表明，在需求收集阶段仓促会导致在测试阶段花费额外的时间，因为必须再次讨论需求。 使用难以理解的行话和引入新的项目执行角色 没有适当的培训和背景会导致用户与项目执行保持距离，从而导致抵制。 前进的道路 •创建一个全面的组织-广泛的变革管理计划这涵盖了关于敏捷工作方式及其好处的强制性培训，以及展示敏捷不同仪式的研讨会 •鼓励分享积极的经验和案例研究由业务利益相关者和内部敏捷拥护者来提高对敏捷实现的理解。如果组织之前没有敏捷经验，则邀请公司或顾问分享他们的故事 •定期发布成功案例专注于可交付成果，突破时刻，成本节约，质量等，以创造积极的心态，并激励更大的企业社区接受敏捷方法 •突出显示参数像最终用户体验和长期价值超出了明显的好处 努力和节省成本，以提高认识和采用 1.B.业务参与度低 通常，初始需求并不总是清晰或精细的。业务利益相关者通常看不到 在初始软件设计和构建过程中参与，假设解决方案可能有太多更改。 对通过稳定的业务参与和“一个团队”运营的概念所取得的收益的了解也很有限。缺乏权威 indecision-makingfurtherreducesparticipationofbusinessstakeholders.Theymaynotbethedirectbeneficiorofthedeliveredsolutionand,hence,shelawayawayfromactiveparticipation.Anothercommonassumptionisthatsolutionsaretootechnicalwiththatthat 理解。由于软件构建的IT和业务角色的严格划分 ，业务利益相关者不认为可交付成果是互惠互利的产品。 前进的道路 •使用设计思维和原型以获得解决方案的早期视图 。这增加了可见性，从而鼓励积极参与 •准备利益相关者价值图在项目的早期，确定并让直接受益者参与解决方案的构建 •参与项目团队的支持将技术解决方案文档转换为业务利益相关者易于理解的文档 •授权产品所有者对技术设计的不同方面做出决定 •确保灵活的预算和时间表以便利益相关者可以探索项目执行的新方法 1.C.“敏捷是为了IT”的神话 在许多组织中，期望IT以最少的方式交付项目 业务用户的参与。但是，敏捷项目中业务用户的参与很少会导致交付不足或交付不完整，使请求者感到沮丧，并由于返工而导致更高的成本。另一个误解是，由于业务用户参与是必要的，因此敏捷使IT 这些错误的想法和糟糕的用户体验源于未能实现敏捷的真正好处，导致了消极的心态。 前进的道路 •举办提高认识会议展示了敏捷执行的好处，并强调了业务参与的重要性。在高级领导的推动下，这提高了用户的参与度 •促进敏捷仪式和方法在纯业务（非IT）项目中。通过将敏捷性定位为战略组织目标 ，业务 将鼓励利益相关者自己构建新的敏捷功能和计划 1.D.不正确的切片要求 通常，用户故事按功能或技术领域进行细分，导致用户故事被视为孤立的工作包。 前进的道路 •指派训练有素或经验丰富的专业人员来编写用户故事。例如，深入了解端到端业务工作流的产品所有者 •明确定义接受标准和故事情节 1.E变更成本高 在SAP中，从成本角度来看，频繁的更改和重新定义业务流程往往令人望而却步，阻碍了实验。主要原因是SAP的模块化结构以及高度专业化的顾问 他们只专注于他们的核心专业知识。此外，每个变化都有自己的回归影响。 前进的道路 •在小的、独立的块中推动创新由于其相对独立的性质，可以从业务和技术角度轻松管理 •实现资源的交叉技能，特别是在技能容易转移的工作流中，如 SD-MM，MM-PP，MM-Ariba， Functional+ABAP等。 •投资于自动化测试并构建回归测试套件当采用敏捷在业务用户中创建积极的心态时，必 须在任何组织变革管理计划中全面涵盖这五个领域 。 Planning Finance Manufacturing SAP 物流 质量管理。 销售和分销 2.改变技术视角 打包应用程序的产品开发不同于定制应用程序。在打包应用程序中，每个需求都必须在预先交付的大规模交叉引用的基础上进行定制 ERP系统。这需要首先了解应用程序，然后了解预配置解决方案和业务需求之间的差距。在使用SAP项目的敏捷方法时面临的常见技术挑战是: A.无法执行多个版本 B.需要跨职能技能 C.由于体系结构限制而导致的版本控制挑战 D.长时间的影响评估 E.繁重的文档 2.A.无法执行多个版本 大多数组织将任何需求视为一个“大”故事，需要在一次迭代中交付。这是需要的最大的思维方式改变。 前进的道路 •业务用户应将其需求分解为较小的需求 以减少跨功能 需求。这在一定程度上可以在IT团队的帮助下实现 •创建独立的解决方案块通过从业务和技术角度梳理和完善故事。然后，这些块可以由独立团队交付，从而消除了对跨职能团队的需求 •优先考虑技术因素超过业务考虑，如果它有助于缩短上市时间 2.B.需要跨职能技能 SAP有多个模块，专注于不同的业务流程，如销售和分销、财务会计和控制、生产计划、物料管理、质量管理、 etc.TheITteamshelpingintheimplementationandmaintenanceofSAPhavealwayshadacleardemarationofskillswithdedicatedspecialistsforeachofthesemodules.Thus,development 主要由一组熟练的高级业务应用程序编程（ABAP）顾问来处理。 前进的道路 •包括具有交叉功能技能或技术功能技能的个人类似于IT团队中其他技术的全栈顾问。这可以是销售和分销模块的专家，具有ABAP技能，可以分析影响并更快，更准确地实现实施。这些跨职能技能在通过业务流程知识增强后，可以帮助快速执行用户故事。 跨职能ERP：提供了很多好处 ，但在实施中带来了挑战 •复杂的解决方案 •相互依赖 •跨职能影响 •昂贵且耗时 2.C.由于体系结构限制而导致的版本控制挑战 SAP项目中的常见挑战之一是多个开发人员无法处理同一段代码（在SAP中称为“对象”） 。该对象在完成软件开发之前是不可用或锁定的 生命周期(SDLC)。因此,在新的变更开始之前,较早的变更必须在生产环境中。这限制了可以并行执行的需求 /项目的数量,导致组织损失宝贵的时间。 前进的道路 •利用发布管理计划更改并避免因需要同一对象的多个项目而产生的任何冲突 •建立发布管理组或变更批准委员会，以确定业务需求的优先级，并决定谁获得对象的所有权 •使代码模块化成为优先事项在IT开发团队中减少对特定对象的依赖 •提供并行环境，一个用于小的增强和错误修复 Operations 事态发展 DEV 改装 QA ，另一个用于主要项目。这种方法可能需要额外的努力，当改造变化和保持系统同步时 PROD •为开发人员提供解决方案管理器中的正确功能例如CSOL（跨系统对象锁定），以及/SDF /OBJ_TR_COMP和/SDF/OBJ_OVERLAP等 Dev和Ops的并行景观 改造程序，以识别冲突并在构建过程中解决冲突 DEV1QA1 ，从而确保只有正确的版本被推入生产 2.D.长时间的影响评估 积压改进 部署后支持 冲刺执行UAT部署 •利用BPCA（业务流程变更分析器）识别影响和测试范围 •BPCA还可以用于在规划阶段基于影响评估得出估计 任何软件更改都需要适当的影响评估。在SAP中 ，由于固有的软件包复杂性，例如跨组织中多个流程的相互依存或跨功能使用解决方案，影响评估需要很长时间。通常，更长的影响评估意味着敏捷性降低。 前进的道路 •建立良好的知识库了解已实施的解决方案 前进的道路•使用ALM工具跟踪解决方案详细信息 ,requirementtrability,etc.,duringthe •使用精益文档提供解决方案的高级概述，implementationphase.Thesecanalsobe 特别是对于较短的上市时间。项目所有者可以选referencedtowhenpreparingthefinal 择消除详细的文档或使其成为实施后的活动documentation •利用ABAP编辑器中的内置文档功能以及代码中的内联注释功能，以简化文档 ，并创建详细的业务流程图，以加快影响评估 •使用BPCA等工具/解决方案在SAPSolutionManager，InfosysPanaya等中加速流程并提高准确性 2.E.繁重的文档 每个项目都涉及在项目生命周期中开发的广泛，复杂和独特的文档。尽管从长远来看需要这些文档，但创建它们是一项耗时的活动，并且阻碍了敏捷性。 3.改变运营视角 “敏捷操作”在指 在组织中应用SAP开发项目的敏捷原则和方法。采用敏捷方法时出现的一些关键运营挑战是： A.管理敏捷的范围 B.处理多个批准 C.通过远程协作实现单团队文化 D.在每个sprint中交付可交付产品 3.A.管理敏捷的范围 定义敏捷合同的范围总是具有挑战性。即使敏捷欢迎在每次迭代中对需求进行更改，不受控制的灵活性有时也会陷入“范围蠕变”，使项目超出其最初定义的计划。 敏捷史诗的不正确表达可能会对用户故事产生级联效应，掩埋实际业务 项目的目标。范围蔓延的其他一些原因包括在细化过程中忽略了业务目标，无法更早地可视化最终产品，以及由于在可行性阶段缺乏技术梳理而缺少关键要求 。