2019-05-11 19:34:29 jnshu_it 阅读数 1603
  • SCRUM敏捷开发视频教程

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

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

这里是修真院后端小课堂,每篇分享文从

【背景介绍】【知识剖析】【常见问题】【解决方案】【编码实战】【扩展思考】【更多讨论】【参考文献】

八个方面深度解析后端知识/技能,本篇分享的是:

【什么是敏捷开发流程 】

这个词猛一听起来感觉很高大上,其实现在已经是主流的团队开发流程 了。
一. 先说一下官方的定义:

敏捷不是指某一种具体的方法论、过程或框架,而是一组价值观和原则。符合敏捷价值观和原则的开发方法包括:极限编程(XP),Scrum,精益软件开发(Lean Software Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Crystal Clear)等等。所有这些方法都具有以下共同特征:

  1. 迭代式开发。即整个开发过程被分为几个迭代周期,每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短,通常为一到六周。

  2. 增量交付。产品是在每个迭代周期结束时被逐步交付使用,而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。

  3. 开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时,团队对于用户的需求也能及时提供反馈意见。

  4. 持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成,有些项目则每天都在这么做。

  5. 开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队,是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制,而非把过程和机制强加给人。

二. 然后是我理解的敏捷

主要说一下我们公司自己的开发流程,因为接触时间尚浅,所以有点地方可能说的不是很到位,希望大家多多包含。

需求评审(参与人员是 客户+产品+UI+开发+测试,也就是所有人员)
主要是产品人员讲解需求,用户需要给出反馈或者提出意见,其他人员可以相应的提出自己的见解。

Story划分(产品+UI+开发)
产品根据UI做出来的原型图给开发人员讲解系统构成和运行,将整个网站按照功能划分成一个个细粒度的story来说明,开发人员(前端和后端)也需要明白自己应该关注那些关键点。

人员划分(leader+开发)
主要是项目小组的leader 根据story划分,给前端和后端开发人员划分story,开发人员根据自己的情况去估算所需时间。

方案设计(数据库设计文档、接口设计文档、方案设计文档)
先根据系统的实际情况去设计DB,包括数据库和表的名字,以及具体的字段。
然后设计接口文档,按照页面和功能进行设计,包括具体的请求地址和入参出参。
最后是根据接口文档中出现的疑难点去做方案设计文档,对遇到的问题进行分析并拿出至少两种具体的解决方案。

方案评审(所有人员)
对前端和后端给出的方案评审其它人员给出各自的意见,有问题的话下次再次开始。

禅道任务拆分(开发人员)
方案评审通过以后开发人员就需要按照预估的总开发时间去拆分story,可以分成多个小的任务,但是一个任务的时间最好不要超过4个小时。

开发(项目日报+工作日报+进度邮件)
每天实际开发过程中遇到问题可以写成项目日报;每天的任务完成情况写成工作日报;相比较整个系统的进度完成情况需要写进度邮件。

端对端(接口)测试(开发人员)
前端写好了页面,后端完实现了接口,就可以进行端到端的测试,可以远程测试,也可以本地测试。

压力测试+集成测试
系统完成以后需要用Jmeter 进行模拟用户访问,通过设置线程来提高并发量的方式达到一定的效果,测试生成的数据需要总结成测试报告。

Demo
对于复盘来说,这就是最后一个程序了,在前后端大师兄的评审下,主要是前端人员进行系统演示,各个功能是否实现、页面是否达到用户要求、有没有什么需要完善的地方。点评过之后如果有问题那就修改之后再次评审;如果没有问题那就算完成复盘项目了。

这么一个流程走下来,特别期间各个环节的良好运行以及团队合作的情况都是确保项目能够正常实现并交付的重要因素,敏捷开发强调的是人的充分能动性,通过这种相互合作的开发模式,相信在前后端分类开发的盛行时代,公司或者团队可以在约定的时间内较好地完成用户委托的项目。

 

 



 

【欢迎加IT交流群565763832与大家一起讨论交流】

2015-06-12 16:35:55 leangoo_cooperation 阅读数 373
  • SCRUM敏捷开发视频教程

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

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

敏捷开发流程及敏捷工具

敏捷开发,要求在开发过程中不断增强,从而提高软件质量,以达到提高商业收入的目的。它是一个迭代的过程,一个不断提高企业投资回报率和服务质量的过程。值得注意的是,成功的敏捷开发,单纯依附于活跃的开发过程和理解敏捷所带来的效益并对此有浓厚兴趣的企业用户。本文将介绍敏捷开发的五大过程及这些过程中所要用到的工具。

敏捷计划

典型的敏捷开发将整体工作分为一系列的发布过程,每个发布过程都是一个迭代循环,每个迭代循环都会发布一组功能特性。

敏捷计划规定了每个循环中所需要完成的工作(发布/迭代)。在该阶段,产品所有者将描述每个循环过程中他希望看到的产品样子。

敏捷计划包含发布计划与迭代计划,两者的内容及执行者不同。

发布计划:包含每次发布的功能组。产品所有者负责在产品发布之前制定发布计划。

迭代计划:开发团队需要在开发工作及迭代开始前确定需要完成的工作。可以通过每天的站立会议来实现。

工具:制定敏捷计划,有很多工具可以使用,如:

创建用户故事

用户故事,是对功能、特性的简单描述。每个特性也可能由很多故事组成。用户故事要简单且容易理解,能在几分钟内通过几行字表述清楚。请注意,用户故事是由项目所有者或主要用户群体来定义的,而非开发者。

正如Mike Cohnrn所建议的,用户故事应该遵循下面的格式:

作为一个(某种角色),我需要(某事)如此如此。

例如,作为一个用户,我希望通过姓名来查找我的客户。

工具:最好的方法是使用索引卡片来记录各个故事。有很多种工具可以帮助完成故事图谱与故事追踪,如

  • SilverStories
  • Pivotaltracker

注意:故事并不是一次性完成的,它循环往复,且贯穿于整个项目开发周期中。

评估你的工作

在敏捷中,评估用于预测功能实现的复杂程度,并根据以前完成相似复杂度功能的经验预估所需要的完成时间。它是一个持续的过程,基于之前的经验和模式学习,不断提高评估的准确性。

通常,评估故事的复杂程度多基于故事要点,而非所耗费的时间。要点解释了故事的复杂性,并通过数据1,2,3……来体现。

评估有助于做出更好的商业决策,定义发布/迭代的范围。例如,我们可以很容易地为每次迭代/发布中的所有故事分配同样的数字。

工具: Planning Poker(估算扑克,scrum中文网微信就有,Scrum_CN,关注即可使用)是定义和改善你评估的最好技术。

站立会议

站立会议是开发团队每天进行的简短会议。会上每个人需要说明昨天所完成的事,及今天的计划和被分配任务现在的状态。商业用户和领域专家偶尔也会参加,这将给他们更多关于项目的信息。

它不是例行会议,仅仅对项目实施情况给出粗略的描述,而是要提供更多关于项目的可视性内容,增强团队间的协作,对当天的计划给出正确指导。

工具:在站立会议中,白板是非常有效的工具,比如Leangoo。

项目监控技术

速率:

通过速率,可以精确地测量开发团队发布商业价值的速度。速率是对生产力的测量。通过计算一定间隔内完成工作的单元数来计算速率。

在每次迭代的最后,为了计算速率,敏捷团队会查看该过程所完成的工作要求,并累加与这些要求相关联的故事点。所完成故事点的总数便是团队的速率。首次小小的迭代之后,你会逐渐发现某种趋势,且能计算出平均速率。

下面一些工具可以帮助追踪速率。

  • TargetProcess
  • Pivotaltracker
  • Timetracking
  • VersionOne

Burndown Reports:

Burndown Report是追踪项目进度的另一个标尺。它用来追踪完成故事点的个数,监控简单的迭代、发布和整个项目积压的工作。它可以显示进度,反映产品交付的价值和团队的速率。

以下一些工具可用于测量Burndown Reports:

  • TargetProcess
  • XPlanner
  • Pivotal Tracker
  • ScrumWorks

来源:Infoq

英文原文:http://techmytalk.com/2013/07/14/agile-software-development-process/

2017-05-01 14:17:41 ogreworld1987 阅读数 2393
  • SCRUM敏捷开发视频教程

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

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

1、我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由ProductOwner 负责的;

2Scrum Team根据Product Backlog列表,做工作量的预估和安排;

3、有了ProductBacklog列表,我们需要通过 Sprint Planning MeetingSprint计划会议)来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog

4Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);

5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn downSprint燃尽图);

6、做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员;

7、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);

8、最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;

2019-03-05 10:55:34 weixin_39835036 阅读数 46
  • SCRUM敏捷开发视频教程

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

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

一个好的开发流程,对于项目的进行,更新和维护都起着至关重要的作用。Scrum适用于一些开发周期长,需求不明确,或者随时间渐进明确,频繁更新的项目。然而,现在国内的一些公司,甚至一些大公司,都对这块不太重视,或者做得不够透彻。从而程序猿们天天加班,苦不堪言。

我们先来看张我通过实际经验画的图流程图,红色圈圈出来的是我认为比较容易忽略的部分,接下来一一说明。

一看就会的敏捷开发流程

01

项目决定启动后,第一步就是产品组准备需求,整理出需求文档。这个需求文档是需要多次会议协商总结出的。在需求前期,产品组可以自由发挥,把对产品的任何要求尽量详细地列出来,细节方面列不完整也没关系,但是对于产品的最终呈现出的效果,大的方向,要有一个彻底明确的说明,因为这个可能直接关系到产品架构的设计。

然后进入需求中期,这个时候一定要引入技术经理以及技术主力,需要从技术角度去评估需求的可行性以及性价比,这让技术部门能够基本了解大的架构方向,(我曾经就有碰到过一个项目,由于产品组在美国,开发组在国内,产品组在没有和开发组彻底沟通的情况下,就把需求和客户达成共识,这之后使得我们技术部门十分被动,结果就是无法在规定时间上线,损失是小,在客户面前失信是大!)。

最后在需求后期,就可以出具项目需求初稿,这个初稿需要产品组根据时间要求以及客户要求,进行优先级划分,并将其划分为多个模块,分配给各个开发经理,制定Story或者backlog,再让开发经理细分task,分配给各个程序猿,从时间的角度,需要设定Sprint,并将各个story分配到各个Sprint中,一个Sprint的周期一般是2个星期(10个工作日),遇特殊情况可延长到3个星期。

这个过程中,最关键的是怎么规划Sprint,这个时候,对story时间的估算是非常关键的。我们以前都是程序猿们和产品经理坐在一起,为每个story一一估算时间。比如说一个story由2个人完成,2个人当然需要在事先了解需求,然后在对方不知道的情况下,分别估算对这个2个人完成的story需要花费多少天/人次,如果两个人时间接近,就去较大的那个天数作为估算的时间,比如一个人估3天,一个人估2天,那么这个story估算的总时间就是3天/人*2人=6天;如果两个人的差距相当大,比如一个人估了2天,另外个人估了10天,那就有需要让两个人说明原因,在排除了干扰因素后,再次估算,最后得出一个合理的时间。项目经理需要根据估算的总时间来安排Sprint里的story。

这些都准备完成后,就可以进行项目开发阶段了。

02

因为我是微软平台的苦B程序猿,所以我接下来用到的都是微软的工具。首先要有一个代码版本控制软件,我要在这里说的是TFS。微软的TFS有两个版本,一个叫Team Foundation Server,一个叫Team Foundation Service,小弟都用过,所以来说明下两者的区别:Server版需要公司用自己的服务器部署,比较适合局域网内开发的项目,当然也可以部署在公网,优点是可以最大程度的customize;Service版是部署在微软云上,由微软托管的,比较适合跨区域中小型公司(缺少硬件支持的),优点是方便,和office365账号绑定,公网也可以访问,缺点是无法自定义流程模板。

其他功能都是一样的。其实无论那个版本的TFS,功能都是非常强大的,完全可以满足敏捷开发项目需要。我曾听有人抱怨TFS只能给程序猿用,项目组又不装VS,不用用它来开task啊,开bug什么的,然后又去买了JIRA什么的专门给项目组用的流程控制工具,其实没必要,TFS有个service portal,类似于sharepoint的站点,可以用它来给项目组用,两个版本都有,非常好用。当然JIRA也是非常不错的,我们当时也是两个一起用,JIRA在自定义流程上面还是相当不错的,我们用JIRA来做部署流程控制以及运维流程控制等与代码本身关联不深的流程控制。

TFS在对代码版本及质量管理方面是很有优势的,我们会把sprint,story,task等等统统在开发阶段开始前录入TFS,这些都是TFS默认的模板,我们也可以自己更换或者修改模板,遗憾的是service版没法改。具体怎么修改可以参考MSDN。

 

一看就会的敏捷开发流程

 

一看就会的敏捷开发流程

然后我们可以通过规则,强制在check in代码的时候绑定task/bug/issue,以及强制写comment以及check in notes,这些都相当重要。当然,代码不能随随便便就能check in啊,最好需要有个人review,这个时候,我们可以先Shelve代码,然后可以指定一个人来给你review代码,review代码的人可以通过TFS自带的比较工具,比较shelve的代码和最新的代码间的区别,也可以给代码片段写comment,最后决定是否可以提交和需要打回去,重新shelve。

有人会觉得,这个好麻烦啊,不是会影响进度。我要说的是,如果没有这个环节,或许你可以很快速的完成开发,但别忘了,代码不是写完就算了的,代码的质量也是相当重要的,谁都不想,项目进入测试环节因为某个不该发生的问题而影响一轮测试,也不想在项目上线之后,因为性能问题,再来review所有代码,找到性能瓶颈......

顺便说下测试,测试不比开发轻松,一般测试分为smoke test,regression test,fuzz test,load test/performance test,security test。前两个不多说了,很熟悉了,后面三个很容易被忽视,但是却非常重要。有一句真理:任何一个软件,永远都存在bug,任何一种测试都无法把所有bug都找出来!

因此,我们需要在测试阶段尽可能地将简单明显的bug统统找出来,这样剩下的只是在特定情况下才会特别发生的bug。smoke test和regression test是为了找简单明显的bug,而fuzz,load,security等等测试是用来找出特定情况下的bug。fuzz能够很好地验证软件的健壮成都,它通过随机无序的任意输入,测试系统的内部应对及输出;load能够让系统在某个压力下测试系统的稳定性能,从而评估该系统/软件可以给多少人用,需要多少服务器,以及找出性能瓶颈,从而优化代码;安全测试可以测试系统的安全性,关于安全微软还有一套完整的流程叫SDL,就不详述了。

我们以前公司一直想做自动化测试,fuzz和load是可以自动化的,但是功能性测试做自动化比较困难,VS自身有针对web服务的自动化测试项目模板,有兴趣可以了解下。但个人觉得还不算理想中那种自动化。反正有大批测试妹子,全自动化了,公司里不就少了很多妹子,哈哈,扯远了。。。

再说下发布,在分布式的发布体系下,比较头疼的是,从QA到UAT,在到Staging和Production,各个环境可能需要不同的配置参数,尤其是SOA的系统,在分布式部署的时候,服务地址的配置通常非常头疼,最简单的方法是用配置文件的自动转换功能,也有公司自己做配置管理工具的,也有把配置移到数据库的。

个人觉得,有条件的可以自己开发套适合自己的配置工具,但是我作为一个从简主义者,我针对SOA系统,我的方法是这样的:首先,在每个环境的服务器集群之中,搞一台机器专门做内部的DNS服务器,我们在dns服务器上为每一个需要分布式部署的service定义一个内部域名,然后在配置文件中,都用这些预先定义好的内部域名,如果需要本地测试,可以修改自己机器的host文件,map到127.0.0.1或者具体的局域网IP地址,包括数据库地址也是可以这么做(这种方法对Azure SQL无效),然后发布到任何一个环境都不需要改跟地址有关的配置;对于一些跟环境相关的其他应用程序配置,本人建议存储到数据库或者做一个专门的配置服务。当在Staging上发布并测试完成后,Production就不要再发布了,通过交换绑定的IP地址来实现切换,具体如何实现是IT的事情,这里不说了。

03

终于一个阶段开发完成,可以顺利进入测试阶段了,这个时候,下个阶段的新需求就又来了,然后又是重复的步骤,估时间,sprint,story,写代码,测试,发布。

04

当产品上线后,肯定会遇到不少特定情况出现的bug,为了发现bug,要有监控系统,这又是一个大话题,暂时略过,然后发现问题后,要能够重现,然后需要评估问题的严重程度,然后根据协商结果,决定是否需要立马修复,还是进入下个发布周期修复,如果是需要立马修复的就要做hotfix,开maintainence window,走一边UAT-〉Staging-〉Production的过程,QA可以不走,因为有可能下个阶段的开发已经在QA上测试,如果下个阶段的开发已经在UAT上了,那么这么急的hotfix也没有意义了,如果下个阶段已在UAT,prod又出现无法运行的后果,那么把production再切会之前的在staging上的版本吧。关于数据库,staging和prod应该是需要工具来同步的。

2018-12-01 00:40:19 weixin_41282397 阅读数 20
  • SCRUM敏捷开发视频教程

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

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

最小可行化产品

硅谷创业家 Eric Rise 在其著作 《精益创业》 一书中提出了 “精益创业”(Lean Startup)的理念,其核心思想是,开发产品时先做出一个简单的原型——最小化可行产品,然后通过测试并收集用户的反馈,快速迭代,不断修正产品,最终适应市场的需求。

假如时光倒流,来到了2007 年,你要从零打造一个类似如今新浪微博的产品,有一系列需求摆在面前:

  1. 用户注册、登录
  2. 发布 140 字的文字微博
  3. 发布带图片的微博
  4. 发布带视频的微博
  5. 发布投票

现在面临两个选择:1. 花费 6 个月的时间,将以上的需求全部完成后上线,给用户一个强大功能的社交网站体验。2. 花费 2 个月时间,完成用户注册登录和发布文字的功能,让用户最快体验到这个功能相对较弱的全新社交产品,在接下来的时间里,根据用户反馈,完善已有功能,同时开发上传图片的功能,一旦开发测试完成,就立即上线。以小步快跑的节奏不断完成需求表格中的其他需求。

精益创业的思想就是采用第二种方案进行渐进式开发,这样的开发模式有诸多好处:

  1. 最小可行化产品能在最短的时间内完成开发,以最快的速度验证用户需求
  2. 时间早意味着具有先发优势,方便更早地积累用户,这一点在社交产品上尤为明显,后发的同类产品往往需要背负“模仿”的帽子
  3. 能第一时间听到用户的声音,最大程度避免了产品方向上的错误

敏捷开发模式(Scrum)实际上是精益创业思想的实践指南。

敏捷开发模式

敏捷开发采用循序渐进的方法进行软件开发,把一个大项目分为多个相互联系,但也可独立运行的小项目,分别去完成,在此过程中软件一直处于可使用状态,具体流程如下:

1. 梳理产品需求(Product Backlog)

在开发之前,一定会有一个需求列表,定义了产品在接下来需要具备的特性和功能,一般由产品经理来定义,在敏捷流程中,称这个人为 Product Owner(PO)。定义 Product Backlog 时,需要遵循 INVEST 原则,即:

  • Independent 独立的,尽量和其他需求没有依赖
  • Negotiable 可讨价还价的
  • Valuable 有价值的
  • Estimable 可预估的
  • Small 足够小,拆分到一个迭代内能完成
  • Testable 可被测试的

定义需求的同时,Product Owner 还需要定义需求的优先级,定义优先级可以借助一个公式:功能带来的的价值除以实现难度, 这个值越大则代表优先级越高。

2. 制定迭代计划

一般规定两周( 10 个工作日)为一个迭代,在迭代开始之前,需要召开迭代计划会制定这一个迭代的计划,把 Product Backlog 按照优先级排序,由 PO 为大家讲解具体每一个需求,团队成员根据需求的复杂程度评估每个任务的工作量,当前 n 个任务的工作量之和约等于团队总工时时,那么这个迭代就把 Product Backlog 中前 n 个任务作为这次迭代的任务,在敏捷中称之为 Sprint Backlog。

团队总工时的计算方法:如果团队有 5 个工程师,一个迭代的工时为 5 * 10=50 人日,考虑到工作效率和其他的意外情况,再乘以 80% ,那么最终实际用于开发的工时为 40 人日,有些团队会以小时作为单位,同理,只需将单位换成小时。

团队需要把 Sprint Backlog 和预估的时间写在便签纸上,把它们贴在白板上,白板划分成三大块:未开始、进行中、已完成,当然,所有 Sprint Backlog 的状态开始都应放在未开始那一列。

3. 迭代执行

在迭代进行期间,由大家认领白板上的 Backlog,每天早上要开一个每日站会,时间在 10 分钟以内,由大家依次报告:

  1. 我昨天做了什么
  2. 今天计划要做什么
  3. 遇到了哪些问题

每日站会强迫每个人向同伴报告进度,迫使大家把问题摆在明面上,尽可能让信息公开透明。报告进度的同时移动对应的卡片到合适的位置,修改 Backlog 剩余所需要的工作量,Scrum Master 需要统计剩余所有的工时,更新到燃尽图中。当燃尽图的走到 0 ,就意味着完成了这个迭代中所有的任务。

燃尽图

燃尽图

4. 迭代总结

迭代的最后一天,还有两个环节要做:成果展示和团队的内部总结。

成果展示环节要求团队成员在这个迭代中自己完成的任务展示给所有人看,除了团队内部所有成员以外,还可以邀请领导等关心项目进展的人。内部总结则只在团队内部进行,总结这个迭代中做的好的地方以及不好的地方,接下来如何改进等。

以上是实施敏捷开发模式的大致流程,当然,在实际执行过程中会遇到或多或少的问题,一般需要几个迭代的熟悉和磨合。

 

参考文献:

https://www.jianshu.com/p/9308a4cffaf7

https://cloud.tencent.com/developer/article/1040819

敏捷开发 迭代流程

阅读数 7478

敏捷开发流程总结

阅读数 113226

敏捷测试开发流程

阅读数 1080

设计敏捷开发流程

阅读数 281

敏捷开发流程

阅读数 24

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