敏捷开发中软件与文档的思考
来源:互联网 发布:centos 6 搭建hadoop 编辑:程序博客网 时间:2024/05/21 20:14
也曾尝试过,不带文档的“裸体”前进,可想而知,最后经常造成项目的返工,新来的人员要拼命读以前的人留下的几乎没有注释的源码。
后来尝试过,制订完善的规范,用了大量的软件开发文档模板,可惜仍然无法减轻开发者的负担,另一方面令人尴尬的是,情况并没有比不带文档好多少,因为在项目的实施中,很少有文档与软件能够完全同步的。一份简单的需求文档从项目开始到项目结束,往往会改动得面目全非,在此同时,要花费专门的软件开发人员去整理文档,不得不说是一种资源浪费。
与其做着虚假的文档,穿着皇帝的新衣,不如就干脆裸体,这是我的想法,但一直没这个胆子去实施。
不知是谁说过:软件=程序+文档,我持一半的赞同一半的不赞同,软件最终就是要给用户用的东西,用户只要用了满意,就是一个好软件,不满意就不是好软件。对于用户来说,他需要付出的是软件的费用,另一部分软件开发过程中的文档等,是公司为了产品以后的升级、维护、扩展而准备,用户没有义务为此付费。
一直以来,我们都采用Case工具,采用UML图进行交流,有时候尽是这些工具很难满足我们的需要,我们也会想尽一切办法去表达自己的意思。使用了这些工具后,我的感觉是,大家都已经由原来的正常人变成了哑巴。有时候,明明一句话可以解决问题的,却要比上半天的手势。
新技术与新工具的采用,带来的应该是人与人之间更通畅的信息交流,如果效果正好相反,那么我们不得不考虑一下,为什么会这样。
直到接触敏捷开发,才觉得开朗了一些,软件开发尽管没有银弹,但在不同的形势下,总有合适的方法来让开发人员爬出焦油坑外。
在《 敏捷建模 极限编程和统一过程的有效实践 》这一本书上,开头作者就指出了,他们在快速交流中,并不使用Case工具,他们使用的不过是几张纸片,而且抓了支笔就开始画草图,甚至,在书中的后半部分,在设计用户界面时,也居然是用草图画出来的。
也许我看起来很可笑,但是说实话,我真的没有这样去做。向来我都认为,严格地管理,严格地遵循规范才能够出高质量的产品,现在看来,好像是我误解了些什么东西。软件设计的目标是成功开发出一个成品,让用户可以使用它。
在做项目的过程中,我们往往过份关注了软件的扩展性与易用性,以致于过度的分析需求,不但提供了一些用户用不着的功能,也让用户投入了不需要花费的资金,同时,我们还浪费了大量的时间。
在XP实践中,有许多实践是令人兴奋的,不说其它的,虽然XP中不反对文档,但根据它的思想,给了开发人员一个尽量少写或不写文档的借口。 我一直没有机会去实践结对编程,但直觉上认为它是一个好东西,虽然并不相信,可以提高百分之几十的效率,但软件的开发毕竟是一个脑力活动,做个小功能,转换一下思路,是一个好办法。
但结对编程中,有一个让我迷惑不已的地方:一般而言,人要进行做某事,要进入状态,大约要15分钟左右的启动时间,然后,无论是任何打扰(包括电话,有人问话),都会造成思路的中断,从而使得人要重新调整状态,这又有几分钟的时间耗费。我不认为这样会使得人更专注(有人在旁边监视也一样)。
因为没有绝对编程的经验,所以也不过妄言几句。
后来尝试过,制订完善的规范,用了大量的软件开发文档模板,可惜仍然无法减轻开发者的负担,另一方面令人尴尬的是,情况并没有比不带文档好多少,因为在项目的实施中,很少有文档与软件能够完全同步的。一份简单的需求文档从项目开始到项目结束,往往会改动得面目全非,在此同时,要花费专门的软件开发人员去整理文档,不得不说是一种资源浪费。
与其做着虚假的文档,穿着皇帝的新衣,不如就干脆裸体,这是我的想法,但一直没这个胆子去实施。
不知是谁说过:软件=程序+文档,我持一半的赞同一半的不赞同,软件最终就是要给用户用的东西,用户只要用了满意,就是一个好软件,不满意就不是好软件。对于用户来说,他需要付出的是软件的费用,另一部分软件开发过程中的文档等,是公司为了产品以后的升级、维护、扩展而准备,用户没有义务为此付费。
一直以来,我们都采用Case工具,采用UML图进行交流,有时候尽是这些工具很难满足我们的需要,我们也会想尽一切办法去表达自己的意思。使用了这些工具后,我的感觉是,大家都已经由原来的正常人变成了哑巴。有时候,明明一句话可以解决问题的,却要比上半天的手势。
新技术与新工具的采用,带来的应该是人与人之间更通畅的信息交流,如果效果正好相反,那么我们不得不考虑一下,为什么会这样。
直到接触敏捷开发,才觉得开朗了一些,软件开发尽管没有银弹,但在不同的形势下,总有合适的方法来让开发人员爬出焦油坑外。
在《 敏捷建模 极限编程和统一过程的有效实践 》这一本书上,开头作者就指出了,他们在快速交流中,并不使用Case工具,他们使用的不过是几张纸片,而且抓了支笔就开始画草图,甚至,在书中的后半部分,在设计用户界面时,也居然是用草图画出来的。
也许我看起来很可笑,但是说实话,我真的没有这样去做。向来我都认为,严格地管理,严格地遵循规范才能够出高质量的产品,现在看来,好像是我误解了些什么东西。软件设计的目标是成功开发出一个成品,让用户可以使用它。
在做项目的过程中,我们往往过份关注了软件的扩展性与易用性,以致于过度的分析需求,不但提供了一些用户用不着的功能,也让用户投入了不需要花费的资金,同时,我们还浪费了大量的时间。
在XP实践中,有许多实践是令人兴奋的,不说其它的,虽然XP中不反对文档,但根据它的思想,给了开发人员一个尽量少写或不写文档的借口。 我一直没有机会去实践结对编程,但直觉上认为它是一个好东西,虽然并不相信,可以提高百分之几十的效率,但软件的开发毕竟是一个脑力活动,做个小功能,转换一下思路,是一个好办法。
但结对编程中,有一个让我迷惑不已的地方:一般而言,人要进行做某事,要进入状态,大约要15分钟左右的启动时间,然后,无论是任何打扰(包括电话,有人问话),都会造成思路的中断,从而使得人要重新调整状态,这又有几分钟的时间耗费。我不认为这样会使得人更专注(有人在旁边监视也一样)。
因为没有绝对编程的经验,所以也不过妄言几句。
- 敏捷开发中软件与文档的思考
- 敏捷开发学习总结(3): 思考开发文档的利与弊
- 敏捷开发学习总结(3): 思考开发文档的利与弊
- 敏捷软件开发思考:与客户一起开发的现实问题
- 敏捷开发中文档的取舍
- 11月27日“软件开发模式思考:传统与敏捷 我们在什么位置?”的主题活动成功举办
- 关于敏捷开发的思考
- 自我管理与敏捷软件开发
- Android软件开发的痛苦与思考
- 软件开发的吐槽与思考
- 软件开发中思考的重要性
- 敏捷开发过程中如何开发高质量的软件
- 敏捷开发过程中如何开发高质量的软件
- 敏捷开发过程中如何开发高质量的软件
- 敏捷软件开发-软件开发的不二法门
- 《敏捷软件开发 原则、模式与实践》的读书笔记
- 敏捷软件开发:原则、模式与实践的学习笔记
- 敏捷开发下的软件架构设计与持续优化
- 分几个层,慢慢细分,写代码。
- SOAP中复杂类型(JavaBean)调用实例实践
- Alpha混合代码
- DirectDraw编程基础(zz From GameRes Blog)
- 对在中国推广Linux的一些看法(ZT)
- 敏捷开发中软件与文档的思考
- [转贴]透视"XML中间件"
- 敏捷开发方法的一个list
- 新的一年即将开始,先总结这一年
- 回家过年了
- Asp.Net常用函数
- MS SQL Server SQL语句导入导出大全
- SQL Server日期计算
- 我们拿计算机来拆,去研究里头有什么,把核心的软件剖析一下,怎么写的,这样我就会Basce汇编语言了,我就可以去讲Basce和汇编的课了。为研究计算机怎么上显示器,我就去研究,当时我们的那台显示器