方法论的问题
[zhenyue]
软件工程作为工程学的一个分支而存在， 其目的和制药工程、生物工程、金融工程等其他工程学领域的区别不大。
最关键的部分是区分不同的方法论所对应的问题空间。
只有确定了问题空间才能找出正确的方法论和正确的工程学工具。
目前对于软件工程学最感无奈的地方就是 “手里是锤子，眼里都是钉子” 这种现象。
重量级的软件工程方法论 CMM RUP
轻量级的软件工程方法论 XP 等 敏捷方法思想
都有各自的问题领域， 跨过各自领域后方法论并非不起作用， 而是成本和风险的急剧上升。
对于xp 等敏捷思想来说， 比较流行的说法是请参照“精益生产"思想的应用领域。
它就是软件行业的精益生产
【G按: 其实agile运动有一个提法，就是反对把软件当作工程学的来看待，软件不能等同于大规模生产过程，不过其他领域的研发管理应该也有可以借鉴的部分,这个问题争论很大。问题空间这个提法很有益，不同的开发方法都有特定的问题空间约束，另外把cmm和rup并列也是不对滴，打个比方，k大就专门有人写过文章如何使用xp玩cmm，cmm和组织使用的具体软件开发方法理论上无关】
[ zhenyue]
二战后的美国，以福特公司为首的汽车制造公司在大肆提倡规模制造（Mass Prodution）的同时，东方的日本，丰田英二等人在考察了美国的制造思路之后，认为美国的制造方式不适合日本，提出了自己的精益制造（Lean Production）的思路，精益制造成就了一代霸主－丰田公司，丰田的制造方式被人称为TPS（Toyota Production System）。丰田公司的丰田英二和大野耐一等人进行了一系列的探索和实验，根据日本的国情，提出了一系列改进生产的方法：及时制生产、全面质量管理、并行工程，逐步创立了独特的多品种、小批量、高质量、低消耗的生产方式。这些方法经过30多年的实践，形成了完整的"丰田生产方式"，帮助汽车工业的后来者日本超过了汽车强国美国，产量达到1300万辆，占到世界汽车总量的30％以上。
回顾这段历史，和软件开发的历史何其相似。大规模制造理论认为，一定程度的浪费，一定程度的废品是正常的，允许的。而在软件开发中，浪费、成本居高不下也同样成为阻止软件开发迈向工程化的一大障碍。像XP这样的敏捷方法从精益制造的思路中吸取了很多的优秀思想，例如，不断改进质量，设计决策应该交给最贴近生产的人员，根据客户的需求来推动生产。虽然我们一直在强调软件开发和制造行业截然不同，但是，处于变革的十字路口的软件开发行业，总是不断的从其它的行业中寻找可借鉴的理论。这种借鉴来的思路就被称为精益编程（Lean Programming）。
【G按:问题是软件业从来就没有出现过福特汽车式的流水线大生产模式，印度的软件工厂只是个案，并未解决所有的问题域空间，又怎么提生产模式的改进？ xp从精益制造的思路吸取很多优秀思想的这个说法是臆造的。xp起始于c3项目，大部分关键实践在xp出现之前就已经出现，并在很多项目中使用，而c3项目的发生地。。。。】
[ zhenyue]
在管理软件领域， 抱怨客户需求变更的情况及其普遍， 而且这条路已经走死。
【G：这也是xp的出发点】
试想
就算 客户的业务流程与工程文档100%同步且需求分析100%正确，代码100%符合文档。
就一定保障客户会满意吗， 客户马上会发现自己的业务流程有问题，而要求你修改文档和程序。
而这一过程仅仅是用程序来验证客户的业务流程而已， 并没有同时起到优化客户的业务流程的作用。
最好的思想还是SAP的行业最佳业务实践。
管理软件的开发上，一定要管理理论优先。
【G:貌似在绝大部分问题域，理论永远是落后于实践的，而且信息系统的建设一定是对现有业务模式的重组过程】
[florid.dong]
XP只是个理论，具体方法有很多，如Scrum等。XP不是将代码转向测试，要知道客户付钱的是实际代码，不是用你的测试代码，更不会为你测试付钱的，你应该对你的产品负责的。
测试细分又有很多，大类有static testing, Dynamic testing, 功能分有Unit Testing, Iteration Testing, Acceptance Testing等，要按模块分又有UI Testing, DB Testing等等，还有很多支持手段贯穿各个阶段，如Daily Build, Code Coverage, Duplicate Analysis等，太细了
【G：这位把xp和agile 弄混了，对测试工作的理解不错】
需求的变动与来回折腾的问题。
[ florid.dong]
主要要原因是技术人员对业务的不了解而产生的误解。以前的开发模式是先花大量时间分析，然后写代码写出个完整的版本再让用户看。而XP方法是开发出不同的小版本来来逐步确认。
打个比方，路很好走，也知道方向，你会走的很快，而且一直走，但如果你不熟悉的路还大步走，不问人肯定出问题，而大多数开发人员过于自信了。所以现在要求，小步走，走的慢些，而且见一个人问一个人来保证方向正确。
需求变动可以看做来回折腾的前兆。原因都是一点，双方都不了解到底要干吗
【G按：道理讲的蛮清楚，例子也举得蛮好，不过有一点有问题，需求理解差异并非单纯是技术人员的问题，而是双方的问题，xp的一个核心就是希望解决用户和技术人员的双向沟通问题，小步迭代并非xp特有的，在rup这种重量级方法里也是核心。】
* [florid.dong] 需求的获取问题
想让用户为把他们的单据可以输入，就付你钱，你就从一开始就玩完了。你跟着他们走，迟早被变化的需求拖死。
但凭心而论，并不是需求变化了，而是用户没说清，或你没有引导用户说清，还有用户自己也说不清。所有国内的管理软件做的都像单据输入一样，可问题在于，你一旦这么一做，每个用户的单据都不一样，就像一个立方体，每个人看的面都不一样，如果你只按看到一个面的用户的要求做，你做不出立方体。要响应变化了，你的产品就要分叉了，时间一长，你就要维护N个版本，头就大了。
必须知道用户在想什么，并且要超过用户才行，而现在的分析员，或开发员都太缺乏相应的业务背景了。
【G按：这个问题的根已经脱离了xp的范畴了，信息系统的建设本质都是对用户业务管理模式的一次重构，试图将现有手工处理模式简单的copy为计算机模式本身就是错误的。对业务的理解，要超过用户比较困难，各种顾问公司的存在并非因为他们真正的超过了用户，更多是提供一种不同角度的思考借鉴和内部矛盾转移。xp的做法其实相反，xp让用户来选择，主导自己的需求，把责任推给用户，这和传统的开发模式是相背的。另外所谓n个版本的问题，其实架构方面可以解决】
业务人员很少有人能了解公司里的所有业务与联系，每个人都是只知道自己的工作内容。高层知道业务联系，但完全不了解细节。很绝望是不是？但这是现实。
好的分析员，就像胶水，能把每个不同立方体联系起来。差的分析员不但不能把每个立方体拼起来，自己还被立方体尖角扎死了。分析员的价值就在这里。
【G按：xp的做法好像是让用户去做这个胶水，呵呵】
自动测试的问题
[ florid.dong]
2）自动测试的编写，大概是怎么一个过程，一般的测试用例怎么定义？很多测试不是单独数据的测试，而是几张单据共同产生不同的结果，这个时候怎么定义？如果再加上各个单据的各个条件的边界值测试，貌似数据量很大很大。。。。
1）到什么地步，取决于你肯投入多少物力，人力。在我的TEAM中连UI测试都是自动进行的。测试人员是多于开发人员的，而且测试员的工作量要显著多于开发人员，相应待遇也要高，能力最高的一般是测试人员。测试人员也是写代码的。
2）自动测试只是一种机制，在某个特定时刻自动执行你写的测试用例。我们的标准是，后台，每三十分钟检查一次代码库，对一个Solution只要有一点变动，就静态，动态，相关测试全跑一遍。还有每天晚上定时至少跑一次。前台代码，每天晚上至少跑一次，其它手工启动。我们还没办法使不同的前台测试同时运行，因为我们是直接通过Win32 API处理的。
测试取决于你的软件开发模式，越模块化的越好测试，在我的TEAM中，后台开发与前台开发是分离的，前后台是单独测试的。如果模块切分的不好，测试就会很复杂。像盖房子，一般都是一堵墙一测的，你整个房子盖好的，当然测的东西要多。
【G: 这种做法其实已经不是xp了，xp中代码测试是由开发人员完成的，需求测试是用户完成的，体现了各自对各自工作的责任感。但是团队中能做到测试人员人数的待遇都超过开发人员，是相当了不起的】
测试数据是否直接创建，取决于你是测那一块。说说我们的做法
引用的基本数据先创建一部分，这样，在引用这些数据的页面里只要引用就好了。
如果是输入等测试，要通过测试输入数据，如果是查询，就事先创建数据。
Test Case是很多的，五种不同属性的供应商，三种结算方式，如果是关联的，至少十五个Test case，如果不关联，至少八个。如果再考虑错误，边界，那就更多了。
换个角度想一想，如果不写测试代码，人走一遍，基本是不可能的，你稍微改动一下代码，如果不全测，说不定，就影响其它部分了，三周后才发现，早就不知道什么原因造成的了。代码再累也只写一次，反正是机器，让它跑去好了，一台服务器，便宜的才几千块。那怕改一行，跑一天也没多少成本，如果是人测，漏了一个，都头痛。长期来看，成本反而会降低。没苦那有甜
确实很累，要真正坚持下去，团队领袖的意志力，技术力，判断力都会变的很重要，这绝对是一个考验。
【G: 这其实是xp和其他方法的一个差别，xp希望做到的是大家自觉折腾产生1+1>2的效果， 而不是依赖于团队领袖的意志力和判断能力】
我们的做法是，1. 测试用例是有重叠的，2. 静态测试 3. 尽量将测试写进我们的测试引擎，然后创建不同的场景，以测试 测试引擎。
没有很好的办法来保证，我的经验是，一般来说，测试代码只有遗漏，错误不多，因为不需要太多逻辑，只要创建数据，然后得到数据判断是否是预期的，就好了。就是给个A，看出来的是不是B
【G: xp中对这个问题的处理一度程度上是依赖PP来解决的，也就是加强review】