BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

敏捷方法需要文档吗?

| 作者 Geoffrey Wiseman 关注 0 他的粉丝 ,译者 乔梁 关注 7 他的粉丝 发布于 2007年7月21日. 估计阅读时间: 3 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

有些人认为敏捷不需要文档,甚至不支持任何形式的文档化。在CIO杂志上的一个敏捷案例研究中声称,这是一个误解。Frans Bourmar最近写了一些关于敏捷方法与文档化的内容 ,而Ian Cooper据此写道:“该是'拨乱反正'的时候了”。

Ian 首先从敏捷宣言讲起。敏捷宣言指出有价值且可工作的软件胜于详尽的文档。他指出,敏捷宣言是一套基本原则和标准,用于检验某个过程是否敏捷,而不是一个具体的方法论。他以下面三种开发过程方法为例,来解释这些原则是怎样发挥作用的:

要理解这个警示,必须记住非敏捷方法论常有文档驱动开发的特征,因为在写代码之前,它需要以大量的文档作为输入。很多情况下,软件开发团队执行相应的过程步骤,只是因为方法论要求他们这样做,尽管它们几乎没有什么价值。结果,很多开发团队完全放弃了这些方法论。敏捷试图避免漫无目标的文档产物,而再次把焦点放在软件开发过程的关键产物上,即代码。不幸的是,很多人没有认识到应该抛弃什么,从而使那种即兴而为式或纸上谈兵式的有限文档成了目标,这些人基本上没有对瀑布式过程(如SSADM)进行完整的实践。

回想一下水晶方法是如何处理文档:

水晶方法把开发看作是一系列的协作游戏,而写文档的目标就是只要能帮助团队在下一个游戏中取得胜利就行了。水晶方法的工作产品包括用例、风险列表、迭代计划、核心领域模型,以及记录了一些选择结果的设计注释。水晶方法也为这些产品定义了相应的角色。然而,值得注意的是,这些文档没有模板,描述也可不拘小节,但其目标一定要清晰,那就是满足下次游戏就可以了。我总是将这些思想以下面的方式向我的团队成员表达:通过它们,你只要了解你明天加入这个团队所要知道的内容就行了。

极限编程是如何对待文档的呢?

与水晶方法相比,XP认为在团队内外,文档都不必太多,并把它看作是需要交付给客户并由客户付费的故事。我觉得这样做的目标就是通过与其它特性集合进行对照评估,来减少多余的文档数量。XP更依重于开发人员之间的直接交流来传递相关的知识而不是依靠写好的文档,而结对编程使其成为可能:因为通过结对,你就可以和其它人分享对系统的理解,而消灭“死角”,也就很少需要文档来记录这些知识了。另外,代码与测试也被看作是描述软件实现细节的文档,它没有更新不及时的问题……总而言之,就是团队必需的东西或者客户想要的东西。

在你的敏捷项目中,应该有多少文档呢?对你来说,多少算多,多少算少呢?

查看英文原文:Do Agile Methods Require Documentation?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讲讲了 by zhou Glamey

这个说的是什么呢 ,能给我讲讲吗?我现在也是正在研究java,比较感兴趣哈。

只写有价值的文档 by Jacky Li

对于那些无谓的需求,设计文档,要保持同步是非常浪费的一件事情。所以还是写该写的东西,比如Story Card,不也是文档么?

最痛恨的就是为了应付什么CMM或者CMMI的评估来写文档,tnnd,评你MB!估你MB!

文档是必须的。 by 竹十一 Julian0zzx

即使是在XP中,文档也是必须的,成文的东西总是要比口头的东西来的实在!
考虑极端的情况,如果小组的人全都离职了,这时候软件如何更新呢?总不能天天电话里跟那些离职的员工XP吧?
我觉得关键在度的问题。文档要适度,不能成为小组工作的累赘,又要做到出现争议的时候有具可查。
在我看来,至少有两份文档是必须的:需求文档和概要设计(Requirement and High Level Design)。需求文档的目的是告诉大家,我们开发的软件要做成什么样子要实现那些功能,这份文档应该是经常更新的,记录XP过程中最新达成的结论。概要设计的用处是让同志们在XP的过程中不会脱离开轨道,天马行空是没错,可马儿总得奔着青草跑吧?至于在细枝末节上的东西XP的过程能解决的很好。
其实还有一份文档如果有,可能会效果更好,这份文档就是关于UI的文档。可用性(usability)对一个软件来说非常非常重要,就跟大家都喜欢美女帅哥一个理由。相比较来说这个文档可能只是个demo和一些简单的说明,它应该是很XP的。

Re: 文档是必须的。 by Jacky Li

我也不否认应当要有必要的文档,但是Story card加上充分的测试用例能不能代替需求文档呢?毕竟要保持文档的同步是非常痛苦的一件事情,除非可以弄一个CM专门做这件事情。

Re: 文档是必须的。 by He Yiding

如果成员离开后你还必须联系他们才能继续工作,那说明他们留下的代码很糟糕,以至于看都看不懂。

Re: 文档是必须的。 by Jacky Li

对啊,就是这样子

Re: 文档是必须的。 by lee tom

完全同意。的确,文档是必须的。
项目开发很大程度上是探索和管理的过程。
没有文档,常常没有有效的累积,没有进一步改进的基础。逃避文档,往往是在逃避清晰准确的表达需求和目的的努力,逃避由于“白纸黑字”所带来的责任。
文档应该精简,目标和思路最重要。文档应该分为多种层次和形式,应用场景描述、需求分析、架构设计、业务/流程建模、项目包、代码结构、方法名、注释、第三方包文档等都是文档。不同层次和形式的文档适合于表达不同的内容,在不同的条件、策略下保持更新。
经过梳理和提炼的需求和设计文档至关重要,想想面对客户,你怎么和他沟通;新成员加入,你让他顺着什么思路快速了解情况,把握轻重...
毕竟,不是每个人都有着同样的思维,就是我们自己,也需要不断的清理、释放,才能放心的不断前进。

Re: 文档是必须的。 by dmhorse dmhorse

不同意楼上的,面对客户,他们根本不愿意看这些所谓需求文档和设计文档,与客户沟通的方式最好是在短时间内拿出可运行的软件,或者prototype(UI)

CMMI要求的文档大多被SEPG组织理解后,建立一套庞大但低效的文档库,让程序人异常痛苦

新人进来最好的方法是XP和交流,而不是单纯看一堆几百页的文档,看过的人,有多少新人能真正理解了呢?

我觉得User Story是最能表达需求的写法,在撰写User Story也会去努力的消除所有的假设,但一字一句将所有细节撰写下来,太浪费时间了,特别是保持文档同步,如果CMMI需要,让product manager去弄吧

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

8 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT