上海Moto工作一个月随笔

    来上海Moto工作一个多月了,有些感想随便写写,当然某些“敏感”的东西就不放在这边了,呵呵。

    首先,最大的不同,是Scrum——近些年流行起来的敏捷软件开发模型。以前在南摩,基本是按照Requirement, Design, Code, Test这个流程走下来的,很清楚,对项目进程也比较好把握。Scrum的理念不一样,它假设项目的需求是会随着时间而变化的,于是它被设计得很有弹性很自由。它的模式大概是这样:
        1) 将整个产品要实现的功能写成backlog,假设按一个Sprint(周期)21天算,把这些backlog分成在这个周期内可以完成的sprint backlog;
        2) 召开sprint planning meeting,划分,确定这个Sprint内需要完成的任务,标注任务的优先级;每个Scrum team自己选择感兴趣的story并分配给每个成员;
        3) 进入sprint开发周期,在这个周期内,召开Daily Scrum meeting,看每一天完成Story的进度;
        4) 整个sprint周期结束,召开Sprint review meeting,将成果演示给Product Owner;
        5) 团队成员最后召开Sprint retrospective meeting,总结问题和经验;
        6) 这样周而复始,按照同样的步骤进行下一次Sprint。
    因为每个Sprint周期很短,所以可以按照需求的变化及时地把这些变化做进项目里。据说这个模型在很多公司实施得很好——
    然而,我觉得在Moto,我看不到Scrum的那么多优点,反而体会到了一些缺点。
        1) 对于scrum team的成员,他只是接触一个个的story,却并不知道这个项目的总体进度,有很多要从整体考虑的东西会被忽略;
        2) backlog里的story需要有非常详细的描述和正确的优先级、effort的预估,可是描述经常不清楚,优先级/effort在真正做事情前很难估计正确;
        3) 缺乏一个CM team支持,加上没有很好的版本控制工具(这跟Scrum没啥关系…),导致需要做release的那段时间会很混乱;
        4) 对于需求的变化,往往是在做一个个story中途发生的,同样会导致这个story白做或者需要改变story要做的事情,浪费effort。
     其实不管什么软件开发模型,对于需求的变化都是非常头疼的,有的变化甚至需要带来架构上的变化,很让人无语。在MDB时感觉还好,一般都是运营商定制好了一个手机的各种需求,然后我们再开发,变化不会太大;而现在做STB,有的东西说变就变了,很无语的。。。
    不过,这些缺点里有的是可以通过老板的工作弥补的,比如说他可以把项目的总体进度share给我们,可以专门找人做CM,可以用更好的版本控制工具,虽然都需要投入,但我觉得是值得的;有些缺点可能真没办法…

    第二,我想说说SVN,这是我们现在用的版本控制工具。以前在MDB我们用Clearcase,很强大的东东,但据说很贵,每年都要charge一大笔钱。而SVN是开源、免费的。以前用SVN、CVS,都是用来在网上下开源的代码,跟昊子合作的那段时间也只是用来在trunk上check in代码的工具而已,体会不到它版本控制的功能。而在真正的大项目里用上SVN之后,我的一大感受是,便宜没好货。相比起clearcase,SVN的差距确实太大了,没有dynamic view只能checkout到working copy;建branch也必须整个项目的东西一起建;merge需要queue而且也是整个项目的code一起搞;某些属性(比如externals)很容易被忽略导致错误地在某个branch上做了本该在另一个branch上做的事… 就我已经经历过的一个多sprint来说,粗略估计花在SVN上建branch、check out、最后merge的时间,可能要占到一个story的20%时间。
    我的想法是,对于一个小项目,或者各个部分比较容易分得开的项目,用SVN还行,如果需要很多人在某一个模块里经常做改动,用SVN的效率会很低。我知道网络上的开源软件都是用SVN的,也许对SVN的了解还不深所以不清楚它的好处,但我觉得在大公司里做的大型项目,还是应该用更好的版本控制、项目管理软件吧。

    第三,关于code review和merge。其实这和前两点都有点关系,不过我还是想特别说一下。在scrum模型里,code review并不是一件很重要的事情,它关注的是及时地把feature deliver给客户。然而在实际操作中,如果缺乏code review会导致很严重的问题。说实话在MDB我对此没有特别的体会,因为在那边有很严格的流程,所有的code都需要inspection才能进main line。而在这里相对随意,code review只是在review board上提一下,然后大家看看、有comments就在上面提就行了,最后有没有改也不知道。就上一个sprint里,我就见过一同事随便改的code也提了review,我看了一下发现里面有了不少bug,过了一天却发现code又被整体改了一遍,跟一开始完全不一样了,bug也没了,我汗… 这样的review有什么效率和效果啊。
    想想还是MDB那么严格的机制比较好,提inspection的时候自己都会保证code质量已经到了一定程度了,不会随便提的,大家一起开会看code有时候是会觉得浪费时间,但长远地看这还是能保证code质量、减少将来的effort的。Merge的话因为在MDB用clearcase,可以对单个文件一个个地改最后用view看一下就可以了,而且经常会请同事帮忙看看merge得对不对,所以较少出错。而现在SVN的merge是件头疼事儿,因为一般merge都是sprint快结束时做的事情,大家一起上,所以只能乖乖排队,而这一排队,等上一两天也是正常的——也就是说要等一两天你的code才能merge到main line里去;有时候也会遇到“没品”的同事一声不吭在merge queue里插队,他是快了,可自己等的时间就更长了….
    关于review,我觉得我们可以做得更严格,即使浪费现在一点时间也是值得的;关于merge,我真是不想用SVN啊~

    关于老板也有些想法,不过比较敏感就不写了,呵呵。最后学习某人,贴张图,休息一下^_^
Scrum_track_form 理想的办公环境

Share
  • Zhongming

    clearcase贵啊 我们换perforce了

  • SJ

    进入状态了啊

  • Yin

    光荣地喊一声,我已经看不懂啦~~

  • Zhou

    可耻的飘过…

  • 妈妈的办公室如此豪华…

  • 悲哀,单个单词都快看不懂了。不过办公室确实是好好好好好好好好豪华啊。。没见过世面的飘过。。