#SCRUM# at ?? Company

2月14是今年的重要日子,不是因为白色玫瑰和黑巧克力,只是从一个坑到了另一个坑。对新公司流程的疑惑,有天晚上加班时Eric给我讲道,好与不好都是相对的,只是你经历过了更好才无法接受现在。恩,我说是,但这不是关键,关键是我每做一步背后都有很强的一阵风顶着,阴沉的放出一句话:上面的人知道了,你会死的很惨。

这就是在新公司里所接受的流程之”美”,但事情也在变化,当队伍短时间扩张几倍时,开始寻求管理之道,SCRUM出现了,这就是这期的话题。

从MSN项目组到现在公司的人很多,无论是PM,DEV, Tester,又因MSN一直是用SCRUM的,所以第一次的Agile的聊天,也就在我们几名老同事间开始。

事后证明我当时的判断很正确,随着对代码的了解,对工作流程的深入,几乎陷入崩溃的边缘,在后面的几个月内,都被拉去救火,还是来自前端的火,用SQL在面试时为难后端,然后让其做Js, CSS开发,这种事情我想不出哪家正规公司能做得出。

####怪异的自动化测试

4月的一次总结会议上,Manager就QA的繁琐性劳动开了一次会议,大家各执已见,我高调的说:自动化测试是王道。然后被所有人认为,这是一个高投入且暂不可行的方案。

短短一个月内,所有的Team都在研究自动化方案,看到Weibo上QA们的签名中忽然都带了selenium的字样,备感诧异。不明白这种转变从何而来。怪异之处在于大家都在做,就这么无声息的开始了,做动UI自动化的人都知道,这玩意的ROI就没有为正过,高投入不一定能得到相对的产出,自动化测试的理念和方向,工具和实践?这样都没有人提过。

####SCRUM Training

5.27,代替@yongweichen 参加了公司的SCRUM培训,当时我们组的成员已经开始实践一些敏捷实践,好奇公司会如何实施新的管理方式。

两天的培训下来,只觉得讲师完整的把书中的理论给口述了一次,唯一不同的是我看的是中译本教材,他是用英文读出来的。当天我发博只说一句话,he is just talking the SCRUM !!! pure and unpractical. 对,这就是我所有的收获。不讲软件开发,只讲SCRUM的定义。

管理的方法论可以讲上几年,但SCRUM不是这般的管理论,也脱离不开那些传统的管理方法,人是感性的,不是说上了Scrum,就像上了发条一样,没命的向前冲,每天都捡最难的活干,8小时的工作都估的满满的,只为将最好的产品及时的发布出去。坑爹啊。

自那以后,好多人觉得我是在反对SCRUM,其实我只是在抵制那种教条似的主义。

####软件开发那些事

曾想过给部门做一次关于Testing的Training,切入点都想好了,就是软件开发特性之#变#。需求的改变是软件的最大特性,上个五年中,我们还都在看#建筑的永恒之道,但二则本质的差异使得短短数年后再无人以此类比。软件是可以变化的,而不可变的东西是注定死亡,于是从传统的抵制到拥抱变化,体现在项目开发方式就是瀑布模型到敏捷。正是因为变化,语言向面向对象进化,又衍生出设计模式,开发方式从一气呵成到不断迭代,最终走到现在的敏捷。实践方式也提出了TDD, Automation Test,BDD。无非都是为了保障快速的周期和拥抱变化。

早期的软件很简单,由于计算机的性能决定软件复杂度,单人就可以完成很牛的工程,WPS,超级解霸是那个时代的转折点,自此之后再无求伯君。软件开发的要素从Product,Process增加了People,也就是说多了最难的东西,因为人是不确定性的,沟通成本的提高会大大提高Process的成本。但软件开法无非就是围绕这三者来进行的。

SCRUM也只是一个框架来定义角色,让Process更有生命力,保障更好的Product产出。但总的来说还只是一管理规则,并不是软件开发的本质。

####软件架构

软件有其特性,正如建筑要打造钢筋混凝土结构一样,软件需要优秀架构,为了更少的劳动得到更多的产出,我们使用框架和类库,这就是软件,我们要评估,要学习,不断改进。做更多的分离和低耦合的组件来保证不同团队开发的无影响性,要有沙箱机制来保护每个组件的安全,要有好的模式使得组件可被无痛替换从而达到最达的可变性,好的测试环境来保证更快速的迭代中的质量,更多方面的自动化测试和部署来提高效率和节约人力,降低沟通成本。「关于架构的更多内容,稍后补上」

总之,好的软件不能没有架构。

而敏捷和快速迭代和架构的冲突也向来是老生常谈的话题,敏捷和架构的冲突 InfoQ的这篇文章就指明了一种方向。

但关于软件架构对组织架构的影响却没有太多的资料来表明,第一次是在Microsoft VSTS Team的一次Training上所闻:产品按功能分成若干级别,每级各自负责自己的产品,上级会负责下级代码的集成测试,决定是否使用期产品进行发布,但组别间没有更多的权力区别,只是会让更好级别的工程师来负责更核心的Feature。拿Windows来举例,就是,Windows被分为很多的小组件,像OS底层,IIS, Media Player, IE,(也就是对应安装时的那几个Role),而每个小产品又可以做成模块化分为更多的小Feature,像IIS中的Log,Log可能由某个小组开发(事实上我曾在那个组呆过),我们保证该Feature所有的接口实现,由IIS Core Team负责将我们的最新版本(DLL)集成到IIS本身进行集成测试,直到通过所有测试。IIS Team将自己的Feautre交由Windows Core Team来做集成。也就是说接口是由上一级Feature来制定,下一级Team负责实现功能。该项目负责人特意提到过TFS来做管理的理念,大抵也就是刚所说的。

此处的项目组都是临时所编,只是为了文章所明所需,实际上的组别也没这么简单。

####我们产品的架构

我们是在做线上教育,整个产品是以数据库为核心的,这也正是为什么作为后端为什么会被问到大量的数据库并发的问题,因为有专门的DBA,所以写复杂SQL的机会并不太多,这一点倒让人欢喜。

而整个产品的设计呢,说难听点就是把一个开源的小网站放大若干倍,记得,要下三层架构的哦。因为有着无数的牛人在亲苦的工作着,细节之处还是很美,新来的架构师也有着同样的感叹,每段小功能代码都像玉一般的精雕细琢,但放在一起就是拼不出一座长城。因为没有优秀的架构,所有的代码都耦合在一起,不同的Team同时去修改同一个项目,修改量之大,让人发指。因为没有分离所造成产品问题的发现特别难,但Team间的关系也也不致于相互力争,同事关系是我们的最大的法宝。

事实上,不仅没有好的架构,公司还有一项让人不解的行为,同样的产品做出了两套,这就是政治的产物,为什么不去共同做一个好的架构,让人们在其上做自己的面向客户的优秀产品,而是在重复的造轮子。

####流程

如果我早一点认识yongwei的话,我想我不会来这边的,当然,这只是假设。yongwei见到我的第一句话是,以后有事自己解决,别总是问我,烦。当时很是震惊,后来熟识之后便开始理解这种烦心事。

Web产品的Js和CSS要做对应的合并,很正常的一个流程,一般公司做在服务器端用脚本来做,但我们不是,我们每人在修改完后手工合并,然后将合并后的js, css签入到服务器,对于此举,异为不解,但心想,公司这么多的牛人不可能没有人知道这般弱智的事,定有原因,新人还是低调,直到一天和神奇yongwei聊天时,才得知大家都烦,但无法进行改变,Release Team只有一个人,他也烦,不会顾及这种小事的。被我问的急了,大家就说别人能做,你丫的为哈就不行。此事暂定。

因为大家都在同一的项目上开发,原因见上一小节。那TFS上每个小组的开发路径又成我另一大疑惑,现行的方案是,所有Team基于同一的路径开发,然后在Release时,每个组报上自己要Release的code file的path,然后由专人(也就是刚提到的那一个人)半自动化的将代码拉到release branch,天那,这是上世纪80年代吗,关于这方面的资料不要太多啊。其中:InfoQ 持续集成之“分支策略”​,社区里也流传着很多互联网公司的分支方案,如豆瓣。我也明白为什么上一个问题会得不到解决和下一个问题是必然的了。

果不其然,代码回滚,差异发布…这些都没做到,更是有人小声谈论每次release是手工将代码copy到每台服务器的。我只能说这人“牛”。

####测试之累

QA是个很奇怪的名字,但很多公司还是这样称呼。虽然算不上互联网产品,但还是基于web来做,就不得不考虑多browser的测试问题。算上ie6,7, 8, 9. FF 3,4,5. Chrome, Safari,再算上Windows和mac两大系统,这有多少平台要测?开篇的第一怪异的自动化测试也因此而来。

Web 的自动化测试能有效的降低产品的测试周期,但前期投入也较高,因为公司没有对应的人,所以这事一直由多招QA作为替代方案来实施,因为没有考虑测试,所以有关测试环境,代码可被测试方面自然没有相应准备,现在让不会Coding 的人来做自动化测试,难那。

####更多更多

强势且无为的架构师,半年终见的项目经理,这此事情都太多太多。

####谈我为什么不看好#SCRUM#

*这里的SCRUM是特指给公司做指导的SCRUM

SCRUM是要求人的,没有好的PO, Scrum Master,强大的Team做后盾,这么灵活的机制是实施不起来的,说话那半年终见的PM拍拍屁股要做PO,这样的团队何以取胜?

还是人,一个小问题,要开上N天会,用上数周来仍无法定夺的事情不是民.主的象征,有时需要英明的领袖。至少让我们知道那个人是谁,谁能决定大权。

SCRUM代替不了软件开发,开发过程中的事从未被提到过台面,并不代码不存在这样那样的问题。每个人心知肚明,只是没人去说。在烂的架构之上怎么能敏捷?当然需求制定和任务分配同等重要,只是作为开发人员我便重代码方面的短板。

讲师,讲师的理想化SCRUM中提到,我们不要架构,我们不要验收测试,不要Code Review,不要xxx,好,一个足够好的团队里,我干吗要SCRUM来碍事,方法是要针对问题的,不是来制造问题。到了后来由于大家的不信可,讲师的言论转了180度,我们要Code Review, 可以OT…现行职位都不变…好吧,哥们我服你了。从纯粹的理论到现实的不变,这也太快了,自己都不坚定立场 ,怎么推行你的方法论。

####家家有本难念的经

每家公司都有自己的问题,在这里只是想写出我看到的问题,如果有幸被其它同事看到,并在公司得以改进,那可真是太好了。

只是想说,在实践任何理论之前,不如先找到自己的问题,点滴的优秀实践胜于空降一套水土不服的开发管理框架。

####我们在努力

冒着被训斥的风险,我们也在进行着一些好的尝试。(话说在XX公司,不被训斥的代码不是好代码)我们引入新的Branch,和持续集成,并在我们工作的层级上尽量消除手工劳动,加入自动化测试,并在可行范围内实施UI自动化测试,引入数据驱动测试的理念,在前端,倡导功能模块化和沙箱的架构。

只是话题有时铺的太大,而细节又都繁琐,没有更多上层支持,凭几人之力难有作为,更多的需要一场自上而下的变革。

20110703 2:56
看到Yongwei Blog上有关于Agile的话题,索性从床上爬起,写下此篇。