2016-01-03 19:07:08 xidwong 阅读数 2365
  • SCRUM敏捷开发视频教程

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

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

简要介绍

《轻松Scrum之旅–敏捷开发故事》以小说的方式向我们介绍了主人公在经历了如噩梦般的传统的瀑布开发模型后,成功向敏捷开发转型的故事。
作者通过4个迭代开发过程,展现了主人公是如何从一个敏捷开发的新手逐步成长为一个资深的Scrum Master的过程;通过这4个迭代开发过程,作者由浅入深的逐步介绍了在Scrum在实施过程中遇到的一个个问题,并通过主人公与一个Scrum专家的邮件交互向我们提供解决办法。同时,还恰如其分的在文章中适当的对敏捷开发的各种概念、实践工具等进行了介绍,让我们能及时了解相关的Scrum知识,而不会感到突然。
这本书非常适合那些想学习Scrum却又无从下手的同学,而且对刚刚实施Scrum的团队来说,也非常具有借鉴意义!
这边书我一口气读完,使我对Scrum实践有了更加深入认识,也促使我回过头来对我们的敏捷过程进行更深入的思考,让我收益颇深!
世上充满无数的选择和努力,但对于成功,选择大于努力。

根据书中内容,总结一下Scrum开发基本的知识:

David的敏捷开发培训–什么是敏捷开发

回家的启发:

stakeholders,我们所有的目标是为了实现利益相关者的利益
sustainable pace,保持一个可以持续的进度,决不能太累
自我管理的团队

敏捷价值观

个体和交互重于过程和工具
可以工作的软件重于面面俱到的文档
客户协作重于合同谈判
随时响应变化重于遵循计划

核心思想

适应变化和以人为本

其他

1, 敏捷开发方法是面向人的而非面向过程
2, 敏捷开发方法是“主动适应”而不是“预先设定的”

敏捷开发的理念

信任开发团队,信任每一个人

敏捷开发中的管理

非命令式,战略指导和服务性质;敏捷开发中,管理者对团队的管理表现在挑选合适的人、为团队创造一个开发自由的工作环境、经常性的反馈、为团队建立评估和奖励机制、当团队有方向性错误时能及早发现并纠正、容忍错误的发生等。

两个故事

买土豆的故事
“鸡”和“猪”的故事

敏捷开发的软素质

A very good team player
Excellent communication skills
Open minded, pro-active, and self-motivated

敏捷开发过程比较

XP
RUP
Lean

Scrum总体结构

scrum workflow
任务板
敏捷项目管理工具

在项目的开始制定一个有效的沟通计划至关重要!
产品Backlog、Sprint Backlog、User Story
User Story:作为<某个角色>,我可以<做什么>,已完成<什么目的>。

Scrum三种角色

Product Owner、Scrum Master、Scrum团队成员

1 Product Owner:
需要确定产品的功能和完成时间,并对产品的收益负责,要根据市场需求确定产品功能的优先级。在每个sprint开始之前,Product Owner可以修改功能需求和优先级。而且PO有权决定接受或者否决各个Sprint的工作成果。
Prouduct Owner的角色通常由市场部门的人员或开发部门内部主要使用该产品的人员来担任,主要工作是根据市场需求确定产品功能,将其列入Product Backlog中斌未这些功能确定优先级。
Scrum团队按照功能的优先级,将它们从高到低分配到各个Sprint中进行开发,这些被分配到一个Sprint中完成的功能就形成了Sprint Backlog。
在产品的整个开发过程中,Product Owner对于产品的需求可能会发生改变。他可以修改Product Backlog, 以及增加某些功能需求、删除某些功能需求、修改优先级等,但这些行为只能在各个Sprint之间进行。

2 Scrum Master:
负责监督整个Scrum项目进程,调整项目计划;确保开发团队成员的能力能够胜任产品的开发;促进团队中不同角色的团队成员充分交流和沟通,并为项目的进行扫除障碍;保证开发团队不受外力的干扰和阻扰;掌握产品的开发进度,参与每日Scrum会议、Sprint计划会议和Sprint平时会议。

3 Scrum成员:
要求Scrum团队是跨职能的,应该包含开发、测试、美工即文档人员。

Sprint计划会议:

时间:一般4-8小时,
参与人员:PO、SM、Scrum团队成员和其他对产品感兴趣的人员,PO从产品Backlog中挑选高优先级的任务,并与Scrum团队成员一起决定这个Sprint中需要完成多少功能。Scrum团队将这些任务分解成小的功能模块。Scrum团队成员详细讨论如何才能按需求完成这些功能模块,并估计完成每个功能模块所需要的大概时间。
确定sprint最后演示的时间和每个story演示的方式

每日scrum会议

每日Scrum会议是Scrum的精髓,最简单又最复杂,如何有效的召开,需要不断的改进和摸索;
一般15分钟,3个问题:
1)昨天我完成了什么工作?
2)今天我打算做什么?
3)我在工作中遇到了什么障碍?
通过每日Scrum会议,团队成员之间可以彼此相互熟悉工作内容,充分了解项目进度,相互帮助解决问题。SM除了倾听团队成员的发言外,还有责任设法解决团队成员在会上提出的困难,尽快扫除阻碍他们工作顺利进行的障碍。即使有的问题SM没有能力解决,他也应该找到团队中的或其他团队中的成员来帮组快速地解决问题。另外,还有两点需要注意:其一,这是团队成员之间的交流,也是相互的承诺,并不是向老板汇报工作进度的;其二,这也不是一个专门用于解决各种问题的会议,团队成员在工作中遇到的问题可以在会上提出来,而又能力解决这些问题的人可以在会后帮助他们解决问题。

Burndown Chart

是常用的衡量团队进度的可视化攻击。敏捷开发可以给项目提供更多的可视性。

Sprint评审会议:

Sprint结束时召开,一般2小时左右,非正式的会议,可以邀请高层参加,气氛要活跃点,避免变成严肃的报告会。
要避免过多的谈论技术细节,要重点关注最后的成果。
注意任务完成(Done)的定义,

Sprint回顾会议:

参加人员:PO、Scrum团队成员、Scrum Master
宗旨:Scrum团队如何在下一个Sprint中做的更好
重要性:第二重要的事件(最重要的是Sprint计划会议),因为它是让Scrum团队成员成长和进步的最好机会。如果不开回顾会议,不久以后,你就会发现,你的团队在不断地犯着同样的错误。
会议内容:
会议中需要讨论有哪些好的建议或方法应该被采纳,在这个Sprint中有什么做法不可取,有哪些做法效果很好,应该继续下去。
Sprint结束后,Scrum团队成员回顾刚刚结束的Sprint,对其进行总结和反思,使整个团队能持续成长。
Sprint回顾会议的形式可以比较随意,主要做到以下几个方面:
SM首先给大家看Sprint Blacklog,总结这个Sprint。然后,团队成员讨论在这个Sprint中发生的一些比较重要的事件。与会人员轮流发言,每个人都有机会发表自己的意见:他认为哪些方面做的好、哪些方面需要改进、应该如何改进等。此外还要对比Sprint Backlog中各个Story的估计值于它们的实际完成时间,如果差距太大,就应该好好分析出现这种情况的原因。
在Sprint回顾会议结束之前,Scrum Master要总结会上的讨论成果,即“如何才能在下个Sprint中做得更好”。
总之,Sprint回顾会议的宗旨就是:Scrum团队如何在下一个Sprint中做得更好!

Wiki是个不错的敏捷项目文档管理工具

计划扑克:

扑克背后的敏捷思想是团队里没有绝对的权威,每个人都有可取之处,要避免少数服从多数。
poker

Sprint目标:

Sprint Goal是个鼓舞士气的好工具。

代理Scrum Master给我的启示:

真正的Scrum Master要能够排除开发人员和产品负责人之间的障碍,确保Scrum达成目标,实现投资回报最大化,确保团队进度,确保团队状态具有高度的可视性,激发团队创造力,提高团队开发水平,采用各种优秀的工程实践,提高生产力等。

其他知识点

两个Sprint之间的缓冲时间,可以起到承上启下的作用。

Team Pulse Survey统计结果的各项实际上告诉我们应该如何成为一个成熟的Scrum团队

Scrum要求在一个Sprint中团队成员高度稳定

持续集成是敏捷开发中核心的工程实践,它是敏捷产出“可以工作的软件”(Working Sofeware)的有利保障。

2011-03-16 16:10:00 tufengtufeng 阅读数 2179
  • SCRUM敏捷开发视频教程

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

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

以下是近期对敏捷开发中由以往“调研-文档-讨论-文档-开发-文档”向新的开发方式的学习一些总结,和大家分享,有任何好的想法欢迎和我沟通。

如何编写用户故事?

1:用户故事不要用技术语言来描述,要使用用户可以理解的业务语言来描述 。不要提及任何有关语言逻辑,数据库,软件,字段的客户无关描述。

2:格式:

<编号>:作为一个<角色/职位>, 我想要<活动/操作>, 以便于达到<功能目标/商业价值>

3:如果用户的故事点很密集和连贯要使用下面的格式加以隔断:

用户(角色)做…...

系统做…...

用户做…...

系统做……

4:可以不需要格式规整的需求说明书,但是必须有一个大家都能看懂的业务流程描述。

5:用户故事的主要目的是和用户讨论而不是写。

用户故事如何排序?

1:客户明确的要求的工作

2:价值和成本(开发工作量)

3:功能相互关联的故事挨着一起

如何使用用户故事?

1:和用户沟通用户故事中的细节。

2:和客户交谈我们会怎么样完成故事(界面草图,原型)

3:经常向用户展示我们开发的小成果,演示我们已经完成的功能,让用户看到我们的进度。

4:听取用户的意见。

5:按用户故事来分解工作任务,指派开发,开展测试。

特殊情况下的敏捷如何开展?

1:客户不能保证持续在场

由project owner在迭代开始前与客户讨论清楚业务流程,迭代开始后由PO担当客户应该做的部分,但PO必须和客户保持畅通的联系。

2:客户无法表达清楚自己想要的,或者还没想清楚

需要在PO或PM之外有一个需求分析员(或者沟通能力比较强大的开发),和用户进行更深层次的探讨,团队可以构建一些Demo给客户参考,直至用户坚定自己的意愿。

2015-09-29 23:23:16 jnqqls 阅读数 3299
  • SCRUM敏捷开发视频教程

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

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

        

      在敏捷开发中除了POSM之外,另外一个非常重要的角色就是TEAM,也就是我们的开发(有些包括测试)团队.

 

      因为在每个迭代进行的过程中,真正的将需求实现为用户需要的产品是在团队的同心合作下进行的,因此将一个新的团队磨合成敏捷开发所要求的自组织团队是一个比较难得过程,尤其是在实际的开发进度和需求等不定因素的影响下.

 

     因此提高Team的凝聚力是创建自组织团队一个 重要因素.

 

    团队的凝聚力来自于大家都在为一件事而努力,每天都在做,而且经常有提高。

      为了提高团队凝聚力,有很多途径可以实施,例如在每天的站立会议,Team成员除了介绍每天的工作,还可以做两个额外的事情:

 

        一个是快速形成某个团队级别的决议,例如将某个方法作为公共模块,临时调整资源等,解决阻碍团队的重大问题;

 

          另一件事情是代码分享或者代码复查,每个人都会拿出昨天最核心的功能代码,讲给大家听,只包括外部模块的耦合,业务逻辑,大家进行讨论,结果不是发现了漏洞,就是发现了某个人的代码更加规范,其他人都会和他保持一致。当然,因为涉及到具体代码此过程在站会的时候进行可能会耽误比较长的时间,项目团队可以根据实际情况,每天留下固定实际来进行此项操作,因为是良性的,所以会越来越好.

       

 

       Team成员每天进行集体沟通,每个人都有机会发言,每个人都不只是听客,每个人都可以感受到其他人对项目的贡献,每个人都有是整个项目和产品的主人翁的感觉.

 

       为了让整个Team的沟通有效率,因此每个敏捷团队人数不易太多,如果有很多人,首先站会就会浪费大家很多时间,也同时因为人数太多,大家的关注点就开始分散起来,不利于高效的去解决问题.

 

       所以在实践过程中,我们原先的20多人的团队分开成两个敏捷团队,每个团队都有各自的PO,SMTEAM.每天的站会分开两部分进行.如果需要两个团队共同来解决公共问题,则还有站会的站会,每个Team派代表来给项目经理说明问题,进度等.

 

       至此,整个敏捷项目的角色基本上全了,PO+SM+TEAM.


2014-06-09 16:53:46 u014419512 阅读数 2305
  • SCRUM敏捷开发视频教程

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

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

           敏捷开发目前已成为互联网公司的首选方案,为应对市场的快速变化,我们公司也在大力推广敏捷,最近在读《用户故事与敏捷方法》一书,我想边读边做一些分享,传播知识的同时加强记忆。

1.       基于用户建模是一个比较好的起点。

产品团队可以采用头脑风暴等形式,挖掘出产品实际存在或者潜在的用户或客户,给他们一些角色。

多种角色出现重叠时,再将重叠部分成立一个独立角色。

比如“运维角色”和“部署角色”都需要做一件事情:做数据修改,那么我们就考虑一个“数据修改角色”专门做这个事情,然后“运维角色”和“部署角色”就都不包含这个职能了。

 

再然后呢,给每个角色找一个生动的虚拟人物来代替,让团队熟悉这个人,就像身边的一个朋友一样了解。

例子:“借款人角色”,代表人物叫“张穷”,30岁,小餐馆经营者,这两年生意做得不错,想扩大店面,但是手头吃紧,正绞尽脑汁想找一笔贷款。

 

用户建模时,可以考虑一些特殊的人群,他们有助于发现一些细致的需求。比如老太太需要屏幕字体够大。

 

2.       寻找用户。

最理想的方式是能够找到软件真实的使用者,了解他们的需求。

条件不成熟的情况下就只有寻找用户代理,不同的人群都可以担任用户代理,但是要注意不同的用户代理看待问题大多是从个人需要出发的,要摸清他们的一些小脾气。

实际用户的经理:他们对于产品细节的关注度可能不高,因为他很可能平时不做实际操作,对于群众疾苦了解得不够;他们可能会过分关注一些管理功能,比如任务调度、查看每个手下现在的任务完成情况等,而这些功能很可能不是产品核心的东西。

开发经理:他们通常缺少对软件的实际体验,其内心驱动因素很可能是业务压力或者成就感,这样的动机很容易背离产品核心业务价值。

销售人员:他们的核心价值观通常是尽量多的订单,为了不丢单,他们总会承诺“没问题”,各种稀奇古怪的东西都想丢进产品里面,使得产品没有规划、随遇而安。

领域专家:他们通常能够在产品设计上提供很大的帮助,但要小心他们弄出一个太“高大上”的东西,不接地气,让小白的用户觉得软件极其难用。

系统分析师:他们是很有想法的文艺青年,既懂技术又懂业务,是很好的用户代理。但要小心他们的空想症,他们有可能花上两天去精心设计一个业务流程,但根本没有做过任何调研。最坏的结果是最后不得不推翻一个精心雕琢的楼阁,浪费、肉疼。。

 

3.       切割故事。

传统的切割方式大多是按实现层面或者技术栈来切割,比如一个功能别切割为前台、后台、数据库几个任务,或者按照技术栈切割为java相关、C#相关、移动端几个任务。

这样的切割方式最大的问题是:单个任务不能产生业务价值、相互依赖导致无法快速交付并得到反馈。

推荐做纵向的切割,每个故事尽量是一个功能闭包,一个故事完成意味着一个功能可交付。

以京东提交订单功能为例,其业务流程为:基于预先选好的商品信息,先选择支付方式、再选择配送方式,然后提交保存。

传统的切割方式可能为:

T1: 前台交互实现(选择支付方式、配送方式),形成可提交的订单数据后提交给servlet

T2:后台接收订单数据,保存到数据库,给成功提示。

 

考虑换一种切割方式:

S1:基于预先选好的商品信息,使用默认支付方式和配送方式,提交订单并保存。

S2:支持用户选择支付方式并保存订单。

S3:支持用户选择配送方式并保存订单。

 

我们不要写哪种大而全的故事,一个故事只为一种客户编写,只满足其一个小小的业务价值。

编写故事时尽量避免涉及界面的描述,这会诱导开发人员按照某人脑海中印象来实现功能,这实际是把设计意图强加到故事之中,更致命的是会隐含的扩大故事范围。

比如这样一个故事:

           在首页的右上方,用户可以看到“注册”按钮并点击它,之后弹出一个对话框,用户录入注册信息后,点击提交按钮,若注册成功就回到首页,并发送激活邮件。

它的问题:

           涉及太多的界面信息,它阻止了开发人员或者分析师跟客户做进一步沟通的欲望,也许这样的交互设计是蹩脚的呢?

考虑写成这样也许更好:

           在首页醒目位置可以进行用户注册,注册成功需要发送激活邮件,注册失败需要失败提醒。

 

下期分享:故事估算和制定计划,谢谢围观~~

2011-06-12 16:15:00 zhangweia 阅读数 4957
  • SCRUM敏捷开发视频教程

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

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

      需求澄清后,SE把所有的故事卡贴到故事墙上,等待开发人员的开发。故事墙的模板为:

image

分析      : 需求澄清完成后,SE把所有的故事卡都贴到分析阶段

等待开发: 开发人员和SE确认了需求,明确了做什么以及怎么做以后,把故事卡从分析阶段移到等待开发

开发中   : 开发人员一次只开发一张故事卡,把相应开发的那张卡移植到开发中

阻塞      : 如果开发过程中,由于配合的原因,导致故事卡无法继续走下去,则把该卡移动到阻塞阶段

开发完成 :如果开发完成,并向SE  SHOW CASE以后,开发人员吧故事卡移植到等待测试

等待测试 :测试人员看到等待测试中有卡以后,对故事卡进行测试,测试完成以后把卡移到测试完成阶段,如果测试有问题,则移出该卡到开发中阶段

测试完成  : 本张卡的生命周期结束

   故事墙的等待开发、开发中属于开发人员。等待测试,测试完成属于测试人员,开发人员和测试人员必须坚守自己的领地,当卡移动过去时,必须确认了才接受,如果有不清楚以及问题,及时的移除自己的领地。

为什么要有故事墙,故事墙的作用是什么了?

    故事墙描叙了开发过程中的各个阶段,能反应当前团队开发的健康状态。在每天的站立会议中,开发人员依据故事墙,给大家分享其开发状态,问题,需要的帮助。项目领导者也能够及时的通过故事墙,了解当前团队的状态,并及时调整。

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