文章目录
  1. 1. 关于
    1. 1.1. 为什么要写这个系列?
  2. 2. Take-away from Day 1
    1. 2.1. Why scrum?
    2. 2.2. How about Project Manager?
    3. 2.3. 一些有关development无关scrum的points
  3. 3. Day 1 小结

关于

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

Why scrum?

当我们采用一种模式并摒弃另外一种模式,一定是因为前者更先进,那么scrum和传统的waterfall模式比起来有哪些好处?
scrum cycle picture

  • More frequent feedback

    传统的waterfall开发模式会整个product development cycle会比较长,从project manager收集并分析需求,到developer拿到需求然后去开发,然后交给QA部门去测试,然后再release到UAT(user acceptance test)环境要用户验收,最后release到production environment。

    至少在我们公司,整个cycle最少要一个月(中间可能还有其他事情delay这个cycle),也就是说,从客户提出需求到把需求完成交给客户要大概一个月的时间,如果客户发现有任何觉得不对或者不爽的地方,发回来要改,那么又将是一个cycle,周而复始…
    而scurm way则是PO(product owner)收集分析需求,然后把所有需求加到product backlog并按照priority排列,team按照priority从上到下根据自己能力选择要在下一个sprint完成的需求,在sprint结束会保证有一个potential shippable product increment让用户验收。 而通常,一个sprint大概在两周(1-4 weeks),这就保证如果这个sprint完成的需求客户不满意,可以在下个sprint继续改进(当然前提是要再次把需求加入product backlog中并prioritize),达到fast feedback的目的。

  • Better working environment

    根据Basvodde的说法,只有在一个长期稳定且互相信任的team里,才会有一个比较好的working environment,成员之间互相激励、反省自己和他人做得好和不好的地方。

    关于这点我问了他一个问题 - “如果团队之间skill level不同,如何保证skill level比较高的人依然可以学到东西?”。 他想了一下后给了一个我认为略逗逼的答案,说他现在有四十多岁了,但是最近还是能从他四岁多的儿子身上学到东西,因为他儿子有一些问题能促进他的思考… 尽管我也认同sometimes同事间一些聊天中出现的问题会促进学习,而且如果不轻易放过话,比如深度思考或者google一下资料可能会让自己理解更深、了解更多,但我依然觉得一个做技术的人还是要尽量把自己置身于一个牛人环绕的环境,就像里面讲的,”Always be the worst in your team”,意思就是只有在身边都是牛人且都比自己牛逼的时候自己才能成长最快。 不过anyway,暂且假设Basvodde的说法也有一定道理吧。

  • Can say No to boss
    在传统模式下,经常是project manager会提出一些比较变态的需求,比如在明天之前完成this,this and this,如果自己说做不到,会被指着鼻子说“I am not asking if you can do it, you MUST do it!”。

    当然,我们程序员在被逼急的时候是会…当然不是反抗…就算熬夜加班也要把这些需求完成的,代价通常就是为了尽快完成工作而没有时间思考怎样的design是最合理的,怎样的code是可维护的。 所以即使这次勉勉强强在deadline之前赶完工,但遗留的问题也会相当多。

    这样导致的后果就是,下一次project manager再次提出impossible mission的时候,自己再说不行,就会被说上次都行,这次必须也得行! 但由于上次的赶工已经遗留太多问题,如果新的需求是build on以前的code,会把效率/开发速度降低一个档次,久而久之,project manager会发现开发的速度越来越慢,进而怀疑developer技术、态度、人品等各种问题,悲剧…

    但是如果用scrum的话,每个sprint做多少东西完全由team决定,不会被project manager逼着做,那么team会尽力在完成需求的同时apply best practices,比如TDD,比如regular refactoring,等等。 这样就保证了codebase的稳定性和易扩展性。

How about Project Manager?

如果采用scrum,那么还需不需要project manager了? 答案是不需要。 为了证明这点,Bas要我们先列举出传统模式下project manager的全部职责,然后再要我们尝试把这些职责划分到product owner,team,scrum master的下面,果然全部职责都可以分出去,which means在scrum模式下project manager可以全部被fire掉…

这里有一个误区就是scrum master常常被当做project manager,但其实scrum master的权利相比原本的project manager要小太多。 scrum master的作用只是帮助team facilitate并尽力移除外界干扰因素,还有就是帮助product owner做更明智的决定已达到better ROI

一些有关development无关scrum的points

  • Don’t forecast too much
    程序猿们经常会在开发过程中不自觉的做forecast,总以为一些function要抽象起来,这样以后再有新的需求会更容易扩展(比如hardcode vs parameterize,程序猿们常常会选择后者,因为那是“better design”),但事实是通常我们以为会增加的需求并没有增加,而我们却在这上面浪费了时间和精力。 Bas建议的是,如果一个需求只出现了一次,我们用最简单直接的方式处理,unless或until类似新需求再次出现我们才考虑refactoring。

  • Use automation test
    在课上一个哥们儿问如果team里的tester做的都是manual testing怎么apply scrum,答案是…全部换成automation test… 2014年怎么居然还有IT公司在做manual testing…汗颜,我所在的公司也是刚刚才尝试用unit test & automation test代替mantual test… 不过当断不断,反受其乱,testing方式的改变也如壮士断腕,尽管会很痛,但为了以后的方便还是有必要的

Day 1 小结

第一天的training干货并不是很多,主要是让大家大概了解一下scrum的基本模式,并通过一些discussion和workshop让大家尝试apply。 说实话这种非技术training我还是有点不习惯,总在某些时候感到昏昏欲睡。 希望接下来两天会有更多的干货和思考。

文章目录
  1. 1. 关于
    1. 1.1. 为什么要写这个系列?
  2. 2. Take-away from Day 1
    1. 2.1. Why scrum?
    2. 2.2. How about Project Manager?
    3. 2.3. 一些有关development无关scrum的points
  3. 3. Day 1 小结