The Phoenix Project

发表于 分类于 Changyan：

受之前任职我所在公司的合作搭档老曹的邀请，非常幸运地报名参加了其组织的《凤凰项目》的沙盘演练活动，近距离地感受 DevOps 的理念，体会精益文化。现就活动的一些感受做一些回顾，以期有更多的收益。
活动时间：2017年9月2日
活动地点：南山智园A3栋8楼
参与人员：报名12人，实到9人，外加主持人和助教共11人。
Phoenix Project

之前没有接触过DevOps，只是在一些活动和文章里偶有遇到，印像中认为DevOps就是“开发”+“运维”，即单纯的测试运维自动化。经过一轮沙盘演练下来，有了进一步的认识：DevOps是一种跨团队的团队协作文化，在保证业务连续性(Business Continuity) 的前提下，实现持续集成(Continuous Integration)、持续交付(Continuous Delivery)的要求，最终实现提升业务产量(Business Outcome)的目标。

  1. 活动进程
    这里赞扬一下老曹的场地和准备工作，智园环境优美大气，前几年每个周末乘坐地铁去西丽北大踢球的时候路过塘朗山此处刚刚开始兴建，现在已然是一个高技术产业园区了，活动现场老曹还准备了丰富的水果零食，活动之前就早早做好了各项准备工作。活动计划于9点钟准时开始，分四个阶段进行，每阶段又分计划、实施、打分、总结，每个阶段的总结部分，大家都能对上一阶段的问题进行充分的发掘，一部分会在下一阶段中得到较大改善，部分问题还是会持续存在。因部分参与人员迟到原因，活动近十点钟方才正式开始，守时应当是一个基本素养，IT项目中守时已然成为了一种奢望。
  2. 人员职责
    活动角色分为CEO、CISO、CIO、CFO、Retail Operation、Human Resources、VP of IT Operation（VP）、Application Department（AD）、IT Support（ITS）、Technology Operation（TO）、Lead Engineer（LE）、IT Test Team（ITT）、Change Management（CM），每个参与者分担一个角色，每个角色的承载量（Workload）是有限的，可以通过互相培训，将工作交由其他角色执行。
    Phoenix Project
    个人感觉这个活动成败的一个关键点就在人员职责这里，明确职责，互相配合。一上来没有搞清楚规则和职责所有人陷入了一团嘈杂的讨论和无所适从的境况，IT Operation部门的伙伴比较茫然，浪费了大半的工作量。几回合的过程中领导力和执行力都没有得到良好的体现，决策层不能做好计划决策做什么，执行层不能有效地响应和反馈，在沟通和信息传递中出现纰漏，表现为几个方面：
  3. 1 业务决策对任务的优先级不能及时调整，对凤凰项目的保证不够
  4. 2 购买训练卡后多次提示培训，承载最受限的ITS、TO、LE三部门均没有积极响应扩容培训，也没有应用其他培训业务，表现为执行不够，合作欠缺，整个过程最大的瓶颈点就在LE，没有尽早地实现知识共享和培训，扩充资源池
  5. 3 信息传递失效，一项业务需要其他部门继续执行的时候其他部门不能正确获得消息并执行，同时当决策层撤销某个任务时，后续部门并没有跟进撤销，导致前序工作撤销后续没有撤销，浪费并不充足的承载。在各部门不能正确有效履行自己职责的时候，需要强有力的领导者和负责验收的把关人，ITT部门是可以对所有操作流程进行确认的，没有及时给予反馈
  6. 工具与效率
    流程和工具在实际的操作中对效率是极大的保障和提高，在此次活动中切实深有体会。One Piece Flow保证了业务能有效的执行，产品能有效交付，不是全是半成品。工作中，提前考虑“瓶颈”问题，减少制约，通过培训、工作流程的标准化等方式，减轻瓶颈的压力可以提升团队的整体工作能力。看板的应用，将任务、流程和进度可视化，可以直观衡量和确认每个项目在每个部门需要的人天及项目进度。便于决策去权衡该做哪些项目，该放弃哪些项目，做出取舍，以及ITT检查项目进度。针对此次活动还有很多各种各样的小技巧，在辅助梳理逻辑和相关联任务中有极大帮助。
    Phoenix Project

《凤凰项目》沙盘演练需要所有人员的主动参与，积极响应，强调团队配合。需要在不同阶段权衡工作之间的关系，保证整个公司层面长期的权益。非常感谢老曹组织的这场活动，以及在活动中作为主持人对项目的介绍解说和帮助大家总结，以及感谢王大胡子助教的指导和DevOps实战分享。