请用 Safari 11+、Firefox 60+ 浏览
我的文章 我的评论 我的书评 我的知乎*
书单 书讯 书评
需求知识体系 特性 用例 统一用例方法 用户故事 需求工具
业务建模 UML OOD
敏捷知识体系 敏捷方法 敏捷问答 敏捷工具 敏捷评论 敏捷资源
业务模式 需求模式 架构模式 设计模式 大道至简:实话设计模式 Web 应用架构模式
.NET Java JS 笔记
Amazon* ITPub* Martin Fowler* Wikipedia* 教程
需求分析需求模型非功能需求业务需求分析
SpringJSF
> >
在线/45 登录/0

建立敏捷统一过程框架(评论)

阅读数:4568
基本

非常感谢 HP Partner Portal 敏捷论坛 诸 网友对本人文章《建立敏捷统一过程框架》的转载讨论与支持! 其中有不少有意思的话题,现引用、点评如下。

wolfkiefer 2005-11-01 08:56:49

看到有篇好文章,作者有自己的独特想法,其中一些内容也特别有利于初学者对一些概念的理解,故转贴过来

三板斧 2005-11-01 10:24:01

标注出处比较好,既是对作者的尊重,有些图形看起来也方便一些! 是一篇好文摘,特别是强调了传统方法和敏捷方法的相互关系,也很象 debug 提到的"大象和猴子"的隐喻. 正在学习中,更希望有好的项目实践!

老蒋 2005-11-01 12:29:51

记得以前看过一个 UP 裁减后并融合 XP 的过程,叫做 dx (把这两个字母完全倒过来就是 xp) UP 即使裁减了,也很难过 use case 这一关,use case 看似定义很简单, 但用起来尺度很难把握,有无数部著作专门讲 use case 该如何划分,如何描述的。在分析整理 use case 的时候非常容易把大量的精力耗在整理 use case 上,而不是与用户沟通明确需求。 在这个角度上如果想快速有效改善过程的话,还是建议使用 Feature 驱动,使用起来比较方便。 不过 use case 的追踪性的确是非常之好,由 use case 可以追踪到设计,编码,测试,部署的各个制品, 当然这需要大量的模型和文档。在一些要求完全可控的关键项目中,use case 的力量是非常大的。

(恂:的确,用例是 UP 的一个关键特征。关于用例的粒度划分并不存在什么“无数部著作”, 就在一本书里 Cockburn 的《Writing Effective Use Cases》中已经讲得很明白了,大概也就几页纸。能否 掌握,关键在于认真地学习。

“把大量精力耗在整理用例上,而不是与用户沟通明确需求”这恰好是用例分析中的一个反模式,熟练的需求分析师会 避免这样做。 而明确用户的功能需求,具体要做的事主要表现为如何去发现遗漏的用例、丰富用例的基本内容、发现更多的 扩展条件和扩展流等工作,在许多项目中仅把需求表达为 Feature 是远远不够的。

Feature 确实比较方便,但也存在精度不够、结构性差等缺点。之所以要用用例,也正是为了弥补这些缺陷。 完整描述的用例可以很方便地导出测例(test case),写到这种程度的软件需求是真正合适的尺度。 Feature 同样可以有很好的跟踪性,事实上用例可以跟踪到特性。建立需求跟踪链、跟踪矩阵并不一定需要大量的 模型和文档,简单的可以用 Excel 或 Access 数据库来管理一些简易表格。Feature 和 Use Case 都可以 敏捷地来用,就像在 Bob 大叔那本讲敏捷的书里。)

加菲猫 2005-11-01 15:10:04

“没有规矩,不成方圆”,对于软件开发这种团队作业的工作,没有一套过程规范去进行管理确实是很难做好的,但是找到一套合适自己的过程规范却不是件容易的事情。

Kitty 2005-11-03 09:31:42

现在有些人盲目追求某种开发模式,大大贬低其它模型,其实每种模型都有它的利、弊, 只有充分了解它们的实质内容,结合使用,才能发挥最大的作用。 1)首先 CMM/CMMI, 这套模型列出了影响一个项目质量的关键内容,如: 模型认为应该好好做项目策划、做用户需求调研、系统需求调研、总体设计、详细设计、测试、要过项目进行风险控制、产品和过程的监控、配置管理等,它认为只要把这些方面处理好,就可以开发出高质量的产品,模型中没有给出某种方法,即怎么去做,它只是指供一种思想。师傅领进门,修行靠个人:) 2)RUP 的思想非常好,不过就象老蒋说的,use case 的道路还很漫长, 我们刚开始用 RUP 的时候就只用了它管理上的思想,如:架构设计、迭代增量。不过也起到了不错的效果。 3)敏捷开发,现在大家都很推崇敏捷开发,敏捷开发的思想确定不错, 但个人认为敏捷开发关注的技术方面较多,而管理方面关注的较少, 如果在项目中运行,尤其在大规模项目中则还需要将其它模型的内容融合在一起, 如敏捷开发对版本的控制要求比较高,所以配置管理很重要,应该引入进来。 4)最后,指出文档中不太同意的一个观点:“大量项目严重拖延、产品迟迟不能交付, 究其根本原因往往是与错误运用了存在明显缺陷的瀑布模型有关”, 个人认为瀑布模型本身并没有错,对于小规模项目、需求比较明确、周期比较短,采用瀑布法是个很好的方法。
(恂:非常赞同第一句。

“use case 的道路还很漫长”其实是一种误解,对用例的历史、技术特点不了解。 用例本身是很成熟的技术,关键在于我国程序员能否虚心的学习。

迭代、瀑布不是对和错的问题,不存在绝对的对与错,只有适用、不适用的问题。 问题是,国内许多项目表面上“需求比较明确”,实际上是很不明确,需求往往分别 存在于客户、开发商、程序员的脑子里,大家口头上说“懂了懂了、明白明白”,而这样的糊涂需求是无法验证的。 国外研究表明,实际上适用经典瀑布法的理想、稳定的项目环境在现代商业、工业条件下是很少的。)

jonah 2005-11-03 10:25:09

所有的方法都存在互相学习的地方,也有落实到实际的问题,包括组织的设计,流程设计,文档的规范,沟通的方式,大家都在再设计。所以理解理念的核心价值是主要的,不要把一个东西看到死。

老蒋 2005-11-03 16:28:43

UP 中最痛的莫过于 use case,技术人员会主要精力会陷入如何划分 use case, 如何表述 use case 这些细节,而忽略了需求本身。 对比一下,还是 feature 更容易掌握一些,跟客户沟通的效果也好于 use case, 甚至于你做了第一版的 feature 列表,用户会自己修改补充。 不过如果已经把 use case 做为驱动项目的标准了话,需要给分析设计人员一些详细的培训,包括: 1.use case 的层次 2.use case 的尺度 3.use case 的描述方法 4.划分 use case 的原则 4.最好有一个不大不小的案例,案例太小,没有效果。

(恂:什么是“需求的本身”?需求只有两种,功能需求和非功能需求。 功能需求的本身就是 use case,用例的划分和细节 当然是很重要的啰,不然需求分析分析啥?用例不够细,你怎么做测试?

用 feature 的好处是属于传统做法,大家比较习惯,但存在的问题是也是传统的,容易留下一大堆 feature,却不知道用户到底要什么,具有“只见树木、不见森林”之功效。而且,feature 的粒度可能 更难把握吧,大大小小的需求都可以叫需求!这时候,基于目标的用例就派上用 场了,通过找到海平面用例,可以显著减少“需求”的数量。

极其赞成老蒋关于用例培训的建议!建议读者首先可以选择自学,如果自学实在吃力,再找外援也是不错的选择 :-)

老蒋 2005-11-03 16:44:13

1.CMM 不是软件过程方法,是软件度量标准。 2.敏捷开发对管理方面是非常关注的。敏捷首先关注的人的管理,组织方式更积极,考虑到一些人性的弱点对组织方式进行改进,充分发挥人的主动性。 如果说配置管理这个层面,其实 FDD 的实践其中就一个就是配置管理,不过需要根据项目的需要确定配置管理的范围。

wolfkiefer 2005-11-03 12:14:59

非常同意 kitty 的这些观点,但是对"敏捷开发,现在大家都很推崇敏捷开发,敏捷开发的思想确定不错,但个人认为敏捷开发关注的技术方面较多,而管理方面关注的较少"这句话,不知道怎么理解,这里说的技术是指管理的技术还是开发的技术问题?还是什么什么技术?

Shaq 2005-11-03 17:06:26

敏捷促成了很多具体的技术方法。但是敏捷从本质上看,最关注的不是技术,而是管理。 这个可以从敏捷宣言得到验证。而且实际上,XP,FDD,Scrum 这些都是管理方法。

(恂:不准确。Scrum 主要是项目管理方法,与具体技术无关,但 XP、FDD 则包含了具体的工程技术方法,如 重构、持续集成、TDD、对象建模等。敏捷宣言和原则对敏捷的管理和技术实践都是强调的。当然,敏捷要成功,关键是实现企业管理、文化、观念和价值观的转变。 )

<帮助> <全部评论> 共 0 个主题 0 条评论 (aupfcomments)
首页 | 使用指南 | 站点地图 | 版权声明 | 联系方法 | © 2005-2018 张恂 版权所有. 沪ICP备05023401号