文章目录
  1. 1. 关于
    1. 1.1. 为什么要写这个系列?
  2. 2. Take-away from Day 3
    1. 2.1. Toolbox of Scrum Master
    2. 2.2. Sprint Planning
    3. 2.3. Daily Scrum
    4. 2.4. Team如何track status
    5. 2.5. Product Backlog Refinement
    6. 2.6. Sprint Review
    7. 2.7. Retrospective
  3. 3. Day 3 小结

关于

这篇文章是我关于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 3

第三天的topic主要focus在Toolbox of Scrum Master, Sprint Planning, Sprint Backlog, Daily Scrum, Sprint Review, Retrospective

Toolbox of Scrum Master

Scrum Master存在的意义就是要保证整个scrum team完全按照scrum frame运转,并且时刻在improve。 那么怎样发现有哪些地方可以improve?

  • Ask how is my PO doing?

    • Is the product backlog in good shape?
    • Does he understand his benefits of Scrum?
  • Ask how is my team doing?

    • Are your team members working together?
    • Is there conflict in the team, are they resolving that?
    • Is the team making decisions?

但是Scrum Master大概是最没有权利的一个role,既不能像PO可以决定Product Backlog上面item的priority,也不能像team决定这个sprint要做什么。 那么Scrum Master有哪些tools可以用?

  • Question

    • I noticed what shall we do?
    • I obsered is that important?
    • I feel do you share that?
    • Shall we try to find out why ?
    • What do you think we should do?
    • Who has any idea about…?
    • Is this useful?
      这个问题很重要,如果team在某件没有意义的事情上花费时间精力,是会影响scrum team效率的。 一旦scrum master注意到大家在这种事情上浪费时间,就要马上提出来让大家思考。
    • What have you decided?
      很多时候,大家就一个问题翻来覆去的讨论了很久,到最后还是各执观点疲惫不堪,然后很可能这个discussion就不了了之,或者大家说“好的我们就这么做”,但散会后没有人清楚到底要怎么做。 这个时候scrum master就要站出来把这个问题提出来,让大家都clarify最后的结论是什么,如果其实是没有结论,要逼着大家有一个结论,这样散会后每个人才知道要做什么。
    • What should I do?
      当scrum master发现team需要帮助的时候,主动offer help,但help on what需要team decide。
  • Educate
    在organisation刚刚开始adapt scrum的时候,因为大家都缺乏经验,这个时候就需要scrum master educate PO和team,让大家理解为什么要用scrum,scrum的rules。

    比如对PO,scrum master要让他了解怎样根据ROI来define user centric product backlog items; 比如对team,scrum master要让team了解一些meeting rules,task-split techniques。

    当然这些都是潜移默化的,PO和team都在成长,可能过了一段时间,就不太需要scrum master再教大家什么了。

  • Faciliate
    有时当team遇到一些问题悬而未决,scrum master就要站出来facilitate。 用我们公司发生过的事做例子,因为公司最初只在一个team尝试了scrum,后来觉得这个是方向,于是希望这个team split掉然后把整个公司所有developer重组成几个team,全部adapt scrum。 但是需要原本的scrum team一些member出来到其他team中去,传播scrum的思想。 但是team经过了多次的discussion也没决定出来谁要走谁要留,这个时候我们的scrum master就站出来faciliate一个meeting,通过给大家一些问题帮助大家思考决定去留。

    但是如果一个team非常的self-managing,那么需要scrum master去facilitate的时候就不会很多。

  • Actively DO Nothing
    有时当scrum master发现team做的一些决定按他看来是不对的,一些问题是有更好的解决方法的,那么他应该站出来帮team做决定么? 答案是否定的。 首先scrum master需要让team自己成长,要尽量少或者干脆不干涉team的决定。 假如第一次scrum master凭借自己经验帮team更好的解决了一个问题,下次team还是会依赖scrum master,这样team没办法成长。 况且scrum master就一定是正确的吗,不一定…

  • Interrupt
    这是scrum master的最后一招,也是不到万不得已不能动用的一招。 只有scrum master感觉在team遇到比较大的危险,比如一个错误的decision可能导致team分崩离析,他才会站出来interrupt,把team拉回正常轨道。

Sprint Planning

Sprint planning meeting会安排在sprint最开始的时候,用来prepare sprint的meeting,分为两部分,part I关于“what”,part II关于“how”。

  • Sprint Planning Part I
    在Part I, PO和team会review product backlog中high priority items,通常这些item都已经在上一个sprint的product backlog refinement meeting被well-analyzed,所以这次只是last minute lcarification而已。 这部分meeting会让team更了解为什么这些item是重要的。 同时大家会estimate这些item有多big,如果too big,就需要split成at most 1/4 sprint length可以完成的。 在part II team会决定这个sprint要做哪些item。

  • Sprint Planning Part II
    在part II,PO可以不参加,因为这部分meeting会在技术层面讨论怎样implement item。 首先team会evaluate team在这个sprint的capacity,也就是每个team member有多少time可以contribute给这个sprint。 比如A会在周三拿leave,所以只有只有四天可以在office,刨除花在meeting、吃饭、喝咖啡、刷网页的时间,剩下可能只有20小时就是可以真正投入到工作上面的时间了。 同理,可以把所有team member的capacity算出来,sum起来就是team在这个sprint的capacity。 然后team会从product backlog按priority从上到下break down item into tasks,讨论technically怎样implement,并estimate每个task要花的时间,然后把这些task加到team的Sprint Backlog。 根据team capacity,team会决定这个sprint要take多少个item。
    sprint backlog picture
    在meeting的最后,team会set一个他们确信可以在sprint结束时deliver的比较靠谱的target,叫做”Sprint Commitment”。

通常team不会在spring planning的时候决定谁要做哪个task,而是在sprint中volunteer要做哪个task,这保证了所有team member都aware所有的task,不会导致B在take了自己要做的task之后就可以完全不care A在做什么。

一旦team决定了这个sprint要做哪些item,PO就不可以在sprint中间要team改变,所有的改变都要留到下一个sprint再说(serious production issue除外)。 Team不用担心在sprint中间会有任何interruption,可以完全focus在完成这个sprint item。 这也会force PO好好思考到底什么是最重要的item,因为一旦作出决定,再更改就要等一个sprint…

Daily Scrum

Daily Scrum是一个stand-up meeting,长度最多为15分钟,一般发生在早上,目的是让所有team member都了解各自昨天完成了什么task,今天要做什么task,以及有哪些困难发生以至于没有完成昨天的task。 在daily scrum中,不会讨论特别复杂的技术问题,如果有member提出自己遇到什么困难,在daily scrum之后可以schedule另外一个folow up meeting来解决这个问题。

Team如何track status

Team每天会update sprint backlog,以及burndown chart,通过这两个图,就可以大概知道team现在的状况。 Burndown chart不一定是一直向下的,但总的趋势应该是向下。 因为当初所有task要花费的时间都是估计,而估计总是不准确的,有可能开始的时候某个task-A估计要花费5个小时,结果做的时候发现要远比之前估计的复杂,那么可能做了一天结果remaining hour反而变成了8小时,也有可能某个task-B估计要花8小时,结果做起来发现特别简单,一小时就搞定了。
daily update of work remaining picture
burndown chart picture

Product Backlog Refinement

每个sprint都会有这个meeting,目的是split bug items, analyze items, re-estimate, re-prioritize for future sprints。 当PO想到什么新的item的时候也可以加进product backlog,或者发现有一些item可以不需要,就remove掉。 通过这个meeting,在sprint planning的时候,就已经有了一个clear, well-analyzed and carefully estimated set of items

Sprint Review

在每个sprint结束的时候会有sprint review meeting,PO、team、Scrum Master都会参加,同时参加的还可以有customer或者任何感兴趣的人。 Sprint Review是一个inspect and adpat activity for the product。 在sprint review PO可以了解到what’s going on with product and team,team可以更加了解PO的想法和market。 Demo和PO以及customer的handson是必不可少的环节。 需要注意的是,sprint review并不仅仅只是一个让PO验收的meeting,而是一个learning opportunity for all parties。

Retrospective

在Sprint Review结束后,team会有一个sprint retrospective meeting,involves inspect and adapt regarding the process and environment。 在retrospective,会画一个sprint length timeline,然后大家各自回忆在这个sprint都发生了什么事,写在纸片上然后粘在timeline对应的时间点上。

把不重要的事情filter掉,然后把每一个剩下的事情拿出来问大家的feeling,good or bad,如果大家都觉得good,那么把这件事情放在“Keep doing” 类别里,如果大家都觉得bad,把这件事情放在“Avoid doing”类别里。 在下个sprint开始的时候,大家都要keep in mind这些要继续保持的和要尽量避免的事情。

Day 3 小结

三天的training结束了,收获颇多,对scrum有了更深的理解,本来的一些问题也都得到了解答。 尽管我从来都是相信个人英雄主义,但我不否认scrum模式确实比传统的waterfall模式进步太多。 所有的developer都要对自己负责、对自己的team负责、对自己的产品负责,所有的process都应该是transparent,所有的politics都不应该存在。 如果一个organisation真正的adapt scrum,那么不管是PO还是team都会有一个更好的working environment,communication也会更顺畅。 这让我有点期待我们将在台湾组建的scrum team,我希望这个team每个人都有自己擅长的技术,而且还是多面手,每个人都有强大的自学能力,而且狂热的想要通过我们的技术去解决真正重要的问题。

文章目录
  1. 1. 关于
    1. 1.1. 为什么要写这个系列?
  2. 2. Take-away from Day 3
    1. 2.1. Toolbox of Scrum Master
    2. 2.2. Sprint Planning
    3. 2.3. Daily Scrum
    4. 2.4. Team如何track status
    5. 2.5. Product Backlog Refinement
    6. 2.6. Sprint Review
    7. 2.7. Retrospective
  3. 3. Day 3 小结