你是否遇到过这种问题呢？
老大口口声声叫着我们要敏捷，结果我们还是按照既定模式，每个产品发布，需求在半年前就已经确定好了，签字画押，用敏捷的迭代做着瀑布式开发，但嘴巴上说我们做着敏捷。
之前team开会说，我们要上两个星期的release，大家都没有反对，但做了半年，却还是一年一个release的节奏，迭代原来怎么做的，现在继续怎么做。
老板说，作为研发组织，我们要以客户为中心。但是呢，研发组织没有跟客户接触的机会，研发的任务还是按部就班做着发布，产品特性都是产品经理拍着脑袋，想出来的。
老板说，我们要按照优先级来开发特性，每个人都说好。但是看向产品待办列表，不同优先级的产品特性都在进行着。每个人都在跟你解释，为什么我们要同时开发那么多优先级的产品特性。
在你们的组织里面，有类似的问题么？我们以为我们喊出来的，我们以为我们认同的，就好像是我们已经实现了的。目标喊出来了，就好像这个目标我们实现了的。不过如果你真实点，看看现实，现实piapia的打在你的脸上。但有时候，你可能不忍心看现实，嗯嗯，所以还会理直气壮的跟别人喊，我们就是这么认为的，而且我们也是这么在做着的。
但实际上，是这样么？这可能是转型最常见的问题。从脑袋的层面，你想通了，说我们要转成那样。但实际上，你没有花任何时间和精力在转型上。你真以为有这么便宜的事情么？当你想好目标以后，转型就默默的发生了？
少年，不要太天真。有投入才有产出，要转型，来听听我们是怎么做的吧。
来说说我们实际的问题吧。我们是一个已经开发了20年的产品，有上千个客户在用我们的产品。我们一直在用敏捷的迭代开发，但是呢，我们虽然是迭代，我们每个迭代都完成不了迭代计划的内容。我们在产品发布的时候，会额外给所有的QA留一个月的时间来做产品的回归性测试。这种方式，大家好像工作的挺开心的。为啥？干了5年这样的模式，咱没出过大问题。
可是这敏捷的世界不允许我们这么慢呀，我们也要转型，转成两个星期的发布。于是，老板跟大家说了，我们要做两个星期的发布，用release train的方式，大家觉得OK，反正那是个遥远的目标，近期不可能实现的。过了三个月，老板发现转型的目标说出去了，但是并没有鸟事发生啊，于是，要干点事了。
开了几场测试的工作坊，FCW工具用起来，于是，真正的转型才开始。
什么是FCW工具呢？FCW工具由三大部分组成。如下所示：
F，Future，代表未来。在现在这个当下，在理想情况下的那个目标是什么。
C，Current，代表当下。当我们从未来的理想情况出发，我们如何看待我们当下的状况。
W，Way forward，代表下一步。为了达到我们的未来，我们的下一步会做些什么来接近这个未来。注意，这里说的是接近，因为未来可能是比较遥远的一个远景，并且是在当下的这个角度看到的远景，很有可能你一步是走不到这个远景的，所以我们说的下一步，去接近这个未来。
这个工具上面标的数字，代表使用的顺序。1代表第一步，以此类推。在我们针对测试转型探索的这个工作坊呢，我们是按照图中的顺序来去使用的，我们希望用这种方式，更多的打开大家对于未来的思路。当然，你也可以使用另外一个方式，按照C>F>W的方式来去使用，可以先依靠唤醒对现有状态的觉察开始，在开始做对未来的幻想。
FCW工具可以一次性使用，但我更推荐，大家按照迭代的方式来使用这个工具。每隔一段时间，可以用这个工具来重新看待一下自己的状态，调整下一步，来进一步接近目标。毕竟在VUCA世界，目标有可能也是一直在变的，用这种方式，保证自己一直在动态调整自己的现状和目标，从而进一步调整自己的下一步，来敏捷的追求自己的目标。
那我们是如何使用这个工具的呢？
第一步：关于未来的成功画面的头脑风暴。F：代表Future。这个Future是未来想要达到的目标。有人会问，这目标不就是Goal么？Goal可能更偏近期一点，这可能是更偏远期的目标。很多时候，在现阶段，你可能很难有个关于目标是什么的清楚定义，因为这是一个变化极快的世界嘛，VUCA大家都懂得。那么我们怎么定义这个未来呢？
我们团队的同学们有个优势，就是特别踏实，特别实事求是。这个优点带来的一个弊端是，所有想出来的未来都是一定会基于现在的所有认知得到的。可是未来会变的，在这个可变的未来上，我们要做点不敢想的东西。所以在这种情况下，我们怎么定义我们的未来呢？
在讨论的时候，为了避免我们有太多现实的限制，我们使用了成功画面的方式来做对未来的想象。当你真真切切的感受到了成功画面，你感觉你离成功也就不远了。在讨论未来的时候，我们讨论的问题是，如果我们现在已经是两个星期的release了，想象一下，在那个时候，我们的团队是什么样的？QA是什么样的？产品又是什么样的？果真，抛开了现实的羁绊，大家的思路一下就开阔了，噼里啪啦说了好多。从不同的维度看到了产品做两个星期的release，大家露出了会心的微笑。
第二步：对于现状的探索。在对于未来的探索里面，大家其实是划分了不同的类别的。所以为了让现实跟未来对应起来，我们从未来的不同类别，来去看待现在的状况是如何的。这个里面也有很多的讨论，特别容易落入陷阱的是，大家很容易就开始想解决方案了，或者说着说着的时候，就觉得不可能到达未来了。比如说，未来有一项是，我们达到了100%的automation。但实际上我们的现状是，automation可能还不到10%。于是大家针对automation怎么做到100%展开了详细的讨论，当觉得自己短期做不到100%的时候，大家就落入了现实的约束，就开始觉得达到不了未来了。所以，在对于现状的探索里面，要小心这个陷阱哦。只谈论现在的现实，不要评价，只说事实，也没必要对自己否定。毕竟，谁也没觉得这个转变会一下子就发生。
第三步：对于下一步该做什么的探索。当现实和未来写在纸上，摆在眼前的时候，大家努力看了很久。当谈到下一步该做什么的时候，大家看了看纸的两边，有同学就说了：“那个未来嘛，只是理想情况，我们现实点，可以怎样怎样。”瞧瞧，这有可能是我们达不到转型的一个很关键的点。你瞧出来没，对于没有做过的事情，尤其是看到现实和理想有很大差距的时候，很多人都会有些恐惧，觉得自己不可能达到未来。可是，很多事情，没有做过，怎么知道自己达不到呢？
就好像穷爸爸和富爸爸里面说的，当一个小学生说他要挣2000刀的目标的时候，穷爸爸永远会看过去，因为过去没有做过成功经验，所以也不敢想象未来自己没有做过的事情，所以会告诉小学生，这事不可能的；但是富爸爸不会因为过去就否定这个目标，而更多的是未来导向，在这个时候就会问小学生，如果你要挣到2000刀，你觉得谁可以帮助你呢？你会做什么呢？
瞧出这里面的差别来了么？一个人还在犹豫盘算这个目标达不达得到，另一个人已经肯定了这目标已经达到，直接去想怎么达到目标的方式了。所以针对下一步，最重要的就是要肯定，我们能达到未来的这个目标，如果在这个前提下，我们现在能做什么，来达到这个目标呢？
对于下一步的探索，我们一起问了自己这么一个问题：如果我们下个迭代就要两个礼拜的发布，我们的现状目前也不会改变，那么我们下一步做什么呢？于是，答案飞快的就出来了。大家说，我们现在也没有想象中那么多automation，但是我们一定两个星期要发布，我们可以在每个迭代的时候花点时间来做产品层面的回归测试。不光只关心我们开发的新用户故事，我们还要更关注用户故事的影响区域，除此之外，我们还要关注这个迭代里面，所有其他改动的影响区域，并且也要包含整体产品最有风险的区域来做回归测试。虽然我们现在没有那么多自动化，我们可以靠手工测试来去做这些事情，这样一样可以保证两周的发布。
这个结果让我太惊喜了。因为之前我们每次谈到产品的质量的时候，大家都会陷在自动化的覆盖率的上面，一般出来的下一步计划就是提高自动化覆盖率。虽然自动化覆盖率在一点点提高，但是对于我们两个星期release的未来，却一点都没有靠近。当我们都认同了两个星期发布的这个未来的时候，我们的下一步是真真切切的朝着未来前进了。没想到，一个观念的转变，就真正带来了行为的改变。
不知道你看了我们的经验，有没有一些启发呢？如果你想在组织里面转型，不妨尝试下这个工具。