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

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

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

敏捷开发需要哪些文档?

需求说明

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

1.画面图

2.数据图

3.需求说明

来源张永光的博客

2018-06-05 13:19:13 lylmwt 阅读数 758
  • SCRUM敏捷开发视频教程

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

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

我们比较熟知的软件项目管理方法是瀑布。其基本流程是需求-> 设计->开发->测试。基本假设只要把每一个环节都做正确,那么最终得到的结果也是正确的。瀑布开发有非常成功的案例,比如微软。但从总体来讲,瀑布项目失败率比较高。国外的软件先行者们针对瀑布开发中暴露出来的问题进行了一系列的探索、思考和总结,提出了Agile Dev的概念,中文翻译为敏捷开发。
一.什么是敏捷开发
敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。
换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。相对于瀑布开发模式,敏捷开发更加灵活可操作。
二.敏捷开发方式及流程
敏捷开发有很多种方式,如scrum,XP,LSD,FDD等,其中scrum是非常流行的一种。
scrum将产品的开发分解为若干个小sprint(迭代),其周期从1周到4周不等,但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。
scrum的基本流程如图所示:

po(product owner指产品负责人)负责整理user story,形成左侧的product backlog(按优先顺序排列的一个产品需求列表)。
发布计划会议:po负责讲解user story,对其进行估算和排序,发布计划会议的产出就是制定出这一期迭代要完成的story列表,叫做sprint backlog。
迭代计划会议:项目团队对每一个story进行任务分解,分解的标准是完成该story的所有任务,最终每个任务都有明确的负责人,并完成工时的初估计。
每日例会:每天sm(scrum master指项目负责人)召集站立会议,团队成员回答昨天做了什么今天计划做什么,有什么问题。
演示会议:迭代结束之后,召开演示会议,相关人员都受邀参加,团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来,由po整理,形成新的story。
回顾会议:项目团队对本期迭代进行总结,发现不足,制定改进计划,下一次迭代继续改进,已达到持续改进的效果。
敏捷流程中的三个关键要素是:product backlog(产品需求)
sprint backlog(本期迭代任务)
burn-down chart(燃尽图,进度的体现)
呈现了任务下达-拆分-推进的整个过程。

三.“轻文档,重沟通”的敏捷
我们知道,瀑布开发是以文档为驱动,文档是一切工作的核心,po需要写非常多而复杂的文档,例如:需求文档、设计文档、API文档、验收文档等等。
敏捷宣言说,“可工作的软件胜于详尽的文档”。敏捷反对这种 “重文档”的方法,而是强调成员之间的紧密协作、面对面的沟通、频繁交付的新版本、紧凑而自我组织型的团队。可见,敏捷开发是更实际,更注重操作性的开发方式。
但这并不意味着敏捷开发完全抛弃文档,敏捷开发遵循“轻文档,重沟通”的原则。
“轻文档”体现在,敏捷开发只关注文档中的重要点,尽可能的简化文档,或者用软件工具呈现另一种形式的文档。
以传统文档来说,一个PRD(产品需求文档)中包含对多个成员的诉求,比如前端工程师、后端工程师、测试人员。众多的产品需求导致文档厚重繁琐,而且在实际工作中,很多开发人员并不喜欢看文档。因为常常一个PRD中可能有好几页内容都是与自己无关的,但是要看过才知道是否与自己有关,这在无形中就造成了时间的浪费。
敏捷管理中采用了用户故事的方式进行product backlog的呈现,“用户故事(称作user story)”是采用用户熟悉的术语来表达需求的一种方法,是用户讲给开发人员的故事(实际由po搜集用户需求并整理成用户故事)。
例如“作为禅道用户,我希望能实现自动登陆功能,这样能更方便的登陆系统。“这就是一个具体的需求描述。
在这个需求描述中,涉及到三个要素“用户角色(禅道用户)”、“达成的目的(自动登陆功能)”、“开发价值(更方便的登陆系统)”
当然除了这三个要素,还需要涉及到验收标准、优先级、评审人等。

借助软件工具实现product backlog的信息传达是敏捷开发最普遍的做法。po把功能点拆分,导入到项目管理软件中,相关人员只需要按照需求目录一条条执行即可,不再需要一页一页的看PRD了。后端只需要与提供接口相关的,前端主要看与功能相关的部分,而不需要查看与自己无关的内容。如果开发人员在具体的sprint backlog开发中存在问题和疑问怎么办呢?沟通!
“重沟通”体现在以结果为导向,以人为核心。通过面对面沟通的方式快速反应,推动进度。
你可以随时一对一沟通po解除疑问。而且整个敏捷团队还需要召开发布计划会议、迭代计划会议、演示会议等内部会议及每日站立会议。每日站立会议上,团队成员依次回答昨天做了什么今天计划做什么,有什么问题,发现问题及时提出和解决。每个人发言完后,要走到任务看板前更新自己的燃尽图。这也是敏捷流程中不可缺少的环节。

任务看板一般包含未完成、正在做、已完成的工作状态,假设你今天把一个未完成的工作已经完成,那么你要把小卡片从未完成区域贴到已完成区域。每个人的工作进度和完成情况都是公开的,如果有一个人的工作任务在某一个位置放了好几天,大家都能发现他的工作进度可能出现了什么问题。

如今的任务看板和燃尽图已经由实物形式转变为项目管理软件。表现形式基本延续实体看板的形式,禅道中分为未开始、进行中、已暂停、已完成、已取消、已关闭几种状态。在看板页面,成员完成某项任务后即可从进行中拖拽到已完成列,跟实体看板的作用如出一辙。

比起传统开发模式,敏捷更加强调去流程化,文档不再必须,变得可以简化和被取代。因为在敏捷开发中,最简单的解决方案就是最好的解决方案,最高效的工作方式就是最好的工作方式。

相关观点及图片来源:
敏捷开发-百度百科
禅道-开源项目管理软件
谈谈我理解的敏捷开发-许大虾

 

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

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

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

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

 

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

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

敏捷的三个层次:

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

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

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

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

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

2010-08-23 09:26:00 powertoolsteam 阅读数 1039
  • SCRUM敏捷开发视频教程

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

    10392 人正在学习 去看看 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。

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

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

    10392 人正在学习 去看看 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是开发人员自身的原因。


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

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