2015-11-23 23:05:36 zhangdaisylove 阅读数 2277
  • SCRUM敏捷开发视频教程

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

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

## 创建故事的时机

1. 由Scrum Master和Product Ower来写故事。敏捷虽然是要提高大家的积极度或参与度,但是故事创建并不需要每个成员都参与,如果都参与写故事会造成故事风格不统一,对整体评估和说明反而不利。


2. 故事创建要提前。Scrum Master需要提前安排好下次迭代开发的故事,并把需求转化为故事,产品需求文档和故事基本可以同时送到团队开发成员。我们上次开发是,一起过需求,然后给大家需求分析时间,然后列故事,对故事进行评估。这样就造成一点不好,Scrum Master和开发人员同时拿到需求,都需要时间分析,而Scrum Master创建故事的时候,大家是没事干的,这个时间至少需要半天。所以Scrum Master需要提前把下次迭代的故事列到backlog里面,下次迭代直接选取优先级高的故事开发,更有利也更合理。

## 如何创建故事

编写好的故事,关注六大特征 INVEST:独立的 (Independent),可讨论的 (Negotiable),对用户或客户有价值的 (Valuable to Purchasers or Users),可估计的 (Estimatable),小的 (Small),可测试的(Testable)。我们开发中的经验是更注重,小的,独立的,可测试的。
* 大的故事一定要拆分,别超过5天,否则故事到Done的时间过长,也不利于控制。
* 独立的,避免故事之间的相互依赖,如果过大,按第一条拆分。
* 可测试的,表示对用户有价值的一个流程,而不是通过页面来划分,很容易陷入这种模式,一个或几个设计界面组成一个故事,这种看是明确的东西,其实隐藏了需求关联性,也容易在开发中容易造成功能遗漏,比方说页面之间的关联功能。故事描述格式可以写作,作为用户,需要什么功能,以便做什么事情。比方说,作为用户需求登录功能进入后台管理。

## 时间预估

扑克牌,每人根据自己情况得出一个天数
如果估算不一致,通过最多和最少估算人说出自己的估算方式,避免遗漏,也避免考虑过多
不需要把故事的需求细节了解的太细,而且不要把细节或实现方式放到估算会上,故事细节由用户和开发人员讨论得出。

预估是估算,不可能每个故事都特别准确,但最终的整体时间是可参考的


使用文件故事做估算时的工作量包含
1. 需求分析/架构设计/编码/测试/部署(至初验款结帐),所包含范围的工作量大约是纯编码期的两倍略多
2. 需求模糊所需的讨论/测试/返工/修改缺陷/响应客户提出变更/乃至部署后提出的变更(在初验结账前),所包含的范围大约是“一次完成”的1~N倍。
4. 由于有多个人参与项目,所以由分工造成的文档/交流/沟通时间/修改别人Bug/人员离职时阅读别人的代码……等时间。
国内的20多个数据表明,若将团队控制在2人,生产率就能达到业界水平的2倍。但很可惜,“2人团队”一般需要至少一个业务和技术均过硬的高手参加,而除非一家公司1/2的人都具备这个素质,否则不可能全部变成2人团队。
5. 人员尽管定编在此项目中,但需要参加其他日常会议/领导前来打搅/紧急缺陷的修复/闲聊/上网……一切最终实际上会被填报在日志中的工时。某些时间看上去很不应该参与到生产率计算中(比如“闲聊/上网”),但因为永远不会有人单独填报“闲聊/上网”时间,所以它们实际上都被填报到日报中参加计算了;“领导前来打搅”的工作量,也不可能计算到其他项目中,所以也计算在人员所定编的项目中。
6. ……

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

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

    10428 人正在学习 去看看 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)的有利保障。

2018-08-10 11:26:13 fan2252228703 阅读数 278
  • SCRUM敏捷开发视频教程

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

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

第一个管理的项目采用的是敏捷开发,以下是个人对敏捷开发的一点实践总结。希望能给大家提供一些帮助。

(关于敏捷开发的3355,敏捷宣言,十二准则在最下边有。)

敏捷开发流程:

1.首先需求负责人理清需求。

2.团队内部要熟悉了解(可以做做游戏)。

3.当天下午及晚上迭代任务拆分。评估工时。

4.开始第一天每日例会领取任务。

5.迭代中旬测试用例评审,接口文档评审,故事验收标准。

6.期间每天早上的站会主要是总结昨天做了什么,遇到了什么问题,今天要干什么(承诺)。负责人需要对问题进行解决。不要阻塞开发。

7.迭代结束需要开迭代评审,迭代回顾。晚上进行任务拆分。

8.上一迭代未完成的任务放进下一迭代。需求变更的也放入下一迭代。

 

 

详细过程:

1.一周主要有以下几个过程:

每日立会。

迭代评审。

迭代回顾。

迭代计划会。

接口评审。

测试用例评审。

故事验收标准。

周报。

演讲分享。

 

每日立会:

每日立会是用来回顾自己在昨天做了什么,还有什么任务没有完成,为什么没有完成,遇到了什么问题需要解决。自己今天要做什么。根据反应的情况进行调整。负责人需要对所有的问题故障进行尽快的解决。

每日立会的公开性透明性能够清楚的认识到每个人的能力和问题。团队成员领取任务是一种承诺,既然承诺了就需要去完成。

 

迭代评审:

迭代评审是对本次迭代的评审,需要严格按照故事的验收标准来进行评审。是检验本次的迭代成果的时候。检验本次的完成情况并进行梳理,看有哪些没有完成,为什么没有完成,是否有什么风险,并将没有完成的移到下一迭代。完成后需要将本次迭代的成果交给甲方进行验收,看是否有需要改变的地方。如果有的话将需要改变的需求移到之后的迭代进行。

 

迭代回顾:

 

回顾本次迭代的团队情况。每个人需要写团队的三个评价:

好,不好,待改进。必须是针对团队的,不能针对个人。之后将统计结果写在黑板上,由团队人员进行投票。每个人必须对每个栏目进行投票,可以投多票反对,一票赞同,赞同票必须投,反对票可以不投。完成后总结团队的情况并解析。下次迭代改进。

 

迭代计划会:

迭代计划会需要对下次迭代的需求进行讲解和任务划分。将故事划分成一个个任务,由相应人员进行工时评估,录入系统。完成后将任务和故事打印出来,贴到看板上。

 

迭代本身:

这个暂时不知道是什么意思。

 

接口评审(迭代中旬):

对团队人员写的接口进行评审,看是否符合标准,解释是否明了,需要用到该接口的人员有什么问题都可以提出来。需要修改的则现场进行修改。

 

测试用例评审(迭代中旬):

对测试人员编写的测试用例进行评审,主要是测试人员进行评审看用例有那些缺陷或不严谨的地方。反思自己写的测试有什么不足。

开发人员则需要注意看看测试人员会测试那些东西,反思自己思维上有哪些没有考虑到,尽量的在开发阶段进行完善。不要提交到测试那一大堆bug。

 

故事验收标准:

故事的验收标准需要由团队人员来进行编写,提交给负责人,负责人同意后,则迭代评审时按照该标准进行评审。

周报:

每个人需要在一周结束时写一份周报来总结。周报内容应包括以下内容:

1.本周所做的工作

2.本周完成的工作

3.本周遗留的工作

4.有挑战性的工作

5.有成就感的工作

6.所学到的知识

7.自己需要改进的方面

8.建议团队需要改进的方面

9.其他

 

演讲分享:

这个是附加的,因为咱们都缺乏一些经验性,常识性的东西,所以需要以演讲的形式来为团队成员扩充知识面。

 

 

敏捷开发术语解析:

分组:开分前需要分好团队,根据不同情况将一个团队分成几个组,可以不分。并取个名。

迭代:一个项目可以分成多个迭代来进行完成。每个迭代完成一部分任务。以主线程为中心。以价值为核心。来判定优先级。

用户故事:将所有的需求划分成一个个用户故事,如果一个用户故事的任务量太大时必须拆分成几个小故事。用户故事有史诗级用户故事和普通用户故事。史诗级用户故事就是特别打的一个任务点。必须拆分成n多个任务故事。

用户故事举例:作为xxx,我要通过xxx,进行xxx。

用户故事地图:用户故事地图就是由许多许多的用户故事及任务张贴到物理看板上之后组成的一个地图。

任务:每个故事可以拆分成多个任务。由不同人员进行认领完成。

任务划分:每个用户故事可以拆分成很多任务,常规的有:前台页面开发,接口文档设计与开发,后台逻辑开发,测试用例编写,接口自动化测试,页面测试。  数据库设计一般在开发前就以完成,不过也可以在开发时添加数据库设计任务。

燃尽图:

所有的用户故事和任务被划分工时后会形成一个燃尽图,燃尽图以一个迭代为周期。随时间推移,团队人员需要为燃尽图进行工时的增减。燃尽图可以直观的看出团队任务的完成情况。

电子看板更新:

每日立会开完后,需要跟新电子看板,将自己认领的任务拖到相应位置。一天当中完成任务后需要将任务拖到完成状态,如果阻塞需要拖到阻塞状态。完成后可以继续认领新的任务。并将物理看板上认领相应的任务,当一天结束时,如果手头的任务没有完成则需要更新剩余工作量。

 

敏捷看板:

敏捷看板有物理看板和电子看板,物理看板只能每日立会的时候可以拖动,电子看板可以随时拖动,敏捷看板可以让团队人员更加直观的看到团队的完成成果和项目进度。

看板有以下几个字段:

用户故事,todo,doing,block,done.

 

 

工具:

敏捷开发的工具网上有很多,我们用的是自己的。

需要具备的功能:

敏捷看板 电子看板及燃尽图的展示。

用户需求 将一个模块拆分成多个用户需求

用户故事 将一个用户需求拆分成多个用户故事

迭代计划 迭代计划时长,迭代完成情况统计,团队人员完成情况统计等等。

缺陷管理 当测试人员测出bug后可以提出缺陷有开发人员进行修改。

用例管理 对测试用例进行管理。

模块管理  一个项目首先划分为一个个模块

 

持续集成:一键自动化集成部署。

 

自动化测试。测试人员进行自动化的接口及页面测试。

 

代码扫描。对所有代码进行,不合规范的将会报错。

接口管理:我们使用的是本地搭建的rap2。

敏捷宣言:

个体和互动 优于 流程和工具

工作的软件 优于 详尽的文档

客户合作 优于 合作谈判

响应变化 优于 遵循计划

 

SCRUM这个框架里面包含了这几个核心的要素:

1、3个角色:SM、PO、开发团队(自然包括了我们的开发人员和QA)。

2、3个产出物:Product Backlog、Sprint Backlog、交互的可用软件工件。

3、5个活动:计划会、sprint评审会、回顾会、每日立会、Product Backlog的梳理(发生在整个SCRUM周期的任何时间)。

4、5个价值观:公开、专注、勇气、承诺、尊重。(这五个价值观尤其重要,贯穿整个敏捷开发。)

十二条准则:

12原则作为敏捷开发对于软件开发流程的指导性纲领,其实是对敏捷宣言进行了具有实际操作意义的解释。下面是敏捷宣言12原则:

我们遵循以下准则:

1、我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。

2、欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。

3、要不断交付可用的软件,周期从几周到几个月不等,且越短越好。

4、项目过程中,业务人员与开发人员必须在一起工作。

5、要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。

6、无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。

7、可用的软件是衡量进度的主要指标。

8、敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

9、对技术的精益求精以及对设计的不断完善将提升敏捷性。

10、要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。

11、最佳的架构、需求和设计出自于自组织的团队。

12、团队要定期反省如何能够做到更有效,并相应地调整团队的行为。

 

 

 

 

 

2017-06-22 00:15:23 chunyexiyu 阅读数 383
  • SCRUM敏捷开发视频教程

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

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

再次参与敏捷开发项目2年多了,期间有敏捷教练的指导,也有实践的一点感悟:

由于从事的岗位,站的角度偏向于从开发人员的角度、开发负责人角度的一些总结:

Part1:遵从的理念:尽快交付有价值的东西。

敏捷开发尽快交付理念,决定了它的周期性,决定了它是以小步快跑的方式,向前推进。

有价值与小步快跑:也决定了它以故事点—有价值的小颗粒的形式,进行交付。

这块的核心就是:以Story的形式进行迭代价值交付。

Part2:迭代结束即发版
持续可交付,迭代的质量标准也是发版标准。
实践1:DOD 制定质量标准,Story研发质量标准。确保迭代交付的Story达到可以发布的质量要求。
实践2:持续集成与自动化测试,每天自动化测试保障,持续补充自动化测试用例,确保已交付的内容被自动化覆盖,确保版本的质量持续是稳定的。
实践3:制定迭代的流程规范,把DOD的标准纳入到迭代规范中,确保DOD有效执行。

Part3:沟通优于流程
研发的过程中,沟通的时机特别多,也有特别多的实践形式。
例如最基本的一体化团队:开发、测试、需求一体化团队;在组织形式上把人聚集在一起,开展团队的各个活动。这个非常利于团队的沟通与交流。
另外常用的:迭代启动会议,敏捷晨会、迭代拆分会议、总结会议都是团队内的所有人员参与。
每天的晨会确保了团队及时同步进度、发现问题或偏差、及时应对。

Part4:以人为中心,考虑人性
迭代计划的执行,需要在迭代中明确时间点

实践一:以story为交付点,story一般是独立的,story划归个人,确保了交付人员的对个人任务的担责,发挥主人翁意识。

实践二:迭代拆分会议,由交付人给出交付用时,交付时间点;这样后续以个人的承诺为基础,跟踪任务。个人承诺个人去努力达成符合人性,可以有效驱动个人发挥最大的努力。

实践三:职责下发,例如会议组织、会议主持、任务检查等职责下发,有利于组织的扁平化,并发挥组内人员的自管理意识,更有效的进行团队建设。

2014-11-30 15:33:17 u010191243 阅读数 1710
  • SCRUM敏捷开发视频教程

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

    10428 人正在学习 去看看 CSDN讲师
    用了3天,充分挤完了海绵里的时间,看了《轻松Scrum之旅:敏捷开发故事》这本书,觉得写得很好,有意思,找到了当时看大话设计模式时候的感觉。
    从书的题目可以看出,这本书主要是讲敏捷开发的,我也是第一次接触,理解的不好还请读者见谅。
    一、从技术角度看:传统的瀑布模型由于在前期花费了大量时间去分析需求和准备文档,导致在产品模型在时间上的每一次迭代都会很漫长。而这其中很可能会发生需求的不断变化,甚至产品完成后早已和时代脱节,失去了其本应产生的作用。造成的后果很明了:用户不满意,而且耗资很大。
    而敏捷开发显得更为轻灵多变一些。首先,轻量级的文档使我们不再需要准备一些多年无人问津的复杂分析和记录;另外,对变化的充足准备使得需求的频繁变动不再成为程序员的噩梦。
    二、从组织管理角度来看,1、我们传统的团队开发很可能存在以下现象。如:部门之间不协调,缺乏充分的沟通,人际交流成为一纸空谈;小组内各成员也常常是各自开发自己的部分,对项目整体或与自己相关的部分也不很了解;沟通渠道缺乏导致上传下达和团队交流出现一些不必要的问题,甚至引发矛盾。
     这些问题的根源就来自于缺乏相应的机制进行组织和交流,把大家的意见和想法充分表达出来是敏捷开发中以人为本、团队合作的宗旨。
     2、在项目把控上,传统的开发都是定义好的,根据计划把整体的任务都一次性定好,缺乏灵活性,难以应对内外部环境的变化。但敏捷开发中的Backlog—Story—Task任务划分机制很好的解决了这个问题,使得在项目需求有较大变化时通过先急后缓的方式充分应对。
     3、在部门划分上,敏捷开发提倡按产品划分,而不是部门。把编码和测试人员绑定在一起,使整个开发的过程成为一个流畅的整体,避免了出现相互争资源;把单元测试放到每一个Sprint阶段之后进行,减轻了集成测试的压力,缓和了测试人员由于不理解需求,测试不彻底或描述不准确与程序员产生分歧。
    三、从学习角度看,我们可以借鉴敏捷开发中的一些优秀经验和思想。平时兼顾整体规划和细节规划,在应对变化上要做到灵活,给自己预留足够的缓冲时间。
     做好人际交流,了解集体状况、优秀的或与自己紧密相关的个人的状况,这是自我调整的强有力参考。
     最后,要做好选择,找到适合自己的环境和方法。踩在如此多的“关毅”的肩膀上,我们已经有足够的知识水平和认知能力去适应这个世界的节奏了。
    
    

敏捷开发 故事墙

阅读数 4958

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