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

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

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

敏捷开发需要哪些文档?

需求说明

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

1.画面图

2.数据图

3.需求说明

来源张永光的博客

2008-11-14 13:42:00 xuxiaozhouxp 阅读数 189
  • SCRUM敏捷开发视频教程

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

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

软件工程是个很新的学科,只有50多年的历史,从产生到现在只是处在一个初级的发展阶段,很多东西都是日新月异的。国内大多数的软件开发还都处于一个初级阶段,

 

软件开发中人的因素最重要。传统的软件开发方法一味强调文档的重要性,认为文档可以解决软件开发中的一切问题:思想的交流、开发的预测等等。从而忽视了人的创造性和灵活性。事实证明传统的软件开发方法存在很多问题,还需要依靠其它的方法加以补足。

所谓敏捷思想就是发挥人的能动性,强调开发效率,剔除传统开发环境中繁杂不必要的工作,保留最关键的步骤,更多的依靠人与人之间的交流来进行软件开发。

敏捷的三个层次:

1.       较小的团队,20人左右。小层面上的敏捷思想。

2.       某个项目组层面的敏捷,200人左右。

3.       大型公司层面的敏捷。上万人。

如何在各个层面上进行敏捷开发,如何针对不同的问题进行敏捷开发都是一个问题。

我们在软件开发工程中不要墨守成规,要积极灵活的变通,要运用敏捷思想的神,而不是敏捷思想的形。

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

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

    10436 人正在学习 去看看 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》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10436 人正在学习 去看看 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-08-23 09:26:00 powertoolsteam 阅读数 1039
  • SCRUM敏捷开发视频教程

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

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

敏捷开发,Agile Development,就是指能够在需求迅速变化的情况下快速开发软件。我们接触最多敏捷实践方式有:极限编程(XP)、结对编程、测试驱动开发(TDD)等。

追究敏捷的历史,就必须要提到著名的敏捷开发宣言,2001年,17位业界专家(其中包括我们非常熟悉的Martin, Martin Fowler)组成了一个敏捷联盟,并且创建了一份敏捷联盟宣言,宣扬了4条核心价值观:

 

 

 

1, Individuals and interactions over processes and tools(人和交互重于过程和工具)

2,Working software over comprehensive documentation(可以工作的软件重于易于理解的文档)

3,Customer collaboration over contract negotiation(客户合作重于合同谈判)

4,Responding to change over following a plan(响应变化重于遵照计划)

此外,还有公开了12条敏捷软件开发的规则。

1,Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

尽早地、持续地交付有价值的软件来满足客户的需求

2,Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

欢迎需求的变化,即使是项目后期的变更。敏捷过程能够驾驭变化,为客户带来竞争优势

3,Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

经常交付可以工作的软件,时间间隔越短越好

4,Business people and developers must work together daily throughout the project.

整个项目开发期间,业务人员与开发人员应该工作在一起

5,Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

围绕斗志高昂的人构建项目,给他们提供所需的环境,满足他们的需要,并信任他们

6,The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

最有效的信息传达方式和与团队相处的方法是面对面交流

7,Working software is the primary measure of progress.

可以工作的软件是进度主要的度量标准

8,Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

敏捷过程提倡可持续开发。投资方、开发者和用户应该总是保持一致的步伐

9,Continuous attention to technical excellence and good design enhances agility.

不断追求卓越技术和良好设计有助于加强敏捷性

10,Simplicity--the art of maximizing the amount of work not done--is essential.

简单--尽量减少工作量是非常重要的

11,The best architectures, requirements, and designs emerge from self-organizing teams.

最好的架构、需求和设计都出自于自我组织的团队

12,At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

每隔一段时间,团队都要反思如何更有效率,并相应地调整自己的行为

更详细可参照敏捷联盟的官方网站(http://www.agilealliance.org/)和敏捷开发宣言网站(http://www.agilemanifesto.org/)。

 

 

从以上的4条价值观和12条敏捷开发的规则中,我们可以得出敏捷开发更强调的是,人与人之间的交互,包括程序员之间,程序员和客户之间的沟通,程序员不再是我们经常形容的代码工人等机械式的个体,受控于大量的规则文档和各种强大的工具。敏捷开发注重的是程序员的个人能力和沟通协作能力,一个具有良好沟通能力的程序员组成的团队更有可能获得成功,结对编程的方式就是利用两个人的紧密协作达到1+1>2的效果。敏捷开发不在受制于庞大笨重的工具,合适的工具对成功来说是很重要的,但是过于庞大笨重的工具就和缺少工具一样,都是不好的。项目中最常用的就是源代码管理工具,实际使用过程中发现昂贵的工具未必能体现其价值,有些免费开源的工具已经足够适用于项目的需求了。

传统的软件开发,非常注重文档的作用,文档有助于软件的后续维护,有助于客户对产品的理解。但是过多的文档比过少的文档更糟,文档太多就需要花费大量的时间去编写和维护。对于需求经常变更的项目,维护庞大的文档本身就是一场噩梦。在敏捷开发中,编写和维护一份简短的系统和结构方面的文档已经足够了。对于后续维护,更细致的说明,应该体现在代码中,设计简单良好、可读性强的代码对程序员来说是比设计文档更直观更容易理解的文档,软件技术专家Jack Reeves曾经说过:“实际上满足工程设计标准的唯一软件文档,就是源代码清单”。所以在项目中,直到迫切需要时才编制文档,按照需求开发可运行的软件才是敏捷开发的重点。

一般的软件项目合同中规定的都是整体的要求,但是我们知道软件开发中有太多的不确定性,这就会带来大量的需求变更,大的变更在项目开发过程总也是很正常的。经常有这样的案例:客户给我们需求,开发团队埋头苦干数月后完成交付客户,但是客户非常不满意,更有甚者,和客户的理解相差太大而导致项目失败。所以敏捷开发强调在开发过程中,保持和客户的沟通,面对面的沟通,完成模块时,应该马上请客户进行验收,这样项目结束的时候,验收的工作也基本完成了,极大地降低了项目失败的风险。敏捷中,强调随时应对变化的能力也会让开发团队有意识地设计和开发可扩展性好、可维护性好的软件。

敏捷开发强调了程序员的能力,极大地发掘程序员个体的潜力和整体的协作来保证项目的成功,而不是靠文档、制度、工具等。

我非常推崇敏捷软件开发模式,这样的方式可以极大地调动程序员的积极性、极大地加强团队的凝聚力。

如果你对敏捷软件开发有兴趣,请关注敏捷开发相关的各种实践,给大家推荐一本敏捷开发的图书,由Robert C. Marting(敏捷宣言发起者之一)编写的经典著作:

 

 

 

如果想深入关注敏捷的动态,也请关注发起敏捷宣言的各位大师们的著作,他们是:

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas。

敏捷的文档

阅读数 90

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