首届“敏捷中国”开发者大会 精彩问答

主持人：非常感谢Roy Sniugham给大家带来精彩的演讲和Martin　Fowler的抱病坚持，也希望大家多体谅。下面将要宣布一个好消息，对于各位Martin Fowler的读者和敏捷的爱好者来说是一好消息。

　　大家看到这两网址是我们在CSDN上面为Martin Fowler先生开的两博客：第一个是敏捷技术专家群；下面那个网址是Martin 　Fowler的中文博客网址，是昨天刚刚开通。这里面ThouhtWorks熊节和他的同事会日常维护这个博客，会把他的最新言论更新到这个博客里面，这个博客也会加入到敏捷技术专家群里面。大家可以登陆这个地方，把自己的博客申请订阅。下面有什么问题大家可以提问。



问：我听说ThoughtWorks的陶文是研究DSL，请您介绍一下ThoughtWorks研究DSL的一些进展，或者项目开发中的一些故事。

答：ThoughtWorks非常多的同事是非常喜欢DSL的，就是通过专家的描述可以把DSL写出来，DSL目前是倾向于语言更加自然。说起目前的项目，目前还没有一个成熟的项目来用DSL构造的。

问：我想请问一下关于编写的格式，实际的作用代码编写之前，怎么在作用代码还没有编写之前就写出测试代码。另外测试代码的编写谁来给测试代码做测试？

答：因为先有需求，根据需求写测试代码。另外是根据你的逻辑给测试编码做测试。

问：我刚才看了现场秀以及关于敏捷这块的例子，我感觉有一个问题我知道您这边遇没遇到过，您刚才说的要加运费，运费有不同的情况，可能我的业务逻辑和结构都要去适应，那我们敏捷对各种情况怎么适应呢？第二个问题，我这边软件情况一般都是管理软件，需要架构重用等等，这种情况下我的中间层在敏捷开发过程中怎么样构建？

答：我觉得你说的问题是需求不断变化，这个问题怎么解决。首先敏捷宣言里有一句话叫“拥抱变化”就是我们不害怕变化，但是变化是有它的成本的，我们在敏捷中是需要有一个在线客户，我们不喜欢刚开始把需求都做完。就像刚才的Story，它是表现了用户的价值，我们是在开发代码的时候跟客户谈你的需求是什么。我们代码在编写的时候一定要注意它的灵活性，就是代码如果真的有变化，你的代码是可以允许一个地方变化而不是所有地方都变化。这两条保证我们对所有的变化都是不惧怕的，都是很快能适应的。

　　第二个问题业务逻辑重用？软件永远都是真实的抽象而已，当真正业务变化的时候证明你的domain已经需要变化了，你的domain变了其他的所有行为都会改变。

问：第一个问题在实际的情况下我们遇到有大量用户使用XP界面的方法，我们有用大量用户故事管理，但是故事之间有依赖性非常复杂这种情况下有没有什么好的经验和最佳实践管理非常多的用户故事的情况。

答：在我们来看一个Story需求非常多的话你最开始的时候都没有分析清楚。Story是依赖于其他的Story的你要先清楚其他的Story。

问：第二个问题，怎么样做估算？你们做演示的时候我看到没有做估算，但是我向客户说的时候要把所有的用户故事排列起来？

答：比如一个项目跟用户报多少价格，用多少时间，这肯定是一个估算，是不准确的。我们使用用户Story管理。我们是会用点数估算，我们会算出点数风险和业务风险，开发人员会写上点数，我们会根据以前的经验判断每一个点数多长时间完成，这样我们得出一个总体时间，根据这个时间算总体的成本。一般一个Story点数不能过大，也不能特别小，如果说一个Story两个星期都实现不出来这个是不合理的。开发人员会根据以前的实践经验理解评估点数。比如1－5，你打这五个数字的时候会知道哪个更复杂，如果说大于五你要把它切成两个Story。