2017-04-01 14:30:30 English0523 阅读数 8203
  • SCRUM敏捷开发视频教程

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

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

从敏捷开发流程模型图当中可以看出,在敏捷实施过程当中,有四种会议,分别是计划会,每日站会,回顾会,评审会,其中数计划会最为重要。应该来说会议是有点多的,不是流传一种说法嘛,不开会的团队的一定不是一个好团队,好的团队一定经常开会。经常开会是需要时间的,因此有利有弊,如果会议时间和节奏控制的不好,就会占用掉团队很多的精力和工作时间,那就得不偿失了。在敏捷开发模式中,每种会议都有其特殊的职责和使命,不同的会议上所讨论的内容是不一致的,只要把握住会议的关键点,就可以为团队的敏捷模式服务。

关于开会,日常工作当中各种会议、培训、沟通等都会占用掉大量的工作时间,因此会议贵精不贵多,在最短的时间内达成最有效的决议,这才是一个有成果的好会议。产品团队必然也会面临这样的问题,在敏捷团队内部,除了必要的全员培训外,尽量保持在团队内部只有敏捷的这四个会议,其余的沟通和会议都可以由PO和SM去参加,然后回来传达给团队成员即可,这样可以减少团队整体的时间消耗,保证团队的工作效率。

Scrum-workflow

Sprint Planning敏捷迭代计划会议

在每个敏捷迭代开始之初,由产品负责人讲解需求,并由开发团队进行估算工时的计划会议。 在会议上需要:排列需求优先级;分析和评估产品Backlog并确定该迭代的目标;计划会议上还需要制定迭代计划,包括: 根据产品Backlog(功能点)创建Sprint Backlog(即迭代任务);然后为Sprint backlog中的任务做估算;团队成员从产品Backlog中挑选他们承诺完成的条目。

敏捷的迭代实现始于计划会议,所以一个好的计划会议是每个迭代成功的基础,一般分两个阶段进行,两个阶段参与会议的人员会不一样;

计划会议的目标:

1、基于敏捷规划产生的Product Backlog以及优先级,通过计划会议,确定迭代的目标、团队成员、形成Sprint Backlog,明确评审会、回顾会时间;

2、分解Sprint Backlog并确定相应的完成时间,并由团队成员共同挑选这些Sprint Backlog;

阶段一参与人员:产品经理、Product Owner、Scrum Master、团队成员,有业务人员的话还可以邀请业务人员一起参加。

会议时长:1-4小时

一般参考进程安排如下:

1、Scrum Master公开迭代时间表;

2、产品经理和Product Owner讲述Product Backlog,对应的业务价值和优先级;

3、团队针对Sprint Backlog和优先级达成一致;

4、Scrum Master和团队成员共同确定Sprint Backlog;

阶段二参与人员:Scrum Master、团队成员,其他人员选择性参加

会议时长:1-4小时

一般参考进程安排如下:

1、团队成员针对Sprint Backlog共同分解任务;

2、团队成员共同进行工作量评估(每个Task不超过2天),确定开始时间和完成时间;

3、团队成员共同认领任务;

4、共同确定DoD,团队达成一致;

5、团队共同确认迭代目标和价值;

如果单个迭代内安排的Product Backlog安排的比较多的话,一般迭代计划会议需要开一个整天,虽然时间有点长,但这个会议会确认整个迭代的详细计划和安排,因此也是值得的。

Daily Stand-up Meeting每日站会

团队每天进行沟通的内部短会,因一般只有15分钟且站立进行而得名,团队成员通常会在会议上讲述如下3点内容:

1) 昨天我做了什么

2) 今天我计划要做什么

3) 我遇到了什么问题,妨碍了我尽可能有效地工作

Scrum Master记录会议上提出的问题,但是不要在会议上讨论和解决问题,而是要会后在找相关人员进行讨论和解决。

Sprint Review敏捷迭代评审会议

在迭代结束前给产品负责人演示并接受评价的会议,并根据反馈结果,提出新的产品Backlog

参与人员:产品经理、Product Owner、Scrum Master、团队所有成员

会议时长:1-4小时,视演示内容而定

主要是检验迭代成果,检查是否完成迭代计划中的迭代目标,有可能的话要求用户参与测试流程,并得到用户对产品的认可,鼓励用户自己进行测试设计和进行破坏性测试,充分暴露产品的设计和功能问题。

由Scrum Master来推进会议进程,Product Owner记录用户反馈,根据结果维护产品 backlog,一般在迭代结束前做一次。

Sprint Retrospective敏捷迭代回顾会议

在每个迭代结束后召开的关于自我持续改进的会议,围绕如下三个问题进行讨论:

1) 本次迭代有哪些做得好;

2) 本次迭代我们在哪些方面还能做得更好;

3) 我们在下次迭代准备在哪些方面改进;

团队确定问题优先级,并根据优先级确定团队能够解决的Top问题;团队讨论Top问题的措施,并选择在下一个迭代可以完成措施,分配责任人进行跟踪。

参与人员:Scrum Master,Product Owner,团队成员。

会议时长:0.5-1.5小时

主要针对当前迭代,团队成员自由讲述可以需要保持的做法,改进的点以及持续跟踪计划。

Scrum Master将团队讨论以及行动计划形成会议纪要,并发送给整个团队和有关同事。需要按照回顾会议的结论,维护一份待办事项列表,在下次回顾会议上进行跟踪。

案例分析

案例一:某Team在每日站会中,Scrum master准时组织大家开始晨会,成员一个接着一个说,昨天做了什么事情,今天计划做什么事情,遇到什么问题,成员A说昨天遇到了一个问题未能解决,Scrum master问遇到的是什么问题,成员A详细说明了该问题,这时成员B说这个问题他也遇到过,他是通过XX方式解决的,讨论后成员A明白了,然后继续晨会,由于小组成员有10个人,整个会议开下来大概花费了30分钟。

问题分析:Scrum master不应该在每日站会上询问详细的问题细节,而应该转移到会下询问,当团队成员之间进行讨论的时候,Scrum master需要及时拉回来,讨论应该转移到会下进行,晨会要在固定的时间固定的地方并且在固定的时间内完成。会议时间需要控制在15分钟之内。

案例二:某Team在开回顾会议中,Scrum master详细总结了本次迭代中有哪些做不够好的,并指出了对应的事和人,接着对应的责任人开始述说哪些地方确实是做的不够好及其原因,最后给出改进措施然后结束会议。

问题分析:回顾会不是批斗会,不应该只说做的不好的,做的好的也要说,Scrum master主要是鼓舞大家的士气,应该先从做的好的方面开始说起;并且做的不好的方面都只对事,不对人,做的不好是整个Team的责任,不仅仅是某几个人的责任;最后的改进措施需要给有后续跟踪的责任人和有效性的反馈。

在敏捷的迭代执行过程中,上述四种会议会随着每个迭代一直进行,基本上形成了一个闭环,可以让团队在每个迭代的执行过程当中去学习和总结,从而正确的按照敏捷的要求去做,使团队真正的敏捷起来。

2017-06-22 14:52:44 kic18 阅读数 2760
  • SCRUM敏捷开发视频教程

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

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

保持透明性、检视与调整是Scrum的三大支柱,
以此作为支撑我们才可以对整个开发过程进行持续的改善。

回顾会议是Scrum检视与调整的一个重要的环节,在这个会议上,ScrumMaster鼓励团队在Scrum过程框架和时间范围内,
对自己的开发过程进行改进,并确定什么样的调整可以使下一Sprint的效率更高、结果更令人满意和更易于工作。
回顾会议旨在对前一个Sprint周期中的人、关系、过程和工具进行检验。
检验要确定好的做法继续保持,以及需要摒弃或改善的做法。

这些包括:Scrum团队构成、会议安排、工具、“完成”定义、沟通方法和将产品Backlog条目转化成“完成”工作的过程。
在Sprint回顾会议的最后,Scrum团队应该确定将要在下个Sprint中实现的有效改进方法,并在接下来的Sprint中付诸行动。

然而,开好回顾会议,让其起到促进团队持续改善的效果并非易事。
要开好回顾会议对会议的形式、主持人的协调能力都有很高的要求。

如果回顾会议过于形式化和刻板则会使团队丧失参与的兴趣,
不利于团队成员说出真实的想法,也不利于发掘更有效的改进建议。

ScrumChina linkedin group(http://www.linkedin.com/groups?gid=3343227
对此进行了热烈的讨论,也分享了不少有用的实践,许多参与者认为回顾会议应该保持轻松愉快的氛围,
让大家畅所欲言,在这里挑出其中的一些供大家参考:

Jingbin Liao:建议增加一个感谢环节,每个人都可以感谢其他人对我的帮助,感谢某某某对团队做出的贡献。

Kai Wang :我们的实践一般会再加一个问题:对于not working的,
我们要采取什么行动 如果这个sprint提的行动,到下一个sprint还没有执行,就加大一个字号,
到下下一个sprint还没有执行,就再加大一个字号,以此类推。

Hongquan Yin : 讨论什么不好,然后就要想出解决的方法。
另外反思会另外一点就是增进团队成员之间的情感交流,因为我发现在做scrum task的时候,更多的是就事论事,比较干燥。

Fred Liu :retrospective是对过程的反思,形式不固定,搞点活泼的也挺好,不过主题不要跑偏了。 说不定可以来点禅家的冥想
Mike Li :制作一些表情符,用这种方式让大家表达一下对Sprint的感受,高兴?沮丧?激动?无所谓?

Mark He : 个人觉得Retrospective最重要还是要能听到真话,Team和个人的Pain Point是什么,以便持续改进。
所以除了什么方面做的好,什么不好之外,一般我会在回顾会议开始加小环节,
总结通报上次会议定下来的行动列表,哪些做了,哪些还没有,没有做的联系人是谁,原因是什么,接下来会怎么做。
回顾会议的结尾,也会做个小结,根据会议内容列出行动列表,便于后期检查。
见过有Team开了会但是没有行动列表的,没有实实在在的解决问题,结果每次开讨论的问题都差不多,最后Team就皮掉了。
当然这个方法未必就一定好,只是个人几次实践下来发现效果还可以,至少Team知道确确实实重视他们的意见,也在不断改进,就会更加愿意说真话,良性循环 。

De Yi (Linda) Liu:我们的做法是(个人感觉很有效):每人发三张便签纸,
分别写下: – What to Keep – What to Change – What to Try
每张纸上不能超过三条。如果实在没有,也可以不写,或少于三条,但不能一张也不写。
(可以记名,也可以不记名,由Team自己决定) 然后把所有的纸条收集到一起,贴到白板上,总结出每一项的Top 3。
经过小组一致同意,确定下来。在新的Sprint中随时跟踪执行情况,并在下一个Retrospective的时候总结。
这样做有很多好处: – 每个人都得以发言 – 大家不会受到某些比较“积极”发言的人的影响 我们在使用这种方法前,往往只是Scrum Master或少数几个活跃的成员发言,其他人”默许”。
但是用了这种方法后,每个人都能提出很有建设性的建议。 另外,如果是记名的,还可以用来评选Sprint Champion。
比如谁的“What to try”的建议被采用得最多。
这又引出我们活跃团队气氛的一个方法:Sprint Champion。
我们的Scrum Team在Sprint Review、Plan、Retrospective时,都会评选不同的Sprint Champion。
经过实践,效果非常好。当然,Champion的内容要选择有利于Team work的项目,而不是突出个人贡献。

2010-05-27 12:21:36 zhanghsh2010 阅读数 73
  • SCRUM敏捷开发视频教程

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

    10404 人正在学习 去看看 CSDN讲师
1 站立会议全员都需要参与;
2 当值员必须提前准备,识别出问题和风险,做好协调;
3 每个组员汇报进展和当天的计划。对于承诺的任务,需要完全执行;
4 每日站会实践不能超过20分钟;
5 三段论:昨天完成什么,今天计划做什么,困难;
6 成员之间信息共享,每个组员都能了解项目总体进展;
7 不要陷于技术细节的讨论,当值人员应该记录下所有的阻碍并跟踪;
8 把每个问题用跟踪卡片(或在JIRA)跟踪起来。
2016-04-19 00:03:23 lilin9105 阅读数 2927
  • SCRUM敏捷开发视频教程

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

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

敏捷开发迭代会议,主要是挑出产品设计和功能问题,保证迭代版本的产品原型完整性、正确性、合理性。如果产品大致功能没有多大问题,留下些小问题,那么可以进行项目拆分、工时估算。(一个细节要提醒的,产品必须在迭代会议之前,把原型提前2-3天交给相关人员,开发人员可以在会议上提出交互细节的问题、竞品分析)

迭代会议一般 14-18点   或 15-17.30;前半场PM主导,讲解原型,Team提出疑问、细节问题;后半场 SM主导APP团队拆分项目,引导团队成员进行工时估算。



--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

PO或PM场

会议流程

一、PO或SM 公开迭代时间表

二、PO 讲述 Product Backlog,对应的业务价值和优先级

注意点:

1、有些功能程序员同事觉得多余 、或没必要做的;PO或PM要特别交代 业务价值。 

         2、相关业务也要对接其他部门、 或公司资源(如分享账号)、支付宝 微信交易的公司账号 或第三方银 行的要交代跟谁对接

三、团队针对Sprint Backlog和优先级达成一致

注意点:

1、开发时候优先完成主要模块功能点再完成交互细节

        2、在提前两到三天,Team拿到 原型后对产品没交代明白的流程、

交互细节做竞品分析记录, 会中向PM或PO提出讨论明确细节

四、Scrum Master和团队成员共同确定Sprint Backlog

1、基本上产品设计都要做,只是一些特别的因"外部原因"、"资源不确定"不做要记下

参与成员

Scrum Master :敏捷教练或懂敏捷开发的项目组长

PM 或PO:产品经理

Team(开发人员或项目实施人员): 前端、后台、app组、测试、UI美工


--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

SM引导Team场(有两种方式)

一种前面提到如果产品提前3天给了,这三天里面不确定因素已经跟产品确认了。这种情况下可以让team  app开发组来进行模块的故事讲解拆分(迭代拆分)

一种因为team缺少拆分经验、对故事讲解不熟悉,产品给的时间较短,那么这时候就要  SM去主导全程进行结合技术进行模块的故事讲解、拆分;引导队员完成项目评估任务

会议流程

1、团队成员针对Sprint Backlog共同分解任务;

2、团队成员共同进行工作量评估 (每个Task不超过2天),确定开始时间和完成时间;

3、团队成员共同认领任务;

4、共同确定DoD,团队达成一致;(DoD  Definition of Done 完成的定义     )

5、团队共同确认迭代目标和价值;

参与人员

一、Scrum Master

1、组织讲解拆分细节      

       2、让组员认领任务

3、与组员之一共同评估时间(一般安队员能力 评估为准)                                        

        4、记录Sprint Backlog  拆分的任务与时间

        5、考虑能力及业务熟悉度   优先制定重要的任务

       给能力强的或熟悉的人, 将简单的任务分给新人或较薄弱的人

二、团队成员

1、前端和后台组、UI组、测试组 可团队内部组织分工。  

       2、后台分工完成后将分工表发至 交流群,并且接口文档上各个接口 标明谁负责

        3、美工明确出图时间、与切图时间;  明确出图的规格:分辨率

三、其他人员选择性参加

1、对接公司账号中心对接人

2、资源对接人(明确资源到位时间)



--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

PS:DoD表示没明白到底是什么意思,如果是成功标准或完成标准那么可以这么几个阶段


--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

以下Dod时间是以18天-21天的迭代

一、后台:(迭代会议前 1个星期就已经介入后台设计及功能开发,评审完后出接口文档)

在原型评审前,后台就提前一周或两周介入;

迭代会议评审完之后的两天后出接口文档进行接口文档给app,app在拿到接口文档后当天或第二天进行接口评审

1、接口是否规范

2、key是否统一、接口设计是否规范

3、一般一个界面初始化的接口不会超过两个

4、更高的安全性、快捷性相关设计是否到位token还是 session;)

接口确认阶段差不多占用4天时间,这个添加了一些不稳定因素


·测试:(项目评估完后,测试3天内熟悉原型、跟进反馈上一个迭代版本问题)

1、测试接口是否畅通

2、是否按接口文档输出数据

3、json格式是否错误

4、关于一些增删改查是否完整等等(这块我应该理解不到位)


ui:(项目评估完7-10内出完UI及ios切图及android大部分切图 )

差不多按照迭代提前一个星期出ios  UI     2X,时间 不够的  android先用这套 (ios&安卓设计标准规范)

android现在基本上用1080 * 1920p 切图了,不知道ios 1080*1920的用,看上面文章应该不能通用;

app:(平均每人5-8天工作日的开发时间,项目的后一半时间,根据接口继续完善逻辑、及接口问题跟踪解决;需要留给测试一半时间测试app)

按照优先级完成任务;没有评估时间内没有完成那么个人留下加班,比较棘手问题那么团队成员有时间的帮助解决棘手问题,保证项目进度正常完成。

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

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

    10404 人正在学习 去看看 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 问题场景&&错误认识

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

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

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

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

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

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

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

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

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

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

敏捷开发 迭代流程

阅读数 7478

敏捷开发实战问题

阅读数 15186

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