|
作者简介： DevOps亮哥：DOF，DOP，DOM证书获得者；拉钩课程《DevOps落地笔记》作者；有10年软件开发经验，4年DevOps效能平台设计与研发经验。曾就职于百度、京东等一线互联网公司，从事DevOps端到端效能平台的设计与研发工作。 背景介绍 1月26日，在北京参加了由谷安天下组织、李聃老师讲授的《凤凰项目》沙盘演练，真实地感受了DevOps三步工作法是如何让濒临倒闭的无极限零部件公司起死回生的，对DevOps的价值以及实践过程有了更深的认识。 凤凰项目 DevOps沙盘是由欧洲著名沙盘游戏研发机构GamingWorks的创始人Jan Schilt先生与《凤凰项目》 一书的作者Gene Kim 先生联手开发的同名沙盘演练课程。《凤凰项目》一书相信每个DevOps爱好者都已经了解，讲述的是一名IT经理Bill临危受命，在董事和团队的帮助下，通过实践 “DevOps三步工作法” ，挽救工期和预算都大大超期的凤凰项目，最终使一家具有悠久历史的汽车配件制造商起死回生的故事。 在凤凰项目沙盘演练里覆盖了业务和IT场景中所有的关键角色，其中CEO/CIO由教练担任，业务角色包括财务总监（CFO）,人力资源部（Human Resource）,市场部（Retail Operations）,IT运维部VP（VP of IT Operations）以及首席信息安全官（CISO），IT角色包括开发团队（Application Development）,测试团队（IT Test Team），技术支持团队（IT Support），技术运维团队（Technology Operations），技术专家（Lead Engineer）和变更管理团队（Change Management）。具体角色结构如下图所示。 等大家都认领完自己的角色，教练介绍了沙盘的游戏规则：经过四轮的迭代开发，实现无极限公司的营收以及挽回不断下跌的股价，以业务价值为目标，这也是实践DevOps的最终价值。 演练过程 在明确了目标之后，就开始了紧张而有趣的四个轮合的迭代开发。在这四个轮合里，第一轮算是准备阶段，后面每轮算是改善阶段，每完成一轮教练就带着大家分析存在的问题，以及需要改进的事项，用于在后续环节有更好的产出。下面将每轮的过程以及个人思考总结一下。 第一轮：熟悉游戏规则，了解角色定位 这一轮一开始几乎每个人都处于迷茫状态，看看自己的卡片，又瞅瞅别人的卡片，不知道要干什么，对流程规则和角色职责都不清楚。但这种状态很快被业务部门讨论需求优先级声音打破，熟悉了自己角色职责的队员都逐渐参与到了需求优先级的讨论中，一下子就打破了部门墙。最终我们团队排列优先级的策略是：先止损，先完成不做就会扣钱的任务，而不是挣钱的任务。 由于每个角色都有容量限制，所做的任务点数不能超过本身的容量，我们很快就发现了流程中的瓶颈点：Lead Engineer，然后使用培训卡片来提升其他角色的能力，使得IT Support可以承担Application Development的任务，Technology Operations可以承担Lead Engineer的任务，从而提升团队整体的吞吐量。 第一轮结束后，我们完成了2个任务，由于主要完成的是止损的任务，对营收和股价并没有带来太大的提升。 总结一下： 虽然一开始教练也有让大家相互认识的环节，但团队成员来自五湖四海且人数较多，彼此之间还不是特别熟悉，又因为大家都是第一次玩沙盘演练，对沙盘的规则和流程都不熟悉。因此团队成员之间的不了解、每个角色职责的不熟悉是影响第一轮的主要因素。有下面几点感触： 学习能力：每当我们进入一个新的环境，新的工作岗位时，最重要的就是学习能力。第一轮对大家来说都是新的，我们需要了解每个角色的职责，整个流程的规则，能否快速开展迭代任务取决于大家的学习能力。发现和解决问题的能力：我们能够在第一轮就能发现流程中的瓶颈点并将其解决掉，这个是非常不错的，这也正是DevOps持续改进的原则。当然了，有些问题也没发现，比如：没有配置管理，当一个需要突然不上线了需要回滚该如何解决？现在的流程是否顺畅，还存在哪些问题，如何改进？等等。这些都是在下一轮迭代中需要改进的地方。 第二轮：理顺工作流程，尝试加强反馈 第二轮我们决定改善上轮中的问题，我们梳理了整个价值流，计划采用看板来将其可视化，然后在物理板上画了几条代表不同角色的泳道，并且标记WIP值，但在实施的过程中，我们发现这种方式反而降低了我们的工作效率。我们需要将卡片从桌子移动到看板上，这个运输过程产生了浪费，影响了效率，最终这种方式被Fail掉了，还是在桌子上完成了整个迭代。 针对回滚需求这个能力，我们采用了版本控制方法，将一个需求的所有相关卡片都进行打标，比如，project2的需求，在整个流程中涉及到的所有卡片及配置项都分别用便签纸做了标记，如果需要回滚也知道是回滚哪个版本的需求。 第二轮结束后，我们仍然只完成了2个任务，对营收和股价的影响都不大。 总结一下： 这一轮虽然大家对整个流程的规则清晰了，但并没有提高整体的交付效率。原因有几点： 没有将任务可视化，团队各角色之间需要通过不断的沟通才能知道当前正在做哪个项目，以及做到什么程度了，在这些信息不清晰的时候，团队成员没有一个统一的目标，流程后面的角色一直处于等待状态。多任务并行，在开始的时候也是想先处理一个任务，但在处理过程中，发现无法快速满足验收条件，这个时候就会搁置当前的任务，进行下一个任务。当这种情况出现多次后，就会有大量的半成品，不仅没有创造价值也浪费了资源。 第三轮：引入看板方法，提升工作效率 第三轮我们又重新设计了看板——墙体看板，与上一轮不同的是，我们将任务卡片全部移到看板的位置，并且做了大量的准备工作，比如梳理了任务之间的瘦身依赖关系，将任务进行了分类，从而减少了查找卡片的时间。另外，人员的职责也更加清晰，有的负责查找任务需要的卡片，有的负责计算有没有超过WIP的限制，当超过WIP限制时也能快速的进行反馈，及时替换掉低优先级的任务。 第三轮结束后，我们一共完成了6个任务，与上一轮相比，整体交付效能有了很大的提升，在营收方面带来大量收入，由于完成的任务里跟凤凰项目相关的任务不多，在股价方面提升效果并不明显。 总结一下： 这一轮整体的交付效能有比较大的提升，我认为主要有几个方面的因素： 任务可视化，使得信息更透明：所有的任务以及任务的状态都能在看板上体现出来，也就是“在不需要解释的情况下,通过看板每个人都能很容易的理解”，减少了团队之间沟通的成本以及信息传递的消耗，同时使得每个人的工作目标更清晰。单件流，使得目标更集中：每次只处理一个任务，同时跟团队成员宣告一下，然后整个团队都聚焦在这一个任务上。因为每次只做一个任务，这个任务是优中选优，也是对业务目标产生最大价值的任务。业务更熟练，流程更清晰：经过前面两轮的磨合，团队成员对整体的工作流程以及自己的本职工作更加熟练，专业性有了很大提升，因此团队的稳定性和专业性的提升对整体的价值交付也是很重要的，也体现了DevOps是以“人”为核心的运动。 第四轮：瞄准业务价值，持续改善流程 经过前面几轮的迭代，团队成员对工作流程和DevOps实践方法有了更深的认识。第四轮我们持续优化工作流程，比如：优先选择对业务目标（即凤凰项目）影响最大的任务。 这一轮结束一共完成了9个任务，并且是提前完成，交付效率较之前又有很大提升。最终实现了营收￥272600和股价￥53的结果，完成了最初定的业务目标。 总结 回顾这次凤凰沙盘演练的全过程，我们从最初的茫然不知所措，到后面不断刷新交付记录，最终超额完成目标，是我们将DevOps三步工作法（流动、反馈、持续学习试验）这一指导思想与实践相结合的完美体现，并且有很强的现实指导意义。 随着DevOps不断普及，有很多企业想通过实践DevOps来提升企业的综合竞争力。由于每个企业的实际情况并不一样，实施DevOps的过程也不会相同。但他们也会有些共性的问题，比如：如何实施DevOps？该从哪里开始？虽然DevOps没有放之四海而皆准的标准，但三步工作法是可以指导每个企业根据自己的实际情况进行DevOps落地的。 我相信，只要按照DevOps三步工作法中的行动准则和最佳实践对业务流程持续改善，就一定能够缩短价值的交付流程，打造高质量的产品，最终提高企业竞争力。因为，我们做到了。 |
|
|
来自： 新用户0175WbuX > 《待分类》
