+1 投票
分类:项目管理 | 用户: (620 分)

敏捷开发的常见误区之九:敏捷是反文档的。 

文档只是为了达成目标的一种手段,如果这种手段是低效的,那就换一种手段。可是完全抛弃了文档,怎样解决沟通的问题?难道你想每次沟通都完全用手比划,用嘴说,跟不同的人重复表述同样的想法,那样更是低效的。 

应该清楚文档的本质是把知识显性化。在一个项目中存在很多需要沟通的知识,知识具备两种形态,显性的和隐性的,传统的观念是尽量把隐性知识显性化,即文档化,而忽略了这其中的代价(特别是更新同步文档的代价)。  

因此,在实施敏捷的时候,需要在团队内明确哪些知识是必须显性的,这些知识可以通过文档交流。哪些知识是可以隐性的,这些知识则完全可以通过口头的方式进行交流,以达到沟通的最佳效率。 

文档不是目的,有效沟通才是目的。

就工作量而言,不写文档,减少写文档时间,看起来确实可以加快开发速度,但实际会严重伤害项目。互联网应用开发不需要似传统大型软件开发那样,按照软件工程,花大量时间去写文档。不要为了写文档而写文档,而是为了开发而写文档。

例如需求文档(或者功能文档-可以含有版本信息,业务流程文档,互通操作文档),无论具体形式如何,需要清晰地给出你的应用针对什么,提供什么,解决什么。需求文档有时也可以作为测试的指导。如果是client+server,你需要给出本期目标的性能,可以简单到一两页纸,但是绝对不能缺。在迭代开发中,你不断地修改它,它是你开发的轨迹。

例如开发文档,不一定要什么概要设计、详细设计这类学院派的东东,但是你需要有文档能够清晰描述开发对象的架构,模块划分,client和server的交互流程,以及关键的核心技术,例如,如何避免client和server中过多连接造成的server压力,为何采用长连接tcp而非upd(反之亦然),如何制定心跳,是否需要通过使用底层的socket进行特定优化等等。你至少需要从架构师的角度对产品进行梳理,描述实现的架构、采用的机制和关键技术。开发文档或繁或简,甚至可以在代码中通过注释说明,利用javadoc生产HTML,格式不论。

不要让文档成为开发的负担,而是成为帮助。现在工作的流动性很大,没有文档,当中一两个开发人员离职,如何后续处理。没有开发文档,在架构和关键技术上没有想清楚,贸然而上,开发的永远只是个demo产品。

没有任何文档,极容易导致推出后,疲于奔命地修修补补,每天一个版本。敏捷开发是快,但是快不等于敏捷开发。

你的回复

昵称(可选):
隐私:你的邮箱仅用于接收通知,不会被公开。
欢迎来到 Ogeek|极客中国 ,有什么不懂的可以尽管在这里话题,你将会收到社区其他成员的回复。
...