参加过Scrum或者敏捷培训的人一定都见过著名的Project Noise图。具体解释就是对于产品开发来说有两个维度，一个是技术方面（x轴），也就是指产品实现的复杂度；另一个维度是需求方面（y轴），也就是指产品需要实现的需求的确定性和复杂度。绝大多数软件产品都是位于从Complex到Anarchy的位置。

为了完成我们的目标（也就是完成产品开发）一般用两种策略：

• 制订一个大的远期目标，然后整个团队开始细化计划、需求、技术实现等等，并相应地划分活动，这其实也是通常意义上的瀑布的做法。
• 制订一系列地目标，包括远期目标（也就是愿景）、中期目标（路线图、发布等等）、以及近期的目标（迭代以及每日）。然后根据实际情况，动态地去调整各个目标。这其实是敏捷的做法。

对于第二种策略来说，PO会从整个产品需求（也就是待解决的问题域）中去分析，确定最高优先级的那些小的问题，把这些小问题从整个问题域中简化出来，交给团队在Sprint中去实现。体现在敏捷开发中，这其实是对用户故事不断切分的过程（从Epic到Theme，再到Story）。尽管对客户来说，Story的粒度太小，意义不大，但是至少可以看出团队是在向正确的方向前进，而且可以对完成的一点点儿功能，作出反馈。这对团队来说也是一个个小的胜利、小的激励。因此从某种意义上来说，这其实是一种成功的策略。把很大的一个复杂问题切分，切成一系列可以在很短时间内完成的小的问题，明确它的结束条件（也就是SMART的目标），然后踏踏实实地去解决这些小的问题，获得小的成功(Small Wins)，最终就会获得大的成功。仔细想一下，从敏捷的五个层次的计划（愿景、路线图、发布、迭代以及每日）到工程实践里面的采用递增和迭代方式进行开发的ATDD（验收测试驱动开发）和TDD（测试驱动开发）无不是在采用这样的策略。

 

Kar Weick早在上个世纪80年代就发现Small Wins的价值，发表了著名的文章”Small Wins: Redefining the Scale of Social Problems”，在文章里面他指出：

• 一个微小的胜利降低了它的重要程度
• 降低了要求(这就是所有需要做的事情了)
• 提升了人们对于自身水平的认识

所有三个因素会使得改变变得更加简单，也更容易自我维持下去。

无独有偶，在敏捷转型的过程中，我们是否可以采取这种策略？不断地听人说，“帮我几个月内把团队带到敏捷吧”，“我们将要采取以下步骤去实现敏捷”。与做软件项目类似，敏捷转型也是一个复杂的过程，不会是一蹴而就，这期间也会有很多的反反复复。而我们要做的就是确定好我们的愿景、根据组织的现状设计好路线图和敏捷发布计划，然后集中绝大多数注意力于眼前，去解决一个个小的问题。

 

很多客户觉得自己问题很多，都是硬骨头，无从下手：自动化测试很多都不能通过，测试覆盖率太低，代码质量太差。采取Small Win的策略，其实很简单，比如我们现在有1000个自动化测试，但是其中有700个不能通过。那我们的首先要保证现有的300个一直通过，然后为每个星期设定一个目标：把10个不能通过的自动化测试调通，这样长此下去，只需要35个星期，我们的所有测试就都可以通过了，放在CI里面一直运行了。

 

提高代码质量，我们也可以采取同样的策略。不需要去审查所有的代码，根据80-20原则，80％对代码的修改都仅仅跟20％的类或者函数有关，因此我们的问题就变得小很多，我们只要去重构并添加测试。同样，也是每个星期仅仅修改几个类或者函数，不断坚持。很多类似的建议，比如每个团队每周重构55分钟，或者每天重构15分钟。

 

类似的道理，其实老子在几千年前就已经告诉我们了：

“图难于其易，为大于其细；天下难事，必作于易；天下大事，必作于细。是以圣人终不为大，故能成其大。”

 

那么，你要解决的下一个小问题是什么？它的结束条件呢？