OSCHINA答读者问之六:杂谈(完结篇)

我曾经去给OSCHINA做过一期有关“软件工程实践”的有奖高手问答 (奖是给提问者的,哈哈),现在来看,许多问题仍然可读之处,因此整理成文字,以为众赏。

原贴在这里:http://www.oschina.net/question/12_78459

本篇的问题:(没有主题,呵呵)

问:我们公司准备进行“敏捷测试”。有没什么建议~!

答:基本上,所有带着“敏捷”字头的,我都很难有建议。那是个黑洞,什么概念都往里扔,却没人担负解释的责任。:)

问:软件工程的风险控制,有没有什么可以一般都遵循的规律或者说指导原则?

答:我只知道一条,向一个进行中的项目添加人手和添加特性,都是万恶之始。

问:对于没有确定需求的开发工作,您有什么好的建议?

答:事实上很难“确定需求”,软件工程为解决需求变化问题已经努力很多年了。现今的一些情况是,以类似于快速迭代、每日构建等方式来应对需求的变化;用原型等方式在较少代价下将需求尽量确定下来;强化测试以在需求变化下保障品质等等。但背后的事实是:我们承认和接受了“变化的需求”。一些极端的情况,就是把客户拉到Team中,让变化直接反馈在阶段产品中,或者让客户自己都疲于变化。总之,这些已既成事实。

问:软件工程,请问一些中小型项目有必要用吗?

答:无关大小。你要用“工程化的方式去做那个软件”,就必然要讨论软件工程的问题。但显然,你要得到“那个软件”,可以买的,可以外包啊,为什么一定要“工程化开发”呢?所以与大小无关,取决于你打算“如何得到它”。

问:大公司架构主要负责什么工作?

答:很多架构师在大公司混饭吃,所以切莫以“公司大小”来看架构师的优劣。将“做架构”以及“做更优秀的架构”作为一个修炼的过程,而不是将自己变成更加的开发高手,就好了。至于变化说到底就是一个“需求要不要满足”的问题,个人意见是“接受需求,控制变化”。但这与敏捷与否是无关的,后者是表象。

问:软件工程学到什么程度才算合格?

答:知道那本叫《软件工程》的书一点儿也不重要,就合格了。

问:您感觉像软件工程这样的课程应该怎么来上呢?

答:按“标准过程”做一两个项目即好。但条件是:要考核每个人的工作量,评估成效;并针对上述结果做出激励机制;并针对激励机制的价值写出论文。至于项目最终成不成,做不做得出软件,无视之。

问题:有没有(类似标准过程的)完整的简单实例给大家来一份啊?

答:请写一个记事本软件。条件是:用十个人开发,其中三个人决定记事本软件的产品特征项、版本规划。

问:您怎么看待权利与规范?

答:真正的特权,是制定规范。无视规范是特权者的特权,无规范是打破特权的神器。但,无规范则无社会框架:没有如水的组织,亦无如水的社会。无规范如是梦中。而做梦,是个体的最终自由和最终动力。