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 成功秘诀和看板方法

3.看板方法---一种成功秘诀相关推荐

为什么要阅读——兼分享《首先,打破一切常规》[中译文]：世界顶级管理者的成功秘诀／(美)马库斯·白金汉,(美)柯特·科夫曼著...
<首先,打破一切常规>[中译文]:世界顶级管理者的成功秘诀/(美)马库斯·白金汉,(美)柯特·科夫曼著.鲍世修等译下载地址:http://pan.baidu.com/s/1mgkca ...
分享苹果电脑和乔布斯的十项成功秘诀
7月1日出版的第147期美国<Fast Company>杂志将刊登科技专栏作家法哈德·曼约奥(Farhad Manjoo)的文章,对苹果的成功秘诀进行全面总结. 2010年5月26日星期三 ...
看板方法：寻找切入点 | Agilean学院 | David博客系列 | 刘永鹏译，杨柳校、李淳审...
(本文由Agilean学院刘永鹏译,杨柳校.李淳审) 若公司计划大规模实施看板方法,就必然会遇到一个问题:切入点在哪?通常,公司会先在某个服务交付流程中做试点,但选择哪个服务交付流程呢?首先, ...
为什么要阅读——兼分享《首先,打破一切常规》[中译文]：世界顶级管理者的成功秘诀／(美)马库斯#183;白金汉,(美)柯特#183;科夫曼著...
<首先,打破一切常规>[中译文]:世界顶级管理者的成功秘诀/(美)马库斯·白金汉,(美)柯特·科夫曼著:鲍世修等译下载地址:http://pan.baidu.com/s/1mgkca ...
在软件开发中如何将看板方法与 Scrum 集合使用？
什么是看板和 Scrum 的混合模式?适合在哪些场景使用?有哪些成功的案例可参考?本文将围绕以上问题展开. 敏捷实践是一个团队过程,选择适合团队的敏捷框架时并没有什么技巧,无论您是使用看板方法.Scr ...
为什么要阅读——兼分享《首先,打破一切常规》[中译文]：世界顶级管理者的成功秘诀／(美)马库斯·白金汉,(美)柯特·科夫曼著
<首先,打破一切常规>[中译文]:世界顶级管理者的成功秘诀/(美)马库斯·白金汉,(美)柯特·科夫曼著:鲍世修等译下载地址:http://pan.baidu.com/s/1mgkca ...
《植物大战僵尸》的12个成功秘诀
口述 / James Gwertzman 整理 / 杨东杰 [caption id="attachment_6675" align="alignleft" ...
《淘宝店铺营销推广一册通》一2.3　热门赚钱行业网店成功秘诀
本节书摘来异步社区<淘宝店铺营销推广一册通>一书中的第2章,作者: 葛存山责编: 赵轩, 更多章节内容可以访问云栖社区"异步社区"公众号查看. 2.3 热门赚钱行业网 ...
硅谷最神奇的成功秘诀《世界上最神奇的24堂课》(查尔斯.哈奈尔, Charles F.Haanel)...
硅谷最神奇的成功秘诀<世界上最神奇的24堂课>(查尔斯.哈奈尔, Charles F.Haanel) The Master Key System: Open the Secret to H ...
《看板方法-科技企业渐进变革成功之道》书摘笔记【第8章】
第8章建立交付节奏 Ø 在敏捷软件开发圈子里形成的一个基本共识是,稳定的节奏很重要,敏捷开发方法通过使用固定时间盒的迭代来获取稳定的节奏,通常迭代长度为1-4周, Ø 为了形成稳定的心跳,必须使 ...

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

3.看板方法---一种成功秘诀相关推荐

最新文章

热门文章