磕磕绊绊的Scrum之行(五)人的管理

补上一节说说过程中遇到的一系列问题和我的解决方式。

技术实现,就是“用什么技术,怎么来用”的问题,这玩意跟你爱看什么电影听什么歌一样,各人有各人的喜好。工作六、七年以上的程序员,实现技术基本上被固化了下来,会习惯于“以前就是这样做的”的思维方式;当你遇到一个很少使用框架、工作经验又丰富的程序员,他首先会很排斥框架,回答千篇一律的“框架不灵活”;另一些经验丰富的程序员有自己的一套编码风格和习惯;新手中的新手不是不知道如何下手,而是不知道如何学习;另一些新手是学了一小半,就忘了自己还有一大半没掌握。

解决方式吧,我比较暴力直接^_^

因为有项目架构师和框架开发人员近四年的工作经验(海量失败经验),在技术这块,我是有问必决的——直接写代码、讲明白,再与成员确认先了解、再结论——看问题尽可能客观。对方反馈是使用框架后确实很强大。

编码习惯问题,其实改起来确实不容易。首先对方花了很多时间与我争论,自称“太影响效率了”,于是一部分工作改由另一人执行,最后把结果拿整个团队一比对,该人工作项全部返工,了事。另一些不合规范的在代码审查中查出,安排专人修改。

半桶水问题,安排给有难度的任务,不懂的地方手把手教,辅以小故事,言传身教,倒不是为谁洗脑,要达到什么样的水平,取决于什么样的态度,要做什么样的成绩,取决于什么样的能力。否则,团队就被拖后腿了不是?

至于新手中的新手,真的只有手把手教,再出考卷考试成绩了。安排给他的角色是敏捷团队中的单元测试编写者,在持续集成中,渐渐地让他把BUG分析工作做起来。

昨天与业务部门主管的会议中遇到一个搞笑的事,某主管报怨下属能力差,什么都不会做,被上司评管理有问题,于是群策为其找解决方案:

报怨主管:他什么都不会做。
总监A:不会做就请示主管啊!
主管A:主管之所以成为主管,就是比下面的人更强才成为了主管。
总监B:……怎么这样说哦?
总监A:&(&你这种说法是错误的,怎么能上升到这种&(居然忘了原话了)层次来?
报怨主管:每次给他说了,每次他还是不会,最后还是我做。
总监A:你要给他一个机会啊!
总监B:要适当地放权,要不然你就太累了……
我:作为上级,培训和指导下属是工作的一部分。

mouge回复道:

把敏捷搞得这样不轻松,是不是有些用力过度.
一方面按照架构自然形成的思路进行工程实践,另一方面一开始就对数据库进行整体设计,有些不理解.
我回复道:
是针对子系统的数据库进行整体设计,因为整个项目是大型重构,架构是全新的,数据库只是结构上的较小调整和命名规范的约束。
mouge:
没有大型重构的说法,如果一定要全面对软件架构进行重构,关键是建立大量的测试用例,第一个sprint应该是建立测试用例->重构编码,而不是一开始就添加什么新功能。
我:
大型是指项目是大型项目,这个是根据投入的人月来评定的。
以前的系统基本上没什么架构,从一般的外包项目不同的是我们是甲方,业务再造权也掌握在我们的手上,更多是从业务入手去重做,所以,针对系统本身不太有很多东西可挖掘。但由于团队是新组建的,所以对旧系统、业务都应该有一个熟悉的过程。
mouge:
改造旧的系统有三种做法:
1、重构旧代码,添加新功能
2、添加新功能,重构新代码
3、一边添加新功能,一边重构
我不清楚你们怎么做,我的倾向是先重构旧代码后,有足够的测试用例后再添加新功能,关键是二项工作必须分开来做
我:
呵呵,你是站在程序员的角度上看问题了。

© 2018 Silent River All Rights Reserved. 本站访客数人次 本站总访问量
Theme by hiero