一、风险管理

1. 风险定义

未来可能发生的、产生不好结果的。区分风险和问题，已经发生或者确定未来发生的是问题。

2. 如何衡量风险

可能性 & 成本cost。

把做决定的时机推迟，推迟到最后时刻，那么作出决定所需的成本更低，且该决定的正确性得以提升，比如项目刚启动的时候，估算迭代velocity所需是很难的。也就是通过经验累积，不断降低不确定性。

风险具有不确定性，我不知道它会不会发生，发生可能导致什么结果。并非越早采取行动越好，时间越早，掌握的信息更少，评估的成本更高，评估结果的准确性也更低，就像这里评估空间更大。随着时间推移，掌握的信息更多，评估更加精准，评估的成本也更低。

经验从何而来？前车之鉴，前一个项目中经验可以应用于后续项目；或者不确定的时候可以找TP等更有经验的人；又或者通过行业风险，如owasp top 10、验尸报告等项目中经常出现的问题。

3. 为什么要关注风险

如果有10个独立风险，每个风险发生概率为10%，那么风险发生的概率是65%。如果运气是你计划的战略组成部分，你的项目注定会失败，鸵鸟效应。

TL职责：确保团队中所有人都参与到风险管理，识别相关风险，指定应对方案，采取行动，regular的回访风险。

4. 管理风险的四种策略

avoid：降低风险发生可能性。避免是绕过那块可怕的石头走过去；逃避是看到可怕的石头就回家了。no risk，no reward，高风险高回报，但避免了风险也无法获得learning。例如系统中存储信用卡号可能导致安全问题，那么avoid就是不保存信用卡号。

contain：准备plan B，风险可能性不变，成本降低。比如我知道下个月项目scope很有可能变大，于是我现在提前找RM要了两个dev。存在机会成本，这两个dev本来可以做其他事情，下个月的风险可能不会发生。

mitigate：此时此刻采取措施来降低风险的可能性与成本。比如下个月需要集成一个接口，那么我现在就让一对pair来做spike。是一种应对风险的本能反应。

evade：逃避。比如不做任何用户测试。

风险1：晚饭吃辣的东西很可能会腹泻。1）avoid：不吃辣；风险可能性将为0，成本是可能错过美味食物。2）contain：准备药和换洗衣服；风险可能性不变，成本是带更多东西。3）mitigate：吃防止腹泻的药。风险可能性降低，影响降低；成本：买药，而且药有副作用。4）evade：该吃吃，该喝喝。full impact：胃痛等。

风险2:客户新加feature可能导致上线延期。1）avoid：不要让他加新feature；风险可能性变为0，cost：无法用新feature带来的新特性；2）contain：让客户意识到这个问题，风险可能性不变，影响会降低；3）mitigate：针对新feature做spike，并找对新feature更熟悉的人来负责该模块。4）evade：什么都不做，按部就班的去做feature，然后上线可能真的会延期，导致客户不信任。

5. 风险管理工具

1）risk-storming exercise；2）六顶思考帽之黑色思考帽，带着悲观、质疑的态度看待问题；3）risk wall：风险是什么，谁提起的，最近更新时间，应对措施。

技术债墙：横轴为难度、纵轴为重要性；难点在于把技术债卡安排到迭代中，和业务卡竞争。在当前业务卡的开发中，至少不增加新的技术债，每当我离开代码时，确保代码没有变得更糟。或者如果迭代内提前完成了业务卡开发，那么剩余的时间就可以用于技术债。

二、发布之路

1. 发布之路

发布之路讲的就是最后一公里的问题，目的是让开发完成的代码尽快在生产环境运行。

价值交付全流程 发布之路

部署和发布是两件事情，比如用feature toggle的方式控制go live。

2. 发布之路的指标

代码从开发完成到上线需要多长时间？上线时间快慢是第一衡量指标，也是我们常说的反馈周期。发布之路不仅取决于技术问题，更有安全等多种考量。其他指标如发布频率，如每个月发布一次、部署的失败率、部署需要几个步骤、经常遇到的问题。

流水线的搭建会加速上线过程，但往往会遇到来自运营部门的阻力，因为运营部门受流水线的冲击是最大的。

作为TL，需要搭建一条顺畅的交付价值的路径；需要充分了解当前的发布之路；发布之路其实是客户最关心的一点。另外，作为新TL，需要获取团队和客户的信任，那么发布之路也是很好的切入点。

3. 如何搭建好的发布之路

1）who - devops：首先是mindset，敏捷交付文化价值观，打破开发与运维之间的壁垒，缩短反馈周期；其次是dev、ops的冲突，ops期望的是stablity，dev期望的是change，冲突是天然存在的；第三，把运维视角纳入到开发阶段，因为上线之后再获取到的反馈太晚了，不仅是测试前移，而且运维的mindset也要前移，从而保证在技术决策阶段就避免后续可能发生的线上事故；第四，进行技术决策时需要考虑运营角度，比如要不要加缓存，需要考虑到后续的性能等因素；第五，dev在做技术决定时无法预知该决策带来的所有影响；最后，dev需要做运维production support，从而获取到对我们开发软件的更全面的认知。

2）how much投资成本：不仅是money或者head count，license、AWS的开销。考虑客户公司的财年预算，多少预算可以用于下一年。tracer bullet，夜光弹，用于探测发布之路的路径，是否通畅、能否命中目标；在Iteration 0写下一个没有意义的代码，fake package，进行发布，来探测发布之路的顺畅行。

3）key CFR：quality attribute；多环境支持，st、uat、perf、灾备环境。

4）工具-价值流图

low hanging fruits指的是唾手可得的事情。

三、技术愿景与CFR

1. 技术愿景

1）为什么技术愿景重要？技术愿景让团队达成一致，避免一盘散沙的问题。

WHY

2）什么是技术愿景？包括业务上下文和技术上下文。

业务上下文

什么业务价值是站在客户的角度，另外还需要站在用户的角度，这里注意客户和用户是不同的。什么叫做业务上下文？用户这里涉及用户画像。

技术上下文用架构图进行可视化，架构图中会凸显用户画像、终端用户视角，作为技术与业务的桥梁。好的架构图示例可以在课程视频中寻找。

3）可视化工具

（1）ADR：记录关键决定的上下文，可以用git管理

（2）故事线、讲故事：类似suncorp的故事线，从2012到2019；

2. C4模型

架构通用语言；Context、Container、Component、Code。代码地图，作为有层次的系统架构图对技术愿景的技术上下文进行可视化，采用zoom in、zoom out的方式查看各个抽象曾经的架构图。用于团队内或者和客户沟通架构、技术问题

Context：系统全景，迅速get到whole picture；Container：重要服务，一系列微服务；Component：针对某个微服务，继续查看集中细节，包括controller、service、repository等；Code就进入到代码层面。

3. CFR

1）客户的跨功能需求：一台机器如何支持百万并发、微服务架构的分布式事务如何处理？使用C*框架、消息队列来保障高性能？rocketMQ。

2）为什么CFR重要：可用性、容错性不够好，比如知乎崩了；2c产品容易被薅羊毛。损失是真金白银和品牌、名誉。

2w的TPS大约需要150-200台机器的集群。CFR是项目成本翻倍的关键因子。

1）Performance：Dev需要注意性能调优；需要构建类生产环境让QA进行性能测试、压力测试，并给出测试报告；生产环境需要日志及监控系统。

2）Availability：具体是几个9的可用性要求呢？一年允许多久的宕机时间呢？需要考虑恢复、灾备、监控与报警；如果采用云部署，则需要多个分区，甚至需要考虑组合采用多个云平台进行部署；设计上线策略，如蓝绿部署来保障系统发布不影响用户使用。

TL需要保证：尽早识别CFR，在inception阶段识别；以技术愿景的形式，让团队都意识到CFR；CFR纳入风险管理。

四、影响力

1. 影响力定义

1）三圈理论：对事情的结果的可控程度；可控，如我今晚吃什么；影响：团队几点开站会；关注：大环境的政策。比如小A和小B是两个团队新人，小A喜欢吐槽行业、老板，这些其实不在他的影响范围内，在红圈，因此吐槽就是无意义的。

影响力的三圈理论

2）职权影响力（职位、权力、角色） vs 非职权影响力（品格、才能、知识、情感）

3）定义：主要是蓝色的一圈，用自己的身体力行影响周边的人。

4）为什么影响力重要？独木难支、集体工作、从单兵到带领团队；众人拾柴火焰高；企业层级，了解客户阻止结构，处理人与人的关系；f2f，计算机解决不了所有问题；权力也是有使用范围的，TL可以在团队内使用职权影响力，但在客户那里是无法使用的；避免不必要的冲突，关系为先。

2. 干系人分析矩阵

有时我们的成功意味着某些客户的失败。在关键会议、关键节点通过行动观察他是支持者还是反对者，比如有多少次是支持我们，多少次是反对我们的。

做完干系人分析之后，需要制定一个干系人沟通计划，并落实到calendar，形成闭环。

TL职责：每两个月做一次盘点；团队活动、达成共识。

3. 影响力风格

横轴指的是让他人在逻辑上理性信服、或者在情感上信服；纵轴指的是能量的方向，push是能量从我到他人（被影响到人），pull则更倾向于倾听，在充分理解被影响人的基础上去影响他。

识别自己和客户的风格倾向，在不同的场景采取不同策略。

项目交付模型

第一、二个迭代要提升人员的能力水平，所以速率会慢于整个项目的平均开发速率。 除此，最后一、二个迭代要准备验收事项，但是因为人员对项目的熟练度提高了，所以也会接近于平均开发速率。

五、冲突处理