2011-10-26 10:45:11 VipWangJian 阅读数 201
  • SCRUM敏捷开发视频教程

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

    10431 人正在学习 去看看 CSDN讲师
2、迭代计划会议
重新讨论、确定本次迭代需要实现的Story,达成共同理解;
若有必要的话,则继续细化Story;
对Story进行优先级排序;
开发、测试、资料人员认领任务,估计工作量并做出承诺,这是敏捷的重要实践之一:开发团队决定承诺完成工作量的多少,而不是由SE或项目PL安排工作量。
共同制定本次迭代的迭代开发计划。要输出针对本次迭代的详细的开发计划,开发、测试、资料是以Story为单位的,所以迭代开发计划也是以Story为核心的。计划中要包括本次迭代要开发的每个Story的开发人员是谁?测试人员是谁?什么时候开始?什么结束?谁来Review?等等。


优秀实践:
明确任务责任人(包括开发、测试、资料)和任务完成时间点;
任务和问题都可作为跟踪项进行跟踪;
计划中根据Story优先级和依赖关系,严格按Story驱动制定计划,尽量减少Story并行开发;
2019-08-07 20:59:52 spfLinux 阅读数 42
  • SCRUM敏捷开发视频教程

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

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

接触敏捷开发一年了,打算写点什么。

    敏捷开发 — 是什么

1. 敏捷开发 — 角色

2. 敏捷开发 — 道具(story/defect/task...)

3. 敏捷开发 — 游戏(自己做一个?或找些玩法过来?)

4. 敏捷开发 — 需求

5. 敏捷开发 — 开发

6. 敏捷开发 — 测试

7. 敏捷开发 — 会议

8. 敏捷开发 — 面板

9. 敏捷开发 — CI/CD

10. 敏捷开发 — 迭代

11. 敏捷开发 — release

12. 敏捷开发 — 常见问题及解决方案

   12.1 敏捷开发 — 新人进来怎么安排(新人story...)

...

先列个大纲吧,慢慢写,如果有写,会在每个item后面给出Link的。

搜罗一点做其他人写的做参考。

https://blog.csdn.net/zhaoenweiex/article/details/78108248

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

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

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

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

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

前言

我们团队引入敏捷已经超过2年了,经过长时间的不断尝试逐渐摸索出一套适应于我们团队的方法论,即计划会议+看板+每日站会+评审演示+回顾会议。上一篇介绍了我们如何进行回顾会议,这一篇我们介绍一下如何进行计划会议。

什么是计划会议

定义

计划会议是作为一个迭代周期开始的团队活动,担负着确定整个团队在本周期中工作范围的作用,是项目开发能否顺利进行的先决条件。
一个成功的周期离不开一个好的计划会议,而一个糟糕的计划会议则可能毁掉整个项目。

参加人员

计划会议作为最重要的团队活动应该全部团队成员都参加,尤其是项目负责人和业务人员,更不能缺席。参加人员包括但不限于:
1.项目负责人&技术负责人
2.开发人员
3.业务人员
4.测试人员
5.运维人员

我们的计划会议的基本构成

计划会议的具体实践随着不同团队的实践形式会有不同,下面是基本必不可少的过程:
1.目标的确定
有项目负责人公布本周期项目目标和度量标准。
2.业务优先级的确定
确定需要完成的业务的优先级
3.工作量的评估
开发团队一起进行业务需求的拆分并逐项进行工作量的评估。
4.最终范围的确定
根据评估的结果和团队经验值,确定范围
在我们的实践中还包括:
1.预热
项目负责人确定本周起开始和结束时间,以及有无特别的安排。
2.可用资源估计
团队一起确定可以资源,计算机,人员等都可以包括在内。
3.业务挑战
项目团队对于需求不清晰或有疑问的地方向项目负责人或业务人员进行挑战。
4.宣布
项目负责人确认工作范围。

计划会议的准备

实际想要进行一个富有成效和高效率的计划会议,需要进行大量的准备工作,尤其是项目负责人(PO),PO需要至少维护一个项目需求列表,根据上个周期团队工作进度和用户反馈,调整需求,移除完成的需求,补充新增需求,调整需求优先级。
总而言之,在计划会议开始前,PO应该给出已经排过优先级的需求列表。

如何进行计划会议

本节将介绍,我们如何具体的开展计划会议。
1.技术经理(SM)宣布本周期的开始和结束时间,评审会议和回顾会议时间,项目人员变动等信息。
2.团队成员说明在本周期内有无要请假或休假的计划或其他安排,统计完成后确定总的可用资源,我们一般讲开发资源和测试资源分开。
3.开始任务评估
3.1.从PO已经排序完成的列表中取出一条
3.2 团队对该条需求进行业务挑战,直至该需求被全部成员认可
3.3 团队对该需求进行工作量估计(估算方法有待下回讲解),我们一般采用人天来度量
3.4 若估算大于3点则进行拆分,再进行估算,直至估算的任务小于三点
3.5 重复3.1~3.4直至全部需求估算完或超过可用资源。
4.PO来对最终范围进行确认,SM宣布周期开始。

计划会议的成果

计划会议的有形成果是.带有优先级的用户故事或任务列表,根据该列表开发人员可以进行开发,测试人员可以进行功能确认
计划会议的有形成果很重要可以指导团队完成工作,但无形成果更为重要。
1.团队对于需求的理解达到了统一
2.业务知识和专业知识在评估的过程中进行了高效率的流动
3.PO对于团队的现状有了更深的认识.
4.风险在评估中更明显的暴露出来。

计划会议的关键点

1.别让业务人员跑了
千万不能让业务人员以忙为借口不参加计划会议,一定要拉着他们,就算他们不能亲自参加也要以视频会议或替代人员参加。
2.不要想着什么都做
尊重客观事实,不要想着什么都做,那样只会带来痛苦。
3.确保计划的产品是针对用户
不要让计划会议变成PO或业务领导的一言堂,确定的产品应该是针对真正的用户的。
4.团队不需要在计划会上考虑到所有事情
过于细节的内容不要放在计划会议上讨论,那样只会失去重心。
5.计划不要定的太满,根据之前的经验留出10%~15%的余量
意外总是会发生。
6.不要忽略技术债务
定期清理技术债务是个好习惯。

总结

计划会议是一个有效的团队计划工具,通过计划会议能在迭代中确定范围和优先级,它的重要性不容置疑。但一切工具方法都依赖于实施的人员,构建团队文化氛围是打造高绩效团队的核心工作。

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

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

    10431 人正在学习 去看看 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的项目,而不是突出个人贡献。

敏捷开发-迭代会议

阅读数 2927

敏捷开发 迭代流程

阅读数 7478

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