文章目录
  1. 1. 关于
    1. 1.1. 为什么要写这个系列?
  2. 2. Take-away from Day 2
    1. 2.1. Definition of Done
    2. 2.2. Product Owner
    3. 2.3. Product Backlog
      1. 2.3.1. Product Backlog Refinement
      2. 2.3.2. Initial Product Backlog
      3. 2.3.3. How many items to deliver per sprint?
      4. 2.3.4. 什么是velocity,怎么算?
    4. 2.4. Something to Note
  3. 3. Day 2 小结

关于

这篇文章是我关于Scrum Master Training系列文章的第三篇,这个系列将主要介绍scrum framework的一些key points以及为何development team用scrum会比传统方式更有效和更能促进团队进步。

为什么要写这个系列?

由于被公司派去台湾组建新的branch和新team,并要在那边用scrum的framework做开发,为了保证未来团队应用scrum的质量,公司派我们参加一个为期三天的Scrum Master Training Course。 我将把这三天所学到的knowledge,以及自己思考所得记录在这个博文系列,以期将来可以refer,若是能造福大家更是一件好事。

Take-away from Day 2

第二天的topic主要focus在Definition of Done (DoD), Product Owner and Product Backlog, obstacles

Definition of Done

还记得我们是怎么定义“Potential Shippable Product Increment”吗? 就是在sprint结束的时候,至少有一个可以交给客户和市场检验的产品或特性。 一个好的scrum team会尽量使DoD和PSPI足够相近,这样完成DoD(sprint success)的同时也意味着分分钟就可以把做出来的东西release到production。

那么怎样的DoD才算比较完整呢? 至少要包含coding stage, testing stage, UAT stage, preparation for releasing stage。 在testing stage又会包含unit test, integration test, exploration test,stressure test,performance test,etc… 在preparation for releasing,会包含script for auto deploy,script for rolling back,etc…

但是,不同的team处在不同的阶段,不管是技术还是见识都会有差异,会有一些team在刚刚adapt scrum的时候还处于比较菜的stage,这样他们的DoD就不可能那么完整,可能只有最基本的一些,比如coding,unit testing,integration test。 这样的Dod显然距离PSPI还有一定距离,我们把这段距离(也就是本该做但没有做的部分)叫做undone work。 从第一个sprint开始,每个sprint都会遗留下一些undone work,越积越多,直到PO set的release day,会有相当多的undone work,怎么办?

并没有好的办法,只有两个bad ideas:

  • delay release: 多加一个release sprint来让team只做undone work,然后在release sprint结束的时候才做真正的release。 坏处显而易见,一个sprint不一定就能做完所有的undone work,而且release day被delay也可能对business造成影响。 但即便这样,我认为这个bad idea也比第二个bad idea better

  • pass undone work to Undone Unit: team在PO set的release day把所有的undone work都handoff给一个神奇的部门(Undone Unit),然后这个部门会complete所有undone work并做release。 team在handoff之后就可以自顾自的做接下来的sprint,直到下一个release day,然后重复这个过程… 真心感觉Undone Unit叫做“擦屁股部门”更合适… 这个idea的坏处就更加明显了,明明应该是team的责任,却被转移到了另外的部门,这不仅仅会影响team的责任感,增加沟通成本,也会影响最后产品的质量。

但如果没有办法一定要解决的话,还是选择delay release并增加一个release sprint。 team会慢慢成长,DoD也会慢慢完善起来,直到有一天像Facebook那样,可以做到每天都有minor release,每周都有major release

Product Owner

PO要对product和customer负责,一方面PO要和customer沟通,了解需求(什么feature会achieve更高的ROI),然后要通过product backlog使team了解需求和release day。 再浓缩成一句话就是: PO对ROI负责。

Product Backlog

PO会define features,并把这些features加到product backlog里面。 这些feature必须是customer centric,如果不懂什么是customer centric,可以问你的customer,what do they consider as a product?

一个product只有一个PO,一个product backlog,不过team数量可以超过一个。 一个PO和一个product backlog保证了在整个开发过程中不会有任何的confusion - 只有一个人可以决定什么feature是重要的必须做的,也只有一个product backlog所有的team都refer to。

PO会根据ROI来prioritize items,比较重要的item会相应有更多的细节, team从product backlog里面按照priority从高到低take items。

Product Backlog Refinement

在Product Backlog Refinement meeting,PO会clarify upcoming items,把当初细节不清楚的items变得更清楚。 team会estimate新的item并重新estimate旧的item(包括没有做的或者在之前sprint没有搞定又回到backlog的),PO和team一起完成acceptance criteria。 关于estimation会在下面详细讲。

在这个meeting,下一个sprint要做的items也会被确定,PO和team要努力确保这些item是清晰的而且不会有某一个item特别大,大到一个sprint完不成。 根据Bas的说法,一个sprint一个team至少要做四个item,如果做不完就说明一个或多个item太大了,要注意。

Initial Product Backlog

不管team是什么时候开始adapt scrum,总会有第一个product backlog,而且通常第一个product backlog是很重要的,因为它会定义所有未来item的基准point scale。

  • 首先PO会拿出一个有一些feature的product backlog,并将它prioritize
  • 然后每个team member会拿到一副扑克,里面的牌全部是按照Fibonacci排列的数字(0,1,2,3,5,8,13,21…)。
  • team达成共识选出两个比较清晰的item,第一个item大概要花4-5天时间,第二个item大概要花2-3周,然后assign 3给第一个item,assign 8给第二个item
  • base on这两个item,evaluate其他的item需要多少effort relatively。 比如认为一个item的复杂程度比第一个高近一倍,又比第二个item低一些,那就可以assign 5给这个item,如果比第一个item还要简单很多,就可以assign 1 or 2,以此类推。

    所有人都要在同一时间展示自己assign给同一个item的value,如果value不统一,就要每个人都解释为什么自己给出这样的value,或者难或者简单,都要理由,在每个人陈述完以后重复这个过程,直到所有人达成共识,assign给这个item同样的value,然后才可以move to next item

How many items to deliver per sprint?

team不会care这个问题,PO会根据以往的经验大概得知team的velocity,可以大概推算出features什么时候可以搞定,在release day之前有多少feature可以被完成,也大概可以推算出完成的risk。根据这些,PO就可以和customer有一个交代。

什么是velocity,怎么算?

假如在一个sprint,team总共完成了下表中四个item,那么这个sprint的velocity就是40
| Items | Value |
| ——————- |———-|
| Item 1 | 10 |
| Item 2 | 5 |
| Item 3 | 15 |
| Item 4 | 10 |

Something to Note

Bas说即便很多公司adapt scrum,但是并没有完全follow rules,导致最后的improvement并不是很高,其中一个例子就是”from waterfall to water-scurm or mini-waterfall”。

比如还是上文用到的table,一个team在一个sprint take了item 1 to item 4,但是在sprint中采取了先做所有的design work,再做所有的coding work, 再做所有的testing,但是不幸的是最后的testing并没有做完,导致所有的item都没有完成,这样他们这个sprint的velocity就是0。

这样其实还是采用了waterfall的模式,只不过把waterfall放在了sprint中间,which is wrong!

正确的做法是,从priority高的开始做,先完成item 1的所有,再做item 2,3,4。 可能最后item 4没有完成,但是因为前三个都做完了,velocity还是达到了30. 不过要注意的是,在team意识到这个sprint不可能完成所有item的时候要尽快通知PO,让他了解这个事实,并和他讨论应该怎么做,或者是把item 4拆分成4.1 4.2,在这个sprint做4.1,还是直接不做item 4,去product backlog把item 5拿出来做。 最后的decision还是team自己做。

Day 2 小结

和Day 1相比,day 2的干货明显要更多一些,发生的讨论也更多更激烈。 经过day 2的学习,我们对product backlog的理解更深一层,大家在product backlog workshop的参与感和代入感也很强。 我相信这些东西是可以带到以后的工作中,给未来的我们一定指导。

文章目录
  1. 1. 关于
    1. 1.1. 为什么要写这个系列?
  2. 2. Take-away from Day 2
    1. 2.1. Definition of Done
    2. 2.2. Product Owner
    3. 2.3. Product Backlog
      1. 2.3.1. Product Backlog Refinement
      2. 2.3.2. Initial Product Backlog
      3. 2.3.3. How many items to deliver per sprint?
      4. 2.3.4. 什么是velocity,怎么算?
    4. 2.4. Something to Note
  3. 3. Day 2 小结