|
|
冰力恰恰 11:27:37
我们来讨论 用例驱动 和 敏捷开发 吧
妖狼 11:27:54
那你先做一个通俗的解释吧
猫 11:28:18
用例驱动最难的地方是什么?
怎么把用户描述很好的抽象成程序能独立开发的一个部分?
妖狼 11:28:16
不要专业的解释，要通俗的，因为很多专业名词或表达方式我不懂
冰力恰恰 11:28:48
用例驱动最难的地方是什么?
最精确最唯一最有效的需求传递
妖狼 11:29:23
不懂，请再通俗一点
猫 11:29:56
需求传递...
紫紫小木 11:30:34
照着葫芦画瓢的？
妖狼 11:31:12
我觉得这些都太专业了，不够通俗
妖狼 11:31:31
要知道做策划的什么出身都有，这样的说法不能让大多数人能良好的进行理解
冰力恰恰 11:31:52
最精确最唯一最有效的需求传递
很通俗啊
59U26J此生无求 11:32:07
通俗的说法 就是 你做的东西就是用户想要的东西
59U26J此生无求 11:32:17
这个通俗把？~~~
妖狼 11:32:30
单此一句可能很通俗，但前后一连接可能就不通俗了
冰力恰恰 11:32:30
不通俗 这个是结果 不是过程……
猫 11:32:52
不通俗...每个人都希望自己做的东西是用户想要的...
Susaro 11:34:01
就是说……
有100个程序员和美术
看到你给的需求，给出来的结果都是一个
而不是100个
后者在很多公司都会出现，因为理解不一样
59U26J此生无求 11:34:21
但是 玩家通常不知道他们要什么。。。。。
冰力恰恰 11:34:27
Susaro(9294184)
大神 我要拜拜你 你说得很通俗
Susaro 11:34:46
那么需要策划去把用户需求抽象出来
59U26J此生无求 11:35:17
不知道要什么怎么抽象？
Susaro 11:38:10
我有一个道具，长什么样？不知道，叫什么？不知道
但功能如下
ItemA：左键单击生效
图形消失，（在道具栏占位1格）
效果是让角色A从现在有坐标消失1分钟（不显示）
妖狼 11:38:56
功能强调，作用强调，效果强调
Susaro 11:38:58
等有空了，我再把它取名为“隐形药”
猫 11:39:01
用例驱动...还是很模糊啊
我只隐约的觉得他能在专业的方向更程序啊什么的更多自由很更多选择
冰力恰恰 11:40:48
1）前置条件：指在用例启动时，参与者（Actor）与系统应置于什么状态，这个状态应该是系统能够检测到的、可观测的；
2）后置条件：用例结束时，系统应置于什么状态，这个状态也应该是系统能够检测得到的、可观测的；
3）基本事件流：基本事件流是对用例中常规、预期路径的描述，也被称为Happy
day场景，这时大部分时间所遇到的场景；它将体现系统的核心价值；
4）扩展事件流：主要是对一些异常情况、选择分支进行描述。
冰力恰恰 11:43:29
唔 我们平时是将他们对应成了以下东东
前置条件 -- 先决条件
后置条件 -- 操作步骤
基本事件流 -- 结果
扩展事件流 -- 其他关联问题
其实 有很多公司都是按这样的方式表示执行案的
目的都是一样 为了确保需求传递的有效性
Susaro 11:44:47
类似于
if
then
else if
else
猫 11:44:49
额...冰
这个就是我昨天看的介绍...
可我觉得似乎这些都不是很重要
重要的是,如果一个基本的用例在策划看来流程很简单
但是在程序的时候,却要遭遇很多不同系统的交叉和编写,似乎就很麻烦了
而且如果用例用的太多,程序完全根据用例来编写的话
又似乎很难去总结系统该有些什么基本的子系统
冰力恰恰 11:44:57
当然 有的公司叫法不一样 比如 群主、花花、男秘等
都将 扩展事件流 称为 冲突与联系 ……
叫什么并不重要 重要的是是否能够确保唯一性
冰力恰恰 11:46:29
如果一个基本的用例在策划看来流程很简单
但是在程序的时候,却要遭遇很多不同系统的交叉和编写,似乎就很麻烦了
这是需求不明造成的结果 不知道我这样理解有没有问题
用例驱动的主要目的 刚才我也说了
最精确最唯一最有效
策划是为了这样的目的 才需要采用用例驱动的工作方式
Susaro 11:47:27
在拆分用例前
还有许多工作要做
就是为了避免出现 猫 说的问题
猫 11:47:28
恩,使用用例驱动是为了让开发人员更好的了解用户的需求,我这么说对吗?
Susaro 11:47:58
用例驱动是让开发人员不用去了解用户需求
照本宣科 就能做出 设计者想要的结果
Susaro 11:48:11
并且这个结果是唯一的
Susaro 11:48:37
其实是降低了程序美术人员的要求
但是对设计者的要求非常高
猫 11:49:08
恩...无论如何,只要开发的结果达到了事件流的效果,那么也就是达到了需求
当然这样的前提是建立在事件流描述正确的基础上
冰力恰恰 11:49:15
设计者 -- 在游戏开发中，是由游戏策划担当的角色（但不排出程序和美术的参加）
猫 11:49:40
但这样似乎对设计者的要求太高了...
冰力恰恰 11:49:53
所以花花和男秘都是达人啊
冰力恰恰 11:49:58
群主是大神……
妖狼 11:50:01
楼上都是超人
Susaro 11:50:46
用例驱动会根据分工不同，分配给程序进行开发
通过分配过程来回避交叉编写造成的问题
Susaro 11:52:13
或者说，去考虑怎么构建 类 和 方法 对这个系统是最有效的和可扩展的
猫 11:52:31
恩...但似乎策划对这个都不是很熟悉
Susaro 11:52:55
是的
用例的过程会系统构架
但是系统构架在用例出来之前，就会做，这是另一项必须的工作
Susaro 11:53:17
但这个构架可以模糊和不准确，但要有扩展性
Susaro 11:53:34
用例的过程会模糊系统构架
冰力恰恰 11:54:03
重点 记下
Susaro 11:54:35
但扩展性和“模糊”
正好是 面向对象 的优势
猫 11:54:51
不过似乎初期的系统构架,在游戏方面,可以让程序的人来做
应该没很大难度的...
Susaro 11:54:53
所以，用例驱动也有其针对性，并不是什么都可以用
Susaro 11:55:09
猫(54677746) 11:54:51
不过似乎初期的系统构架,在游戏方面,可以让程序的人来做
应该没很大难度的...
Susaro 11:55:42
经过用例驱动磨练过的策划
并且经历过 构架 阶段的
都有资格成为系统架构师
妖狼 11:56:04
我是没资格了
冰力恰恰 11:56:13
Susaro(9294184) 11:55:42
经过用例驱动磨练过的策划
并且经历过 构架 阶段的
都有资格成为系统架构师
老大 你说偶呢……
猫 11:56:37
我是在YY...全部是臆测...
Susaro 11:56:39
用例驱动 只是一个方法
并不代表 本质
紫紫小木 11:56:59
架构师都出来了啊
妖狼 11:57:22
可以说是是一种思想传递并完整继承的方法
猫 11:57:30
但在用用例编程的过程中出现的新系统的归类应该怎么做?
妖狼 11:57:35
这样说应该不算错吧
冰力恰恰 11:57:50
妖狼(40755332) 11:57:22
可以说是是一种思想传递并完整继承的方法
对 顶
Susaro 11:58:04
因为，前期的构架，还是需要策划和程序至少能明确到某个层次的需求才能进行下去
而且，每一个用例拆分，都需要咨询看的人，拆分是否合理
所以，沟通和交流也非常重要
Susaro 11:58:46
新系统归类？
在构架阶段就已经划分好了
妖狼 11:59:16
一般在规划的时候要有什么系统都会考虑的
Susaro 11:59:34
而且也很抽象
如，我需要
启动
登陆
创建
行动
攻击
技能
道具
=======
继续下去
妖狼 11:59:38
如果每天都要增加一个新系统那估计就没法做了
Susaro 11:59:51
但这些东西到底怎么样
我可以先不去考虑
妖狼 11:59:56
因为可能会和以前的设定产生无数的冲突
冰力恰恰 12:00:11
这些都应该在框架案里进行约束和定义吧
紫紫小木 12:02:09
听你们说完了，感觉自己是另一个世界的人鸟。
冰力恰恰 12:02:16
……难道 难道用例驱动就这么讨论完毕了 汗
妖狼 12:02:26
这个只是一种方法
妖狼 12:02:41
只要说明方法的意图作用基本就算说完了
猫 12:03:35
我不是说的游戏的小系统
是程序在用例中需要新增的一些小功能,也许这些小功能会在其他的用例里也有用
这些新增的小功能又怎么分类到程序系统里去
还是不重要的东西允许一定量的重复
冰力恰恰 12:05:44
目的是传递的有效
现在却推翻了唯一性 就因为程序私自增加需求
妖狼 12:05:47
如果程序可以任意在里头增加新内容，那么就完蛋了
猫 12:05:53
程序编写的一些功能有可能是可以做为一个基本块,在其他用例里也需要而可以被直接调用
紫紫小木 12:06:01
能把例具体解释一下和举例吗
妖狼 12:06:08
这样做了以后就可以准备部门之间的对骂大战了
冰力恰恰 12:06:08
猫(54677746) 12:05:53
程序编写的一些功能有可能是可以做为一个基本块,在其他用例里也需要而可以被直接调用
哦 这样啊
Susaro 12:06:56
那么我的问题是
为什么这些改动，事先你们没有发现和准备？
猫 12:07:04
不是改动
猫 12:07:07
没有改动
Susaro 12:07:29
如果不是改动
那么就应该在框架许可范围内了
妖狼 12:07:29
我只想知道为什么要增加
冰力恰恰 12:07:36
我明白猫的意思 如果他的意思是
猫(54677746) 12:05:53
程序编写的一些功能有可能是可以做为一个基本块,在其他用例里也需要而可以被直接调用
Susaro 12:08:04
你是说 类 和 方法？
冰力恰恰 12:08:41
那样是允许的 例如你做了一个面板的控件 在A系统中
那么 在B系统中也有这样的面板 那么可以调用的
这 应该算是一种方法吧……但这个面板应该是一个类？
Susaro 12:09:40
代码重用，那是好事啊
妖狼 12:09:53
功能调用而已
冰力恰恰 12:09:55
Susaro(9294184) 12:09:40
代码重用，那是好事啊
这是反话么……
Susaro 12:10:05
正常的叙述
冰力恰恰 12:10:35
嗯 这就对了 可以调用 猫 你的问题解决了
猫 12:10:44
按冰的例子,那我说的意思A系统和B系统是两个不同的用例
在A系统中的面板,因为和B系统不是同一个人或者小组开发的
虽然功能相似，但就可能被A小队和B小队都编写一遍而造成浪费
妖狼 12:11:02
我觉得这个说法是过于多虑了
Susaro 12:11:13
那应该去收拾写这份用例驱动的人
Susaro 12:11:28
程序没错
妖狼 12:11:28
面板操作可以看做是一个通用模块来处理
Susaro 12:11:30
需求错了
冰力恰恰 12:11:32
这个是 设计者 提出的需求
所以设计者应该在提这份需求的时候就考虑这样的问题
妖狼 12:11:36
那么你觉得还有没有这个问题呢？
猫 12:11:42
没有.面板是一个很大的东西
很容易见
猫 12:11:49
如果比面板更小的东西呢?
冰力恰恰 12:12:10
如果设计者没有考虑到这样的问题
则 回家抽自己脸去
Susaro 12:12:12
学会用例驱动的写法很快
但是要理解拆分合理，那需要时间磨练
妖狼 12:12:15
假设某一个设计会在多个方面重复出现，那么这个设计在我看来可以做成通用设计，各部分调用
冰力恰恰 12:12:17
一样的
冰力恰恰 12:12:38
再大或再小的东西 都一样
做什么事 浪费都是可耻的……
妖狼 12:12:47
粒粒皆辛苦啊
金银铜铁 12:12:53
浪费是必然的
妖狼 12:13:05
把楼上的拖出打！
Susaro 12:13:24
所以 用例驱动 对设计者的要求非常高
Susaro 12:14:20
至于怎么避免修改或者回避修改带来的风险
那属于项目管理里的内容了
Susaro 12:14:36
难道又要把话题转到项目管理？
金银铜铁 12:14:36
对整个项目的认识不足，限于淤泥中不可自拔
Susaro 12:15:01
用例驱动，或者说任何一个方法都不能单独使用，它只是一个一个过程中的一环
冰力恰恰 12:15:04
已经扯到项目管理了 老大
妖狼 12:15:24
没有万能的方法
Susaro 12:15:36
确实由人来操作的东西，就有误差，且无法回避
那么只有用其他方法来 降低风险
猫 12:15:39
恩,浪费是必然的
但如果有什么方法能让程序在编写的时候有意识的再过滤一次
似乎是会好一些
而且对于用例驱动设计者的要求太高也似乎不是好事,特别对于游戏策划来说，在程序的归类上只是个初学者- -
如果能在更多环节上弥补降低要求造成的损失
那么也就能更好的推广这方法
妖狼 12:15:39
不要指望采用一种新的方法就可以改变一个结果
Susaro 12:15:55
不过，暂时到此为止吧，呵呵
项目管理以后再谈
冰力恰恰 12:16:01
猫 提出了新的疑问……
Susaro 12:16:19
猫 说的问题确实存在，且无法用全部用 用例驱动来解决
冰力恰恰 12:16:30
交流沟通 的重要性
Susaro 12:16:41
那么，我们等待以后的讨论了
先吃饭
彼岸花 12:17:11
猫(54677746) 12:15:39
恩,浪费是必然的
但如果有什么方法能让程序在编写的时候有意识的再过滤一次
似乎是会好一些
————主程在评估文档给反馈的时候去过滤，不过实际上很多主程都不这么做
猫 12:17:52
彼岸花(109079043) 12:17:11
这个如果要落实,应该是普通程序的事,如果是主程序的话,不行的,这些细节的问题他把握不了
彼岸花 12:18:37
基本反馈要有，那么就该通读了一遍
如果通读了一遍还没有概念，那……可能我自己阅读理解能力太强了，那就当我没说吧
Susaro 12:19:01
怎么说好呢
我宁愿用白纸
也不用有经验的
因为让有经验的转用例驱动和敏捷开发，太难了
妖狼 12:19:29
我就是有经验的……
妖狼 12:19:40
完蛋了，以后换公司的话没人要了！
彼岸花 12:19:53
冰力恰恰(517030) 12:18:47
其他人 都懒得去了解 用例驱动 是什么
————因为了解了在国内绝大多数公司也不用
Susaro 12:20:34
不，妖狼
你强的是 理念 和 思想核心
这是你的年龄优势造成的
所以你不用担心
妖狼 12:21:00
啧啧
冰力恰恰 12:21:05
一家公司假设有10个开发工作室
可能只有1个用用例驱动
也可能只有1个用敏捷开发
Susaro 12:21:40
没这么高的比例
Susaro 12:21:56
游戏开发公司，几乎没有
软件开发公司，有部分用
冰力恰恰 12:21:58
那就 100个开发工作室
2个用例 2个敏捷
妖狼 12:22:06
……
|
|
发表于 2007-7-25 23:03:00
楼主
