class="topic_img" alt=""/>
文|吴雪峰
现任 ThoughtWorks 资深架构咨询师，主要负责精益敏捷软件开发与软件架构设计。擅长 Java/Scala 技术，微服务架构、Reactive 分布式软件架构、Serverless 架构、DevOps 以及精益实践。提出“契约驱动微服务开发”、“精益微服务工程体系”、“API as Business”等观点和实践。
所谓精益思想的价值和原则非常多，我这里引用 ThoughtWorks 同事 Jonny Schneider 即将出版的《Understanding Design Thinking,Lean,and Agile》， 试图通过日常软件开发实践来补充这些看起来很虚的价值和原则，希望能推广精益成为更好的软件开发指导思想。
价值一: 学习和适应优于分析和预测
原则:
通过实践验证假设，而不是分析和计划
我们都知道邓小平说“实践是检验真理的唯一标准”，但在软件开发的时候往往都忘了这句话。 软件开发是一个需要高度协作的工作，涉及到想法提出、需求分析、设计和实现、测试和交付、价值验证，又因为每个环节被要求做到最好，结果就很容易陷入局部打转，进行低效的分析和计划中。
比如领导提出的一个想法，就马上变成正式需求进行大规模实施，然而没有经过验证的想法只是个价值假设，我们需要先把想法进行实践验证才能确定想法是有价值的。但是有更坏的一种情况，就是大家都有想法，但就是一直分析分析而没有任何行动。这种情况比一有想法就进行盲目的行动还要坏得多，盲目行动后至少能知道一条路是不通的，一直在原地打转却是实实在在的浪费精力和时机。
每个项目基本上都会抱怨需求多、需求不稳定，于是就加大对需求的分析投入。但过犹不及，开发团队有时候会没有具体的需求做，因为需求还在分析中。然而我又没见过一个需求分析能做到完全清晰不需要在开发阶段再进行分析和澄清的，所以 INVEST 原则的第二条，就是能沟通，而不是要求把需求做到尽善尽美。INVEST 原则的最后一条是可测试，来验证”Done”，而不要开发扯皮说“我就是根据你说的做完了啊，怎么这个需求又变了。”
延迟决策到最后一刻
我反对 Scrum 管理方式的一个原因是 Scrum 设置了一个所谓的时间盒，在这个时间盒里面开发工作不能被打断。首先我没见过不打破时间盒的实践，第二，时间盒的概念违反敏捷宣言中“欣然面对需求变化”的原则，时间盒只是换了个花样拒绝需求变化而已。
另外 Scrum 又要求进行工作量评估用来做计划，然而我们知道评估工作量基本上是很扯淡的事情，基本上误差在 100% 以上。而且团队的产能是固定的，不知道做计划的价值是什么。
我比较同意做粗粒度的时间里程碑规划，用来规划几个特别重要的需求，而对于日常的管理工作完全没必要做计划。
具体来说就是，延迟决策到最后一刻，开发团队什么时候做下一个需求应该由什么时候做完上一个需求决定。先做哪个需求应该等到需求马上就要进入开发状态了再做决定。而不是做个 Sprint 计划用一天时间把一两个星期的决策都做了。
刻意练习思维方式
用 Kata 训练思维方式。很多时候我们所谓的知道了，其实只是记住了一些名词和解释，并没有领悟内涵。就像有很多争论的 TDD 一样，可能很多人没有刻意练习过 TDD，并不知道 TDD 到底好不好，优缺点是什么，只是因为听说 TDD 好或 TDD 不可行，就给自己下了个结论。
软件开发中有很多是手艺的问题，需要手脑协同完成。我说应该把重构剥离出 TDD，同事杨云说重构是软件开发的习惯，无所谓剥不剥离。就是说重构已经成为杨云进行软件开发的行为习惯，看到 bad smell 就会自然感觉不爽从而进行重构一把。但是对于新手来说，这不是看完《重构》就能学到的，需要刻意的练习。Pair programming 和 code review 都是新手刻意练习重构的好时机。
价值二: 赋权的人更快乐并能取得更好的成果
原则:
定义清晰的目标，信任团队并给予自主去取得成果
我们还是讲一个好的需求应该用 User Story 的方式进行阐述，而好的 User Story 最重要的特点是要求陈述需求的价值，而不只是说想要什么，更要说想要什么背后的目的。
所以有时候我们会拒绝客户的“需求”(其实是客户提出的解决方案)，用更少的成本达到客户更大的业务价值。
去中心化决策
日常的软件开发中经常会有一些团队级别的公共事件，比如每日站会的主持、CI 纪律责任、回顾会议主持和纪要等。比如 Scrum 就要搞一个 Scrum Master 来主持每日站会。但是这些所谓的公共事件，其实除了要做什么事情，背后还有一些不大不小的决策。
如果我们不把决策权给到团队，而是握在所谓的 XX Manager 手上，就会导致决策信息和决策执行分离，变成敏捷里面鸡和猪的故事，引发团队内的不信任和冲突。决策和执行不一定要同一个人，但需要大家都在一个战壕里面能感同身受，能即时根据情况进行变化。
价值三:成果优于输出
衡量交付的价值，而不是做了多少工作
有个俗语叫“没有功劳也有苦劳”，然而问题是我们往往衡量苦劳而不衡量功劳。
这要说世界是多么的不公平，有些人辛苦付出却一无所获，有些人轻轻松松却满载而归。
马云说，轻松付出就能满载而归的人是福将，应该多用。
因为 business is business，我们不是弱势群体互助会，而是拿人钱财替人解决问题的商业组织。
虽然这个话说起来很简单，但往往因为外部的交付价值变数多并难以衡量，而内部做了多少工作比较明确。
比如经常要加班到几点几点，前天昨天又通宵了什么的，搞得自己很敬业，其实是在唱悲情戏。
如果唱悲情戏能在企业获得认可，我觉得无论对于个人还是企业都是悲哀的。即使是在华为这样的企业，非常强调奋斗，天天加班，但在衡量绩效的时候也还是拿实际产出说话，而不会因为谁加班多(但没产出)就多给钱。(当然我不反对加班， 因为有时候加班确实能交付更多的价值)
有些人代码写得不好，经常出 bug，一出 bug 还找不到原因，跟无头苍蝇似的乱找，搞得自己很辛苦，对客户来说其实价值很低，甚至是负产出。但如果以工作态度或工作量衡量，这种人反而应该得到嘉奖。所以公平其实是相对的，要看从哪个角度去看，精益思想认为应该从外部价值来看。
明确价值并经常度量
什么是价值？
可能很多人会说，但又明确不了，就更不要说经常度量了。
我觉得我们的重要价值是高响应力、高质量、可持续维护的软件，然后应该度量每个交付项目，看看是否获得了重要价值。
比如外部缺陷率是否很少并持续降低(并持续增加需求)，需求响应力是否持续提高，维护成本是否持续降低？
这些指标都可以在精益价值流中明确的度量和展现出来。
价值四：管理流动优化价值
减少批次大小
如果要我说软件开发管理中最重要的工作是什么，我觉得应该是减少批次大小。
软件管理中存在很多问题，比如需求不明确、需求易变、开发估算不准确、难测试、上线后发现没有真实价值等。
这些问题其实都可以靠减少批次大小来解决，我一般建议把 User Story 分解到1~2 人天(当然还是要用故事点的方式，不能直接用人天来估算)，这样的好处是：
微服务架构更加强化了减少批次大小的诉求和价值，达到更小的需求、更快的响应、更稳定的交付流速。
管理队列
批次大的时候，一个人好像只在处理一个事情。但实际上人脑容量有限，还是会把一件大的事情分解成多个小事情做，只是无意识的做而已。Scrum 的管理方式比较粗暴，看上去只有 Sprint backlog 一个队列，因为在迭代会议的时候把事情都分配给开发人员了。所以对于 Scrum 这样的管理框架来说看不到什么队列，这样有什么问题吗？
因为人脑的局限，事情总是会溢出在外面，实际上就造成有个隐形的队列存在，只是没人刻意去管，这就造成有些人盲目的忙，有些人井井有条的干活，纯粹看个人意识。
隐形任务队列的坏处：
所以首先应该把任务队列显性化，要用团队的能力和意识来管理队列，而不是让个人去随便搞。
然后才是队列管理技巧，比如优先级调整，任务依赖关系管理，阻塞点识别和清除。
在精益里面有个很重要的原则，叫限制在制品数量，意思是要严格限制正在进行的任务队列大小，这样就能很容易的识别阻塞点，及时处理，并且更容易控制交付流速。
交付速度
在讲 TDD 特有价值的时候我提出其中了两个：
但怎么衡量这两个指标呢，尤其是可维护性。我觉得可以归到“交付速度”一个指标上。我们不把修 bug 当做价值而是当作浪费，这样质量差的软件开发，必然导致交付资源会被修 bug 挤占，从而影响交付速度。
软件的可维护性也会体现在交付速度上，做的好的软件交付速度会越来越快。因为该做的基础工作都逐渐完善，开发人员的领域知识和开发技能也逐渐提高。
然而很不幸的，能逐渐提升交付速度的团队很少，理由往往是需求越来越复杂啊，以前都没提有这样的需求现在要大改啊什么的。而且没人正在度量交付速度，所以只是开发人员和客户都抱怨罢了。
减少浪费
以前西方流行的精益观念认为“减少浪费”是精益思想的精髓，然后有非常全面的识别和消除浪费的方法。
我觉得减少浪费是精益思想的很小一部分，就像我们想增加收入要做开源节流。不能认为节流能增加收入就当做主要手段用，导致影响开源。但很不幸的是节流比开源要容易很多，所以很多企业在危机时刻很容易选择节流而导致开源不利。
比如只从业务功能角度讲，搭 CI/CD 所花的时间是浪费掉的，因为没有直接产出业务价值。
减少浪费的观念确实非常有用，能有效指导消除不必要的工作。
响应客户需求优于创造库存
我发现开发团队很喜欢创造库存，有一些原因：
敏捷宣言用了很大的比重来强调拥抱变化响应客户需求，很好地改变了软件开发团队和客户之间的信任关系。但是并没有什么方法很好的去响应客户需求，要不然 Scrum 这种固定时间盒的方法也不会大行其道了。
精益的拉动式流管理是完全面向客户的，利用客户需求驱动团队工作。而且只有需求交付到客户手上才算是完成了，使得软件尽早产生业务价值，这也是 MVP 思想的来源。
价值五：质量是结果而不是活动
内建质量
内建质量就不多说了，是我们倡导的实践口号，只是需要配合质量度量和持续改进，不然就只是口号了。
持续学习和改进
除了交付客户所需的价值，对我们来说更重要的是团队个人能力的提升。因为软件交付给客户价值后，对我们的价值(钱)也就结束了，唯有团队个人在交付的过程中不断提升，才能提升公司的整体价值和竞争力。
在敏捷管理里面设置回顾会议以支持持续改进，而且更关注问题和解决问题。为什么要等一个月或两个星期才做一次回顾会议呢？ 固定时间、固定任务、做固定的事情好处是能有一种仪式感，容易协调不同人的时间和工作内容。但因为反馈周期太长，算不上持续，只能说是断断续续的学习和改进。
其实最好的学习和改进机会是做到 on demand，发现问题及时处理问题，如果处理不了及时提出来引起团队的注意。另外每日站会和每日 code review 都是固定的时间点，可以用来做学习和改进。
学习和改进的内容不仅仅是软件代码、架构设计、需求质量，还有协作方式、甚至座位安排、客户对接方式、价值排序原则等。
追求完美
可能对于一个商业组织来说，追求完美是最正确又是最错误的事情。因为很容易陷入闭门造车，导致投入产出比失衡，造成亏损。
但精益思想并不是一个点，而是一组。我总结的精益思想的哲学是以客户为中心，持续自我改善，追求长期利益(完美)。
每个人或组织心中应该有个对“完美”的定义，以此为愿景进行长期可持续追求，但由于是企业，所以要以客户为中心。当然基础还是富有激情的个人在每时每刻进行持续学习和改进，以达到个人的完美。
相关文章
