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阶段之后进行,减轻了集成测试的压力,缓和了测试人员由于不理解需求,测试不彻底或描述不准确与程序员产生分歧。
    三、从学习角度看,我们可以借鉴敏捷开发中的一些优秀经验和思想。平时兼顾整体规划和细节规划,在应对变化上要做到灵活,给自己预留足够的缓冲时间。
     做好人际交流,了解集体状况、优秀的或与自己紧密相关的个人的状况,这是自我调整的强有力参考。
     最后,要做好选择,找到适合自己的环境和方法。踩在如此多的“关毅”的肩膀上,我们已经有足够的知识水平和认知能力去适应这个世界的节奏了。
    
    
2012-07-30 15:41:59 DrifterJ 阅读数 3195
  • SCRUM敏捷开发视频教程

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

    10428 人正在学习 去看看 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是一组具体的敏捷实施指导原则,概念清晰,比较适合初次采用敏捷的开发团队使用。

 

2004-11-03 14:37:00 JJNW 阅读数 1598
  • SCRUM敏捷开发视频教程

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

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

论敏捷开发中的注意点

摘要

本文是笔者项目开发经历的经验总结。笔者所在的公司根据自身开发实力和承接项目规模选择了敏捷开发思想来开发这个项目。在开发过程中,我们感受到了敏捷思想给我们带来的成果,也看到了敏捷思想在我们所处的实际情况下的需要本地化的地方。我们对这些地方做了研究,形成了一些理论并努力使之可移植到相似的开发环境中。

背景

我所在的公司从年初开始尝试用敏捷思想来开发特种设备的监察检验软件,从某市先开始试点,我参加了这个项目,做了系统分析、代码编写、系统测试的工作。

特种设备的生产检查与定期检验是国家规定强制执行的,近年来,国家技术质量监督局鼓励各地方技监局采用信息化手段改造业务,提高工作效率;另一方面,信息化业务便于数据的收集与管理,为特种设备的管理检验标准的制定和修改提供有利依据。

我们要做的一套系统,包括了某市锅炉检验单位的全部监察检验业务的信息化及该单位的日常管理软件的开发,有一部分软件是需要分派到下层单位中收集数据,然后该单位收集整理上报给上级单位,上级单位审批后发回来,再由该单位处理,另外一部分则需要让软件使用者通过互联网填写数据以简化重要性较弱的数据收集。单位内部要对所有员工有一个统一的软件界面,而相应的业务都是从这个界面启动,我们描述为总平台。总平台是B/S结构,采用Asp.net开发,而业务使用的软件由于涉及大量的数据业务,采用Delphi+SQLServer开发。

对于为了理清头绪,我们定义了三个等级的工作,依次为:项目、模块、功能点。模块被我们看成了可以独立执行的应用程序,一个项目被分成了如干个模块,每个模块又包含若干功能点,我们的主要工作即可定义为迭代开发功能点。这么做的原因是,一方面,我们所做的项目,已在有少量实施成功的案例,它们可以作为我们功能点设计的参考;另一方面,系统的行业特性较明显

注意点一:注意发布周期的选择

敏捷软件开发的一大特点就是周期性发布可运行的软件产品,这么做的初衷是为了更明确客户的需求,背后的原理是我们常说的"客户只有看到了你给他什么,才能知道自己需要什么"。而选择周期性发布是因为一方面要及时响应客户的需求,另一方面避免开发走弯路,减少错误带来的损失。但是在具体实施的时候,我们却遇到了实际的问题。我们的开发结果是以模块发布的形式,每次发布某个模块的某个状态。起先计划是三周发布一次。结果开始阶段的三周后我们的模块只有粗糙的启动、退出功能,后台数据库初步成形,模块框架已经搭建好。发布时,我们需要客户对上述构架作出评价并反馈给我们,以便我们修改。结果客户的反馈迟迟不到,因为实际的情况是,客户只看了一眼便退出来,因为里面什么功能都没有。当我尝试向客户们解说他们可以就这个软件随意谈谈看法时,他们的反应还不如我们以需求分析为目的时的谈话,其中一个还表示了对我们的失望。我们现在就面临这么一个问题:这次发布明显是失败的,它不仅没有达到预期的效果,甚至起到了反作用。那么我们究竟失败在哪里?我们重新审视了自己发布的产品,它可评价的地方还是很多的,比方说数据库的架构,极可能存在与将来的模块数据可以合并的地方(事实上这问题在后期出现了),那么我们必须在初期定义足够兼容的实体结构和关系,这一点我们所知甚少,而客户中却有同时使用多个模块的人物,他应该看得出来,而不必等到我们对模块分析得足够彻底后跳到项目级别来分析设计项目。但是我们的客户拒绝评价之,这就是最主要的问题:客户并不知道什么敏捷开发,什么极限编程,所以更别希望他们懂得什么是迭代,他们是以自己的或者说是传统的观点看待软件,而对于他们来说,软件就是一件商品。客户对商品的概念影响着他们对我们发布的模块的看法。在他们看来,商品就是花钱买了来就能用的,没有哪家商家会给你一个厂里的半成品,过段时间再给你一个半成品,前面的那个让你扔掉,如此反复几次,才算你买到了这个商品。当我们推测到此处时,我们着手验证这个推想。我们随即给客户送过去一个我们以往实施成功的案例,请他们就软件界面提一些自己的看法,当然在选送案例时我们考虑了一些因素,既要让客户得到可靠的信息有要客户没有多少额外的负担,同时也要保证公司业务的保密。我们的想法是针对客户的心理提出来的,因为是已成熟的公司的代表作,客户会放松地使用和评价,同时可以潜移默化中接受公司的软件风格。很快地,反馈回来了,客户提出了很多零散的要求,我们从中发现了对我们的模块有可应用的变更。这时已经过完第四周了。我们注意到如果第六周再发布新板本的模块的话,会重复我们第一次发布后的尴尬,所以我们改变了发布计划,准备在模块整体功能完成后发布,整个模块的开发花去了我们五个星期的时间。之后我们的模块发布,根据我们收到的反馈和模块的完成情况,我们估计下一次发布可以定在4周之后。随后,我们的模块发布稳定在了两周。

注意点二:你的客户也要注意更改要求

敏捷开发中最平静的应该是代码开发阶段,这个阶段产生的结果依赖于团队的技术水平。但是业界公认的是不管团队水平如何,客户总是会提出更改的,这一点大家习以为常。以我们团队为例,每次迭代发布后收到的更改要求都在五个以上。理论上来讲,反馈中的更改数量应该是开始阶段较多,而后慢慢减少的。但是目前这种情况却让我们感觉到我们的开发不够敏捷。于是我们花了点时间在用户的变更需求上,方法是整理用户需求:用一张二维的表格来划分需求,横轴是需求提出的时间,竖轴是需求所属的分类。分类是我们自己定的,事先并没有具体的定义,也就是说分类的完善是和用户的更改需求归类过程同步进行。我们发现用户的更改需求可以分为以下三类:一、个人习惯类要求;二、软件正确性要求;三、软件有效性要求。个人习惯即用户的操作习惯,如一条更改要求是“在界面上输入数据时,要能够通过Enter键跳到下一个输入框内”,此类更改发生得最频繁。我们甚至发现了改了又改回去的要求。第二类的更改需求通常由用户的误操作或故意破坏性输入引发的系统报错。第三类更改需求是我们的软件流程与他们的业务流程不相符的地方。不管我们处于开发的何种状态,第一类的更改需求总是居高不下,这使我们的软件开发十分尴尬:我们期望客户能够多提出二、三类的更改需求,但是客户显然没有理解我们的这一需求。我们决定管理一下客户的更改需求。以往,我们会选定一个更改要求收集人员,定期到客户处收集客户的更改需求,收集的方法是听用户的抱怨。而更改需求是专员随手记录的,回来我们再研究这些远古咒语般的更改需求。为改善这种方法,我们做了一张更改需求的描述单,每张单子对应一个更改需求,单子上需要填写更改的原因,目标的详细描述,另外这张单子必须由我方人员和客户方负责人同时签字才能产生效用.具体实施起来如下:问题收集者每次分发给客户足够数量的问题描述单,同时回收上次的问题描述单,对单子的内容确认后请客户方负责人审核签字,随后问题收集者签字.我们在下一次迭代中应用这些更改.这么做的好处是,用户的更改需求被提升到一个让用户引起重视的地位,用户在重视更改需求的情况下提出的更改要求是经过他们挑选过的,是整个系统中较为重要的部分,而一些次要的不必要的更改,则在客户内部被过滤。另外一个好处就是客户的更改需求提出方式宽松了,可以随时提出来更改需求。以往是在我方人员的监视下使用软件,有心理压力,以为我一定要试出毛病来,就算没有也不能浪费这个做上帝的机会,结果过分地追求细枝末节

第三点:注意保持开发节奏

敏捷开发中“敏捷”的含义中,有一个我们经历了开发过程才发现的意义,即开发节奏的保持。举个例子说,敏捷开发中禁止超时工作,即使有人自愿或热衷,这并不符合我们的观念。这么做不是单为了效率,还有另外一层含义:团队行动的节奏远远要比个体行动的节奏难以把握,而团队很难在变动的节奏下创造价值。如果把握团队节奏的难度非常大,我们宁愿将团队节奏定在一个稳定的小范围内。这一点是我们亲身经历的心得。事实上,每个团队的最合适的开发节奏都不一样,要靠团队领导者有意识地调节。而一旦找到了这个开发节奏,团队的软件过程即可预测,达到已管理级,这也是我们衡量团队开发节奏的条件。

第四点:节对编程的实施

整个开发过程,我们团队共处一室,讨论着开发细节,技术问题在平时开发中讨论解决,需求性问题在每天的固定时间向客户咨询,客户如果也无法明确需求,我们自作主张地开发出来。我们鼓励团队成员讨论,互相看代码。这和敏捷开发描述的结对编程有出入,我们觉得这种编程方式对国内的程序员来说普遍过于开放了(夫妻程序员可以例外)。结对编程是一种兼顾开发效率和开发质量的方法,但不唯一,我们在侧重效率兼顾质量的原则下采取单人编程团队辅助的方法理论上要比结对编程更有效率。这么做的后果有一点就是代码质量下降,让我们在后期的迭代中有一段时间举步维艰,幸好我们因此做出的代码重构工作扭转了局面,保证了开发质量和速度。

总结

以上是我在一个敏捷开发思想指导软件开发过程的项目中的总结,这些结论的得出都经过了问题的发现,解决方法的探讨、选择、优化这些环节。对我今后的工作有不可忽视的影响。

2019-03-01 12:07:38 weixin_44606268 阅读数 164
  • SCRUM敏捷开发视频教程

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

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

敏捷开发与DevOps的一些随想

这是笔者第一次在 CSDN上发文章,估计可能读者寥寥。无妨无妨。

最近一直在从事DevOps项目,并且公司层面也是敏捷开发的推动者之一,所以对于DevOps和敏捷有了一些自己的感受:

今早看了王晔倞在CSDN上发问《为什么都敏捷开发了项目还会延期?》,我有感而发。

敏捷开发的根本是满足的灵活性,而非效率的提升。或者换句话说:业务需求和人员投入始终是成正比的,换了啥方式都是一样的,不是说敏捷成了银弹。这是产品经理或业务人员需要明白的问题。所以对于产品需求的取舍、用户倾向的试探就显得尤为重要,或者换句话说,码农们是产品实现的工具,是手和脚,但真正要去哪、干些啥、怎么干还需要产品经理这个大脑来决策。

敏捷开发来满足快速交付,但只是软件生产全流程中的一段,即:由idea到安装介质包的阶段(可能只作为单元测试,或者单元测试都还没做过)。离产品上线产生价值还远了去了。所以接下来的加速,就需要DevOps以及云的助力,例如:云的编排模块能不能做到自动资源供给,DevOps能不能实现各个环境的自动化部署,能不能将自动化回归测试一并结合进来,等等。

所以总结下个人观点:

  1. 工具做好工具的事情,但工具只能帮助决策,不能替代决策;
  2. DevOps在传统企业落地,极有可能是Dev和Ops分期来实现,时机成熟时,才串起全流程;
  3. 敏捷、DevOps确实是天生一对,但要一起上,还得看时机才成,但无论是敏捷、DevOps都需要持续的度量、反馈、优化、改进,对流程、对工艺、也是对产品都是一样一样的。
2010-10-31 13:39:18 iteye_4596 阅读数 18
  • SCRUM敏捷开发视频教程

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

    10428 人正在学习 去看看 CSDN讲师
敏捷开发方法:一种以人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法。
敏捷的精辟概括:敏捷开发就是在一个高度协作的环境中,不断地使用反馈进行自我调整和完善。

态度决定一切:
1. 做事:
指责不会修复bug。把矛头对准问题的解决办法,而不是人。这是真正有用处的正面效应。
切身感受:勇于承认自己不知道答案,这会让人感觉放心。一个重大的错误应该被当做是一次学习而不是指责他人的机会。团队成员们在一起工作,应互相帮助,而不是互相指责。
2. 欲速则不达:
不要坠入快速的简单修复之中。要投入时间和精力保持代码的整洁、敞亮。
切身感受:在项目中,代码应该是很敞亮的,不应该有黑暗死角。你也许不知道每块代码的每个细节,或者每个算法的每个步骤,但是你对整体的相关知识有很好的理解。没有任何一块代码被警戒线或者“切入入内”的标志隔离开。
3. 对事不对人:
让我们骄傲的应该是解决了问题,而不是比较出谁的主意更好。
能容纳自己并不接受的想法表明你的头脑足够有学识。----亚里士多德
切身感受:一个团队能够很公正地讨论一些方案的优点和缺点,你不会因为拒绝了有太多缺陷的方案而伤害别人,也不会因为采纳了某个不甚完美(但是更好的)解决方案而被人嫉恨。

敏捷开发学习体会

阅读数 1184

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