2020/2/8
《知行合一实现价值驱动的敏捷和精益开发》第四部分 新一代精益软件工程 笔记
“最佳软件开发的境界是什么？”“做到CMMI五级就达到这个境界了吗？”
通过4个深入浅出的例子，清楚地解释了MVP的目的，以及由简至繁的产品进化过程及方法。建议读者看一下这篇博文，其网址是http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp。
提出支持快速开发的架构要能做到以下3点。
支持子系统的复用：显而易见，高复用度意味着高速开发。高复用要求我们的架构设计必须是模块化的。
尽早冻结子系统间的接口：接口需要明确定义清楚，并划分清楚相关责任田。接口设计的冻结点确定要足够早，同时接口设计要有足够的灵活性，这样既可以有效支持同步开发，同时又能处理好不可避免的需求变更。在某种意义上，这是一个用成本换速度的办法。
尽量避免使用对进度影响大的技术：由于新技术的使用往往会导致进度的不确定性，如果进度是第一考虑，那么架构设计应优先考虑支持使用熟悉的成熟技术。
让敏捷12原则落地，我们需要方法论层面的支持，在这方面常见的敏捷方法没有给出有力的支持。
忽略了开发中的等待队列
什么是降低响应时间最经济的做法呢？常见的做法有加班、想办法提升团队能力、引入新的技术和工具等，而这些都是费力难讨好的做法。多年来我们忽略了一个最省力的方法，就是管理好软件开发过程中的等待队列。
忽略了开发过程中的变异管理
软件开发问题的一个重要根因是我们借鉴了不合适的产品开发模式，也就是制造业可预测的开发模式，在前面章节中我罗列了它带来的各种弊端。
软件开发需借鉴什么？
软件开发更应该借鉴业界成功的创新性产品开发模式。和软件开发一样，如何管理好不确定性，用最小的代价获取最大的利益，都是大家面临的共同挑战。
精益软件框架（Leffingwell,2011）。这个框架包含了以下5部分内容。
屋顶，目标：快速、持续交付有价值的需求。
支柱1：对人的关注。
支柱2：持续改进。
基础：精益管理支持。
内容：精益产品开发流。
将Reinertsen提出的重要原则和解决软件开发问题的思路连接起来，帮助读者使用这些原则解决自己的实际问题。
首先我们解决指导软件开发所有决策的依据问题，也就是如何用经济指标而不是替代指标指导软件开发活动。然后我们讨论新一代软件管理方法的数学依据：队列理论及统计分析方法及其应用。接下来我们会讨论如何关注软件开发中的两个关键指标：开发过程中的批量规模（精益中的所谓的Batch Size）及在制品（WIP）规模，这两个概念在传统开发模式中完全被忽略，在许多敏捷方法中也未被显性关注。最后我们探讨新一代精益管理方法及有效实践。
1．用延期成本指导产品决策
所有软件产品经理都应该意识到的一个基本事实是：从一开始意识到市场有需求到产品正式发布，延期成本在各个阶段都是一样的，但不同阶段的时间代价则差异巨大！
2．追求响应时间的改进高于效率的改进
我认为单纯追求工作效率是软件过程改进的一个问题，也是替代指标遮盖了真正指标的常见例子。
数学依据
等待时间和所投入资源以及资源利用率的关系如何确定呢？这恰好是非常成熟的队列理论可以帮助我们解决的问题
有哪些有效做法可以减少等待队列规模从而缩短响应时间呢？
1．平衡并设置恰当的资源规模
如果钱能解决的问题不算问题的话，那么按任务峰值设置资源就是最简单的做法。
设置共享资源池、专家池是个好办法，他们可以支持所有项目
通过培训提升人员能力，培养T型人才也都是低成本增加资源的有效做法。
2．科学管理开发团队的任务包规模
除了处理好资源设置外，管理好等待队列还要求我们管理好给团队的任务包规模，也就是源头的控制。看板的WIP上限的设置是一个简单有效的做法。
极少看到来自开发的需求变更申请。其实提出合理的需求变更可以成为开发团队拯救一个失控项目的最好手段。
当前版本暂不包括Y银行是一个明智的选择，因为我们只是将用户群从100%降到95%（假设Y银行的用户不超过5%）。这个损失换回的是项目按期、高质量完成。
如果需求规格要求系统和所有微软Windows版本兼容，而前期版本的Windows用户已经接近于0，那么开发团队应该要求将这些需求从规格中删去。
规划好产品特性、避免需求蔓延是软件精益开发管理最重要的一点。
最小有市场价值特征（MMF）集方法对解决这个问题很有帮助，通过迭代方式实现持续交付对用户有价值的产品特性，同时保证每个迭代的需求列表规模不会让团队超负荷。增加软件开发各个环节的复用率对减少开发团队的任务量也很有帮助
3．科学管理队列
有些项目管理背景的读者都知道关键路径对进度控制的重要性，队列管理也不例外。处理关键路径上的队列应遵循一个原则：尽可能将其从关键路径上移开。通过将宝贵资源投入到合适的点
4．软件开发中的3个队列例子
除了开发源头的需求队列外，软件开发过程中也有很多等待队列，这里我们举3个例子：评审、测试及缺陷修复和采购。
软件开发过程中变异量的管理
在统计学中，我们用标准差（也就是σ，即西格玛）来表示变异量，到目前为止，改进都是以追求标准差的缩小为目的的。
从过程性能模型角度来讲，我们可以更加关注响应时间的预测，本章讨论的WIP的个数、等待队列规模、任务规模等都是很好的可控因子的候选项。它们和响应时间的关系及预测对软件开发过程有显而易见的价值。
（1）统一使用共享资源池，服务差异大的上游下来的任务
（2）缩短计划周期。产品需求规划一般不要超过两年，因为随着时间前推，所有预测的难度会呈指数级增长
（3）尽可能将大创新分解成多个小创新
（4）重复有益的活动。系统性地重复一个活动比将所有活动一次完成更能减少变异量。如极限编程的持续集成每日构建远比6个月做一次的好处多很多。
（5）复用减少变异。
（6）针对性的调整可以减少变异。让上游人员掌握一些下游工作的方法，是通过针对性调整、减少变异量的例子。
（7）使用缓冲积蓄可以减少变异。这是个用钱或用时间买确定性的做法。
如何将变异可能带来的代价最小化、价值最大化呢
（1）关注软件开发过程中变异的后果。
（2）快速反馈能够让团队管理好变异的后果，将价值最大化。
（3）将变异控制在可接受的范围内。
（4）用低代价的变异替代高成本的变异。。追加成本的变异带来了进度的稳定，花钱买稳定往往是在用低代价的变异（成本）替代高成本的变异（进度）。
5）缩短迭代周期是降低缺陷的有效做法。
6）将变异过程转移到成本最低的阶段。
由于不确定性的存在，变异是软件开发的必然产出物。
两个关键关注点
软件精益开发过程中，有两个至关重要的度量项：批量开发规模及在制品（WIP）个数。通过对这两个度量项的控制，我们可以在不追加资源的情况下减少响应时间。
减少软件批量开发规模，它主要体现在减少需求颗粒度上
可以把批量规模分成批量处理和处理后结果的传递两部分。
敏捷强调面对面沟通及团队一起办公，这也是减少批量规模的一个有效做法。开发测试工具的有效使用可以大大减少批量规模。
需要注意的一点是批量规模有可能是动态，不一定要强求一致。因为规模过小，也会追加需要处理的次数，累积有可能增加管理成本，所以批量规模是小规模带来的价值和处理成本的平衡
控制好软件开发队列的WIP个数，精益实践告诉我们控制WIP的个数是一个有效的手段。
控制WIP的个数需要管理者改变心态，他们必须认识到追求100%人员使用率不见得能够减少延时，有时反而适得其反。
精益管理控制实践
减少批量规模并控制WIP能帮助我们解决许多问题，但还是不能解决所有问题，开发过程中还是不能完全消除堵塞现象。
这里我们讨论一些经过验证的有效精益管理控制实践。
在充满不确定的环境下，尽可能保持流畅的软件开发通道
在管理堵塞时，有两个有用的原则：让堵塞情况可视；为不同队列设置不同的代价。
保持产品开发通道流畅的方法
第一个方法是建立开发节奏。节奏可以定义为在开发过程中形成定期、有规律、可预见重复活动。
另一个敏捷常用的实践——每日持续集成也是一个很好的例子
CMMI中提出的里程碑点及项目定期出的状态报告、定期的决策评审和技术评审也是形成开发中节奏的例子
同步拉通不同于节奏，它是让多个活动在同一时间发生。巧妙地在过程中设计同步拉通，对消除开发中的堵塞问题会有帮助
充分、及时、有效地利用开发过程中的反馈信息
一个重要基础工作就是建立一个有效的反馈度量体系。反馈的度量项很有可能是替代指标，我们必须将其和真正经济指标的可追溯关系说清楚。这些度量项应该是可控因子，通过调整这些因子，我们可以达到有效利用反馈信息的目的。
我们需要学会正确区分固定目标和动态目标反馈处理的差异。固定目标追求的是按计划执行，而动态目标要求团队做出及时调整，这也是瀑布模式和敏捷模式的差异
另外，不要忽略及时反馈对人的心理的影响。当团队能够快速收集到自己工作的效果反馈时，他们会感觉到一切都在掌控中。同时，能很快看到他们的工作是有后果时，对团队的行为也会有正面影响。
使用模块计划（modular plan）的方式也是有效处理软件开发中不确定因素的一个好做法。