OSCHINA答读者问之六：杂谈（完结篇）
我曾经去给OSCHINA做过一期有关“软件工程实践”的有奖高手问答 （奖是给提问者的，哈哈），现在来看，许多问题仍然可读之处，因此整理成文字，以为众赏。
原贴在这里：http://www.oschina.net/question/12_78459
本篇的问题：（没有主题，呵呵）
问：我们公司准备进行“敏捷测试”。有没什么建议~！
答：基本上，所有带着“敏捷”字头的，我都很难有建议。那是个黑洞，什么概念都往里扔，却没人担负解释的责任。:)
问：软件工程的风险控制，有没有什么可以一般都遵循的规律或者说指导原则？
答：我只知道一条，向一个进行中的项目添加人手和添加特性，都是万恶之始。
问：对于没有确定需求的开发工作,您有什么好的建议？
答：事实上很难“确定需求”，软件工程为解决需求变化问题已经努力很多年了。现今的一些情况是，以类似于快速迭代、每日构建等方式来应对需求的变化；用原型等方式在较少代价下将需求尽量确定下来；强化测试以在需求变化下保障品质等等。但背后的事实是：我们承认和接受了“变化的需求”。一些极端的情况，就是把客户拉到Team中，让变化直接反馈在阶段产品中，或者让客户自己都疲于变化。总之，这些已既成事实。
问：软件工程，请问一些中小型项目有必要用吗？
答：无关大小。你要用“工程化的方式去做那个软件”，就必然要讨论软件工程的问题。但显然，你要得到“那个软件”，可以买的，可以外包啊，为什么一定要“工程化开发”呢？所以与大小无关，取决于你打算“如何得到它”。
问：大公司架构主要负责什么工作？
答：很多架构师在大公司混饭吃，所以切莫以“公司大小”来看架构师的优劣。将“做架构”以及“做更优秀的架构”作为一个修炼的过程，而不是将自己变成更加的开发高手，就好了。至于变化说到底就是一个“需求要不要满足”的问题，个人意见是“接受需求，控制变化”。但这与敏捷与否是无关的，后者是表象。
问：软件工程学到什么程度才算合格?
答：知道那本叫《软件工程》的书一点儿也不重要，就合格了。
问：您感觉像软件工程这样的课程应该怎么来上呢？
答：按“标准过程”做一两个项目即好。但条件是：要考核每个人的工作量，评估成效；并针对上述结果做出激励机制；并针对激励机制的价值写出论文。至于项目最终成不成，做不做得出软件，无视之。
问题：有没有（类似标准过程的）完整的简单实例给大家来一份啊？
答：请写一个记事本软件。条件是：用十个人开发，其中三个人决定记事本软件的产品特征项、版本规划。
问：您怎么看待权利与规范？
答：真正的特权，是制定规范。无视规范是特权者的特权，无规范是打破特权的神器。但，无规范则无社会框架：没有如水的组织，亦无如水的社会。无规范如是梦中。而做梦，是个体的最终自由和最终动力。