价值一: 学习和适应 优于 分析和预测

原则:

• 通过实践验证假设，而不是分析和计划
• 延迟决策到最后一刻
• 刻意练习科学思维

通过实践验证假设，而不是分析和计划

我们都知道邓小平说“实践是检验真理的唯一标准”，但在软件开发的时候往往都忘了这句话。 软件开发是一个需要高度协作的工作，涉及到想法提出、需求分析、设计和实现、测试和交付、价值验证，又因为每个环节被要求做到最好，结果就很容易陷入局部打转，进行低效的分析和计划中。

比如领导提出的一个想法，就马上变成正式需求进行大规模实施，然而没有经过验证的想法只是个价值假设，我们需要先把想法进行实践验证才能确定想法是有价值的。但是有更坏的一种情况，就是大家都有想法，但就是一直分析分析而没有任何行动。这种情况比一有想法就进行盲目的行动还要坏得多，盲目行动后至少能知道一条路是不通的，一直在原地打转却是实实在在的浪费精力和时机。

每个项目基本上都会抱怨需求多、需求不稳定，于是就加大对需求的分析投入。但过犹不及，开发团队有时候会没有具体的需求做，因为需求还在分析中。然而我又没见过一个需求分析能做到完全清晰不需要在开发阶段再进行分析和澄清的，所以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还找不到原因，跟无头苍蝇似的乱找，搞得自己很辛苦，对客户来说其实价值很低，甚至是负产出。但如果以工作态度或工作量衡量，这种人反而应该得到嘉奖。所以公平其实是相对的，要看从哪个角度去看，精益思想认为应该从外部价值来看。

明确价值并经常度量

什么是价值？

可能很多人会说，但又明确不了，就更不要说经常度量了。

我觉得我们的重要价值是高响应力、高质量、可持续维护的软件，然后应该度量每个交付项目，看看是否获得了重要价值。

比如外部缺陷率是否很少并持续降低(并持续增加需求)，需求响应力是否持续提高，维护成本是否持续降低？

这些指标都可以在精益价值流中明确的度量和展现出来。

—未完待续—

价值四:管理流动优化价值

• 减少批量大小
• 管理队列
• 交付速度
• 减少浪费
• 响应客户的需求 优于 创造库存

价值五:质量是结果而不是活动

• 内建质量
• 持续学习和改进
• 追求完美