3.看板方法---一种成功秘诀

第3章 一种成功秘诀 
	以最小的人事变动启动一场变革，来提升组织效能。
	失败教训，主要是借助职权强制推行某些过程和工作流程。

	成功秘诀在于新任管理者对现有团队可以采取的若干行动指南。遵循这些秘诀，能够快速改善团队现状，而来自团队成员的阻力会很小。包含6个步骤：
		1.专注于质量
		2.减少进行中的工作
		3.频繁交付
		4.根据交付速率来平衡需求请求量
		5.进行优先级排序
		6.消除变异性的根据，提升可预测性

3.1 使用秘诀 
	秘诀中的各项内容，是按照技术职能经理能够依次操作的顺序排列的。"专注质量"列在第一步，因为这是像开发经理或者测试经理这样的管理者，或者其上司如拥有类似"工程总监"头衔的管理者，
  所能单方面控制和施加影响的。
  	沿着列表向下，到"进行优先级排序"这一步，可控制性将逐步降低，而和其他上下游群体进行合作的要求则会逐步加强。优先级排序是业务部门的本职工作，而不是
  技术组织的工作，因此，不应该是技术经历职责范围内要考虑的事情。不幸的是，业务管理人员没能承担这一职责，而把工作优先级排序扔给技术经历来做，然后反过来指责技术经历做出糟糕的选择。
  	"消除变异性的根源，提升可预测性"之所以处在列表的末尾，是为了减少某些类型的变异性，必须进行行为改变。而要求人们改变行为是很困难的。因此，最好把消除变异性留在后面，等前面的步骤
  成功实施且组织气氛有所改变后再实施。
  	"专注于质量"是最容易的一步，因为它是只能经历能够操纵的一项技术性实践。其他步骤具有更大的挑战性，因为它们依赖于与其他团队的协议和合作。实施这些步骤，要求你具备口才，谈判，心理学，
  社会学和情商等方面的多项技能。
  	“根据交付速率来平衡需求请求量”达成共识，是至关重要的一步。而要解决团队成员之间在角色和职责方面的技能障碍问题，则需要更强的交集和谈判技能。因此，先寻找那些在你直接掌控之下，并且
  也知道解决它们对团队与业务效能影响能产生积极影响的事情，这种做法是有道理的。
  	能与其他团队建立互相信任，可以是很多难题成为可能。构建和提交缺陷很少的高质量代码，能够增加彼此的信任。通过有规律的构建活动来发布高质量的代码，也可以增加更多的信任。随着信任的增加，
  管理者便能收获更多的政治资本。这便能促使朝向秘诀的下一步前进。最终，大家都尊重你的团队成员，从而让你能够影响产品所有者，市场，业务方去改变他们的行为，大家一起协作，根据价值大小对
  开发工作进行优先级排序。
  	"消除变异性，提升可预测性"是很难的一步，在一个团队变得更为成熟和效能水平提升到某种水平之前，都不应该进入这一步。秘诀中的前4步，都能产生显著的影响。实施这些步骤，能够成为一名新任
  经历带来成功。但是，要真正形成一种具有创新和持续改进的文化气氛，就必须在过程中不断消除变异性的根源。因此，秘诀中的最后一项是加分项。也是区别普通管理者和高级管理者。

  1.专注质量
  	缺陷过多是软件开发中最大的浪费。
  	不管是敏捷开发还是传统方法，对提高质量都有可取之处。应该综合使用它们。专业的测试人员应该做好测试。让测试人员发现确信啊，防止缺陷遗留在代码中。要求开发人员编写单元测试代码，使用
  单元测试代码自动化，以提高自动化的回归测试，这样也可以产生巨大的效果。看起来，要求开发人员先编写测试代码具有心理学上的好处。测试驱动开发(TDD)似乎确实能带来测试覆盖更为完整的好处。
  	代码检查能够提高质量，无论是结对编程，同行评审，代码走查，或者完整的费根式检查，进行代码检查都是很有效的。代码检查能够帮助改善外部的代码质量和内部的代码质量。代码检查最好经常做，
  并且以小批量进行为好。我建议团队成员每天至少花30分钟进行代码检查。
  	协作式分析和设计，能够提高质量。团队成员一起分析问题和设计解决方案，产出的质量会更高。建议团队成员召开协作式的分析和设计建模会议。设计建模会议应该以小批量的方式每天进行。
  	使用设计模式能够提高质量。设计模式总结了对已知问题的已知解决方案。使用设计模式能够确保更早的获取更多信息，使设计缺陷在软件生命周期的早起得以消除。
  	使用现代化开发工具也能够提高质量。许多现代化工具都包括静态代码分析和动态代码分析的功能。对每个项目，应该把代码分析的开关打开，不断进行代码优化。这些分析工具，可以防止程序员犯低级错误，
  如安全漏洞这类众所周知的问题。

  2.减少在制品并频繁交付
  	1.在制品，前置时间和缺陷
  		累积流图是描绘处于某个给定状态的工作量的面积图。
  			库存：是指待办项或队列中那些尚未开始的需求项
  			已开始：是指已经向开发人员解释的需求
  			已设计：是指那些UML序列图已经绘制好的需求项
  			编码完成：那些已经实现序列图上的方法的需求项
  			完成：是指需求项的所有单元测试已经通过，代码也已经进行了同行评审，并且团队主开发人员也已经认同编码，并且确认可以进入测试

  		任意一天中，第二条曲线和第五条曲线的纵向高度，显示的是当时的在制品，即进行中工作的数量；而第二条曲线和第五条曲线之间的横向距离差，显示的则是一个特性从开始到结束的平均前置
  	  时间。有一点需要特别说明，横向距离为平均前置时间，并不是某个特性的具体前置时间。累积流图并不跟踪特定的特性。
  	  	可以发现，在制品数量与前置时间直接相关。当在制品数量减少，平均前置时间也随着减少。而且是线性相关。在制造业中，这种关系称之为利特尔定理。前置时间增加，则质量会下降。因此，
  	  提高质量的管理杠杠点是减少在制品数量。减少在制品数量或者缩短迭代的长度，将对初始质量产生重大影响。随着在制品数量的增加，缺陷数量会不成比例的增加。为期2周的迭代比4周的迭代好
  	  是有道理的。较短的迭代会产出更高的质量。

  	2.频繁发布能够建立起信任
  		减少在制品数量能够缩短前置时。缩短前置时间，意味着可以更为频繁的发布可用代码。频繁的发布代码，能够与外部团队建立起信任。社会学家称之为社会资本。他们发现，小而频繁的表现或
  	  活动，较之那些大但是偶尔发生的表现或者活动而言，更能增加信任的产生。
  	  	小规模的发布表明，软件开发团队具有交付能力，并且能够一直致力于产出价值，与外部团队建立起信任。

  	3.隐性知识
  		为什么以小批量的方式进行编码能够提高产品质量？在知识工作领域，随着进行中的工作数量的增加，问题的复杂性也会呈指数级增加。软件开发中，有很多知识迁移和信息发现活动，它们是隐形的，
  	  而且都是在面对面的协作过程中发生的。我们的大脑要存储这些隐性知识是不可能的。通过讨论或者利用群体的共享记忆，就可以解决记忆丢失的问题。

  3.根据交付速率来平衡需求请求量
  	根据交付速率来平衡需求请求量，意味着要根据交付可工作代码的速率，来设置新需求进入软件开发管道的速率。这样便可有效的将进行中工作项的数量规定在某个值。在有工作项交付后，便会从需求提请者
  那里拉入新的工作项。因此，对任何新工作的优先级，只可能在现有工作项被交付的情境下才发生。
  	这一变化具有深远影响。流程的交付速率会受限于某个瓶颈，想要知道这个瓶颈位于何处几乎不可能。事实上，价值流中的每个人都会声称自己已经超载。然后，一旦根据交付速率来平衡进入的需求请求量，
  在价值流中限制在制品，就会有意想不到的情况发生。只有瓶颈资源才会保持满负荷的状况。很快，处于价值流中其他环节的员工会发现，他们有了富余能力。同时，那些处在瓶颈的员工的工作会很忙，但不会
  过载。

  	产生富余时间
  		人们只有在释放组织中的大部分压力，才能够集中精力准确高质量的完成工作。那些手头上有富余时间的工作者，会开始将精力投向于环境改造。他们可能会整理工作区或者参加一些培训，可能会开始
  	  不断提升自身技能，改进使用工具，改善与上下游的沟通协作方式。随着时间的推移，一个小的改善会引发另外一个改善。人们发现，团队在持续改善，进而整个文化气氛都会得到改进。通过限制在制品以及
  	  只有当有可用产能时才拉动新工作的方法，将产生富余时间。允许有一项瓶颈资源存在。

  4.优先级排序
  	如果秘诀中的前三项都已经实施，那么整体应该运行的比较顺畅，应该能够做到频繁的发布高质量的代码。随着在制品数量被约束，开发前置时间也会缩短。这时，管理中心应该转向优先级排序，而不仅仅只是
  交付的代码数量。当交付方面尚缺乏可预测性时，很少有人会关注优先级排序问题。当需求的交付次序不可靠时，为什么要浪费精力去排定它们的输入次序呢？在解决这个问题之前，最好将管理经验重点用于改善
  交付能力和交付的可预测性上。一旦能够真正做到按需求请求的大致次序交付需求，就应该把思考转向如何对输入的需求进行优先级排序。

  	影响力：
  		优先级的排序本不由工程技术部门控制，因此，也不应该由工程技术部门管理层掌控。要改进优先级排序，需要产品负责人，业务方改变他们的行为。最好的情况下，工程技术部门管理层也只在优先级排序
  	  上具备一定的影响力。为了获得政治资本和社会资本以影响变化，应该先在彼此间建立一种相当水平的信任关系。如果不具备定期交付高质量代码的能力，就不可能建立起信任关系，因此，在优先级排序上具备
  	  影响力的可能性也会很小，也就无法进一步优化软件团队的交付价值。
  	  	目前，业务价值优化已经是一个流行的话题，而可工作代码的生产率(速度)已经不再是一个重要的度量指标。这是因为已交付的业务价值才是真正成功的衡量标准。

  	循序渐进的构建成熟度：
  		我认为，一个团队应该这样逐步迈向成熟：
  			1.要学习构建高质量的代码
  			2.减少进行中的工作数量，缩短前置时间，并频繁发布
  			3.根据交付速度来平衡需求请求量，对在制品设置限额，进而产生富余时间并释放个体的创造力，促进改善行为的发生
  			4.随着软件开发的顺畅运转和能力的优化，通过改善优先级排序来优化交付的价值。

  		期望进一步实现优化业务价值，只是一种不切实际的美好期望。遵循成功的秘诀并采取行动，才是逐步达到期望的成熟度水平。

   5.消除变异性的根源，提升可预测性
   		变异性产生的影响和如何减少过程中的变异性，这都是高阶话题。为了降低软件开发中的变异性，知识工作者需要改变他们的工作方式，学习新的技术，并改变他们的个体行为。所有这一切都比较困难，
   	  因此不适合初学者或者不成熟的组织。变异性会导致更多的在制品以及更长的前置时间。变异性要求非瓶颈资源具有更多的富余时间，以应对工作流中的波动，而富余时间又影响流经价值流汇总的工作流
   	  负载。要想了解这一点，要具备过程控制和排队论的知识。

3.2 成功秘诀和看板方法