小小的成就

参加过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分钟。

 

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

图难于其易,为大于其细;天下难事,必作于易;天下大事,必作于细。是以圣人终不为大,故能成其大。

 

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

 

Share

One comment

请输入正确的验证码