几段在脑子里盘旋了很久的话:
带一个项目,要保证项目的质量,当然要靠Team Leader的水平。那么,什么才是最重要的项目质量呢?当然是代码质量!一个软件项目,最重要的产品当然是代码!
如果这个Leader看不懂项目的代码,他只能通过要求文档的质量,来间接的控制代码的质量。一个能够看得懂代码的Leader,他就能够直接控制代码质量。而能够直接控制代码质量的Leader,对于文档的要求,会合理很多。
直接控制与间接控制,哪一个更加有效,是不言而喻的。当然,那些没有代码阅读能力的Leader,他们会更加强调文档的重要性,甚至舍本逐末,认为文档质量才是项目质量的体现。进而变态地追求文档完美,以至于浪费了程序员写代码的时间。这样的Leader,根本就不可能管好项目的。
公司往往会出于恐慌,向员工要求很多详尽的文档,主要是为了防止员工离职带来的损失。而问题在于,公司的主要努力,应该用于留住员工,而不是用于加强“善后能力”。更不是为了增强善后能力,搞得员工越发想离开这家公司。
btw:
补记一段交锋对话:
UP和Agile都是工程过程实践的总结,林德彰先生说过“UP是正楷,XP是草书。先学好了UP,才能学好XP;先学XP再学UP就会乱套。”
Agile强调的是“代码是真正有价值的东西。”这同样也是实践的结果。二位对于过程有不同的看法并不能说明孰是孰非,这只是在不同的实践内容和阶段上的总结。在过程的选用问题上,只有不断地实践才是前进的方向。
我的回答是:
林德彰的说法,是一个在校教师,典型的和稀泥的说法,我不同意。
没想到今天有一个朋友WANG回了一帖:
老林是在校教师?你应该去看一下人家在美国打拼的经验~~
我的回复是:
他在美国打拼怎么了?还有好多土生土长的美国人,也不鸟那什么UP呢?
我为什么要听一个海龟来上课呢?
这年头,海龟还不够多吗?
另外对GHawk多说一句话:让组员快速磨合的最好办法,是结对编程,而不是大家埋头写文档。
posted on 2006-04-22 21:35
读书、思考、生活 阅读(29943)
评论(21) 编辑 收藏