《凤凰项目》读书笔记
2018-01-29 19:57:48 14 举报
AI智能生成
《凤凰项目》笔记
作者其他创作
大纲/内容
四种工作类型
业务项目,IT内部项目,变更,计划外工作
术语
ITI
GTD
TOC
Theory of constraints:约束理论/瓶颈理论
所有在非约束点的改进都是假象:在瓶颈之后做出任何改进都是徒劳的,因为只能干等着瓶颈把工作传送过来;而在瓶颈之前做的任何改进则只会导致瓶颈处堆积更多的库存。(P78)
TOC(Theory of constraints),我更喜欢称之为瓶颈理论:任何系统至少存在一个制约因素/瓶颈,系统最终的产出受限于系统内部最薄弱的环节。要想显著提高系统的产出,就必须找到系统最大的瓶颈解决掉。所以,持续优化过程就是: (1) 先找最大的瓶颈;(2) 最高优先级地解决掉这个瓶颈;(3) 然后再找新的瓶颈,重复上述步骤。 这个过程渗透着3个问题:应该在什么环节改善?改善应该带来什么成果?怎样推行改善? 我在百度工作的时候,大家都把自己的工作内容用便利贴粘到画板上,每项任务都需要提交申请,通过在画板上的需求栏、执行栏、完成栏之间移动便签纸呈现项目各个环节的状态,不仅让团队成员参与其中,还能清晰地展现出哪个环节最容易成为瓶颈。
人物
凤凰项目
三步工作法
约束点理论,等待时间,业务项目/IT运维项目/IT变更/计划外工作
(1) 确保工作流水线不要中断。比如,需求、开发、测试、小流量实验以及推全这些环节中有一个中断了,那就降低了整体的效率。(2) 出现问题,就要找到问题的源头,从根源上解决掉。比如,线上出BUG,根源很可能是系统code混乱到需要重构,不只是测试的问题。(3) 持续地尝试改进系统,不要把全部人力用在功能开发上,留有20%人力改进非功能性需求。
(1) 确保互相依赖协作的部门之间的工作流能够无缝衔接。如开发代码不断的在提交,但运维始终不能把代码部署上去,这就属于衔接出现了断节(2) 部门之间出现问题,一定从找出问题源头,并从源头上解决问题。(3) 养成习惯或氛围:不断的试错、实践,从实践中学习经验并成长。
# 第一工作法是关于从开发到IT运维再到客户的整个自左向右的工作流。为了使流量最大化,我们需要小的批量规模和工作间隔,绝不让缺陷流向下游工作中心,并且不断为了整体目标(相对于开发功能完成率、测试发现/修复比率或运维有效性指标等局部目标)进行优化。必要的做法包括持续构建、集成以及部署,按需创建环境,严控半成品,以及构建起能够顺利变更的安全系统和组织。# 第二工作法是关于价值流各阶段自右向左的快速持续反馈流,放大其效益以确保防止问题再次发生,或者更快地发现和修复问题。这样,我们就能在所需之处获取或嵌入知识,从源头上保证质量。必要的做法包括:在部署管道中的构建和测试失败时“停止生产线”;日复一日地持续改进日常工作;创建快速的自动化测试套装软件,以确保代码总是处于可部署的状态;在开发和IT运维之间建立共同的目标和共同解决问题的机制;建立普遍的产品遥测技术,让每个人都能知道,代码和环境是否在按照设定的运行,以及是否达到了客户的目标。# 第三工作法是关于创造公司文化,该文化可带动两种风气的形成:不断尝试,这需要承担风险并从成功和失败中吸取经验教训;理解重复和练习是熟练掌握的前提。尝试和承担风险让我们能够不懈地改进工作系统,这经常要求我们去做一些与几十年来的做法大不相同的事。一旦出了问题,不断重复的日常操练赋予我们的技能和经验,令我们可以撤回至安全区域并恢复正常运作。必要的做法包括营造一种勇于创新、敢于冒险(相对于畏惧或盲目服从命令)以及高信任度(相对于低信任度和命令控制)的文化,把至少20%的开发和IT运维周期划拨给非功能性需求,并且不断鼓励进行改进
第一工作法的关键部分,在开发部和IT运维部之间建立快速工作流,看板上的索引卡片是做成这件事最好的机制之一,因为每个人都能看到半成品。现在根据第二工作法,你必须根除计划外工作的最大源头。
第一步,如何建立快速工作流第二步,如何缩短及放大反馈回路,避免返工第三步,文化,探索
方法论
个人看板方法
类比
把it开发运维比做加工厂,一切还在开发中的未上线的版本,都是积压在车间的半成品,不创造业务价值。这个比喻有种全新的视角。
0 条评论
回复 删除
下一页