敏捷开发-IC极客摘要

#Alice的敏捷分享–0323-验证#

我近一两年非常多次在社群里面启发大家思考一个问题，验证的目标是什么，相对能达成共识的有以下几点：

• 验证的目标是保证质量，不是debug
• 芯片可以带bug交付 （乙方会表达成，这不是bug，这是feature,或者你的姿势不对）
• bug分等级，category A/B/C，有严重到影响产品销售的bug，也有没任何影响的bug
• bug可以通过软件规避

验证team的loading实在是太重了，不996是不可能的。无论哪个部门改动都会影响到我们的loading和验证计划，需求改我们改，架构改我们改，设计改我们改，后端，DFT改了反馈给前端，我们接着改，每日三省吾身，这个bug是spec的错，设计的错还是验证自身的错。

不堪重负的验证团队于是开始自救，主流方法不外乎以下几种：

1. 把验证工作在全流程shift left
2. 自动化，并行，解耦，分层
3. 按特性跟设计结对，交付之前先过sanity check
4. 跟其他部门划清楚河汉界，定交付规则，谁的活儿谁干，谁的锅谁背

已经有点敏捷和CI的意思了，但，还不够，没有从根因上解决导致问题的元问题，罪魁祸首是谁，肯定不是design, 他们不无辜么？架构师，你忍心责怪他们？客户？你敢让客户背锅？客户也有他的客户啊。

在传统瀑布流模式下系统成员的关系：客户是甲方，芯片的需求方，业务，产品，研发（按流程切分4-8个部门），运营共同构成乙方，以芯片交付的方式满足甲方价值需求。其特点为 1，推，上游推下游，每个层级沟通都会有信息损耗，损耗导致误差，误差导致迭代 2. 下游是被动接任务，活儿是上游给的。特别是验证，谁改都是给他又来活儿了。这个系统模型从根因上决定了验证的loading，任务的总量降不下来，上述1234的方案一定程度上缓解，但没有解决根因问题。敏捷试图解决的是根因问题。

敏捷的底层逻辑从系统成员的关系视角来看：

1. 客户是甲方（需求方），研发是解决方案，解决方案要靠近问题，跟问题共生，跟需求直接发生化学反应，需求变，方案紧跟着变，按需求点拆成价值点，把价值点转化为特性和指标定义，这，叫业务驱动研发。
2. 在研发内部，架构师是解决方案，解决方案的本质是一堆模型的组合（参考之前模型化架构师的交付物讨论），其他人帮他把模型实现成real的可交付价值的芯片，在组织内部，RTL, PR, DFT都是架构的乙方，帮他做实现。验证唯二的两个价值主张就是以最小的投入最大化保证过程质量，是中立的第三方，需要跟架构放在同一个layer。都有义务引导组织内部乙方loading不要太重，如果乙方过程飞掉，甲方自身利益受损。
3. 上述所有的甲方乙方之间遵循两个原则，1. 乙方以成就甲方目标为己任（这个观念已经比较深入人心了）2. 每个人以谈判的形式争取自己利益最大化（scrum的3355）利他是天性，利己是人性，只有在这两种力的张力下充分沟通过了达成的一致性才是真正的一致性，才是组织利益的最大化。
4. PO管人管钱管事，是真正的product owner，他可以决定，这波研发不行，我们换一拨，这个研发是key player，给他加薪，这个feature优先级不高，砍掉，因为钱是他的，ROI是他最重要的决策指标。其他人，不代表他的利益，没有立场排序真正重要的事，但每个人的主张和利益诉求要给到他，他不掌握足够信息无法形成有效激励，但决策权在他。

总结一句话，按照敏捷的系统论过程模型，从根因上解决了瀑布流导致的信息损耗的问题，解决了由于利益和权力不对等而导致的动力缺失和内耗问题，解决了由于信息不对等，不及时导致的出错和方案与价值需求不匹配问题。是一种以人为本，尊重人性，道法自然的工程实践方法论。聚焦客户的价值交付，以拉动的方式，持续改善工程生产力。

#Alice的敏捷分享–SAFe 和LeSS有什么区别#

敏捷体系当中发展出很多流派，其中影响最大的是SAFe和LeSS，他们俩的关系有点像C和S的关系，是经过一轮竞争唯二独大的两个友商（社区），这种道法术器一体化的敏捷转型不像EDA工具，直接基于同一个case跑，优劣立竿见影。企业文化研发体系转型，往往耗时几年，拼的是思想，方法和长久实践，两派各有一堆成功和失败的案例，用来互相打口水战，常年在社区互相攻击。

核心区别大约有以下几点：

1. SAFe在超大规模组织中较流行，LeSS是classic的敏捷（轻量级方法论），认为SAFe的臃肿固定的框架已经背离了敏捷的初衷，你如果对着SAFe framework框架图，初学者不看上十分钟几乎完全看不懂，LeSS framework就是非常清清爽爽的泳道，冲刺，一目了然。

2. 都注重沟通和敏捷团队，都需要CICD DevOps支持，在两个体系框架下用的术语和概念不同，稍微有点对应，但不同。价值流图，敏捷交付火车，看板方法是SAFe的术语，实例化文档，影响地图，用户故事地图，冲刺，scrum是LeSS的术语

3. 在经典的项目管理工具Jira当中，两种方法都支持，Kanban vs. scrum sprint，但不能混用

4. Kanban vs. scrum核心区别有两个，一是任务切分的边界不同，一个是按交付物为边界切，一个是按activity切；看板是连续的流动，sprint多了个time box，1-2w，一个冲刺内，需求不允许变更，经典模式是冲-回顾-拉

5. 发布计划不同，Kanban没有冲刺，一般做三个月的长期规划，LeSS注重快，小，并行的sprint-long iterations

6. SAFe注重resource 优化，注重人与人的关系，LeSS注重产出物优化，注重人与技术的关系

7. 都注重客户导向，SAFe的客户沟通还是由business owner，PM驱动，LeSS直接砍掉了这一层，直接是业务驱动研发，把所有人拉到一线去直接面向客户

8. SAFe适应超大规模相对稳定的组织，LeSS在创业团队中更受欢迎

#Alice的敏捷分享–三分钟快速了解敏捷体系#

本篇试图回答三个问题，以下言论纯属个人理解，仅供参考，欢迎拍砖

1. 敏捷体系的overview
2. 立论基石
3. 核心实践

敏捷虽作为一种轻量级方法论诞生，但随着在科技公司，软件公司及企业的数字化转型中广泛普及，作为企业的工程生产力构建指南，仍然保罗万象，海纳百川。它最早始于重构，统一语言，简单设计，TDD，极限编程，实例化文档等用于开发环节的理念，后来吸收了CICD DevOps，项目管理层面融入了精益的思想，如前置时间，看板方法，产品需求及沟通管理层面引入了影响地图，用户故事地图，增量开发等理念，开发管理上引入了scrum，团队建设上直奔学习型组织，管理3.0那一套东西，注重沟通和赋能而非控制，沟通中注重启发式，教练式，倾听式，提问式，杜绝KPI，严禁指责。放到SOC语境里面则必须要把CICD DevOps和EDA流程进行深度融合。测试是整个体系改革的重点，也是唯一能无缝映射到SOC验证领域的最佳实践。

立论基石：1. 知识消费（参考下午发的内容）2. 聚焦价值交付的一致性沟通 3. 实例化文档/TDD/ATDD/BDD 如果我说在一个系统论的框架下，这三点都是一回事，大家能理解么？你尝试跳出传统瀑布流，稍微升维一下，从业务视角向下看研发。

核心实践：1. 度量体系 2. 可视化一切 3. 流动及反馈