来上海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啊~
关于老板也有些想法，不过比较敏感就不写了，呵呵。最后学习某人，贴张图，休息一下^_^
