|
锁定老帖子 主题：《特征驱动开发方法》
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-08-21
期待o6z的讲解
|
| 返回顶楼 | |
|
发表时间：2004-09-02
colorUML有没有中文的资料呢？现在就等o6z的讲解啦@_@
|
| 返回顶楼 | |
|
发表时间：2007-01-14
嘿嘿,老帖了, 请o6z再接着讲解
|
| 返回顶楼 | |
|
发表时间：2007-01-29
可惜是E文的,看着就头大啊,有没有高人翻译一下!
|
| 返回顶楼 | |
|
发表时间：2007-01-29
ozzzzzz 写道 其实FDD和XP非常类似，而和RUP的距离要远的多。在FDD中很少有中间的制品，而且那些中间制品也非常容易被维护和释读。 首先同意大家的看法，我也认为FDD更加适合。但是对于ozzzzzz这个RUP的观点，我认为值得讨论，就我个人对RUP的了解，虽然RUP列出了很多中间制品，但是那些都是给流程设计师参考用的，具体的项目可以根据情况进行调整，包括增加，删除，修改，合并等等。RUP里面有非常重要的一点，就是在使用RUP之前，一定要进行定制。 |
| 返回顶楼 | |
|
发表时间：2007-01-29
dlee 写道 XP 中还有一个问题是没有软件详细需求文档，而仅仅有一系列的 User Story。
Alistair Cockburn 在《编写有效用例》第 18 章“用例概述和极限编程”中写到： Alistair Cockburn 写道 采用 XP，应用和业务专家与软件开发人员坐在一块，因此，开发组不需要编写软件详细需求，而只记录下“User Story”作为有约束力的备忘录以便将来能围绕这些功能讨论需求。
...... 只有了解需求的用户和系统开发人员在一起时，这种方法才是可行的。在设计期间，设计人员可以直接与有需求的用户合作。就像 XP 的 User Story 一样，如果双方都能履行约定好的备忘录，这个条件就可以满足，XP 也是可行的。但是，在大多数项目中，这些约定条件没法满足。因此最好还是把应用描述为用例编写开始之前的练习，并把用例概述作为项目概要的一部分。 这段话回答了我对 XP 的另一个主要的疑问，同时也说明了为什么 Alistair Cockburn 后来要自创水晶开发方法。 XP 对于用户提出了过高的要求，不仅难以找到符合 XP 要求的程序员，而且难以找到符合 XP 要求的用户。反复打扰客户是很招人嫌的，打搅次数多了客户甚至会怀疑你是否听不懂人类的语言。要客户派一个人来和开发人员一起工作，他们往往会派一个无关紧要的人过来（真正的业务专家往往都非常忙，不可能经常过来与程序员共同工作）。这样的人没有任何决策权，对业务也没有完全理解，他提供的意见你能完全相信？ 因为有以上的这些顾虑，我的结论是 XP 不是适合中国软件企业的开发过程。国内的软件企业可以借鉴 XP 中的一些最佳实践，但是绝对不能全盘照搬 XP 的做法。 十分同意。XP的前提条件非常重要，而该条件又是极为难以达成的。事实上我认为XP不仅不适合国内软件开发，而且在国外也不适合绝大多数软件开发项目。XP前几年流行带来的好处是大家知道了敏捷，虽然XP带来了些副作用，其某些较为极端或者非常有个性特点的行为方式迎合了绝大多数程序员的口味，这或许是其流行的原因。 |
| 返回顶楼 | |
|
发表时间：2007-01-31
呵呵，期待o6z的讲解
|
| 返回顶楼 | |
|
发表时间：2007-02-07
o6z失踪许久了，难道是逃跑？
:D |
| 返回顶楼 | |
|
发表时间：2007-02-08
谢谢各位大侠的评论，给后来者指点良多。
再次感谢！ |
| 返回顶楼 | |
|
发表时间：2007-02-11
colorUML其实可以用一句话来表达。
任何的需求（其实任何的事情）都可以表现为: 什么人（或者事物） 在一个什么时间（或者什么时间段） 以一种什么方式 做了一种什么样的行为 当然你还可以使用不同的时态来构造这个表达。其实这是我们语言上陈述句子的基本形式，当然你可以使用oo的方式来构造。不过我觉得fp的基本要素也孕育在其中了。也就是说这个基本的模式，其实oop和fp都是这个基本现实形态的一个投影。 |
| 返回顶楼 | |
