- 浏览: 155830 次
- 性别:
- 来自: 南京
最新评论
-
luhantu:
人才啊兄弟!
JAVA在线api -
congpeixue:
不评不行
如何唱好卡拉OK -
yunmoxue:
TMD...好!
(转)什么才是软件开发的葵花宝典? -
snow8261:
不错,学习了
cygwin使用心得
敏捷的文档
作者 滕振宇 发布于 2009年2月23日 下午8时42分
软件项目中有很多种文档,包括需求文档、设计文档、API文档、缺陷报告、进度报告、移交文档、验收文档等等。
在传统的软件项目开发中,每个团队成员都要花费很多时间和精力去维护文档及填写各种表格和报告。第二条敏捷宣言是"可工作的软件胜于详尽的文档",据此很多人想当然认为敏捷开发不重视文档。更有甚者,有人为逃避写文档而借口敏捷开发不需要文档,成为所谓的PAP(Pretty Adventuresome Programming)。其实这些人忽略了敏捷开发中有很多实践(比如坐在一起、现场客户、测试驱动开发、客户测试、结对编程、信息化工作间等等),敏捷借助这些实践进行信息交流,起到了文档在传统软件开发中的作用。本文通过分析项目开发中的文档类型与作用来说明敏捷开发中为什么很多文档是不需要的。
首先,需要明确文档的用途,文档是用来交流信息的。关键是团队中信息分享是否及时准确,而这与文档的多少没有必然的联系。就比如James Shore在博文"文档之谜"(http://jamesshore.com/Blog/The-Documentation-Myth.html)里面指出的,很多人指责敏捷开发的文档不够。其实他们忽略了问题的实质,"丰富的文档并不一定是好事,能及时得到答案才是好的"(Myth: Document is good; Reality: Answer is good)。
专业知识或者信息主要分为两类:
* 可以被整理,文档化的知识,一般只占所有知识的30%。
* 占70%的存在于人脑中的隐含(Tacit)知识,只能通过人与人之间的交流来分享,口口相传。因此促进团队内部以及团队之间的交流对信息的传播更加有效。
软件项目文档通常有三种:
* 项目文档,用于项目组内部信息交流,比如需求文档、设计文档、进度报告等。
* 产品文档,通常是有业务价值的,是客户需要的,比如用户手册或者API文档。
* 移交文档,在项目移交或者项目不同阶段之间移交的成果物。
产品文档是客户需要的,是产品的一部分,有业务价值,绝对不能省略。应该在迭代中为其安排一个文档任务。
从敏捷角度来看,另外两类文档中的很多种是可以简化或者省略的。
在敏捷开发过程中,
* 整个团队坐在一起,移交文档变得多余了。精益思想认为移交(Transportation)是很大的一种浪费(参见Mary Poppendieck,精益思想的原则 http://www.poppendieck.com/papers/LeanThinking.pdf),首先移交文档会花费很大的精力,其次很多信息会在移交过程中丢失,另外每个阶段还总会添加一些新的信息。所有团队成员(PO, Dev, QA, Doc)坐在一起,用白板进行面对面的沟通,既省时又省力,还有效。(参见Alistair Cockburn,敏捷项目中的沟通 http://www.agilemodeling.com/essays/communication.htm)
* Product Owner跟团队坐在一起,随时回答团队成员的需求问题,是活的文档。
* 在Sprint计划会议中,团队选择要完成的用户故事(Sprint Backlog上的小卡片),形成Sprint backlog,这其实就是迭代计划。
* 在发布计划会议中,Product Owner会确定发布内容,形成故事墙,这其实就是较为长期的开发计划。
* Dev 和QA一起设计客户测试(一般用Fit类工具)。重要的用户逻辑被设计成客户测试。这种需求(客户测试)是可以运行的,因此永远不会过时(如果出现问题,持续集成系统立刻就会发出警报)。这比传统意义上的需求文档要有效得多。传统文档有太多的问题,比如很少会有人去测试文档的正确性,很少有人去及时更新文档,很少有人去检查需求覆盖率(其实根本没有办法检查,很多工具想当然的提供一些从需求到实现的追踪,但这岂不又是一种形而上学?)。
* 在开发中微观的具体的逻辑可以设计成TDD(或者BDD,行为驱动开发http://behaviour-driven.org/))的用例,起到了详细需求文档或者设计文档的作用。
* 开发人员使用结对编程(很多好处,参见"我喜欢结对编程" http://www.nomachetejuggling.com/2009/02/21/i-love-pair-programming/,以及 "结对编程:到底有多重要?"http://xprogramming.com/blog/2009/01/28/pair-programming-how-important-is-it/)。健康的系统架构应该是动态的,不断演进的。因此如果把它用文档固定下来,也会出现过期或者不全面的问题。在设计具体模块的时候,团队利用白板设计大体框架并确定方向,然后通过结对编程来具体实现。通过结对编程,可以很好的在团队中分享和演进系统架构信息。
* 团队在每日站立会议中汇报进度,更新状态以及遇到的问题,所有信息会立刻反映到Sprint Backlog,Burdown chart以及各种图表上,成为信息化工作间的一部分,团队可以据此进行自我调整。
* 每一次迭代之后举行反省会议,团队自我改进,也可以设计各种各样的手画表格(Ron Jeffries在个人网站上给了一些例子,http://www.xprogramming.com/xpmag/BigVisibleCharts.htm)来监控团队自身的问题。因此传统的审查及统计的文档就变得多余了。
* 敏捷中高层次的需求通过愿景(Vision)文档体现,这种文档一般只有一页,变化的可能性不大,很容易维护。
* 高层的系统架构图还是必要的。这种高层次系统架构变化的可能性也是很小的,维护成本也比较低。
* 代码即文档。很多敏捷大师十分注重架构清晰度以及代码的可读性(比如Robert Martin总结的S.O.L.I.D原则,Robert Martin的Clean Code,以及Kent Beck的"实现模式")。在某种意义上我们写的代码其实就是指导计算机完成任务的式样书。式样书就是为了让别人容易读懂(要不然为什么不用二进制去编写程序,放到机器上就可以运行)。
正如James Shore总结的,获得信息的手段有很多。
最优的手段,代码清楚、单元测试完备、命名规范,因此根本不需要问;
其次,只需要问一下旁边的人,或者打一个电话,就可以立刻得到答案,这也就是为什么敏捷鼓励“坐在一起”和“现场客户”r;
再次,Google一下找到答案,这也不错;
……
很次,可以通过读文档找到答案。可是为了找到答案,需要读的文档越多,效果越差...
作者 滕振宇 发布于 2009年2月23日 下午8时42分
软件项目中有很多种文档,包括需求文档、设计文档、API文档、缺陷报告、进度报告、移交文档、验收文档等等。
在传统的软件项目开发中,每个团队成员都要花费很多时间和精力去维护文档及填写各种表格和报告。第二条敏捷宣言是"可工作的软件胜于详尽的文档",据此很多人想当然认为敏捷开发不重视文档。更有甚者,有人为逃避写文档而借口敏捷开发不需要文档,成为所谓的PAP(Pretty Adventuresome Programming)。其实这些人忽略了敏捷开发中有很多实践(比如坐在一起、现场客户、测试驱动开发、客户测试、结对编程、信息化工作间等等),敏捷借助这些实践进行信息交流,起到了文档在传统软件开发中的作用。本文通过分析项目开发中的文档类型与作用来说明敏捷开发中为什么很多文档是不需要的。
首先,需要明确文档的用途,文档是用来交流信息的。关键是团队中信息分享是否及时准确,而这与文档的多少没有必然的联系。就比如James Shore在博文"文档之谜"(http://jamesshore.com/Blog/The-Documentation-Myth.html)里面指出的,很多人指责敏捷开发的文档不够。其实他们忽略了问题的实质,"丰富的文档并不一定是好事,能及时得到答案才是好的"(Myth: Document is good; Reality: Answer is good)。
专业知识或者信息主要分为两类:
* 可以被整理,文档化的知识,一般只占所有知识的30%。
* 占70%的存在于人脑中的隐含(Tacit)知识,只能通过人与人之间的交流来分享,口口相传。因此促进团队内部以及团队之间的交流对信息的传播更加有效。
软件项目文档通常有三种:
* 项目文档,用于项目组内部信息交流,比如需求文档、设计文档、进度报告等。
* 产品文档,通常是有业务价值的,是客户需要的,比如用户手册或者API文档。
* 移交文档,在项目移交或者项目不同阶段之间移交的成果物。
产品文档是客户需要的,是产品的一部分,有业务价值,绝对不能省略。应该在迭代中为其安排一个文档任务。
从敏捷角度来看,另外两类文档中的很多种是可以简化或者省略的。
在敏捷开发过程中,
* 整个团队坐在一起,移交文档变得多余了。精益思想认为移交(Transportation)是很大的一种浪费(参见Mary Poppendieck,精益思想的原则 http://www.poppendieck.com/papers/LeanThinking.pdf),首先移交文档会花费很大的精力,其次很多信息会在移交过程中丢失,另外每个阶段还总会添加一些新的信息。所有团队成员(PO, Dev, QA, Doc)坐在一起,用白板进行面对面的沟通,既省时又省力,还有效。(参见Alistair Cockburn,敏捷项目中的沟通 http://www.agilemodeling.com/essays/communication.htm)
* Product Owner跟团队坐在一起,随时回答团队成员的需求问题,是活的文档。
* 在Sprint计划会议中,团队选择要完成的用户故事(Sprint Backlog上的小卡片),形成Sprint backlog,这其实就是迭代计划。
* 在发布计划会议中,Product Owner会确定发布内容,形成故事墙,这其实就是较为长期的开发计划。
* Dev 和QA一起设计客户测试(一般用Fit类工具)。重要的用户逻辑被设计成客户测试。这种需求(客户测试)是可以运行的,因此永远不会过时(如果出现问题,持续集成系统立刻就会发出警报)。这比传统意义上的需求文档要有效得多。传统文档有太多的问题,比如很少会有人去测试文档的正确性,很少有人去及时更新文档,很少有人去检查需求覆盖率(其实根本没有办法检查,很多工具想当然的提供一些从需求到实现的追踪,但这岂不又是一种形而上学?)。
* 在开发中微观的具体的逻辑可以设计成TDD(或者BDD,行为驱动开发http://behaviour-driven.org/))的用例,起到了详细需求文档或者设计文档的作用。
* 开发人员使用结对编程(很多好处,参见"我喜欢结对编程" http://www.nomachetejuggling.com/2009/02/21/i-love-pair-programming/,以及 "结对编程:到底有多重要?"http://xprogramming.com/blog/2009/01/28/pair-programming-how-important-is-it/)。健康的系统架构应该是动态的,不断演进的。因此如果把它用文档固定下来,也会出现过期或者不全面的问题。在设计具体模块的时候,团队利用白板设计大体框架并确定方向,然后通过结对编程来具体实现。通过结对编程,可以很好的在团队中分享和演进系统架构信息。
* 团队在每日站立会议中汇报进度,更新状态以及遇到的问题,所有信息会立刻反映到Sprint Backlog,Burdown chart以及各种图表上,成为信息化工作间的一部分,团队可以据此进行自我调整。
* 每一次迭代之后举行反省会议,团队自我改进,也可以设计各种各样的手画表格(Ron Jeffries在个人网站上给了一些例子,http://www.xprogramming.com/xpmag/BigVisibleCharts.htm)来监控团队自身的问题。因此传统的审查及统计的文档就变得多余了。
* 敏捷中高层次的需求通过愿景(Vision)文档体现,这种文档一般只有一页,变化的可能性不大,很容易维护。
* 高层的系统架构图还是必要的。这种高层次系统架构变化的可能性也是很小的,维护成本也比较低。
* 代码即文档。很多敏捷大师十分注重架构清晰度以及代码的可读性(比如Robert Martin总结的S.O.L.I.D原则,Robert Martin的Clean Code,以及Kent Beck的"实现模式")。在某种意义上我们写的代码其实就是指导计算机完成任务的式样书。式样书就是为了让别人容易读懂(要不然为什么不用二进制去编写程序,放到机器上就可以运行)。
正如James Shore总结的,获得信息的手段有很多。
最优的手段,代码清楚、单元测试完备、命名规范,因此根本不需要问;
其次,只需要问一下旁边的人,或者打一个电话,就可以立刻得到答案,这也就是为什么敏捷鼓励“坐在一起”和“现场客户”r;
再次,Google一下找到答案,这也不错;
……
很次,可以通过读文档找到答案。可是为了找到答案,需要读的文档越多,效果越差...
发表评论
-
国外java网站---转
2011-07-26 13:45 939http://www.infoq.com/ - Info IT ... -
powerDesigner使用(建索引、自增列、检查设计模型)---转
2011-06-04 14:32 4930模型检查中的Existence of ... -
powerdesigner常用设置1
2011-06-04 14:31 1601重新拾起久违的技术,重新熟悉曾经的工具。 这个是转帖,转载自h ... -
敏捷拥护者眼中敏捷开发的常见问题
2009-03-10 15:55 11401. 技术负债在敏捷团队 ... -
我和敏捷团队的五个约定
2009-03-10 15:54 1254作为测试人员,在敏捷项目中往往是一个孤单的角色,在一般规模的项 ... -
xplanner 在jdk1.6上部署问题
2009-03-06 09:27 2758很早的时候就想尝试使用XPlanner,但是一直都没有成功,感 ... -
adblock plus 中文过滤规则添加
2008-12-08 21:03 5558abp://subscribe/?location=http% ... -
JAVA在线api
2008-12-05 15:28 14085JavaTM Platform Enterprise Edit ... -
wget, 一个强大的下载工具
2008-11-28 14:03 1494如果你认为 wget 只是一个命令行下载工具, 那你就错了, ... -
前端架构blog
2008-11-27 13:11 1176http://www.blogjava.net/OneEyeW ... -
posrtgres命令行下备份恢复数据库
2008-11-27 12:52 1141Backup to Script: 首先切换到postgres ... -
Flex开发必备
2008-10-07 16:12 2733Sean Moore Bio 说道:秋天又一次来临了,是时候回 ... -
oracle
2008-10-07 09:36 779oracle解除锁定用户 alter user usernam ... -
lighttpd+tomcat+squid3.0
2008-09-26 13:23 1393我这里主要是用lighttpd来代替已有的apache2.2. ... -
Beyond Compare 2.x 的注册码和破解方法:
2008-09-10 15:04 8580方法是用UE打开BC2.EXE, 查找以下内容并进行修改。 1 ... -
网页设计标准尺寸:
2008-09-02 13:04 9021、800*600下,网页宽度保持在778以内,就不会出现水平 ... -
fckeditor2.6 for jsp 配置方法
2008-08-11 14:04 14701、首先登陆www.fckeditor.net/downloa ... -
powerDesigner设定identity类型快捷方式
2008-08-06 16:53 2582工具这个东西就是不用则手生!还是找个地方记录下,比较好哦! A ... -
linux中查询raid信息
2008-07-25 09:17 2136有些情况下系统不是自己装的,raid也不是自己配置的,远程登录 ... -
又遇到了同样的问题linux java图形显示
2008-07-22 16:48 1579Java在图形处理时调用了本地的图形处理库。在利用Java作图 ...
相关推荐
pmp项目管理认证-敏捷文档
在Python中结合doctest和Epydoc产生敏捷文档的一种方法
在Python中结合doctest和Epydoc产生敏捷文档的一种方法.pdf
[敏捷无敌][王立杰,.许舟平(著)][电子工业出版社][2009年6月].pdf Kan ban And Scrum-cn.pdf
JEECG 敏捷框架技术文档JEECG 敏捷框架技术文档JEECG 敏捷框架技术文档JEECG 敏捷框架技术文档JEECG 敏捷框架技术文档JEECG 敏捷框架技术文档JEECG 敏捷框架技术文档JEECG 敏捷框架技术文档JEECG 敏捷框架技术文档...
2018 红帽论坛,超过500位客户亲临现场。演讲人 Cui Xiaonan Cloud Infrastructure SA。
敏捷开发敏捷开发 介绍 文档 学习无止境
敏捷开发项目管理软件——禅道官方部署及使用帮助文档 .pdf 敏捷开发-落地实践-持续改进.pdf 敏捷数据.pdf 敏捷管理规范及流程思路指引.rar 敏捷软件交付项目管理.pdf 敏捷软件开发_原则、模式与实践.pdf ...
软件敏捷开发过程文档,包括:需求规格说明等31个文档,覆盖开发全过程
敏捷开发文档总结敏捷开发文档总结敏捷开发文档总结敏捷开发文档总结敏捷开发文档总结
敏捷开发项目文档的为什么和是什么;如何写好用户故事;如何写好设计文档;如何写好代码发布及维护的相关文档;
敏捷开发项目管理软件——禅道官方部署及使用帮助文档 .pdf 敏捷开发-落地实践-持续改进.pdf 敏捷数据.pdf 敏捷管理规范及流程思路指引.rar 敏捷软件交付项目管理.pdf 敏捷软件开发_原则、模式与实践.pdf ...
敏捷开发项目管理软件——禅道官方部署及使用帮助文档 .pdf 敏捷开发-落地实践-持续改进.pdf 敏捷数据.pdf 敏捷管理规范及流程思路指引.rar 敏捷软件交付项目管理.pdf 敏捷软件开发_原则、模式与实践.pdf ...
敏捷开发是现在大多数公司都会用到的,其规范很是重要
敏捷大家在文档管理的真积灼见,值得一看!!!作者从自身多年的敏捷项目COACHING中总结出针对文档管理的项目实操.
敏捷测试请大家多多指导,根据自己实际经验写作!
Scrum是一种迭代式增量软件开发过程,通常用于敏捷软件开发,希望本文档能对各位有所帮助
敏捷测试,android相关经验,初学者可以看看,必有收货
敏捷学习各种资料文档,自己做个备份,也方便其他有需要的伙伴。