2018-01-17 07:38:53 hello_zyg 阅读数 25026
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10434 人正在学习 去看看 CSDN讲师

敏捷开发需要哪些文档?

需求说明

    对功能、交互方式、出错或边界情况的表现进行总体描述

1.画面图

2.数据图

3.需求说明

来源张永光的博客

2016-03-19 10:39:56 zzhdi 阅读数 3697
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10434 人正在学习 去看看 CSDN讲师

easypm-敏捷开发

在产品研发过程中经常需要编写很多文档,例如:需求文档、设计文档、API文档、验收文档等等。团队成员要花费很多精力去维护众多的文档,甚至有“兄弟,我替你写代码,你替我写文档”的无奈。

敏捷开发宣言
* 个体和互动 胜于 流程和工具
* 可以工作的软件 胜于 详尽的文档
* 客户合作 胜于 合同谈判
* 响应变化 胜于 遵循计划

敏捷宣言的第二条“可工作的软件胜于详尽的文档”,很多人理解为敏捷开发不重视文档,甚至以此为借口逃避写文档。同样,在对待”敏捷开发是否需要架构设计”的问题上也有类似极端的看法。

敏捷宣言在写什么样的文档以及如何写方面并没有给出任何刚性的指导原则,那么在敏捷管理的项目中我们该如何编写文档呢?

首先,我们需要理解敏捷宣言背后的思想。
敏捷4条宣言都是在强调“价值”、“快速交付价值”、“为客户提供价值”的理念。换句话说,研发团队要把精力放在能够为客户带来价值的地方,避免在不产生价值或者ROI(投入回报率)低的任务上浪费时间。

其次,我们要理解文档的作用是什么?文档是用来准确传递信息,帮助理解事物,沉淀知识。

基于以上理解,在遇到是否要写文档的疑问时,可以通过回答两个问题来判断

  • 是否有比写文档更高效传递信息的方式?
  • 简陋的文档是否满足需要?

从文档的读者来划分

  • 读者是项目组外人员
    这类文档往往是需要编写的而且不能“简写”的。例如:用户手册、验收文档、API文档等。

  • 读者是项目组内人员
    这类文档能省则省,能简则简。如果能够在每天站会上沟通的,就可以不写。建议高层的系统架构图、内部API文档可以简写。
    如果项目Leader通过类似EasyPM这样管理工具能够查询到的信息,可以在周报中简写甚至省略。


对于可以“简写”的文档,可以考虑使用Markdown格式。

Markdown是一种简单易用的标记语言,用户可以使用这些标记符号以最小的输入代价生成极富表现力的文档。

EasyPM 的文档编辑器使用Markdown语法,并且实时保存/预览、支持代码高亮、文档评论以及全文搜索。在版本管理上,支持手动和自动进行版本管理。文档评论也支持@功能,可以高效地对文档进行评审。

2018-07-04 15:05:32 rocling 阅读数 1304
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10434 人正在学习 去看看 CSDN讲师

敏捷开发学习总结: 思考开发文档的利与弊



文档是个好东西,这是不可否认的,但是太依赖文档也有弊端,下面我从不同的度来分析一下文档的利与弊,然后思考在敏捷开发时,文档又是如何进行的。


从 公司的角度来看,编写文档有如下好处: 
a1) 公司使用的是瀑布生命周期(或序列式开发,传统开发),所以必然的,在某一个阶段,需要编写大量的文档作为进入下一阶段的输入。
a2)过程改进的 需要,认为只要过程控制得足够细,例如只要文档编写得足够详细,那么人员是可以被替换的,也就是说,有了文档,人员的流动不会给项目带来大的风险。
a3) 受到其它行业的启示,例如建筑行业,图纸制定好并确否没有问题后,施工队才能准确无误地施工,所以要求在编码之前先编写HD、DD文档,除了方便交叉 REVIEW,同时,文档用于指导资浅工程师的编码工作,文档只有编写的足够详细(DD最好给出伪代码),工程师才不至于走偏。
a4) 企业知识库的建设需要,没有文档,技术就没有得到积累。


从工程师的角度来看,为什么工程师有时不愿意写文档呢? 
b1) 代码与文档的同步问题,很多设计文档在写完后就被代码远远地抛在后面了,开发人员只有二个选择,要不更新文档,要不任由文档逐渐地开始撒谎,如果选择维护 文档与代码同步,那么就会耗费大量的时间和精力在文档更新上面,而维护这份文档目的只是为了将来有可能有人需要阅读---也有可能无人问津。
b2) 任务的工时安排得很紧,但编写文档又导致进度太慢。
b3)认为文档太枯燥,不比编写代码有成就感。
b4)没自信,怕文档写不好会误导别 人。
b5)本身没有搞清楚思路,所以也就写不出文档。


从敏捷开发思想的角度去看待上述的一些问题: 
对应 a1) 这就是敏捷开发反对瀑布模型的原因之一吧。
对应a2) 首先寄望于通过过程控制来达到开发人员可替换性目的这个想法,是有争议的 ,另外,极限编程中使用“代码集成所有权属于团队”的实践方法来保证团队内部的知识共享,从而减少人员流动对团队带来的风险。
对应a3) 敏捷开发的建议是只写有用的文档,例如编写整个系统的HLD或架构文档是值得的,因为整个团队的成员以及新人都要阅读它来了解整个系统的架构和设计,而某 个模块的DD文档,它的读者只是负责该模块的程序员,敏捷开发的建议是面对面进行交流来传达设计比较来得快捷,不编写过于详细的DD文档的原因是它太容易 与代码脱节了,另外,面对面交流,并不是资深人员传达设计给资浅人员,而是让资浅人员参与到设计中来,是以平等的方式与资深人员一起讨论和确定最终的设 计。可是文档毕竟比起代码易于阅读,总得要有个载体描述模块的DD设计啊,一般来说是推荐“Self-Documenting ”的形式来代替DD文档。
对 应a4) 轻量级的文档不代表不编写文档,所以这一点与知识库的建设不冲突。
对应b1) 尽量使用“Self-Documenting”的形式,即将文档以注释的形式插入到代码中,来解决文档与代码的同步问题,需要文档时,再用工具从代码中提 取出文档,例如Java中的JavaDoc工具,而Qt的API文档也是这么干的,Qt的文档是用doxygen来生成的。
对应b2) 这就是轻量级文档的原则所要解决的问题,除了避免编写无用的文档外,如何避免长篇大论的文档也是要解决的问题,我从UP开发方法的产出物(制品)中了解 到,UP开发方法使用的“用例驱动”方法将需求分析文档以“用例(Use Case) ”的形式来编写,减少了出现长篇大论的可能性。
剩下的 b3,b4,b5是开发人员自身的原因。


最好做个总结,文档是好东西,但它的弊端就是要花时间(包括写作和维护的时间),如果项目时间都比较紧,如何把握文档的量和细致程度,确实是值得思考和权衡的问题。

2010-11-30 15:21:00 zhangwei_wuyan 阅读数 460
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10434 人正在学习 去看看 CSDN讲师

最近一直在忙,今天对于上次说的问题做补充。纯属个人一点小看法,只抛砖而已,希望能引玉。文章只针对于中小型企业,且没有成熟的开发过程企业来说,所以裁剪的文档参考CMMI3级的标准文档。

关于敏捷开发和CMMI的管理大家都各有心得,我就不在对各自具体管理做阐述了,紧紧针对文档裁剪说点看法,首先敏捷开发强调的核心的东西是交流,但对于当今的项目开发来说,个人交流恰恰是个难点,做开发的基本上都是能不交流就不交流,开发进度紧张时更是如此,在项目中开发和测试交流起来更加困难,这两部分人员有部分工作在某种意义上是敌对的。更何况再把客户加入交流的名单之内,因此适当的文档可以避免项目资源流失和踢皮球的做法。

1.       项目开始的估算是需要的,但可以简化估算的过程和文档,例如各种估算标准和报告。

测试计划可以简化,不必给出详细的项目过程计划,因为敏捷开发的项目过程几乎是没法计划的。

2.       Walkthrough的会议要经常开,里程碑会议文档可以裁剪,项目监督控制文档可以裁剪。但项目周报需要。

3.       集成项目管理文档可以裁剪。因为很多项目coding完成后,基本上也就完成了,集成的观念在很多项目过程中都被忽略,基本上很少有集成管理,集成测试的具体实施,结项报告需要。可以作为经验总结放到公司的配置管理服务器上作为以后对该项目查询问题的一个文件材料。

4.       基线建立文档可以裁剪,配置审计等相关配置管理文档可以裁剪。

5.       风险管理相关文档可以裁剪为一个风险管理一览表文档进行跟踪管理。

6.       如果公司有独立的PPQA人员,过程和产品质量保证的检查可以保持不变,但如果没有独立人员,该部分可以裁剪,但概要设计,和详细设计不能裁剪,最少也要出来一个文档,虽然需求变化对这两个文档改变较大,这两个文档可以避免开发人员流动带来的项目交接问题,还能为测试提供依据,需求变更如果管理得当,总的来有利大于弊,还需要对开发概要设计,详细设计文档,编码进行Review和交叉审查。

7.       度量部分可以裁剪,因为度量项需要根据项目开发过程中的各种文档和人员来搜集度量的数据,没有了文档度量数据可靠性没有可信度,所以可以裁剪。

8.       决策分析和解决方案可以裁剪,决策和解决方案可以放到walkthrough会议中讨论。

9.       需求变更相关文档不能裁剪,并且应该加大需求变更管理力度,因为敏捷开发强调的是对变化的快速反应,而实际项目中因为各种原因客户和项目人员交流不够,而测试人员和开发人员,客户交流更不够,所以难以达到敏捷开发的对变化快速响应这一核心价值。因此应加大需求变更的管理力度,相关文档不能裁剪。

10.   需求管理相关文档可以裁剪,例如需求开发指南,需求开发文件等。敏捷开发的核心价值就包含与客户的交流重于合同约束,而与客户交流就涉及到方方面面的问题,所以要注重多交流,迭代的需求调研,不断挖掘潜在需求。因此需求调研的各种文档可以裁剪,但应该清晰记录客户访谈记录分析表,最后必须给出一份基本需求规格说明书。

11.   产品集成的计划,环境检查列表,报告可以裁剪,但接口列表不能裁剪,且应该对其进行交叉审查。

12.   测试阶段,测试计划可以裁剪为一个简单的文档,测试用例不要裁剪,因为如果项目都是一个人做测试可以考虑将测试用例裁剪,改为测试操作过程记录。但如果多个人参与,同一个人的测试操作记录重用性很差,所以多人参与测试的项目测试用例最好不要裁剪,Bug跟踪管理可以用Bug管理工具实现,测试报告不可以裁剪。

13.   OPFOPD过程域相关文档可以裁剪,因为没有任何可靠数据可以追寻,文档没有实在意义。

14.   OTSM相关的文档可以根据实际情况适当裁剪。

2010-04-04 16:10:00 kwiner 阅读数 1158
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10434 人正在学习 去看看 CSDN讲师

文档是个好东西,这是不可否认的,但是太依赖文档也有弊端,下面我从不同的度来分析一下文档的利与弊,然后思考在敏捷开发时,文档又是如何进行的。

从 公司的角度来看,编写文档有如下好处:
a1) 公司使用的是瀑布生命周期(或序列式开发,传统开发),所以必然的,在某一个阶段,需要编写大量的文档作为进入下一阶段的输入。
a2)过程改进的 需要,认为只要过程控制得足够细,例如只要文档编写得足够详细,那么人员是可以被替换的,也就是说,有了文档,人员的流动不会给项目带来大的风险。
a3) 受到其它行业的启示,例如建筑行业,图纸制定好并确否没有问题后,施工队才能准确无误地施工,所以要求在编码之前先编写HD、DD文档,除了方便交叉 REVIEW,同时,文档用于指导资浅工程师的编码工作,文档只有编写的足够详细(DD最好给出伪代码),工程师才不至于走偏。
a4) 企业知识库的建设需要,没有文档,技术就没有得到积累。

从工程师的角度来看,为什么工程师有时不愿意写文档呢?
b1) 代码与文档的同步问题,很多设计文档在写完后就被代码远远地抛在后面了,开发人员只有二个选择,要不更新文档,要不任由文档逐渐地开始撒谎,如果选择维护 文档与代码同步,那么就会耗费大量的时间和精力在文档更新上面,而维护这份文档目的只是为了将来有可能有人需要阅读---也有可能无人问津。
b2) 任务的工时安排得很紧,但编写文档又导致进度太慢。
b3)认为文档太枯燥,不比编写代码有成就感。
b4)没自信,怕文档写不好会误导别 人。
b5)本身没有搞清楚思路,所以也就写不出文档。

从敏捷开发思想的角度去看待上述的一些问题:
对应 a1) 这就是敏捷开发反对瀑布模型的原因之一吧。
对应a2) 首先寄望于通过过程控制来达到开发人员可替换性目的这个想法,是有争议的 ,另外,极限编程中使用“代码集成所有权属于团队”的实践方法来保证团队内部的知识共享,从而减少人员流动对团队带来的风险。
对应a3) 敏捷开发的建议是只写有用的文档,例如编写整个系统的HLD或架构文档是值得的,因为整个团队的成员以及新人都要阅读它来了解整个系统的架构和设计,而某 个模块的DD文档,它的读者只是负责该模块的程序员,敏捷开发的建议是面对面进行交流来传达设计比较来得快捷,不编写过于详细的DD文档的原因是它太容易 与代码脱节了,另外,面对面交流,并不是资深人员传达设计给资浅人员,而是让资浅人员参与到设计中来,是以平等的方式与资深人员一起讨论和确定最终的设 计。可是文档毕竟比起代码易于阅读,总得要有个载体描述模块的DD设计啊,一般来说是推荐“Self-Documenting ”的形式来代替DD文档。
对 应a4) 轻量级的文档不代表不编写文档,所以这一点与知识库的建设不冲突。
对应b1) 尽量使用“Self-Documenting”的形式,即将文档以注释的形式插入到代码中,来解决文档与代码的同步问题,需要文档时,再用工具从代码中提 取出文档,例如Java中的JavaDoc工具,而Qt的API文档也是这么干的,Qt的文档是用doxygen来生成的。
对应b2) 这就是轻量级文档的原则所要解决的问题,除了避免编写无用的文档外,如何避免长篇大论的文档也是要解决的问题,我从UP开发方法的产出物(制品)中了解 到,UP开发方法使用的“用例驱动”方法将需求分析文档以“用例(Use Case) ”的形式来编写,减少了出现长篇大论的可能性。
剩下的 b3,b4,b5是开发人员自身的原因。

最好做个总结,文档是好东西,但它的弊端就是要花时间(包括写作和维护的时间),如果项目时间都比较紧,如何把握文档的量和细致程度,确实是值得思考和权衡的问题。


敏捷的文档

阅读数 90

敏捷开发

阅读数 278

没有更多推荐了,返回首页