上两周参加了部门项目敏捷培训，讲的是项目管理敏捷，内容很多，挑了一些点在团队中试运行，最终可落地的只剩下需求分解，看板管理两点。看起来，从技术角度看敏捷，通常讲的是项目研发层面的敏捷，涉及通过组织架构、流程机制、绩效管理、项目协同、产品研发、持续交付等层面的调整，推动业务技术相融合。由于各团队的现状不一样，很难采用一套标准化的敏捷协同模式，敏捷更多的是局部根据实际情况，悟出敏捷强调的“价值交付、适应变化、自组织、沟通、MVP”等的内涵，并进行落实。
本篇作为系列第2部分“运维组织”的“组织思维”章节中的“敏捷思维”的理解。
1、数字化转型与敏捷思维
虽然不同企业的数字化转型举措各有不同，但总体上大家还是认同以下主流观点：
- 用数字化思维重塑并打造一个以数字化为主的商业、业务、运营模式；
- 业务层面，需要快速响应政策要求、市场变化、客户需求；
- 管理层面，需要建立在线的协同网络，构建数字化工作空间；
- IT层面，需要快速交付业务需求；
上面观点的解决方案都关联着敏捷思维，以火得不行的中台战略为例，讲的是“前台、中台、后台”三个齿轮的故事。原来前台的小齿轮与后台的大齿轮在转动时由于速率不一样出现匹配上的问题，所以需要在前台齿轮和后台大齿轮之间加一个中台的适配齿轮。这样前台的小齿轮可以转得很快，而后台的齿轮又可以转得很稳，所以中台是为了前台敏捷。同样，业务的数字化是为了敏捷的感知客户需求、快速决策、高效执行，设计思维、精益创新等方法讲的是敏捷创新的方法，建立扁平化、轻量化、柔性化、网络化的组织架构对应的是敏捷组织等等都与敏捷相关。
咨询公司分析师可能都会说，数字化转型企业迫切需要打破原有的组织体系，进行组织变革，打破条线割裂、层级森严的传统组织架构，实现敏捷型组织。从技术角度看敏捷，通常讲的是项目研发层面的敏捷，涉及通过组织架构、流程机制、绩效管理、项目协同、产品研发等层面的调整，推动业务技术相融合。再到具体的敏捷方法会有看板、用户故事、持续集成、持续发布等。
2、运维中的敏捷思维
运维领域的方法论ITIL、ISO20000、ITSS等讲的是最佳实践，最佳实践强调标准化、规范化，与敏捷提到的“适应变化、自组织”等思想看起来不搭。但如我在系列开始提到的，企业价值创造是一个传递过程，如果企业数字化转型强调敏捷，这种企业文化将会传递到运维组织。由于金融企业需确保当前业务稳健开展，且行业对业务连续要求越来越高，运维组织要思考运维领域中哪些适合最佳实践类的标准化、规范化、流程化，哪些又适合敏捷。
以下从敏捷宣言看看哪些需要运维关注。
【持续交付】我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。
【接受变化】欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
【MVP、持续交付】经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
【加强沟通协作、IT服务】业务人员和开发人员必须相互合作，项目中的每一天都不例外。
【员工赋能】激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
【加强沟通协作】不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
【MVP、持续交付】可工作的软件是进度的首要度量标准。
【持续交付】敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
【架构可扩展性、高可用】坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
【不浪费】以简洁为本，它是极力减少不必要工作量的艺术。
【自组织】最好的架构、需求和设计出自自组织团队。
【加强总结】团队定期地反思如何能提高成效，并依此调整自身的行为表现。
从上面的敏捷宣言摘一些与运维相关的关键词：持续交付、接受变化、IT服务、加强协作、架构可扩展性、自组织、不浪费、加强总结。下面讲讲对这些关键词的理解：
2.1持续交付
devOps思想是敏态的一种方法论，而持续交付是devOps最常用的落地方法，devOps从运维角度看可以通过敏稳双态来分析。联想提到过IT敏稳双态的思想，指企业在转型过程中，将会面临业务形态呈现不同程度的双态特征，即确保现有传统核心业务稳健、有序发展，同时敏捷、高效的尝试拓展各种业务创新。用敏稳双态的思想看运维，大致如此：
- 稳态：以ITIL、ISO20000等思想为主，流程固定，使用行业相对成熟的最佳实践，技术架构更加成熟。
- 敏态：以devOps思想为主，通常是面向创新，需要快速交付客户需求，具有高频迭代，广泛采用新技术架构的特点。
由于金融企业对于业务连续性的高标准，当前，稳态运维模式仍将是IT运维的主要思想，敏态的运维模式重点是对稳态运维对于IT交付效率与速度不断提升情况下的补充。在敏态运维中，运维需要在业务连续性保障基础上，能够更高效的响应业务需求，快速交付业务，这就需要运维将能力前移。持续交付是在CI的基础上完成软件构建，不断的将软件持续部署到测试、准生产、生产等环境，并在相应环境进行操作，目标是将软件产品交付给用户，持续交付关注业务价值。从持续交付角度看，一方面需要运维更好的适应迭代频率不断提升的变更迭代，另一方面还要提升高频迭代带来业务连续性风险的应对能力。持续交付涉及的线上化、数字化、自动化工具链是帮助运维人力资源基本保持不变的背景下，提升持续交付能力的基础。关于持续交付的内容详见《持续交付》。
2.2 接受变化
有人说运维属于不喜欢变，不善于变化的团队。我觉得在企业数字化转型的大背景下，运维应该是变得最快的团队。IAAS云颠覆了基础、硬件团队工作模式，去IOE改变了基础、系统、数据库管理员的技术栈，云原生架构改变业务运维的一些工作职能，高频迭代、复杂架构等给运维带来大量挑战，运维工具平台不断消灭操作性工作……这一切都引导着运维团队不断打造软件运行数字世界的方向，站在敏捷角度看接受变化，我觉得运维团队要从企业价值，从业务角度去提升运维组织的能力，而不应该丢掉不断复杂的业务层，下沉到越来越标准化、软件定义的基础设施环境。站在业务角度，就要持续加深好运维对于软件运行数字世界的掌控能力，具体能干什么详见《数智万物下，重新思考运维价值》
2.3 IT服务
IT服务放在敏捷这里好像是反向的，因为敏捷讲变化，IT服务是标准化与契约精神，我觉得IT服务价值重点提升沟通协作效率，线上化的服务交付方式已经在电商、云、电子政务等领域证明是一种加强沟通协作的方式。将运维转向服务型的组织，就是要运维像电商一样售卖商品，像电子政务一样提供政务服务。IT服务对于运维作用是：回归到业务价值，以契约方式交付业务连续性保障、软件交付、业务咨询、硬件资源、运营数据等IT服务能力；线上化服务交付过程，数字化交付质量，持续提升业务价值创造的质量；将琐碎的事情标准化、自动化，释放人力推进更高价值的工作。
2.4 加强协作
上面的IT服务是一种加强协作的方式，chatOps、CD也是一种加强协作的方式，这些加强协作方式的关键是围绕协同网络打造的连接方式。连接，要利用好自动化、数字化手段将人（运维、研发、测试、业务……）、机器、软件、机器人组织起来，用工具去给协作赋能，让机器人去做琐碎、重复、操作性的协同的事，比如通知、召集等，让CMDB帮助你记住复杂的机器、软件的关系，让工具记录下协作过程中的需要留痕的信息。当然，这些技术角度的连接赋能，不反对增加人与人面对面沟通，主要是善用工具做一些辅助沟通协作的工作。
ok，今晚先写到这里，关于架构扩展性、自组织、不浪费、加强总结下次再补充。
end
