3/16/2025
敏捷软件开发。
分享之前，先回顾下前2篇分享要点：
1、 敏捷的适用场景、由来、原则
2、 为什么要用敏捷？
a. 缩短价值交付周期，快速得到用户反馈，及时调整方向
b. 减少无用功：减少不必要的文档
c. 激发团队主动性
1、 如何带来价值？
2、 如何缩短价值交付周期？
3、 如何激发主动性？拒绝批评性会议，这样的话大家都不敢把问题暴露出来
回归此次分享
1.价值流图
1）为什么是价值而不是产出量？
对于知识工作者来说，写很多文档、代码不等于就创造了价值，因此要提倡价值。
2）目的
注重整体的交付价值，而不是单一角色的交付内容。
3）样式
图片来源于网络，侵删
4）名词解释
LT（Lead Time）：开始到结束的时间
PT（Process Time）：真正花的时间
%C/A（完成度与准确度百分比）：一次通过率
5）画价值流图的步骤：
1、确定开始节点和结束节点：可以是开始需求分析到上线，也可以是从代码开发完到上线。
2、写出主要步骤，步骤数量不用太细，但要比看板的流程更多。
3、评估好每一个步骤的LT、PT、%C/A，最后算出总的LT、PT、平均%C/A。
注意：每步骤的LT等于上一个步骤的结束到此步骤结束的用时。
最后，根据价值流图，找出改进点，制定具体可执行的方案，进行持续优化。
发现了问题，则需要制定改进计划，每个周期只定一个小目标，做好做扎实。而不是大目标，但不扎实。怕发现了问题，也不去解决，然后遗忘，等问题再出现时，又提出来一次，然后又慢慢遗忘。但更可怕的是，自我感觉良好，认为无需优化了。
2.敏捷的目标：缩短价值的平均交付周期
1）避免无用功
1、不要提前一年制定开发需求，因为具体执行的过程中，会有新的高优先级需求出现，会挤掉之前制定的需求，而且一年前制定的需求，可能一年后就没必要做了。为了避免无用功，提前一个季度、月度制定需求即可。那么公司的考核制度也需要变，不要以年度的需求完成度来考核。
2、需求池中的需求，无需都分析完，如果都分析完了，等后面有资源开发时，会发现有些需求根本没必要开发了。此时因自己花了精力，不舍得放弃分析好的需求，于是做了一个无用的功能，导致产品臃肿起来。只需提前分析好下个迭代的需求即可。
2）一起解决堵塞问题
1、看板中的每一个环节，同时处理任务数不能过多。而且每人最多同时处理2个任务。
举例：当测试同事手上已有两个任务，那么开发同事则不能把开发好功能送给测试同事测试，那么开发也不能开发新的需求，此时就会倒逼开发帮测试同事完成任务。
每人最多同时处理2个任务，还有一个好处，可以提高效率，因为多个任务来回切换，效率低。
2、每人轮流主持晨会，可能会让大家更团结主动，因为这样，大家才会关心他人的进行中的任务，他人是否遇到困难。
3）注重价值
1、为了衡量价值，就要对需求进行分类：用户需求（价值）、技术需求、任务、缺陷。
2、如果一个人太忙的话，就会去忽略价值。
4）缩短LT
1、环节之间，尽量并行，比如原型设计的差不多后，开发就可以开始程序设计，而不是等原型都OK后才开始程序设计。
2、充分解耦。对大公司来说，功能之间要充分解耦，这样才能拆分成小团队，小团队的功能升级就不需要等其他部门进行统一升级。这样就能想什么时候升级就什么时候升。才有可能做到一天一个发版。
3、轻量化需求沟通，缩短沟通链条。理想的情况是业务人员直接做产品。这样可以直接跟开发沟通，而不是先和开发负责人沟通，开发负责人再给具体的开发沟通。因为开发负责人最后还是要找业务拍板。而且业务尽量与it一起办公。
5）拆细需求
1、需求分级：史诗级>特性（ATM取款）>故事（余额查询）>任务（数据库设计）。
2、对于一个较大功能，即使可以在一个迭代内完成，也需要拆成多个小需求。不管这几个小需求是否是单独的可交付的用户价值。都要拆，拆细后，好开发、好测试。
3、一个大功能，可以先上线其中的几个小功能，先让一部分用户用起来；然后再上线此功能中的其他小功能，让剩余用户用起来。
以上是我的分享，希望有用！