2009-07-15 23:21:06 lufeng4321 阅读数 11
  • SCRUM敏捷开发视频教程

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

    10394 人正在学习 去看看 CSDN讲师
现在行业里很多人都在谈论敏捷开发,这是一个热点,很多公司也正在企图把敏捷开发模式做为企业的核心竞争力之一,可见敏捷已经超越了传统的软件开发方法的范畴,变成了具有商业意义的业务模式。

什么叫敏捷,其实无论有多少定义,其核心就是一点:快速向客户交付软件产品,快速响应客户的需求变化。为了实现这些快速,软件企业在风险可控的基础上,可以忽略很多传统开发的流程、规范方面的工作要求,直接完成程序的交付工作。在敏捷者看来,很多规范方面的要求其实都是与最终交付的软件产品没有太大的关系,是属于不能直接产生收益的无效工作。

不过,多数人在讨论敏捷时,往往是都从程序开发的角度来实现敏捷,敏捷思想的一个实践就是XP。既然是XP,那么能够完成那个P的Programmer(程序员)就是一个关键因素了。然而,在国内目前的现状下,这个P恰恰是敏捷实现的一个瓶颈。按照道理来讲,敏捷最好的基础是有经验的资深程序员,应该是一些30岁左右的人群,既可以写出高质量的代码,同时又能够快速理解客户的业务,并且可以随时因客户需求而变,调整自己的程序,总而言之,是一种对产品对预见力和洞察力。然而这种思路在国内软件市场上却是一个很危险的模式:一方面,国内的市场似乎没用这么大的利润空间给一家软件公司去养众多的资深程序员,另一方面,从个人发展上来看,多数资深程序员在有了一定的业绩后,都进入了各个软件公司的管理层或者骨干团队,真正在一线做软件开发的人将越来越少。

所以,我们有必要在中国的国情下,发展出一种新的敏捷模式。事实上,在一个团体里,当优秀的程序员转变成为管理者或者中高端的技术领导者,一定会面临一个问题,就是他们的知识如何在更高的层次上进行放大,转换成为更大的商业价值。敏捷模式则提供了一根杠杆,让优秀程序员沉淀的知识,通过他们对软件的预见力和洞察力来撬动巨大的商业回报。

Dejax设计了软件工作室模式就是基于这种思路,以资深技术人员为基础,组建工作室这种单元,用于放大他们的价值,从而创造更大的商业回报。


以上文章转自http://www.dejax.cn/Advocacy/ShowArticle.asp?ArticleID=62
2012-07-30 15:41:59 DrifterJ 阅读数 3192
  • SCRUM敏捷开发视频教程

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

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

公司所有开发组目前都在提倡敏捷开发,我所在的开发组也没有out,刚刚发版的产品我们就引入了敏捷开发的一些概念--虽然还比较粗糙,但整体感觉还是蛮好的。发版后,有一段空闲期,闲来无事,看到同事桌上有本《轻松Scrum之旅--敏捷开发故事》,就借过来读了一下,通篇就是一个产品的敏捷开发过程,从概念和使用方法上看,能有不小收获。这次就写一下自己初次体验敏捷的一些感受和这本书的一点读后感。

先说一下自己在实际开发中的一些感受吧。

敏捷开发整体来说是一种思想,但凡是思想的东西就不会局限于某种或某几种应用之上。敏捷也不例外,软件开发作为一种智力工程,只是敏捷的一个应用而已。具体到实际的应用,思想就会被具化为一些行之有效的手段和指导原则。敏捷在实际软件开发有XP,RUP,Scrum等多种应用框架,这些框架基本都是一些指导原则的集合,我们实际开发中采用了Scrum,但中间也采用了其他框架的一些非常优秀的指导原则!这其实也体现了敏捷的部分思想:不拘泥于形式!

使用Scrum,首先要有功能看板,现在有很多软件形式的看板,我们第一次使用敏捷,果断没有使用这种看板,而是采用了更具视觉冲击力的实物看板,我们开发经理用周末打造了如下看板:

上面就是我们组大而帅的功能看板,那他的作用是啥呢?上面在不同格子上贴的便签又是啥呢?我先简介概括一下我们使用敏捷的步骤,这些问题你就会有了答案的。

我们第一次是这样使用Scrum的(其中的一些步骤和涉及到的用词和标准Scrum有所区别,这个我后面会分析):

1》 部门经理,开发经理,需求人员将产品进行分解,分解为一些较大的点,然后根据重要性和难易度将这些点分为3个迭代周期,即3个迭代周期后,产品整体及出炉了。

2》 开始每一次迭代前,部门经理,开发经理会将这个迭代的大点进行细分成一些小点,大小通常控制在1~3天。

3》 开始具体一次迭代,我们首先会开一个任务分配会议,时长大约1个多小时,开发经理给出所有的上述分解出的小点,挨个“招标”。如果有人感兴趣,举手示意即可,对于没人认领的点,开发经理最后会根据时间,强制分配给某人。

4》 开始迭代,首先所有人将自己的开发点写在便签上,并且贴在上述看板自己对应行的【准备】列中。这个看板“行”是和开发人员对应的,一人一行。“列”是和任务过程对应的,通常包括:准备;进行中;自测;完成。

5》 每天早晨9:00,开发经理会组织所有开发人员在看板前集合,举行每日例会,时长通常在20-30分钟。每个开发人员必须发言,发言内容为:昨天我做了什么事情,我遇到了什么困难,今天我要做什么事情。说的过程,同时移动任务便签到看板相应的列上。每个任务便签上都写有该任务的完成时间,如果开发时间和进度不匹配,开发经理会立即发现并进行沟通。

6》 一次迭代完成后,部门经理,开发经理,需求人员,所有开发人员,测试人员会开一次评审会议,时长大约2个小时,这期间主要是开发人员向所有与会者展示这次迭代的开发成果。测试人员也了解一下产品的使用方法,便于马上开展的测试工作。

这就是我们的敏捷过程,借用部门经理的话,这就是“山寨版”敏捷......但我们还是在这几条步骤下,经过3次迭代,产品成功发版了。其中也遇到了一些问题,比较典型的如下:

1》 任务分解粒度太粗!2~3天的任务,通常会产生拖延,因为这个时间本身就是估算的,任务时间长,说明其包含的功能点多,每个功能点有一点延迟,整个任务就有延迟,一个任务有延迟,最后往往会波及到整个迭代的时长!我们这3个迭代最后多出现了延时情况。

2》 任务粒度太粗还有另一个问题时,功能点的遗漏!这个问题甚至会拖延到测试时才被发现,只能临时将其添加到下次迭代中,影响了下次迭代的开发。

3》 开发人员受外界影响太大!我们开发人员不仅要参与这个产品的发版,同时还要参与维护以前的产品。这种时间没法计算到迭代周期中,但同样会影响迭代周期的计划时长。

4》 分解任务分配时间时,代码评审和自测的时间估量的太少,导致每次迭代后交付给测试的产品小问题太多。虽然整体流程可以走通,但仍热让测试团队怨气颇大!

这就是我们第一次自我敏捷的过程和期间产生的一些问题。如果仅仅从“敏捷的实施”这个角度看,我们的敏捷是失败的。因为我们没有按时优质的交付每一次迭代成果,最后的产品也产生了拖延。

 

然后再说一下我读完《轻松Scrum之旅--敏捷开发故事》一书后,对Scrum的一些收获吧,其中还有和我自己的敏捷开发进行的对比。先说一下Scrum中涉及到的一些名词:

1》 Product Owner:产品所有者,这个人发起一个产品的开发,并且负责将产品通过User Story的形式进行描述,并对所有User Story按优先级排序,给出一个大概的开发时间。我上述描述中“部门经理”就是我们那个产品的Produce Owner。

2》 Product Backlog:产品的功能点的总纲,即所有的User Story。最后Scrum是否完成,就看这个Backlog中是否还有剩余User Story。敏捷中允许Product Backlog发生变化,这分为两点:一是前面迭代中完成的部分发生了需求变化,则将这部分放到未完成的Backlog中,另一个是没有开发的部分发生变化。并且如果Scrum的整体周期很难变化,可以视开发进度从Product Backlog中将部分User Story移出。

3》 User Story:产品的一个开发点,通常是一个较大的点,从用户角度进行描述。一个大的User Story通常会包括多个较小的User Story。较小的User Story会包含多个Task。

4》 Task:产品的一个小的开发点,我们进行开发忘功能看板上贴便签上,写得就应该是Task。每个Task的时长通常为0.5~1天。从这个角度看,我上述描述的自己的敏捷对Task的大小没有控制好,这点确实对开发影响很大!

5》 Scrum Master:Scrum团队的负责人。负责一个Scrum团队和Product Owner交流的一个人。Scrum强调团队的自我管理性,即开始Scrum后,这个团队就相对封闭了,不应受外界影响。这个团队的一个开放口就是Scrum Master 。这个人负责团队与外界沟通,并且阻止外界对团队的影响。我上述描述自己的敏捷中,开发经理就相当这个角色。

6》 Sprint:中文翻译就是“冲刺”, 我上面描述自己的敏捷提到的“迭代”就等同于Sprint。实际实施Scrum中,就是要完成几个Sprint。一个Sprint时间通常为2周~2个月,这个视产品大小而定。

7》 Sprint Backlog:一个迭代过程中需要完成的功能点列表。这个列表就是从Product Backlog中挑选出来的。

8》 Sprint Planning Meeting:Sprint计划会议。这个会议是开始一个Sprint的标志会议。通常分为两部分,第一是Product Owner,Scrum Master,所有开发人员,用户(如果有的话最好)同时参加,共同决定这次Sprint中要完成Product Backlog中哪些功能,如果此刻又不明白的地方,Scrum Master和开发人员必须和Product Owner进行充分沟通,直到明白为止。第二是Scrum Master 和所有开发人员参加,将这次Sprint中的User Story分解为Story,每个Story完成时间控制在0.5~1天,并且由开发人员按兴趣领取相应的Task。注意代码评审和自测也要分别作为一个Task存在。

9》 Daily Scrum Meeting:每日例会。由Scrum Master和所有开发人员参与的例会。这个是Scrum的精髓,Scrum Master控制一个Spint的进度就是根据这个会议。

10》 Sprint Review Meeting: Sprint评审会议。每次Sprint后对整个Sprint的成果向Product Owner,测试进行演示的一个会议,是一个Sprint完成的标志。

11》 Sprint Retrospective Meeting:Sprint回顾会议。这个会议由Scrum Master 和全体开发人员参加,大家讨论一下在刚刚结束的一个Sprint中的所得和所失。是一个Scrum团队自我成长和进步的最好的方式,大家互相提出自己的建议并发现问题,进行团队经验累积。我上述自己的敏捷没有这个会议,这个是一大损失!

这些都是这本书提到的一些Scrum概念,在实际应用中,我们的一些东西和这个肯定会略有不同,这个无关紧要,但其中一些重要的步骤,比如最后8~11 这个4个,是不可或缺的!

Scrum是软件开发中对敏捷的一组具体的应用指导原则,他强调面对面的沟通(一个Scrum团队最好保持在6~8人,并且大家办公位置能在一起),欢迎变化,弱化文档(他强调代码和注释是最好的文档),并且不提倡加班(对于视加班为常态的广大IT“民工”真是一大福音啊)。

实施Scrum中,有几点是要提前有所防备的。Scrum欢迎变化,所以我们就不可避免会有一些需求的变动或开发人员请假的一些情况,所以我们在安排时间时尽可能留一些预留时间,这个长度视经验而定。如果在实施过程中,预感到进度出现滞后的现象,Scrum Master要及时和Product Owner进行沟通,暴露问题所在,提前做出调整,如延长一定时间或者去掉一些User Story。

Scrum中涉及一个功能看板,这个看板很重要,可以用实物看板(我上述描述的敏捷过程所用),目前也有很多Scrum实施软件,如ScrumWorks(这本书中使用的软件),这个软件好像是收费的,所以我也没用过,但貌似功能很强大!不仅能有实物看板一切功能,而且还支持自动绘制“燃尽图”,这是一个整个项目进度的可视化显示,从网上找到的燃尽图,大家可以看一下:

红线表示计划进度路线,蓝线表示实际进度路线。蓝线在上面,表示进度有所滞后,蓝线在下面表示进度有所加快。如果不用ScrumWorks这类软件,我们如果需要这种可视化图片,需要自己手动进行。

这就是自己先糊里糊涂经历过敏捷而后又细细品味后敏捷的一点入门小得,总结一下,敏捷就是一种思想,是一种以人为出发点的一种管理哲学,可以应用在各种领域。在软件工程领域,Scrum是一组具体的敏捷实施指导原则,概念清晰,比较适合初次采用敏捷的开发团队使用。

 

2013-07-11 16:20:30 heliang1108 阅读数 901
  • SCRUM敏捷开发视频教程

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

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

前几天和一个刚换工作的同事沟通,他告诉我他所在的新公司领导不喜欢敏捷开发模式,原因是他们领导觉得敏捷开发对工程师素质的要求太高了。我觉得这个想法很新颖,值得讨论一下。

 

1 我常说,敏捷开发模式的基础是代码要敏捷,即如果工程师生产出来的代码本身不够“敏捷”,那也无所谓谈何种开发模式了,从这个角度看,敏捷开发确实对工程师素质有很高的要求

2 对于素质高的工程师,哪个项目经理不喜欢呢?敏捷开发模式也好,传统瀑布开发模式也罢,作为项目的管理者,总是希望项目的开发工程师素质越高越好,从这个角度看,高素质工程师总是受欢迎的,并不是敏捷开发模式特别偏爱

3 现实的项目中,在项目管理者看来,所谓的高素质工程师总是不够的,或者说,素质不高的工程师总是占大多数的,那既然敏捷开发对工程师素质又有那么高的要求,因此,领导们对敏捷开发敬而远之好像也有那么点道理

4 一般而言,敏捷开发模式的推崇者宣称敏捷有着更多的优点,表现出来就是更好的响应变化的需求、更快的开发进度和更高的质量等等,就我个人的体会,敏捷还有一个很突出的优点就是如果某个项目注定要失败,那么敏捷可能可以更早的把这一不幸的结果暴露出来,这个优点有时候我甚至觉得这是敏捷最大的优点

5 敏捷号称的那么多优点,仅仅是因为参与敏捷开发的工程师素质高吗?

6 来看一个实际的例子:某个项目经过任务分解,一共有十个子模块需要开发,在传统的开发模式下,项目经理把这些子模块往开发工程师处一扔,要求他们评估出工作量和制定研发计划,开发工程师做完评估预估和制定完计划后,接下来就开始进入实际开发阶段了;开头几个子模块进展很顺利,每个周的周报都很好写,项目经理也很乐观;开发到最后两个子模块或者是所谓系统联调阶段时,开始出现各种状况了,各种质量问题、各种发布计划 DELAY,项目经理开始纠结了,项目失败的苗头开始显现了。为何会出现这种情况?我是这样认为的:从人情上而言,开发工程师在拿到10个子模块开发任务后,他会选择那些比较熟悉、比较有把握的模块开始先做,而比较麻烦、不太熟悉的子模块会相对的放到最后做。而正是这样的一种开发顺序选择,很容易导致上述例子中的状况

7 在敏捷开发模式 scrum 中,上述状况是可以得到避免的,因为开发模式把子模块开发顺序的权力明确赋予了产品经理,而非研发人员,这样一种职能的分配,可以有效的降低项目的风险

8 当然,如果某一个子模块确实开发难度高,敏捷并不能帮程序员把开发难度降低,程序员在传统模式下无法完成的某些算法的开发,在敏捷模式下依然无法完成,但是,敏捷的好处是,它可以让产品经理或者项目经理很快发现这个事实,再了解到该事实后,他可以暂停或者取消该项目,也可以再增加一些资源的投入,确保技术困难得到解决,这是敏捷一个很大的优点之一

9 从上面的例子可以看到,所谓的传统模式对工程师要求低的看法,其实是以传统开发模式的项目失败率上升为代价的,即如果工程师能力不够完成某项目,在传统模式下,这个项目依然可以立项和推进,直到某一天这个项目走向失败;而在敏捷开发模式下,这个项目可能很快就被公司给暂停或者取消,因为他们很早的就可以发现工程师素质不足以完成工作的事实,而这个事实,工程师自己很可能是知道或者疑虑的,但是工程师自己是很可能不会告诉产品经理或者项目经理的

10 我的看法是,在投入同等资源(人员、时间、其他部门配合等)的情况下,敏捷开发模式的效率更高,即产出的产品功能更多、质量更好;而在完成特定指标(功能点、质量水平等)的情况下,敏捷对资源的要求可能比传统的方式更低

2009-03-27 13:41:28 bhscHello 阅读数 149
  • SCRUM敏捷开发视频教程

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

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

敏捷

以前对敏捷这个词并没有多少认识,以为就是“快”。然后最近看了《敏捷软件开发--原则、模式、实践》才算对敏捷有了一点初步的认识:

真正的敏捷指的是快速宾锲可持续的方式前进,不是50米短跑而是马拉松长跑。不以阶段、文档、基础结构来衡量软件的进度,而是以满足顾客的需求的数量来衡量

敏捷团队

经常进行面对面的交谈来进行交流,而不是文档,并且随着环境的变化而不断 对团队的组织方式、规范、关系等进行调整。

所有的任务都是分配给团队的,再由团队确定分配任务的方法,不存在单一人 员的任务

以最高的质量来完成简单的工作,而不是夸夸奇谈未来性

人是最重要的因素,任何负面影响都应该尽可能改变

敏捷的项目

尽早、持续的交付有价值的软件来提高质量,交付的时间越短越好

不惧怕修改

重要的敏捷方法---XP

尽可能使客户成为开发人员,融入团队工作

短交付工期,每两周交付一次可以工作的软件

结对编程

集体所有权:没有程序员对任何特一的模块或者技术负责。每个人都参与各方面的工作

持续集成:任何时候可以拆出代码进行修改,最重要的是可以保证所有测试通过

可持续的开发速度、开放的工作空间、计划游戏、简单的设计、重构、隐喻

计划游戏

两周左右进行一次迭代,每次迭代开始前都与用户讨论迭代周期内需要实现的客户素材,一旦迭代开始,客户就不能改变迭代期内需要实现的素材。可以添加或者修改其他素材。

过大的用户素材要进行拆分,过小的需要合并。

测试驱动开发(测试先行、频繁运行测试

1. 确保先前的工作正确,不允许倒退

2. 先编写测试,让我们的程序便于调用

3. 迫使程序可测试的

4. 测试可以作为一种无价值的文档

2019-04-16 18:20:53 jackjyy 阅读数 88
  • SCRUM敏捷开发视频教程

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

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

设计敏捷开发流程

阅读数 280

敏捷软件开发

阅读数 1170

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