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

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

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


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

2019-08-27 00:50:57 seagal890 阅读数 70
  • SCRUM敏捷开发视频教程

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

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

[敏捷开发实践] 敏捷开发的误区

误区之一:人人都有机会,为项目招聘新人组建新团队,采用Scrum过程模型开发

误区之二:敏捷开发不需要写文档

误区之三:敏捷了要拥抱变化,PO(Product Owner)可以随时提出需求变更

误区之四:敏捷了一定要引入自动化测试,否则没有“高大上”的感觉

误区之五:敏捷开发一定可以加快系统/产品发布

误区之六:敏捷开发倡导“个体和交互胜过过程和工具”,过程和工具没有那么重要了

 

(更新中)

 

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

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

    10433 人正在学习 去看看 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相关的文档可以根据实际情况适当裁剪。

2018-08-10 11:26:13 fan2252228703 阅读数 278
  • SCRUM敏捷开发视频教程

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

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

第一个管理的项目采用的是敏捷开发,以下是个人对敏捷开发的一点实践总结。希望能给大家提供一些帮助。

(关于敏捷开发的3355,敏捷宣言,十二准则在最下边有。)

敏捷开发流程:

1.首先需求负责人理清需求。

2.团队内部要熟悉了解(可以做做游戏)。

3.当天下午及晚上迭代任务拆分。评估工时。

4.开始第一天每日例会领取任务。

5.迭代中旬测试用例评审,接口文档评审,故事验收标准。

6.期间每天早上的站会主要是总结昨天做了什么,遇到了什么问题,今天要干什么(承诺)。负责人需要对问题进行解决。不要阻塞开发。

7.迭代结束需要开迭代评审,迭代回顾。晚上进行任务拆分。

8.上一迭代未完成的任务放进下一迭代。需求变更的也放入下一迭代。

 

 

详细过程:

1.一周主要有以下几个过程:

每日立会。

迭代评审。

迭代回顾。

迭代计划会。

接口评审。

测试用例评审。

故事验收标准。

周报。

演讲分享。

 

每日立会:

每日立会是用来回顾自己在昨天做了什么,还有什么任务没有完成,为什么没有完成,遇到了什么问题需要解决。自己今天要做什么。根据反应的情况进行调整。负责人需要对所有的问题故障进行尽快的解决。

每日立会的公开性透明性能够清楚的认识到每个人的能力和问题。团队成员领取任务是一种承诺,既然承诺了就需要去完成。

 

迭代评审:

迭代评审是对本次迭代的评审,需要严格按照故事的验收标准来进行评审。是检验本次的迭代成果的时候。检验本次的完成情况并进行梳理,看有哪些没有完成,为什么没有完成,是否有什么风险,并将没有完成的移到下一迭代。完成后需要将本次迭代的成果交给甲方进行验收,看是否有需要改变的地方。如果有的话将需要改变的需求移到之后的迭代进行。

 

迭代回顾:

 

回顾本次迭代的团队情况。每个人需要写团队的三个评价:

好,不好,待改进。必须是针对团队的,不能针对个人。之后将统计结果写在黑板上,由团队人员进行投票。每个人必须对每个栏目进行投票,可以投多票反对,一票赞同,赞同票必须投,反对票可以不投。完成后总结团队的情况并解析。下次迭代改进。

 

迭代计划会:

迭代计划会需要对下次迭代的需求进行讲解和任务划分。将故事划分成一个个任务,由相应人员进行工时评估,录入系统。完成后将任务和故事打印出来,贴到看板上。

 

迭代本身:

这个暂时不知道是什么意思。

 

接口评审(迭代中旬):

对团队人员写的接口进行评审,看是否符合标准,解释是否明了,需要用到该接口的人员有什么问题都可以提出来。需要修改的则现场进行修改。

 

测试用例评审(迭代中旬):

对测试人员编写的测试用例进行评审,主要是测试人员进行评审看用例有那些缺陷或不严谨的地方。反思自己写的测试有什么不足。

开发人员则需要注意看看测试人员会测试那些东西,反思自己思维上有哪些没有考虑到,尽量的在开发阶段进行完善。不要提交到测试那一大堆bug。

 

故事验收标准:

故事的验收标准需要由团队人员来进行编写,提交给负责人,负责人同意后,则迭代评审时按照该标准进行评审。

周报:

每个人需要在一周结束时写一份周报来总结。周报内容应包括以下内容:

1.本周所做的工作

2.本周完成的工作

3.本周遗留的工作

4.有挑战性的工作

5.有成就感的工作

6.所学到的知识

7.自己需要改进的方面

8.建议团队需要改进的方面

9.其他

 

演讲分享:

这个是附加的,因为咱们都缺乏一些经验性,常识性的东西,所以需要以演讲的形式来为团队成员扩充知识面。

 

 

敏捷开发术语解析:

分组:开分前需要分好团队,根据不同情况将一个团队分成几个组,可以不分。并取个名。

迭代:一个项目可以分成多个迭代来进行完成。每个迭代完成一部分任务。以主线程为中心。以价值为核心。来判定优先级。

用户故事:将所有的需求划分成一个个用户故事,如果一个用户故事的任务量太大时必须拆分成几个小故事。用户故事有史诗级用户故事和普通用户故事。史诗级用户故事就是特别打的一个任务点。必须拆分成n多个任务故事。

用户故事举例:作为xxx,我要通过xxx,进行xxx。

用户故事地图:用户故事地图就是由许多许多的用户故事及任务张贴到物理看板上之后组成的一个地图。

任务:每个故事可以拆分成多个任务。由不同人员进行认领完成。

任务划分:每个用户故事可以拆分成很多任务,常规的有:前台页面开发,接口文档设计与开发,后台逻辑开发,测试用例编写,接口自动化测试,页面测试。  数据库设计一般在开发前就以完成,不过也可以在开发时添加数据库设计任务。

燃尽图:

所有的用户故事和任务被划分工时后会形成一个燃尽图,燃尽图以一个迭代为周期。随时间推移,团队人员需要为燃尽图进行工时的增减。燃尽图可以直观的看出团队任务的完成情况。

电子看板更新:

每日立会开完后,需要跟新电子看板,将自己认领的任务拖到相应位置。一天当中完成任务后需要将任务拖到完成状态,如果阻塞需要拖到阻塞状态。完成后可以继续认领新的任务。并将物理看板上认领相应的任务,当一天结束时,如果手头的任务没有完成则需要更新剩余工作量。

 

敏捷看板:

敏捷看板有物理看板和电子看板,物理看板只能每日立会的时候可以拖动,电子看板可以随时拖动,敏捷看板可以让团队人员更加直观的看到团队的完成成果和项目进度。

看板有以下几个字段:

用户故事,todo,doing,block,done.

 

 

工具:

敏捷开发的工具网上有很多,我们用的是自己的。

需要具备的功能:

敏捷看板 电子看板及燃尽图的展示。

用户需求 将一个模块拆分成多个用户需求

用户故事 将一个用户需求拆分成多个用户故事

迭代计划 迭代计划时长,迭代完成情况统计,团队人员完成情况统计等等。

缺陷管理 当测试人员测出bug后可以提出缺陷有开发人员进行修改。

用例管理 对测试用例进行管理。

模块管理  一个项目首先划分为一个个模块

 

持续集成:一键自动化集成部署。

 

自动化测试。测试人员进行自动化的接口及页面测试。

 

代码扫描。对所有代码进行,不合规范的将会报错。

接口管理:我们使用的是本地搭建的rap2。

敏捷宣言:

个体和互动 优于 流程和工具

工作的软件 优于 详尽的文档

客户合作 优于 合作谈判

响应变化 优于 遵循计划

 

SCRUM这个框架里面包含了这几个核心的要素:

1、3个角色:SM、PO、开发团队(自然包括了我们的开发人员和QA)。

2、3个产出物:Product Backlog、Sprint Backlog、交互的可用软件工件。

3、5个活动:计划会、sprint评审会、回顾会、每日立会、Product Backlog的梳理(发生在整个SCRUM周期的任何时间)。

4、5个价值观:公开、专注、勇气、承诺、尊重。(这五个价值观尤其重要,贯穿整个敏捷开发。)

十二条准则:

12原则作为敏捷开发对于软件开发流程的指导性纲领,其实是对敏捷宣言进行了具有实际操作意义的解释。下面是敏捷宣言12原则:

我们遵循以下准则:

1、我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。

2、欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。

3、要不断交付可用的软件,周期从几周到几个月不等,且越短越好。

4、项目过程中,业务人员与开发人员必须在一起工作。

5、要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。

6、无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。

7、可用的软件是衡量进度的主要指标。

8、敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

9、对技术的精益求精以及对设计的不断完善将提升敏捷性。

10、要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。

11、最佳的架构、需求和设计出自于自组织的团队。

12、团队要定期反省如何能够做到更有效,并相应地调整团队的行为。

 

 

 

 

 

2018-05-24 11:20:45 runOnWay 阅读数 460
  • SCRUM敏捷开发视频教程

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

    10433 人正在学习 去看看 CSDN讲师
    一、敏捷开发是一种开发方式
    敏捷开发,英文是Agile Development,是一种以人为核心、迭代、循序渐进的开发方式,是一种软件开发的流程。它会指导开发人员用规定的环节去一步一步完成项目的开发。由于它采用迭代式开发,所以它主要的驱动核心是人,而不是像瀑布模型那样,以文档为核心。
    敏捷开发更注重的人与人之间的沟通、交流。它认为个体和交互胜过过程和工具,可以工作的软件胜过面面俱到的文档,客户合作胜过合同谈判,响应变化胜过遵循计划。虽然右项也有价值,但是敏捷开发认为左项具有更大的价值。
   迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样一个周期就是一次迭代的过程,同时每一次迭代都可以生产或开发出一个可以交付的软件产品。
   二、几个重要的名词
   Scrum:是一个橄榄球专业术语,意味并列争球。用了这样一个词在敏捷开发中,可以证明,在整个敏捷开发的过程中,团队中的每一个人都要像橄榄球运动员一样迅速、富有战斗激情,在这种氛围下才会达到敏捷开发快速迭代的要求。
   XP:极限编程,是一种轻量、高效、低风险、柔性、可预测、科学而且充满乐趣的开发方式。它强调在更短的周期内,更早地提供具体、持续的反馈信息;在迭代地进行计划编制,首先在最开始迅速生成一个总体计划,然后在整个项目开发过程中不断的发展它;依赖于自动测试程序来监控开发进度,并尽可能早地捕获缺陷;依赖于口头交流、测试和源程序进行沟通;倡导持续的演化式设计;依赖于开发团队内部的紧密协作;尽可能达到程序员短期利益和项目长期利益的平衡。

注:Scrum和XP是敏捷开发的两种方式,Scrum偏重过程,XP偏重实践。

    PO:Product Owner,产品负责人。主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。
    SM:Scrum Master,流程管理员。主要负责整个Scrum流程在项目中的顺利实施和进行,以及扫清挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。
    ST:Scrum Team,开发团队。主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5-10人左右,每个成员可能负责不同的技术方面,但要求每个成员必须要有很强的自我管理能力,同时具有一定的表达能力。成员可以采用任何工作方式,只要能够完成开发任务。
   PB:Product Backlog,产品需求列表。由PO负责,按优先顺序排列产品需求。
   Sprint:冲刺。指一次迭代,每次迭代的周期大约是一个月。
   INVEST原则:是缩写组成,Independent独立的、Negotiable可协商的、Valuable有价值的、 Estimable可估计的、Small小的、Testable可测试的
   三、Scrum开发
   1.首先由PO,制定PB。
   2.ST根据PB,进行工作量的预估和安排。在工作量预估中,可以使用计划筹码,每个筹码代表着完成一个故事的时间,是一个故事点的倍数,一般有1、2、3、5、8这几个数字。每个人对工作的预估在亮出筹码之后,如果有不同意见,不能折中选平均数,而是要各自说出理由,再重新进行预估。
   3.有了PB列表,就需要通过Sprint Planning Meeting来从中挑选出一个Story作为本次迭代完成的目标,然后将这个Story进行细化,一个优秀的Story要遵循INVEST原则,形成Sprint Backlog,然后再继续细化,争取每个细化的任务能在2天内完成。
   4.在ST完成PM上选出的Sprint Backlog过程中,要进行Daily Scrum Meeting,每次会议要控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报昨天完成的工作和承诺今天要完成的任务,如果遇到问题也可以提出问题,表述结束后,要更新自己的燃尽图。
    5.要做到每日集成,每天都要有一个可成功编译、并且可以演示的版本,这就凸显出了持续集成的重要性。
    6.当一个Story完成,也就是Sprint Backlog被完成,就代表一次Sprint完成,要进行Sprint Review Meeting,PO和客户都要参加,每个ST成员都要展示自己完成的任务。
    7.最后就是Sprint Retrospective Meeting,所有成员轮流发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中。

   敏捷开发的快速迭代有很明显的优势,但是对团队的要求也更高,尤其是按时完成任务,对自己的承诺负责这点,如果要保重能够按时完成任务,就要在预估工作量上更加严谨,而不是取折中这种方式,每个人要更加坚持自己的立场,只能够因为合理的逻辑做出计划。
没有更多推荐了,返回首页