2015-09-29 22:21:25 jnqqls 阅读数 7543
  • SCRUM敏捷开发视频教程

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

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

        

        通过上篇文章我们已经知道了敏捷角色中PO的角色内容,接下来的一个敏捷角色在敏捷开发中非常关键,但是往往很多项目实践中都没有很好的把控好这个角色,让他或多或少的没有起到相应的作用,这个角色就是ScrumMaster.

 

Scrum Master(SM)

 

        敏捷开发中的SM即ScrumMaster,字面意思是敏捷专家或者敏捷大师,即熟悉敏捷开发模式及敏捷实施流程的人员,一般可由敏捷团队当中的开发负责人担任,部分能力很强且懂技术的产品经理也可担任这个角色,因涉及到工作量评估和分派等工作,最好都是由技术能力较强的人员担任。

 

       Scrum Master是团队的导师和组织者,与ProductOwner紧密合作,及时为团队成员提供帮助。促使team按照scrum方式运行,为Scrum过程负责的人。

 

       ScrumMaster并非团队的领导(因为团队是自我组织的),而是一个负责屏蔽外界对开发团队干扰的角色。 ScrumMaster是规则的执行者,他是Scrum团队中的服务型领导。

 

       这一点在实际项目经验中是很难达到的,因为想要达成自我组织的团队并非一朝一夕,尤其是新组建的团队,本身团队就是一个磨合的过程,只不过我们是通过哪种方式可以磨合的更快,更有效率.如果SM这个角色能够很好的担当和把控,非常有利于整个团队的磨合.

 

Scrum Master主要工作职责

 

      确保scrum被理解和正确使用并使得Scrum的收益最大化。主要职责如下:

 

1、保证团队资源合理利用;

 

2、保证各个角色及职责良好协作;

 

3、解决团队开发中的障碍;

 

4、作为团队和团队外部的接口,协调解决沟通中的问题;

 

5、保证开发过程按计划进行,组织ScrumPlanning Meetings(Sprint计划会议), Daily Stand-up Meeting(每日站会), Sprint ReviewMeeting(Sprint评审会)和 Sprint Retrospective Meeting(Sprint回顾会)。

 

            结合我们项目中的实践,SM的角色一直处于变化的过程中,大概在项目进行半年之后才稳定下来,前期因为变更着,导致项目整体比较混乱,没有一个主线.SM稳定之后,整个局面有好转,但是并没有预期的效果好.

 

        总结SM这个角色就是:教整个团队怎么做,如何估时,跟进每天进度,风险控制,定期总结,计划排定。

 

2018-05-10 09:31:13 An1090239782 阅读数 3180
  • SCRUM敏捷开发视频教程

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

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



记录一些优秀的敏捷开发案例或经验:

敏捷开发:项目管理的一些思考
w_fsovereign:三个月(敏捷)项目收获
RobinsonZhang:敏捷开发入门



一、敏捷过程

敏捷开发是一种以人为核心,以迭代方式循序渐进开发的方法,其软件开发的过程称为“敏捷过程”。
在这一过程中,软件项目的构建被切分成多个子项目,各个子项目的成功都经过测试,具备集成和可运行的特征。
在2001年年初,一些业界专家成立了敏捷联盟,起草了敏捷软件开发宣言。该宣言针对一些企业的现状,提出了让软件开发团队具有快速工作、快速应变能力的若干价值观和原则,其中包括4个简单的价值观以及敏捷开发方法应遵循的12条原则。

1.1 敏捷开发的价值观

  1. 个人和交互胜过过程和工具。
  2. 可以运行的软件胜过面面俱到的文档。
  3. 客户合作胜过合同谈判。
  4. 响应变化胜过遵循计划。

1.2 敏捷开发应遵循的12条原则

  1. 通过尽早的、不断地提交有价值的软件来使客户满意。
  2. 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
  3. 以从几个星期到几个月为周期,尽快、不断地提交可运行的软件。
  4. 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
  5. 以积极向上的员工为中心,建立项目组,给他们提供所需的环境和支持,并对他们的工作予以充分的信任。
  6. 在团队内部,最有效、效率最高的传递信息的方法,就是面对面的交流。
  7. 测量项目进展的首要依据是可运行软件。
  8. 敏捷过程提倡可持续的开发,责任人、开发者和用户应该为能够保持一个长期的、恒定的开发速度而努力。
  9. 时刻关注技术上的精益求精和好的设计,以增强敏捷能力。
  10. 简单是最根本的。
  11. 最好的构架、需求和设计出于自组织的团队。
  12. 每隔一定时间,团队要反省如何才能更有效地工作,然后相应地调整自己的行为。

敏捷组织提出的敏捷开发模型的整体框架主要有三个:
Scrum、XP(eXtreme Programming)、OpenUP 这3个敏捷实践。



二、敏捷开发的原则

  1. 凝聚人的力量,紧密协(合)作。包括业务负责人、开发团队、客户、管理者之间的关系,所有这些关系在以前都是造成项目危机的原因之一,那么,在敏捷时代,我们需要这些角色 紧密合作,最大限度的发挥各个角色的力量.
  2. 聚焦客户价值,消除浪费(如何聚焦用户价值,即频繁的交付用户可工作的软件,快速收到用户反馈)

2.1 敏捷团队运作机制

  1. 一个团队有自己的代办事项,对代办事项进行拆小。
  2. 按客户价值进行优先级排序,产品经理负责价值排序。
  3. 小而稳定,跨职能团队。
  4. 多个团队松耦合(依赖性比较低),对齐迭代时间和战略目标。

2.2 关键的团队角色

  • 产品负责人
  • Scrum主管(流程主管)
  • 开发团队

2.3 产品负责人(Product Owner)

  • 负责管理产品backlog(代办事项)的唯一负责人
  • 代表客户/项目如责任人
  • 定义产品的所有特性
  • 负责产品的投入产出
  • 负责最大化产品和开发团队工作的价值

2.4 Scrum Master(流程主管)

  • 起到教练的职责,领导团队完成Scrum的实践以及体现其价值。
  • 排除团队遇到的困难,使得团队紧密合作,使得团队个人具有多方面职能的工作能力。
  • 确保团队能胜任其工作,并保持高效的生产率。
  • 保护团队不受到外来无端影响

2.5 关键的团队活动

  • 每日例会:每日5分钟左右的一个简单例会,尽可能多的开发人员参与进来对紧要问题的讨论。
  • 评审会:需要在迭代周期的最后一天召开,1个小时左右就可以了,需要客户出席,如果客户不能出席,则需要产品经理出席
  • 迭代回顾会:迭代回顾会是在每个迭代结束时进行,总结工作中的经验和教训,时间维持在30-60分钟内,整个团队都需要参加(Scrum Master、Product Owner、开发团队以及客户)。迭代回顾会包括两部分,第一部分是定量分析,第二部分是定性分析。其中定量分析又包含团队是否完成了迭代目标,收集并评审迭代度量指标(包括速率、迭代燃尽图、迭代计划故事和实际完成故事、计划发布日期与实际发布日期、客户满意度、团队满意度、生产环境Bug数、生产Bug解决时间、用户故事等)。定性分析包含哪些工作良好(应该继续保持),哪些做的不好(应该停止)?哪些可以改进(团队选出1-2条在下一个迭代实现)?

敏捷开发
作者:木可大大

三、敏捷团队的五个约定

3.1 约定1. 业务分析师们,我们其实是同一个角色的两种面孔,请叫上我们参加客户需求会议

我们的团队需要让客户频繁的得到可用的软件,客户的不断反馈会给软件的未来做出最正确的方向指引。

如果我们交付的软件有很多质量的问题,存在大量的缺陷,客户会被这些缺陷的奇怪行为干扰,没有办法把注意力放在软件本身的价值是否符合他们的真正需求上,
不能给出最有价值的反馈。所以,我们只有频繁的做测试,在每次交付之前都把质量问题找出来告诉我们的团队,问题才能及时的得到改正。

而我坚信“prevention is better than
cure”(预防胜于治疗),我会要把工作的重点放在预防缺陷上,这样可以节省Dev们很多修复缺陷的时间与精力。

为了达到这个目的,我需要跟你一起参加客户需求会议,尽早的了解客户需求与使用软件的惯常行为。那么在你完成需求的验收条件的定义的时候,我也基本完成了测试用例的准备。

我们可以赶在开发人员们写代码之前就告诉他们我要测什么,让他们减少因为过于乐观而漏掉的一些重要的有破坏性的情况,减少缺陷的发生。这是我测试的一项重要任务。

如果你们在大部分需求都整理好了再交给我们,我会浪费掉等待的时间。更重要的是,开发好的软件里面已经有很多本来可以不存在的缺陷在里面了,开发人员们可能需要加班加点来保证在项目最终交付时间之前把它们改好。这样很容易产生新的缺陷的。

所以,请让我尽早了解需求,请不要让我到项目后期才能开始测试。

3.2 约定5. 测试人员们,那些敏捷实践对于我们也是有用的。

如果你发现开发人员们做出的架构决定使测试工作变得更困难。那么请大声地告诉他们,design for testability(提高你们设计的可测性)。

如果你发现业务分析师写的需求无法验证,定义的客户行为不够具体,一个用户故事中包含太多了功能点,等等,那么也请大声地告诉他,INVEST(独立,可协商,价值,可估算,短小,可测)。

也请你们多跟开发人员结对写自动化测试,既可以帮助你们学习怎样更好的编写自动化测试,也能帮助开发人员们结对更多的了解用户行为。

我和敏捷团队的五个约定

四、敏捷开发的前置条件

4.1 比较固定的流程,文档,需求

  1. 需求是控制稳定性的根本,对于需求一定是整体可控的,并且是可以由迭代内进行调整的,而不是定死的
  2. 流程是指什么时间什么人该做什么事是高效的,明确的
  3. 文档是指每个流程阶段具有可交付或者可查阅参考文档,不是口头或者个人评定。

4.2 可灵活调整,允许试错

  • 检查

检查是指在每天的站会中检查每个人的工作状态,是否能完成自己的任务,存在什么问题,完成效果如何。另外就是保证整体在每天的进度,是否有有整体效果,如果没有完成今天的整体效果,需要检查是否符合整体迭代。

  • 调整

调整是指检查发现迭代的进度或者外界环境发生变化时,及时调整当前迭代的开发任务,保证迭代最终产物的准确及时性变动。当然,这种变动是不允许太多的,一般情况下在需求没有做详细分析时,不接受;在当前有风险的情况下,撤销某些需求;其他情况不做描述。

  • 试错

正是由于检查以及调整的策略,保证了迭代的灵活性,我们可以在敏捷团队中尝试一些较革新、新的功能点或者技术点,如果实验成功则可以对外拓展;如果不行,可以快速切换方案。

4.3 问题场景&&错误认识

  • 一个团队闭关开发一个项目就是敏捷

正确理解:敏捷不等于闭关,只是可能坐一起效率更高,其倡导的是何时都可以发生沟通,并准备一白板可以随时讨论方案;敏捷团队质量以及效率高于一般团队;敏捷团队开发的是以迭代为单位,不是项目;

  • 有了任务细分,开发白板,站会就是敏捷

正确理解:任务细分、白板、站会都是其形式,关键还是其将迭代的内容进行细化,可执行化,用高频的沟通反馈提高开发、沟通、理解的效率。

  • 敏捷团队没有特殊前置条件

正确理解:前面有讲到敏捷对团队,需求,文档,流程,调整等都有比较完整的规定。

  • 敏捷团队做的事情没有差别性

正确理解:敏捷完成的任务具有明细化,分阶段性,可调整性。所以在开发相关任务时,也具有类似的特点。

  • 敏捷团队会完整完美的交付产物

正确理解:敏捷在迭代结束只交付该阶段的可交付产物,很可能不完整不完美,对于可交付也有不同的理解。

2019-05-18 18:58:21 Peter_Changyb 阅读数 567
  • SCRUM敏捷开发视频教程

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

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

    敏捷开发中的POProduct Owner,产品或业务负责人,即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员,一般可由产品经理担任,也可由熟悉业务的开发人员担任。如果敏捷团队是在一起办公的,建议由产品经理担任,本身产品经理已经是所有业务的接口人,熟悉业务是其本职工作;如果产品经理和开发、测试团队是两地办公的,如设立的研发中心、外包服务等形式的,建议在开发团队内指定一个人来担任PO,这样产品经理在第一次PRD全体review之后,只需跟这个PO讲解清楚产品逻辑,后续开发和测试当中遇到的问题,都可以咨询PO来得到解决,PO不确定的可以联系产品经理确认,这样可以减少一部分的沟通成本。

    敏捷开发中的SMScrum Master,字面意思是敏捷专家或者敏捷大师,即熟悉敏捷开发模式及敏捷实施流程的人员,一般可由敏捷团队当中的开发负责人担任,部分能力很强且懂技术的产品经理也可担任这个角色,因涉及到工作量评估和分派等工作,最好都是由技术能力较强的人员担任。

Product OwnerPO

Product Owner角色定义

确定产品的方向和愿景,定义产品发布的内容、优先级及交付时间,为产品ROIprofitability of product)负责。 是维护产品需求清单( product backlog )的人,代表利益相关者的利益。

Product Owner工作职责

负责最大化产品以及开发团队工作的价值。主要职责如下:

1、确定产品的功能;

2、决定发布的日期和发布内容;

3、为产品的ROI负责;

4、根据市场价值确定功能优先级;

5、每个sprint中,根据需要调整功能和优先级(每个sprint开始前调整);

6、接受或拒绝开发团队的工作成果;

7、参与Scrum Planning MeetingsSprint计划会议),Sprint Review MeetingSprint评审会)和 Sprint Retrospective MeetingSprint回顾会)

Product Owner在团队中的作用

junior团队中:主要的需求来源,个人确定需求价值和优先级

intermediate团队中:多角度的收集需求,和团队成员共同确定需求的价值和优先级

Senior团队中:和团队成员共同提出和收集需求,共同对产品负责

这里的团队分级主要是指团队的敏捷成熟度,即产品团队实施敏捷开发模式后,对敏捷开发模式的适应程度、接受程度和学习程度。后面会专门介绍团队的评估标准。

一句话总结PO这个角色就是:告诉产品团队要做什么,做功能的先后顺序是怎样的,需求有变动时该如何处理。

Scrum MasterSM

Scrum Master角色定义

是团队的导师和组织者,与Product Owner紧密合作,及时为团队成员提供帮助。促使team按照scrum方式运行,为Scrum过程负责的人。

Scrum Master并非团队的领导(因为团队是自我组织的),而是一个负责屏蔽外界对开发团队干扰的角色。 Scrum Master是规则的执行者,他是Scrum团队中的服务型领导。

Scrum Master工作职责

确保scrum被理解和正确使用并使得Scrum的收益最大化。主要职责如下:

1、保证团队资源合理利用;

2、保证各个角色及职责良好协作;

3、解决团队开发中的障碍;

4、作为团队和团队外部的接口,协调解决沟通中的问题;

5、保证开发过程按计划进行,组织Scrum Planning MeetingsSprint计划会议), Daily Stand-up Meeting(每日站会), Sprint Review MeetingSprint评审会)和 Sprint Retrospective MeetingSprint回顾会)。

Scrum Master在团队中的作用

junior团队中:主导和控制

intermediate团队中:引导和教导

Senior团队中:辅导和协助

一句话总结SM这个角色就是:教整个团队怎么做,如何估时,跟进每天进度,风险控制,定期总结,计划排定。

2016-07-26 07:55:46 qq_28391549 阅读数 1217
  • SCRUM敏捷开发视频教程

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

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

讲到敏捷开发,那么在每个team里面,都会有一个叫做PO(project owner)的角色.

在敏捷开发中,PO这个角色扮演了很关键的作用。

首先讲讲PO都会干些什么:
1 PO是开发team与客户之间的桥梁,他负责与客户沟通,并且商量需求。
2 从客户那边确认了所有的需求之后,PO需要对这些需求做一个优先级的排序,可以让开发人员知道首先应该实现哪些需求。

根据PO的工作性质,我们可以发现,PO必须你具备良好的沟通能力,这是必要的。并且还有一点也很重要,PO必须你要是一个对项目十分了解的一个人,因为只有对项目十分了解,才能够对接到的需求进行优先级的排序。
所以,PO对于开发team来说是有一定风险的,如果沟通不到位,需求理解不正确,或者优先级决定有问题,都可能导致team无法及时给出阶段性的产品,就算给出,可能也达不到客户所要的需求。

这只是我自己对于敏捷开发的一点见解,可能有很多不对的地方,大家看看就好。

2020-01-07 14:23:28 gao2175 阅读数 31
  • SCRUM敏捷开发视频教程

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

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

本文主要从Scrum的定义和目的、敏捷宣言、Scrum中的人员角色、Scrum开发流程、敏捷的12原则等几方面帮助大家理解Scrum敏捷开发的全过程。

一、Scrum的定义和目的

Scrum是一个用于开发和维护复杂产品的框架,是一个增量的、迭代的开发过程,目的是让开发人员像打橄榄球一样迅猛并充满激情,通过团队合作,提高工作效率。通过团队间的有效交互,为企业创造价值。

二、敏捷宣言

其实,在发表《敏捷宣言》之前,很多的敏捷实践都已经存在且使用了,比如:Scrum、XP、KanBan等。之所以发表《敏捷宣言》,是因为这些实践都是在单打独斗地推进敏捷开发,而不是以一个联合体的形式,且没有一个统一的指导方针。所以17位敏捷联合创始人决定发表《敏捷宣言》,共同在全世界推进敏捷开发运动。下面是敏捷宣言的4句话:

 

敏捷开发流程之Scrum:3个角色、5个会议、12原则

 

 

三、Scrum中的人员角色

3个角色

Scrum中的人员分为3个角色:产品所有者(Product Owner), Scrum Master,开发团队(Team)。

  • 产品所有者:定义所有产品功能,决定产品发布的内容以及日期,对产品的投入产出负责,根据市场变化对需要开发的功能排列优先顺序,合理地调整产品功能和迭代顺序,认同或者拒绝迭代的交付。
  • ScrumMaster :ScrumMaster不是项目经理,他没有分配任务的权力,没有考核的权力,没有下命令的权力,他指导项目组的成员按照Scrum的原则、方法做事情,领导团队完成Scrum的实践以及体现其价值,排除团队遇到的困难,确保团队胜任其工作,并保持高效的生产率,使得团队紧密合作,使得团队个人具有多方面职能的工作能力,保护团队不受到外来无端影响。
  • 开发团队:经典团队拥有 5-9 人,团队成员包含程序员、测试员、用户体验设计等等,团队关系在一个迭代中应该是固定的,个人的职能可以在新迭代开始时发生调整,团队自我组织和管理(自组织,自驱动),团队成员都全职工作。

四、Scrum的开发流程

 

敏捷开发流程之Scrum:3个角色、5个会议、12原则

(图片源自网络)

 

不同于瀑布模型将开发过程划分为需求、设计、编码、测试等阶段,Scrum将整个开发过程分为多次迭代(称为Sprint,冲刺),一般为期2~4周,最常见的为2周。Scrum并非以一段时间集中完成一个过程,而是将所有过程中必须的每一部分集中在这段时间内完成。需求、设计、编码、测试、上线都必须在一个迭代中完成,每个迭代必须产生一个可以工作的软件。

4.1 五个会议

Scrum 整个开发过程分为五个会议:

1)待办事项整理会议(Backlog Grooming Meeting)

迭代计划会议开始之前3天召开,Product Owner与Scrum Master必须参加,关键开发者或架构师需要参加;时间控制在30分钟到1小时。

由Product Owner将一批希望团队在下次迭代时实现的用户故事,按照实现顺序描述给在场的团队成员,Scrum Master与在场成员分析用户故事,明确指出团队认为需求不明确的地方,Product Owner现场记录,会后补全,Scrum Master与架构师,还有在场成员分析用户故事需要包含哪些技术任务,Scrum Master先把子任务建立,方便迭代计划会议的时候团队可以更准确地预估任务故事点。

会议结束时,Product Owner确保在迭代计划会议开始之前团队提出的问题都能被解决,会议重点如果团队发现需要加强或是完善的地方,Product Owner还有两到三天的时间可以补强,而不是浪费迭代计划会议的时间去做这件事情。

2)迭代计划会议(Sprint Planning Meeting)

产品负责人建立产品功能列表(Product Backlog)。产品功能列表是一组条目化需求,它必须从客户价值角度描述,并按优先级排序。

Scrum Master召集相关人员召开迭代计划会,迭代计划会在每个迭代第一天召开,目的是选择本次迭代的Backlog和估算本次迭代的工作量。

产品负责人逐条讲解最重要的产品功能,开发团队共同估算Backlog所需工作量,直到本迭代工作量达到饱和。产品负责人参与讨论并回答和需求相关的问题,但不干扰估算结果。队员认领任务(或由组长协商分发),独立或与别人一起完成任务;会议时间控制在1-2小时内。

3)每日站会(Standup Meeting)

团队内部利用每日立会来沟通进度,15分钟结束,开发团队利用燃尽图来展示整体进度;如无特殊原因,迭代期内无变更,在每日站会上团队成员需要回答以下3个问题:

  • 昨天你做了什么?
  • 今天你将要做什么?
  • 你有需要帮助的地方吗?

这些都是团队成员的彼此承诺。

4)评审会(Retrospective Meeting)

小组向产品负责人展示迭代工作结果,产品负责人给出评价和反馈。以用户故事是否能成功交付来评价任务完成情况。整个团队都需要参加,ScrumMaster、产品所有者、团队,可能还有客户,时间控制在1-2小时内。

5)反思会(Retrospective Meeting)

在每个迭代后召开简短的反思会,总结哪些事情做得好,哪些事情做得不好。做得好的保留,不好的摒弃。会议得出这样的结论:开始做什么、继续做什么、停止做什么,一般控制在15-30分钟。

Scrum是一套开发流程,是敏捷的一种,实施主要还是看人,强调是自组织、自驱动的,只有不断的在实际应用中仔细体会,才能理解Scrum的真谛,把Scrum用好。

4.2 12原则

下面给出敏捷开发的12原则,这12原则作为敏捷开发对于软件开发流程的指导性纲领,也是对敏捷宣言进行了具有实际操作意义的解释,希望大家在实际应用中仔细体会。

我们遵循以下准则:

  • 我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。
  • 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。
  • 要不断交付可用的软件,周期从几周到几个月不等,且越短越好。
  • 项目过程中,业务人员与开发人员必须在一起工作。
  • 要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。
  • 无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。
  • 可用的软件是衡量进度的主要指标。
  • 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
  • 对技术的精益求精以及对设计的不断完善将提升敏捷性。
  • 要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。
  • 最佳的架构、需求和设计出自于自组织的团队。
  • 团队要定期反省如何能够做到更有效,并相应地调整团队的行为。

作者:史文帅

来源:宜信技术学院

敏捷开发

阅读数 9

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