所谓的精益思想的价值和原则非常多，这里引用ThoughtWorks同事Jonny Schneider即将出版的《Understanding Design Thinking, Lean,and Agile》， 通过日常软件开发实践来补充这些看起来很虚的价值和原则，以此推广“精益”成为更好的软件开发指导思想。这是下篇，我们来简单回顾一下上篇：
价值一：学习和适应 优于 分析和预测
- 通过实践验证假设，而不是分析和计划
- 延迟决策到最后一刻
- 刻意练习科学思维
价值二：赋权的人更快乐并容易取得更好的成果
- 定义清晰的目标，信任团队并给予自主去取得成果
- 去中心化决策
价值三：成果优于输出
- 衡量交付的价值，而不是做了多少工作
- 明确价值并经常度量
本篇将继续讲述价值四和价值五。
价值四：管理流动优化价值
- 减少批次大小
- 管理队列
- 交付速度
- 减少浪费
- 响应客户的需求 优于 创造库存
减少批次大小
如果要我说软件开发管理中最重要的工作是什么，我觉得应该是减少批次大小。
软件管理中存在很多问题，比如需求不明确、需求易变、开发估算不准确、难测试、上线后发现没有真实价值等。
这些问题其实都可以靠减少批次大小来解决，我一般建议把User Story分解到1~2人天(当然还是要用故事点的方式，不能直接用人天来估算)，这样的好处是：
- 故事小对应的需求范围也小，比较容易明确；
- 又因为需求小，变了也不可惜；
- User Story小更容易暴露开发过程中的问题，比如把计划一天的任务分派给新人做，即使超出原计划的100%工作量其实也就是多了一个人天，这样团队可以及时干预；
- 只有一两天的工作也更能消除“一天完成90%，剩下的10%需要一个星期完成”的进度报告问题。或者是一个人同时做很多事情，但都没法交付；
- 需求小也更容易测试，能更快上线给真实用户。
微服务架构更加强化了减少批次大小的诉求和价值，达到更小的需求、更快的响应、更稳定的交付流速。
管理队列
批次大的时候，一个人好像只在处理一个事情。但实际上人脑容量有限，还是会把一件大的事情分解成多个小事情做，只是无意识的做而已。Scrum的管理方式比较粗暴，看上去只有Sprint backlog一个队列，因为在迭代会议的时候把事情都分配给开发人员了。所以对于Scrum这样的管理框架来说看不到什么队列，这样有什么问题吗？
因为人脑的局限，事情总是会溢出在外面，实际上就造成有个隐形的队列存在，只是没人刻意去管，这就造成有些人盲目的忙，有些人井井有条的干活，纯粹看个人意识。
隐形任务队列的坏处：
- 任务间穿插、相互影响效率。一个人最佳的工作效率产生于同一时间聚焦做一件事情。但由于事情过大，看起来是在做一件事情，其实是还是处理多个事件，然后思路在不同的事情上面跳跃穿插，造成做事效率低下；
- 不分任务轻重缓急。其实很多看似紧急的事情，都是因为一开始不做，到需要了才开始做就没时间了，搞得压力很大。比如客户突然过来问XXX事情进行得怎么样了，想明天看一下。你心里立刻开始跑马，“你们咋不早说啊，这事还没开始做呢！” 但从客户的角度讲，这个事情在两个星期前就安排了啊，而且说了很重要。但因为队列是隐形的，大家都只是脑子过一下，或嘴上说一下就过去了，全靠个人意识去处理。
- 掩盖问题。一个人或团队手上一堆事情，然后有些出现了问题阻塞进展，但因为是隐形队列，很容易导致大家都“忽视”问题，直到所有的任务都遇到同一个阻塞点。隐形的队列越大，掩盖的问题也越大。这个问题特别严重也最常见，我们经常会听见客户说自己没有问题，因为表面上大家都在做开发没遇到问题，只是到了一个月交付的时候拖延一个星期才能交付出去而已，已经是习惯了，这也很正常啊。但是稍微聊一下就会发现需求不明确，沟通不顺畅，缺乏自动化测试，质量不稳定，手工运维经常出点“小”问题等等，这些问题其实每天都在发生，但都可以一直掩盖到最后一刻才暴露出来。
所以首先应该把任务队列显性化，要用团队的能力和意识来管理队列，而不是让个人去随便搞。
然后才是队列管理技巧，比如优先级调整，任务依赖关系管理，阻塞点识别和清除。
在精益里面有个很重要的原则，叫限制在制品数量，意思是要严格限制正在进行的任务队列大小，这样就能很容易的识别阻塞点，及时处理，并且更容易控制交付流速。
交付速度
在讲TDD特有价值的时候我提出其中了两个：
- 质量
- 可维护性
但怎么衡量这两个指标呢，尤其是可维护性。我觉得可以归到“交付速度”一个指标上。我们不把修bug当做价值而是当作浪费，这样质量差的软件开发，必然导致交付资源会被修bug挤占，从而影响交付速度。
软件的可维护性也会体现在交付速度上，做的好的软件交付速度会越来越快。因为该做的基础工作都逐渐完善，开发人员的领域知识和开发技能也逐渐提高。
然而很不幸的，能逐渐提升交付速度的团队很少，理由往往是需求越来越复杂啊，以前都没提有这样的需求现在要大改啊什么的。而且没人正在度量交付速度，所以只是开发人员和客户都抱怨罢了。
减少浪费
以前西方流行的精益观念认为“减少浪费”是精益思想的精髓，然后有非常全面的识别和消除浪费的方法。
我觉得减少浪费是精益思想的很小一部分，就像我们想增加收入要做开源节流。不能认为节流能增加收入就当做主要手段用，导致影响开源。但很不幸的是节流比开源要容易很多，所以很多企业在危机时刻很容易选择节流而导致开源不利。
比如只从业务功能角度讲，搭CI/CD所花的时间是浪费掉的，因为没有直接产出业务价值。
减少浪费的观念确实非常有用，能有效指导消除不必要的工作。
响应客户需求 优于 创造库存
我发现开发团队很喜欢创造库存，有一些原因：
- 库存带来安全感；因为开发团队总是被客户挑战，手上拿几个已完工的需求会觉得到时候有货交差会很好。
- 库存里的东西不用马上验证，自己认为总是对的；
- 库存里面堆什么可以自己决定；人总是会倾向做自己熟悉或感兴趣的事情，而总是响应客户需求的话可能会被迫出舒适区。比如很多业务系统一上来就做个用户管理模块，虽然看起来这些基础模块是必须的，但在一开始的时候对客户业务人员来说真的是必须的吗，如果只有一两个用户明显可以工作，那硬写在代码里就可以了。
- 管理者不想让开发人员闲着；尽管当前没有明确的客户需求，管理者为了不让开发人员闲着，也会要求做一些有的没的需求，号称以后用的上。
- 客户不愿意频繁接收需求；这种情况多是因为客户接低质量的需求接怕了，所以拒绝频繁接，以为让完工的软件在库存里多呆一会质量会自动提高；第二是可以一鼓作气去应对低质量的需求，集中时间处理麻烦事。
敏捷宣言用了很大的比重来强调拥抱变化响应客户需求，很好地改变了软件开发团队和客户之间的信任关系。但是并没有什么方法很好的去响应客户需求，要不然Scrum这种固定时间盒的方法也不会大行其道了。
精益的拉动式流管理是完全面向客户的，利用客户需求驱动团队工作。而且只有需求交付到客户手上才算是完成了，使得软件尽早产生业务价值，这也是MVP思想的来源。
价值五：质量是结果而不是活动
- 内建质量
- 持续学习和改进
- 追求完美
内建质量
内建质量就不多说了，是我们倡导的实践口号，只是需要配合质量度量和持续改进，不然就只是口号了。
持续学习和改进
除了交付客户所需的价值，对我们来说更重要的是团队个人能力的提升。因为软件交付给客户价值后，对我们的价值(钱)也就结束了，唯有团队个人在交付的过程中不断提升，才能提升公司的整体价值和竞争力。
在敏捷管理里面设置回顾会议以支持持续改进，而且更关注问题和解决问题。为什么要等一个月或两个星期才做一次回顾会议呢？ 固定时间、固定任务、做固定的事情好处是能有一种仪式感，容易协调不同人的时间和工作内容。但因为反馈周期太长，算不上持续，只能说是断断续续的学习和改进。
其实最好的学习和改进机会是做到on demand，发现问题及时处理问题，如果处理不了及时提出来引起团队的注意。另外每日站会和每日code review都是固定的时间点，可以用来做学习和改进。
学习和改进的内容不仅仅是软件代码、架构设计、需求质量，还有协作方式、甚至座位安排、客户对接方式、价值排序原则等。
追求完美
可能对于一个商业组织来说，追求完美是最正确又是最错误的事情。因为很容易陷入闭门造车，导致投入产出比失衡，造成亏损。
但精益思想并不是一个点，而是一组。我总结的精益思想的哲学是以客户为中心，持续自我改善，追求长期利益(完美)。
每个人或组织心中应该有个对“完美”的定义，以此为愿景进行长期可持续追求，但由于是企业，所以要以客户为中心。当然基础还是富有激情的个人在每时每刻进行持续学习和改进，以达到个人的完美。
