透明
涌现的过程和工作必须对执行工作的人员和接受工作的人员都是可见的。在Scrum 中，重要的决策是基于其 3 个正式工件的感知状态。透明度较低的工件可能导致做出降低价值并增加风险的决策。
透明使检视成为可能。没有透明的检视会产生误导和浪费。
在声称做敏捷的组织中，最常见的透明就是过程的透明，比如打造一个看板，使用一个管理工具，把任务拆分开来，将任务和过程都透明化。然而即使是过程的可视化种，很多时候“透明”这个支柱并没有非常有效的工作，更不用说在整个工作过程之中了，下面举几个例子说明这些场景。
Sprint Goal。这个是经常被模糊掉的一个概念，本来它应该是清晰可见的，对于团队来说，一个Sprint应该要实现的目标应该是对全团队透明，但是很多时候往往不是。有的时候是因为没有人关心，Sprint失去了time box应有的作用，仅仅是“一堆互不相关的需求”的集合，而不是为了实现一个统一的Goal所必须的一些需求；有的时候Goal是存在的，但是SM和PO没有帮助团队将其透明可视出来，这样的后果是团队自然把注意力放到了任务而不是目标上。
Product Backlog。Sprint backlog一般对于团队来说是很透明的，但Product Backlog有的时候不是。经历过Product Backlog用excel来维护的情况，这种情况PB很容易变成PO和技术专家所私有的一个list，而不是透明给整个组织。Excel当然可以共享给团队，但是更重要的是参与，让团队成员真正看见它。曾经有过的一个实践是在每个迭代的开始都跟团队一起过一遍Product Backlog list，看一下正在做的feature，将要做的feature，正在讨论的feature分别是什么，PB透明了，team也明晰了方向，即使是调整也知道为什么。
DoD。只是异常重要的一个主题，因为它不仅影响质量，还会影响沟通。经常给团队举得例子就是娃做作业，他说的做完了指的就是写完了，而家长认为的做完了是指的写完了，检查了，改错了，不会的练习了。完全不是一个概念。团队里如果对于DoD没有透明可视，经常遇到的情况就会是在同步状态的时候说做完了，然后要上线的时候会告诉你很多但是。我代码写完了，但是还需要测试，我功能测试做完了，但是还需要压测等等很多问题。所以DoD不但要有，而且要透明，要贴到白板上，这样才能做到大家交流的时候用的语言是一样的。
价值的透明。这个往往是很多组织所忽视的一个地方，也是很多时候把解决方案当成需求的一个原因。就是我们总是谈要创造价值，交付价值，那么该如何去判断什么是有价值的？价值的大小呢？尤其是研发团队距离业务有些远的时候。这就需要在组织层面分享业务进展，业务数据，业务状态等信息，除去保密信息，尽可能的让所有的业务信息透明给团队，才能让团队更好的聚焦价值。
沟通的透明。有的时候看起来我们什么都透明了，但是依然工作的不够好，仔细观察会发现只是个形式而已，沟通的时候就不是真正的透明。比如沟通的时候，设计了看板，任务拆分，每日站会，但是同步的时候能听到这样的声音：“我在写代码，我在做测试”。这里面有什么信息量呢？什么都没有！这也是不透明的一种表现，而且危害不浅，团队成员依然是自己关心自己的任务，筒仓没有打破，SM应该及时发现此类问题并想办法予以解决。
检视
Scrum 工件和实现商定目标的进展必须经常地和勤勉地检视，以便发现潜在的不良的差异或问题。为了帮助检视，Scrum 以 5 个事件的形式提供了稳定的节奏。
检视使适应成为可能。没有适应的检视是毫无意义的。Scrum 事件旨在激发改变。
检视不能很好工作的一个最常见的问题就是检视环境不够安全，反馈不真实。因为检视的目的是发现问题，为后面的适应提供依据，一个是收集数据，一个是使用数据。如果检视的结果是不真实的，后面的的适应也就无从谈起。回顾会议开始的时候调查团队认为当前环境是否安全是尤其必要性的。尤其是新团队或者刚开始开回顾会议的团队，需要确认团队成员对于反馈的心理安全感受，当团队成熟以后可以没有类似的调查。
Retro会议没有声音或者只有抱怨，变成吐槽会。这是回顾会议的两个极端，都会导致检视失效。对于回顾会议来说，这是一个非常适合各种引导技巧发挥的会议，SM完全可以有很多的工具和手段来解决没有声音的问题。而后者则是没有声音的反方向，声音很多，都是抱怨，且往往向外。这个时候需要SM非常注意开会的节奏，比如约定提出可被改善的3条内容，其中2条应该是我们自己能控制的，引导团队意识到要从自己可控的部分开始改善。另外一个避免抱怨的实践是过往回顾会议的行动项要有结果，进展要透明给大家。
检视过程缺少角色，有人不参加。比如review meeting成了内部会议，主要的利益干系人/客户并没有参加会议。这样有了检视的形式，但是缺少了检视的效果。站会是个每天的检视过程，总有人迟到不仅是对于承诺和协作的破坏，同时也使得检视的效果减弱。
适应
如果过程的任何方面超出可接受的范围或所得的产品不可接受，就必须对当下的过程或过程处理的内容加以调整。调整工作必须尽快执行以最小化进一步的偏差。
当所涉人员没有得到授权或不能自管理（self-managing）时，则适应将变得更加困难。 在通过检视学到任何新东西时，Scrum Team 会做出相应调整。
Daily scrum没有调整。如上面所说，每日站会是很好的一个检视过程，但是将这个会议开成汇报会的大有人在，在Daily Scrum中不能及时作出调整，将丧失最好的适应机会。出现延期、技术障碍、需求变更、人员流动、质量问题、流程问题，在Daily Scrum中可以很快识别并作出相应的适应性改变。
只想改变别人和环境，不改变自己。这是检视过程不够好的一个延续，最后的行动项都是别人和组织，而不是自己。这个无效的地方很显然就是每个人能够改变的首先是自己，而且也应该是自己，至于环境，需要更多的努力和工作去影响和沟通。
只调整过程管理，不调整工程实践。发现问题的时候往往试图通过调整过程管理来解决问题，比如质量问题通过增加更多的测试环节来解决，事实上，对于软件开发来说，其根本能力还是软件开发人员的技术能力、工程实践。不断适应的除了工作方式，还有不断精进的技术栈、工具和能力。
最后，Scrum的3355都是学习非常简单，但是用起来都有很多场景失效。对于Scrum的三个支柱来说也是如此。所以在实际工作中，当事事透明，时时检视，适应调整，对于具体的行动如此，对于支柱亦如此。
网友评论