ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 8.11 ITPUB在线交流——Scrum

8.11 ITPUB在线交流——Scrum

原创 Linux操作系统 作者:susan_huangyong 时间:2009-08-28 13:20:09 0 删除 编辑

突然很想以“敏捷来了”来做为标题,想到要统一格式只好作罢。

如果你是IT从业人员,“敏捷开发”这个字眼已经一定不会感到陌生,在百度上搜索,能搜出二十多万条链接。我也是如此,惭惭感到“敏捷开发”离我们越来越近了,但仍然对此不甚了解,不知道是否能使用这种方法来实施公司内的业务系统。本期交流就是针对“敏捷开发”进行了科普,很是受益,与大家一同分享。

敏捷,是针对瀑布模型而来的。

瀑布的问题:由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发的风险;早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果;等等

而敏捷方法则在几周或者几个月的时间内完成相对较小的功能,强调的是能将尽早将尽量小的可用的功能交付使用,并在整个项目周期中持续改善和增强。

敏捷宣言:

 * 人和交互重于过程和工具。

    * 可以工作的软件重于求全责备的文档。

    * 客户协作重于合同谈判。

    * 随时应对变化重于循规蹈矩。

敏捷方法共有七种,最多谈到的就是Scrum和XP,Scrum解决的是组织层面的敏捷问题,XP解决的是编程实践层面的问题,二者正好互为补充,相得益彰 。Scrum 主要提倡如下敏捷原则 :

       保持简单:Scrum本身就是很简单轻量级的流程,它能简化我们的开发流程。

       接受变化:Scrum鼓励将工作细分成小块。它关注的是一小段一小段时间,但是只有在这些时间段的中间,我们才可以重新调整工作的优先级。

       不断迭代:Scrum需要在小于30天的一次次迭代中构建应用程序。

       不断的反馈和改善:在每一次迭代的末尾,Scrum流程要求我们回顾以前是怎么做的,并且思考我们下次可以做哪些不同的事来改善流程。

       协作:Scrum强烈鼓励团队成员的协作和沟通。如果没有这些,Scrum就一点用都没有。

 减少浪费:Scrum帮助我们识别做那些只对客户或者团队有价值的情。

 

"产品订单" (product backlog):这是你构建一个产品所需做的所有事情的一个高层次的列表,并按优先级排列,这样可以保证你总是工作在最重要的任务上。" 冲刺订单"(sprint backlog):是sprint的工作任务列表。一个"冲刺"订单来自于产品订单上最高优先级的一些任务,以及产生的附加任务,每一个任务都应该有一个 明确的“完成(Done)”的定义。 

"冲刺"(sprint):一个sprint就是一次为完成特定目标的迭代,一般是2-4个礼拜。 

"产品负责人"(Product Owner):这个人是负责维护产品订单内容和优先级。 

简单讲 "产品负责人"是先建立一个产品"订单"(backlog),做一个短期“冲刺”(sprint)计划,执行这个计划,每天开会讨论计划中的问题和进展,计划完成后演示工作成果,再对该阶段的工作做回顾、反思,接着不断重复以上流程。每天开一次短会,检查sprint中每个任务的进展状况,对未完成的任务,要求任务所有人给出新的剩余工作量的估算。  最后后再开一次回顾会议,找出不足,持续改善。

Scrum Master 是规则的执行者 ,促进 Scrum过程,他的主要工作是去除那些影响团队交付冲刺目标的障碍。ScrumMaster 并非团队的领导(由于他们是自我组织的),而是负责屏蔽外界对开发团队的干扰。

“每日站立会议” 每个团队成员需要回答三个问题:

    * 今天你完成了那些工作?

    * 明天你打算做什么?

    * 完成你的目标是否存在什么障碍?

 

在公司里使用的就是瀑布型的实施过程,遇到最大的难题就是不断的变更要求,要花费很多的精力和客户沟通,打消变更的想法,或是承诺在下一次的扩展实施中执行变更。因此,多多少少降低了客户的满意度,也使得客户的积极性有所降低。但是如果执行变更,则可能会由于变更部分关联了许多对象,一旦配置文档不完整,就可能对系统部分构成威胁。我们经常遇到的问题就是,由于一个变更引起一系列的衍生的变更,需要花费更多的精力来进行执行,最后的结果就是项目延期。当然,这也不能排除项目初期需求分析不够全面、系统架构设计存在先天缺陷或漏洞的因素。

如果说敏捷开发就是适用于变更频繁的项目,那么是否能够在公司里推行呢?就我对敏捷的理解,作为甲方,如果要推行敏捷方法,我会采取如下措施:

1、第一个迭代过程就是需求分析和架构设计。输入是项目的总体目标、范围,相关业务部门的需求诉求。输出为一个产品清单。我的想法:产品清单的优先级顺序,应该是以需求最为明确的功能放在最前面,因为往往重要的需求也是业务部门希望优化的流程,变更的可能性相当大,而且对系统架构的设计也会有很大威胁。第一个迭代过程,如果顺利而且按期完成,会对项目团队的热情有极大帮助。产品清单中的每一个迭代周期都不超过4周,防止产生懈怠。

2、其后每一个迭代过程中的每个里程碑,都要检查和更新产品清单,有了变更就产生新的迭代,同时更新配置库,记录过程绩效。其实,我仍旧担心,采用敏捷方法,用户会随心所欲地提出变更,不知不觉中产品清单越来越长,遥遥无期。而且,凡是变更不可避免会对数据库有改动,难道不会影响整体设计吗?

3、每天的站立会议很有参考价值,有问题及时暴露出来,有错误也可以及时纠正过来。也可据此做为绩效评价的依据。

 

对敏捷还不甚了解,欢迎大家批评指正。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/352988/viewspace-613482/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2009-07-16

  • 博文量
    35
  • 访问量
    95014