2014-02-22 23:56:40 xiaoxian8023 阅读数 9598
  • SCRUM敏捷开发视频教程

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

    10414 人正在学习 去看看 CSDN讲师
       在Scrum中有三种角色:产品负责人Product Owner,Scrum Master和Scrum团队,他们的职责分别是:
  • 产品负责人(Product Owner)
    • 确定产品的功能和完成时间;
    • 对产品的收益负责;
    • 根据市场需求确定产品功能的优先级;
    • 在每个Sprint开始之前,可以修改功能需求和优先级;
    • 有权决定接受或否决各Sprint的工作成果。
       Product Owner的角色通常由市场部门的人员或开发部门内部主要使用该产品的人来担任,他的主要工作是根据市场需求,确定产品的功能,列入Product Backlog中,并为这些功能确定优先级别。
       Scrum团队按照功能的优先级,将它们从高到低分配到各个Sprint中进行开发,这些被分配到一个Sprint中完成的功能就形成了Sprint Backlog。
       在产品的整个开发过程中,Product Owner对于产品的需求可能会发生改变。他可以修改Product Backlog,增加某些功能需求、删除某些功能需求、修改优先级等等,但这些行为只能在各个Sprint之间进行。
  • Scrum Master
    • 负责监督整个Scrum项目进程,调整项目计划
    • 确保开发团队成员的能力能够胜任产品的开发;
    • 促进团队中不同角色的成员间充分交流和沟通,并负责为项目的进行扫除障碍;
    • 保证开发团队不受外力的干扰和阻挠;
    • 掌握产品开发进度,参与每日Scrum会议、Sprint计划会议和Sprint评审会议。
    • Scrum Master最经常的情况就是由过去的项目组长(Team leader)来担当。
  • 开发团队

       一般由5-10个能全职工作的成员组成较为理想;团队成员横跨各个职能,通常包含开发,测试,文档设计人员等等。


       这与我们传统的开发模式(瀑布模式)截然不同了。开发团队可以及时有效的交流,而不是像瀑布模式中受职位和文档的限制,使得出错率低,积极性高,从而提高了开发效率。



2018-11-27 11:15:29 wangqiang9x 阅读数 301
  • SCRUM敏捷开发视频教程

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

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

现在敏捷开发、敏捷管理被抄的火热,一时间到处是敏捷,一些公司打着敏捷的旗号以敏捷为名去压榨员工的劳动力,对此我还是有些惋惜的。这样的团队也很难成长起来并成为有创造力、战斗力的强大团体,最多是个劳动工具而以。

什么是敏捷呢?

很难说怎么做才是敏捷,当你把敏捷规范落地到你的公司时,你会发现或许已经面目全非(即使这样也有成功的例子),或许你的公司适合这种模式,或许你得静下来问一下自己这到底有没有违背你改革的初心。
你的模式起码要满足敏捷宣言(它很精简),否则可能是个假敏捷。
《敏捷宣言》
https://baike.baidu.com/item/敏捷宣言/1585951?fr=aladdin

我是个敏捷控,敏捷给公司带来的利益是巨大的,体现在多个方面包括员工满意度、项目的准确度、项目的速度、客户的满意度等等,正好今天看到一篇来自阿里的“中台战略”,说明阿里也在努力的迎合敏捷,拥抱敏捷。
https://mp.weixin.qq.com/s/L6jvPtzz2M-sHTqPwsp32Q

几个重要的敏捷元素:

小而精的团队
让你的团队保持小而精的状态,大的团队并不容易充份的沟通,效率也当然随之下降,一般来说团队3-7个人为佳,最多不要超过9个。
团队角色有: PO,scrum master , 团队(研发人员)
PO : 主要负责产品的规划
scrum master : 确保scrum的运作
团队:具体做事的人
这里的角色介绍的很简单,后面会单来一个文章来描述,这里是有的写的

项目启动会
众所周知,敏捷相对与瀑布来说就是小步快跑会把一个大项目拆分成很多小项目,每个小项目会有一个项目启动会。
项目启动会中需要PO把项目拆分后的小故事分享给团队,需要让团队充份理解用户故事,并且团队有权有义务向PO提出自己的看法或见解,充份发挥团队的做用。若产生了较大的分歧,scrum master出面协调。同时启动会也可以团队带来点仪式感,让项目推进更有冲劲。

冲刺(sprite)
冲刺是指启动会后,完成一次迭代的过程。对于冲刺有几个比较重要的点:
1、明确项目截止日期
2、一次只做一件事
专注:做事的时候,事件切换所花费的的时间成本是非常大的,有人说一心两用是能力,其实这样在做事的时候是不好的。
3、让事情有始有终
承诺:言出必行,评估工作量也是种能力,可以不答应,但答应了需要做到。
4、产品快速展示给公众
这是敏捷的核心价值,不停的展示不停的变,要始终面向公众面向你的用户,让你的产品迅速产生价值少走弯路。

每日立会
重点如下 :
1、不要超过15分钟
2、全员参加,积极交流
3、保持激情
4、信息公开透明

回顾会
这认为这是scrum中最重要的部分,每个迭代完成后都要总结一下好的地方和不好的地方,团队在运行中不断的优化。回顾会要讨论的四个问题:
1、做的不好的
人人发言, 把sprint中的问题都给暴露出来
2、优化方案
针对做的不好,或者是可以好上加好的方案都可以说。大家一起来定优化方案,大家一起定的,执行起来肯定没问题
3、做的好的
做的好的也要说,比如哪方面谁做出了突出的成就、谁对谁提供了很多的帮助。。。正能量的话题都可以说
4、上报问题
如果是团队解决不了的问题可以在这里上报,比如是资源不到位、服务器经常会不稳定等

敏捷管理
1、营造更开放更自由的文化
2、加速交付产品
3、成果快速可视化
4、增进员工间的合作

解释一下2、3两条,加速与快速是指让实现方式最简单、最直接,而不是要一味的压缩工作量,这样会适得其返

做事方法
1、一次只做一件事
2、做正确的事

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

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

    10414 人正在学习 去看看 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原则作为敏捷开发对于软件开发流程的指导性纲领,也是对敏捷宣言进行了具有实际操作意义的解释,希望大家在实际应用中仔细体会。

我们遵循以下准则:

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

作者:史文帅

来源:宜信技术学院

2011-02-24 15:53:08 iteye_6172 阅读数 38
  • SCRUM敏捷开发视频教程

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

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

敏捷开发的敏捷,本质上觉得是对应变化的能力。而并不指效率上的大幅提高。

敏捷开发team 中的角色

pm dev writer po ui tester

pm 项目经理

dev 开发人员

writer 文档撰写人员

po 理解客户需求的人员或者客户本身

ui 软件原形设计者

tester 测试

敏捷开发的几个原则

Individual

interraction

working software

costomer collaboration

responding to change

在敏捷卡发中对于一个sprint的顺序

unit test -system test-coding

每一天的plan metting 和issue meeting分别为不同的意义。

在开发的具体细节上

按照架构层次分配任务比按照功能模块分配任务更符合sprint的生命周期但同时可能降低个人的效率。

面对面的沟通在敏捷思想中第一重要。

 

2011-08-04 16:48:34 xianpengliu 阅读数 8775
  • SCRUM敏捷开发视频教程

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

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

最近买了一本介绍敏捷开发的书,《敏捷软件开发——原则、模式与实践》

作者是个大拿级别的人物,Uncle Bob


这两天有空就读几页

这是本理论性较强的书,所以读完后印象不会很深(但读书时绝对不会打瞌睡,这可是本bible似的的书啊)

所以读到经典之处、会心一笑之处,需要及时记下自己的理解,以便将来翻阅


敏捷一词来源于2001年初美国犹他州雪鸟滑雪圣地的一次敏捷方法发起者和实践者的聚会,正式这帮人组成了“敏捷联盟”

该会议起草了敏捷软件开发宣言,其中最重要的部分就是对一些与会者一致同意的软件开发价值观的表述:

  • 人和交互 重于 过程和工具。
  • 可以工作的软件 重于求全责备的文档。
  • 客户协作重于合同谈判。
  • 随时应对变化重于循规蹈矩。


第一点很容易理解,强调人以及人与人之间的交互。在大学的软件工程课上,主要介绍了两种开发方式:瀑布式和迭代式。

敏捷开发区别于瀑布式的特征很明显,敏捷开发是以一种迭代的方式推进的。

而敏捷开发与迭代式开发的区别在哪呢?重视交互应该是最明显的区别之一吧(暂且加上之一)

敏捷开发提倡结对编程,就是常说的pair programming,这增加了两个人之间交互的机会

更甚的是,结对的两个人通常在一天内会更换,就是说你上午跟A结对,下午可能跟B结对。

另外敏捷开发更适用于小型团队,在一个办公室工作,属于那种通信基本靠吼的状态,当然团队成员之间的交互会更方便。

另外敏捷开发强调用户(或用户代表)要与开发团队在一起工作,便于及时沟通交流。

还有一个好处,就是有利于团队中知识的迅速传播。即使有人离开团队,另外的人也能完成相应的工作。

(在微软这样的大型公司,通讯方式中邮件站很大比重,当然这样也有好处,不会打断团队成员的思维。敏捷方式在这里并不是非常合适)

因此,“人与交互”被列为敏捷开发价值观之一,并排在第一位。


第二点也比较容易理解,就是客户常说的“少整那些虚的,我只要看到能用的软件”

这条价值观能安抚客户的情绪,增加客户对团队的信任。

如果按照瀑布式流程,客户可能在签订开发合同3个月后,看到的还只是各种文档(需求文档、设计文档、详细设计文档等等)

客户心理肯定不踏实。并不是说瀑布式一定不好,而是客户不懂这些,他们只要看到能用的东西


第三点也很容易理解,“协作”VS“谈判”

在第一点中说的交互也包括开发人员与客户的交互。

在第二点中说过如果采取瀑布式,那么客户可能在3个月内什么都看不到,除了一堆文档

这时候,客户心理没底,肯定要与团队进行“谈判”。。。

所以第三点强调与客户之间的协作。这里说的客户,可能是客户代表,也可能是公司内的业务人员

这里是要把客户当做朋友关系相处。

这里我体会很深,我们公司一直提倡客户派人员到我们团队中来,一起工作。

客户也很愿意,为了保障项目的进度,为了监督我们不偷懒。。。

当然,这样对改善与客户的关系也非常有帮助,尤其在中国这个“关系型”社会,意义重大


第四点理解起来也容易,在大学软件工程课上,老师说在瀑布式开发中,需求修改的时间越靠后,成本越大

所以需求分析人员的压力很大。。。

由于敏捷开发是迭代式的,通常迭代周期是2个星期,因此很容易相应新需求或是对旧需求的修改。

当然,在一个迭代计划(2星期)制定后并进行开发,就不能修改了。

如果是新需求的话,就在制定下一个迭代计划时考虑。

如果是对旧需求的修改,那也在制定下一个迭代计划时考虑,只不过是作为新需求的方式提出。什么意思呢,就是说先提出一个需求,然后再修改,这就相当于提出了两个需求。我细想了下,这有一个非常现实的意义,两个需求就是收两份钱啊。。。即使不会多付钱,那客户也是知道开发团队多做了一件事情


按照我上面的理解,我们公司倒还真是个敏捷型的,除了不是结对编程

不过我们也是一个小型团队,在一个办公室,通讯基本靠吼

看来这本书是买对了,对以后的工作肯定能提供不少指导

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