2019-04-12 22:52:55 y_279611480 阅读数 551
  • SCRUM敏捷开发视频教程

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

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

SCRUM 是什么?

Scrum是敏捷开发中的名词。

敏捷开发是什么?

敏捷开发(Agile Development) 是一种以人为核心、迭代、循序渐进的开发方法。

简单的说的话:

  1. 它只是一种开发思想,而不是开发技术;
  2. 其次,需要明白,通过敏捷开发的项目,包含的诸多子项目,都会带有,已经测试结束,具备了集合和可运行的特征;
  3. 敏捷开发,初始,并不追求完美的设计以及编码,而是,尽可能快的先开发出产品的核心功能,以及发布可用版本。之后,才会在多余的生产周期内,根据需求,不断的完善升级与迭代产品。

eg:对于Java全栈式开发工程师来讲,拿到需求,了解之后,第一件事,并不是先去完善后台代码,而是迅速的先将需求页面(网站),先实现。而后,才开始根据需求一步步实现功能。

以人为核心是什么意思?

一句话概括来讲的话,便是:

不似瀑布开发的思想,往往开发完后,写了一堆的开发文档进行开发、
而是,尽量的少写开发文档,只写一些必要性的文档,因为敏捷开发注重的是人与人面对面之间的交流。所以说它是以人为核心。

迭代 是什么意思?

类似与 单体开发 与 微服务、分布式开发的区别。
一个是,将所有的功能实现后,方可测试与后续操作。
另一个是,将所有的功能分为一个个服务或小功能,完成一个便可开发,测试,上线一个小功能。慢慢的完成总体。

循序渐进自然,也可由上明白。

SCRUM 与 敏捷开发思想有什么关系?

Scrum是敏捷开发之后的方法的一种。

敏捷开发的模式分类(摘抄至互联网):

敏捷开发的实现主要包括 SCRUM、XP(极限编程)、Crystal Methods、FDD(特性驱动开发)等等。其中 SCRUM 与 XP 最为流行。

同样是敏捷开发,
XP 极限编程 更侧重于实践,并力求把实践做到极限。这一实践可以是测试先行,也可以是结对编程(eg:多人协调开发)等,关键要看具体的应用场景。

SCRUM 则是一种开发流程框架。
SCRUM 框架中包含三个角色,三个工件,四个会议,听起来很复杂,其目的是为了有效地完成每一次迭代周期的工作。

SCRUM 的工作流程(摘抄至互联网)

学习 Scrum 之前,我们先要了解几个基本术语:

Sprint:冲刺周期,通俗的讲就是实现一个“小目标”的周期。一般需要 2-6 周时间。
User Story:用户的外在业务需求。拿银行系统来举例的话,一个 Story 可以是用户的存款行为,或者是查询余额等等。也就是所谓的小目标本身。
Task:由 User Story 拆分成的具体开发任务。
Backlog:需求列表,可以看成是小目标的清单。分为 Sprint Backlog 和 Product Backlog。
Daily meeting:每天的站会,用于监控项目进度。有些公司直接称其为 Scrum。
Sprint Review meeting: 冲刺评审会议,让团队成员们演示成果。
Sprint burn down:冲刺燃尽图,说白了就是记录当前周期的需求完成情况。
Release:开发周期完成,项目发布新的可用版本。

开发模型:
流程图

流程:

  1. 由产品的负责人,按照需求的优先级,优先取出一部分Backlog(需求清单)。
  2. 在每个Sprint(冲刺周期),开发团队根据计划,确定好每个周期的需求清单(Backlog)。既,在每段时间内需要完成的工作任务是什么。
  3. 对团队成员进行任务的分配开发。每天,团队都会开启Daily meeting(每天的站会)【既,明白自己之前完成了什么】。
    而后团队成员调整自己的Task状态【既,每个小任务的完成时间又该控制在什么时间内】,整个团队便更新自己的Sprint burn down(冲刺燃尽图)。
  4. 当这份Backlog(需求清单)完成之后,便会开启团队的Sprint Review meeting:(冲刺评审会议)。没问题的话,便会发布出发此阶段产品的发型版本(Release),且进行Sprint review meeting(回顾会议)

写在最后,PS:此文内容,部分摘抄至互联网,如若,原文博主介意,可私聊。谢谢。
自然,此文并不完善,欢迎各位点评。

2019-08-12 20:39:23 yjn1995 阅读数 763
  • SCRUM敏捷开发视频教程

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

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

前言

  

迭代开发

  敏捷开发的核心是迭代开发(iterative development)。敏捷一定是采用迭代开发的方式。那么什么是"迭代开发"呢?迭代的英文是 iterative,直译为"重复",迭代开发其实就是"重复开发"。
  对于大型软件项目,传统的开发方式是采用一个大周期(比如半年)进行开发,整个过程就是一次"大开发";迭代开发的方式则不一样,它将开发过程拆分成多个小周期,即一次"大开发"变成多次"小开发",每次小开发都是同样的流程,所以看上去就好像重复在做同样的步骤。
  举例来说,SpaceX 公司想造一个大推力火箭,将人类送到火星。但是,它不是一开始就造大火箭,而是先造一个最简陋的小火箭 Falcon 1。结果,第一次发射就爆炸了,直到第四次发射,才成功进入轨道。然后,开发了中型火箭 Falcon 9,九年中发射了70次。最后,才开发 Falcon 重型火箭。如果 SpaceX 不采用迭代开发,它可能直到现在还无法上天。
  迭代开发将一个大任务,分解成多次连续的开发,本质就是逐步改进。开发者先快速发布一个有效但不完美的最简版本,然后不断迭代。每一次迭代都包含规划、设计、编码、测试、评估五个步骤,不断改进产品,添加新功能。通过频繁的发布,以及跟踪对前一次迭代的反馈,最终接近较完善的产品形态。

增量开发

  迭代开发只是要求将开发分成多个迭代,并没有回答一个重要的问题:怎么划分迭代,哪个任务在这个迭代,哪个任务在下个迭代?这时,一般采用"增量开发"(incremental development)划分迭代。
  所谓的"增量开发",指的是软件的每个版本,都会新增一个用户可以感知的完整功能。也就是说,按照新增功能来划分迭代。
  举例来说,房地产公司开发一个10栋楼的小区。如果采用增量开发的模式,该公司第一个迭代就是交付一号楼,第二个迭代交付二号楼…每个迭代都是完成一栋完整的楼。而不是第一个迭代挖好10栋楼的地基,第二个迭代建好每栋楼的骨架,第三个迭代架设屋顶…
增量开发加上迭代开发,才算是真正的敏捷开发。

敏捷开发的好处

早期交付

  敏捷开发的第一个好处,就是早期交付,从而大大降低成本。
  还是房地产公司为例,如果按照传统的"瀑布开发模式",先挖10栋楼的地基、再盖骨架、然后架设屋顶,每个阶段都等到前一个阶段完成后开始,可能需要两年才能一次性交付10栋楼。也就是说,如果不考虑预售,该项目必须等到两年后才能回款。
  敏捷开发是六个月后交付一号楼,后面每两个月交付一栋楼。因此,半年就能回款10%,后面每个月都会有现金流,资金压力就大大减轻了。

降低风险

  敏捷开发的第二个好处是,及时了解市场需求,降低产品不适用的风险。
  请想一想,哪一种情况损失比较小:10栋楼都造好以后,才发现卖不出去,还是造好第一栋楼,就发现卖不出去,从而改进或停建后面9栋楼?
  对于软件项目来说,先有一个原型产品,了解市场的接受程度,往往是项目成功的关键。有一本书叫做《梦断代码》,副标题就是"20+个程序员,三年时间,4732个bug,100+万美元,最后失败的故事",这就是没有采用敏捷开发的结果。相反的,Instagram 最初是一个地理位置打卡 App,后来发现用户不怎么在乎地理位置,更喜欢上传照片,就改做照片上传软件,结果成了独角兽。
  由于敏捷开发可以不断试错,找出对业务最重要的功能,然后通过迭代,调整软件方向。相比传统方式,大大增加了产品成功的可能性。如果市场需求不确定,或者你对该领域不熟悉,那么敏捷开发几乎是唯一可行的应对方式。

如何进行每一次迭代

  虽然敏捷开发将软件开发分成多个迭代,但是也要求,每次迭代都是一个完整的软件开发周期,必须按照软件工程的方法论,进行正规的流程管理。

 &emssp;具体来说,每次迭代都必须依次完成以下五个步骤。

  • 需求分析(requirements analysis)
  • 设计(design)
  • 编码(coding)
  • 测试(testing)
  • 部署和评估(deployment / evaluation)
    每个迭代大约持续2~6周。

敏捷开发的价值观

《敏捷软件开发宣言》里面提到四个价值观。

  • 程序员的主观能动性,以及程序员之间的互动,优于既定流程和工具。
  • 软件能够运行,优于详尽的文档。
  • 跟客户的密切协作,优于合同和谈判。
  • 能够响应变化,优于遵循计划。

十二条原则

该宣言还提出十二条敏捷开发的原则。

  • 通过早期和持续交付有价值的软件,实现客户满意度。
  • 欢迎不断变化的需求,即使是在项目开发的后期。要善于利用需求变更,帮助客户获得竞争优势。
  • 不断交付可用的软件,周期通常是几周,越短越好。
  • 项目过程中,业务人员与开发人员必须在一起工作。
  • 项目必须围绕那些有内在动力的个人而建立,他们应该受到信任。
  • 面对面交谈是最好的沟通方式。
  • 可用性是衡量进度的主要指标。
  • 提倡可持续的开发,保持稳定的进展速度。
  • 不断关注技术是否优秀,设计是否良好。
  • 简单性至关重要,尽最大可能减少不必要的工作。
  • 最好的架构、要求和设计,来自团队内部自发的认识。
  • 团队要定期反思如何更有效,并相应地进行调整。
2015-10-12 10:32:44 junli_chen 阅读数 6755
  • SCRUM敏捷开发视频教程

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

    10414 人正在学习 去看看 CSDN讲师
敏捷开发的核心思想主要是迭代式开发,将整个项目分解为数个短期的迭代周期,快速相应需求进行增量开发。
结合我们公司的开发经验来看,我个人觉得敏捷开发主要包括几个步骤:
需求制定——》需求分析——》设计编码——》测试、功能验证——》发布版本——》下一个周期

1、需求制定:需求方根据上一个版本,提出的新开发需求或调整等。
2、需求分析:开发及测试人员,与需求方讨论并分析新需求,并验证需求的可行性。
3、涉及编码:根据确认后的需求,设计实现方式并进行编码。
4、测试、功能验证:对软件稳定性进行各种测试,并由配合需求方进行功能验证。
5、发布版本:将这个版本发布给需求方。
6、下一个周期:重复1到5步骤。

实际开发中不可能情况非常顺利,一般都会有新的需求或修改在开发过程中被发现或提出,
这时候并非不能调整原有的开发计划,可以视具体情况而定决定是否加入开发计划中,
如果涉及到大规模的改动则一般需要作为下一个版本的开发任务。

由于敏捷开发是使用增量式的开发,开发周期短响应快,一般不会出现致命的缺陷,整个开发过程较为流畅。


Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以达到管中窥豹的目的。

敏捷开发宣言——
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
虽然右项也有价值,但是我们认为左项具有更大的价值。

以上的宣言比较抽象,基于该理念,以下是ThoughtsWork咨询公司的推崇的n个敏捷开发实践:
Iteration
迭代开发。可以工作的软件胜过面面俱到的文档。因此,敏捷开发提倡将一个完整的软件版本划分为多个迭代,每个迭代实现不同的特性。重大的、优先级高的特性优先实现,风险高的特性优先实现。在项目的早期就将软件的原型开发出来,并基于这个原型在后续的迭代不断晚上。迭代开发的好处是:尽早编码,尽早暴露项目的技术风险。尽早使客户见到可运行的软件,并提出优化意见。可以分阶段提早向不同的客户交付可用的版本。
IterationPlanningMeeting
迭代计划会议。每个迭代启动时,召集整个开发团队,召开迭代计划会议,所有的团队成员畅所欲言,明确迭代的开发任务,解答疑惑。
Story Card/Story Wall/Feature List
在每个迭代中,架构师负责将所有的特性分解成多个Story Card。每个Story可以视为一个独立的特性。每个Story应该可以在最多1个星期内完成开发,交付提前测试(Pre-Test)。当一个迭代中的所有Story开发完毕以后,测试组再进行完整的测试。在整个测试过程中(pre-test,test),基于Daily build,测试组永远都是每天从配置库上取下最新编译的版本进行测试,开发人员也随时修改测试人员提交的问题单,并合入配置库。
敏捷开发的一个特点是开放式办公,充分沟通,包括测试人员也和开发人员一起办公。基于Story Card的开发方式,团队会在开放式办公区域放置一块白板,上面粘贴着所有的Story Card,按当前的开发状态贴在4个区域中,分别是:未开发,开发中,预测试中,测试中。Story Card的开发人员和测试人员根据开发进度在Story Wall上移动Story Card,更新Story Card的状态。这种方式可以对项目开发进度有一个非常直观的了解。
在开发人员开始开发一个Story时,ta需要找来对应的测试人员讲解Story功能,以便测试人员有一致的理解,同时开始自动化系统测试脚本的开发。
Standup Meeting
站立会议。每天早上,所有的团队成员围在Story Wall周围,开一个高效率的会议,通常不超过15分钟,汇报开发进展,提出问题,但不浪费所有人的时间立刻解决问题,而是会后个别沟通解决。
Pair Programming
结对编程是指两个开发人员结对编码。结对编程的好处是:经过两个人讨论后编写的代码比一个人独立完成会更加的完善,一些大的方向不至于出现偏差,一些细节也可以被充分考虑到。一个有经验的开发人员和一个新手结对编程,可以促进新手的成长,保证软件开发的质量。
CI/Daily Build
持续集成和每日构建能力是否足够强大是迭代开发是否成功的一个重要基础。基于每日构建。开发人员每天将编写/修改的代码及时的更新到配置库中,自动化编译程序每天至少一次自动从配置库上取下代码,执行自动化代码静态检查(如PCLint),单元测试,编译版本,安装,系统测试,动态检查(如Purify)。以上这些自动化任务执行完毕后,会输出报告,自动发送邮件给团队成员。如果其中存在着任何的问题,相关责任人应该及时的修改。
可以看到,整个开发组频繁的更新代码,出现一些问题不可避免。通过测试部又在不停地基于最新的代码进行测试。新增的问题是否能够被及时发现并消灭掉,取决于自动化单元测试和系统测试能力是否足够强大,特别是自动化系统测试能力。如果自动化测试只能验证最简单的操作,则新合入代码的隐患将很难被发现,并遗留到项目后期,形成大的风险。而实际上,提升自动化测试的覆盖率是最困难的。
Retrospect
总结和反思。每个迭代结束以后,项目组成员召开总结会议,总结好的实践和教训,并落实到后续的开发中。
ShowCase
演示。每个Story开发完成以后,开发人员叫上测试人员,演示软件功能,以便测试人员充分理解软件功能。
Refactoring
重构。因为迭代开发模式在项目早期就开发出可运行的软件原型,一开始开发出来的代码和架构不可能是最优的、面面俱到的,因此在后续的Story开发中,需要对代码和架构进行持续的重构。迭代开发对架构师要求很高。因为架构师要将一个完整的版本拆分成多个迭代,每个跌倒由拆分成很多Story,从架构的角度看,这些Story必须在是有很强的继承性,是可以不断叠加的,不至于后续开发的Story完全推翻了早期开发的代码和架构,同时也不可避免的需要对代码进行不断完善,不断重构。
TDD
测试驱动开发。正如上面讲的,迭代开发的特点是频繁合入代码,频繁发布版本。测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。


敏捷方法反思:
自己参与的敏捷开发项目总的来说不是很成功,这可能也是业界遇到的通病:
1、对于全新的软件,在项目早期测试人员就参与并实现自动化测试脚本,但实际上软件的界面等非常不稳定,导致测试人员返工的工作量很大。
2、对于全新的软件,资料人员过早参与,后期返工工作量大,原因同第一点。
3、自动化系统测试工作量大,测试人员投入大量的精力在使测试自动化起来,而没有足够的精力放在真正的测试软件的功能是否正常。即便是这样,自动化系统测试脚本也多流于形式,测不出深层次的问题。
4、代码动态检查工具执行不理想,流于形式。没有人对Purify有深刻的理解和应用经验,报告中查出来很多告警,但不知如何消除。
5、由于快速搭建原型,没有在架构上进行严谨的设计,导致后期一直堆砌代码。
6、异地开发模式下无法实现快速构建、快速交付,团队普遍感觉很疲惫。
7、敏捷开发不提倡加班,但实际上不管是CMM还是Agile哪一种开发模式跟是否加班都没有必然联系。

2018-05-24 11:20:45 runOnWay 阅读数 455
  • SCRUM敏捷开发视频教程

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

    10414 人正在学习 去看看 CSDN讲师
    一、敏捷开发是一种开发方式
    敏捷开发,英文是Agile Development,是一种以人为核心、迭代、循序渐进的开发方式,是一种软件开发的流程。它会指导开发人员用规定的环节去一步一步完成项目的开发。由于它采用迭代式开发,所以它主要的驱动核心是人,而不是像瀑布模型那样,以文档为核心。
    敏捷开发更注重的人与人之间的沟通、交流。它认为个体和交互胜过过程和工具,可以工作的软件胜过面面俱到的文档,客户合作胜过合同谈判,响应变化胜过遵循计划。虽然右项也有价值,但是敏捷开发认为左项具有更大的价值。
   迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样一个周期就是一次迭代的过程,同时每一次迭代都可以生产或开发出一个可以交付的软件产品。
   二、几个重要的名词
   Scrum:是一个橄榄球专业术语,意味并列争球。用了这样一个词在敏捷开发中,可以证明,在整个敏捷开发的过程中,团队中的每一个人都要像橄榄球运动员一样迅速、富有战斗激情,在这种氛围下才会达到敏捷开发快速迭代的要求。
   XP:极限编程,是一种轻量、高效、低风险、柔性、可预测、科学而且充满乐趣的开发方式。它强调在更短的周期内,更早地提供具体、持续的反馈信息;在迭代地进行计划编制,首先在最开始迅速生成一个总体计划,然后在整个项目开发过程中不断的发展它;依赖于自动测试程序来监控开发进度,并尽可能早地捕获缺陷;依赖于口头交流、测试和源程序进行沟通;倡导持续的演化式设计;依赖于开发团队内部的紧密协作;尽可能达到程序员短期利益和项目长期利益的平衡。

注:Scrum和XP是敏捷开发的两种方式,Scrum偏重过程,XP偏重实践。

    PO:Product Owner,产品负责人。主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。
    SM:Scrum Master,流程管理员。主要负责整个Scrum流程在项目中的顺利实施和进行,以及扫清挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。
    ST:Scrum Team,开发团队。主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5-10人左右,每个成员可能负责不同的技术方面,但要求每个成员必须要有很强的自我管理能力,同时具有一定的表达能力。成员可以采用任何工作方式,只要能够完成开发任务。
   PB:Product Backlog,产品需求列表。由PO负责,按优先顺序排列产品需求。
   Sprint:冲刺。指一次迭代,每次迭代的周期大约是一个月。
   INVEST原则:是缩写组成,Independent独立的、Negotiable可协商的、Valuable有价值的、 Estimable可估计的、Small小的、Testable可测试的
   三、Scrum开发
   1.首先由PO,制定PB。
   2.ST根据PB,进行工作量的预估和安排。在工作量预估中,可以使用计划筹码,每个筹码代表着完成一个故事的时间,是一个故事点的倍数,一般有1、2、3、5、8这几个数字。每个人对工作的预估在亮出筹码之后,如果有不同意见,不能折中选平均数,而是要各自说出理由,再重新进行预估。
   3.有了PB列表,就需要通过Sprint Planning Meeting来从中挑选出一个Story作为本次迭代完成的目标,然后将这个Story进行细化,一个优秀的Story要遵循INVEST原则,形成Sprint Backlog,然后再继续细化,争取每个细化的任务能在2天内完成。
   4.在ST完成PM上选出的Sprint Backlog过程中,要进行Daily Scrum Meeting,每次会议要控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报昨天完成的工作和承诺今天要完成的任务,如果遇到问题也可以提出问题,表述结束后,要更新自己的燃尽图。
    5.要做到每日集成,每天都要有一个可成功编译、并且可以演示的版本,这就凸显出了持续集成的重要性。
    6.当一个Story完成,也就是Sprint Backlog被完成,就代表一次Sprint完成,要进行Sprint Review Meeting,PO和客户都要参加,每个ST成员都要展示自己完成的任务。
    7.最后就是Sprint Retrospective Meeting,所有成员轮流发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中。

   敏捷开发的快速迭代有很明显的优势,但是对团队的要求也更高,尤其是按时完成任务,对自己的承诺负责这点,如果要保重能够按时完成任务,就要在预估工作量上更加严谨,而不是取折中这种方式,每个人要更加坚持自己的立场,只能够因为合理的逻辑做出计划。
2011-08-15 11:05:57 ahead_zhan 阅读数 38
  • SCRUM敏捷开发视频教程

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

    10414 人正在学习 去看看 CSDN讲师
[quote]简单的说,敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。[/quote]


最近一段时间以来,很多人开始谈论敏捷开发、研究敏捷开发,那么究竟什么才是敏捷开发呢?

  简单的说,敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。 敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则,并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践,揭示更好的软件开发方法。

  敏捷开发(agile development)概念从2004年初开始广为流行。Bailar非常支持这一理论,他采取了"敏捷方式"组建团队:Capital One的"敏捷团队"包括3名业务人员、两名操作人员和5~7名IT人员,其中包括1个业务信息指导(实际上是业务部门和IT部门之间的"翻译者");另外,还有一个由项目经理和至少80名开发人员组成的团队。这些开发人员都曾被Bailar送去参加过"敏捷开发"的培训,具备相关的技能。

  每个团队都有自己的敏捷指导(Bailar聘用了20个敏捷指导),他的工作是关注流程并提供建议和支持。最初提出的需求被归纳成一个目标、一堆记录详细需要的卡片及一些供参考的原型和模板。在整个项目阶段,团队人员密切合作,开发有规律地停顿--在9周开发过程中停顿3~4次,以评估过程及决定需求变更是否必要。在Capital One,大的IT项目会被拆分成多个子项目,安排给各"敏捷团队",这种方式在"敏捷开发"中叫"蜂巢式(swarming)",所有过程由一名项目经理控制。

  为了检验这个系统的效果,Bailar将项目拆分,从旧的"瀑布式"开发转变为"并列式"开发,形成了"敏捷开发"所倡导的精干而灵活的开发团队,并将开发阶段分成30天一个周期,进行"冲刺"--每个冲刺始于一个启动会议,到下个冲刺前结束。

  在Bailar将其与传统的开发方式做了对比后,他感到非常兴奋--"敏捷开发"使开发时间减少了30%~40%,有时甚至接近50%,提高了交付产品的质量。"不过,有些需求不能用敏捷开发来处理。" Bailar承认,"敏捷开发"也有局限性,比如对那些不明确、优先权不清楚的需求或处于"较快、较便宜、较优"的三角架构中却不能排列出三者优先级的需求。此外,他觉得大型项目或有特殊规则的需求的项目,更适宜采用传统的开发方式。尽管描述需求一直是件困难的事,但经过阵痛之后,需求处理流程会让CIO受益匪浅。

  敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则,并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践,揭示更好的软件开发方法。通过这项工作,他们认为:

  个体和交互 胜过 过程和工具
  可以工作的软件 胜过 面面俱到的文档
  客户合作 胜过 合同谈判
  响应变化 胜过 遵循计划

 [color=red] 并提出了以下遵循的原则:[/color]

  我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
  即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
  经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
  在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
  围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。
  在团队内部,最具有效果并富有效率的传递信息的方法,就是面对面的交谈。
  工作的软件是首要的进度度量标准。
  敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
  不断地关注优秀的技能和好的设计会增强敏捷能力。
  简单是最根本的。
  最好的构架、需求和设计出于自组织团队。
  每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。

  关于敏捷开发的方法研究

  (一)注: 本文是阅读Alistair Cockburn的Agile Software Development和William C. Wake的XP Explored的一些笔记和想法,Agile Software Development是一组软件开发方法的总称,包括(Crystal , Extreme Programming , Adaptive software development等等)。敏捷开发方法又称为“轻量级”开发方法。

  下面这段话摘自Martin Fowler的一篇文章:

  从无到繁重再到敏捷

  多数软件开发仍然是一个显得混乱的活动,即典型的“边写边改” (code and fix)。设计过程充斥着短期的,即时的决定,而无完整的规划。这种模式对小系统开发其实很管用,但是当系统变得越大越复杂时,要想加入新的功能就越来越困难。同时错误故障越来越多,越来越难于排除。一个典型的标志就是当系统功能完成后有一个很长的测试阶段,有时甚至有遥遥无期之感,从而对项目的完成产生严重的影响。

我们使用这种开发模式已有很长时间了,不过我们实际上也有另外一种选择,那就是“正规方法”(methodology)。这些方法对开发过程有着严格而详尽的规定,以期使软件开发更有可预设性并提高效率,这种思路是借鉴了其他工程领域的实践。

  这些正规方法已存在了很长时间了,但是并没有取得令人瞩目的成功,甚至就没怎么引起人们的注意。对这些方法最常听见的批评就是它们的官僚繁琐,要是按照它的要求来,那有做太多的事情需要做,而延缓整个开发进程。所以它们通常被认为是“繁琐滞重型”方法,或Jim HighSmith 所称的“巨型”(monumental)方法。

  作为对这些方法的反叛,在过去几年中出现了一类新方法。尽管它们还没有正式的名称,但是一般被称为“敏捷型”方法。对许多人来说,这类方法的吸引之处在于对繁文缛节的官僚过程的反叛。它们在无过程和过于繁琐的过程中达到了一种平衡,使得能以不多的步骤过程获取较满意的结果。

  敏捷型与滞重型方法有一些显著的区别。其中一个显而易见的不同反映在文档上。敏捷型不是很面向文档,对于一项任务,它们通常只要求尽可能少的文档。从许多方面来看,它们更象是“面向源码”(code-oriented)。事实上,它们认为最根本的文档应该是源码。

  但是,我并不以为文档方面的特点是敏捷型方法的根本之点。文档减少仅仅是个表象,它其实反映的是更深层的特点:

  ? 敏捷型方法是“适配性”而非“预设性”。 重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划,然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实,它们的目的就是成为适应变化的过程,甚至能允许改变自身来适应变化。

  ? 敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。 它们试图使软件开发工作顺应人的天性而非逆之。它们强调软件开发应当是一项愉快的活动。

  我认为以上两个特点很好的概括了敏捷开发方法的核心思想:适应变化和以人为中心

 [color=red] (二) 方法背后的思想
[/color]
  Alistair Cockburn在Agile Software Development中讲述了敏捷开发方法背后的思想

  人们掌握过程(process)可以分为3个阶段:

  1 following 遵循一个定义好的process

  2 detaching 知道不同process的适用范围,在不同的场合使用不同的process

  3 fluent 不关心是否遵循特定的process,知道在什么情况下采用什么动作

  软件开发是一个充满发明和交流的协作性游戏(cooperative game of invertion and communication)。软件开发的首要目标是生产出软件,遵循特定的过程和模型只是手段,只要传递了足够的信息,手段是次要的。交流的效果要远远重于交流的形式(Effect of communication is more important than the form of communication)。

  一般软件开发有两个目标:1 尽快的生产出软件 2 为下一个team或项目做准备,有时这两个目标是矛盾的,我们要在这两个目标之间寻求平衡

  在软件开发中,人的因素要远远大于过程和技术。人是有缺陷的:

  1 容易犯错误,因此必须在错误扩散之前找到并改正错误

  2 当觉得可能失去较多的时候,不愿意冒险

  3 重新构造而不愿意重复使用已有的东西

  4 难于坚持一个习惯

  针对个人因素的几个建议:

  1 具体的模型较抽象的模型更容易理解

  2 从一个例子开始是容易的

  3 通过观察他人的成果学习

  4 要有足够的不受打扰的时间

  5 分配的工作要与个人意向,能力匹配

  6 不正确的奖励会有坏作用,从长期看个人兴趣比奖励更重要,培养在工作中的自豪感:

  1) pride in work参与工作的自豪感,通常参与一个重要的工作会有自豪感

  2) pride in accomplishment 完成工作的自豪感,长期未完的工作会使士气低落

  3)pride in contribution 为他人贡献的自豪感

  7 鼓励关心其他人的工作和整体的工作

  在一个团队之间,交流是最重要的,实践证明面对面的实时的交流是最有效的,对交流的延误会损失信息,白板是最好的交流工具,交流工具的先进并不能提高交流效果。文档的作用是记录和备忘,不能通过文档交流。


[color=red]
敏捷开发方法要避免的过程设计的几个常见错误
[/color]
  1 对所有的项目使用同一种过程

  2 没有弹性

  3 过于沉重

  4 增加不必要的“必须完成”(“should do” is really should?)

  5 没有经过实践检验
[color=red]
  敏捷开发方法过程设计的几个原理:[/color]

  1 交互的面对面的交流是代价最小,最迅速的交换信息的方法

  2 超过实际需要的过程是浪费的

  3 大的团队需要重量级方法

  4 处理重大问题的项目需要重量级方法强调

  5 增加反馈和交流可以减少中间产品和文档的需求

  6 轻量级方法更强调理解(understanding),自律(discipline)和技能(skill),重量级方法更强调文档(documentation),过程(process)和正式(formality)

  understanding指整个团队关于项目的全部知识,包括讨论的过程,documentation只能记录其中的一部分
  discipline是指个人主动的完成工作,process指个人根据指令完成工作
  skill指具有良好技能的人可以省略中间的产品,formality指必须按照规定步骤完成工作

  7 确定开发中间的瓶径,提高它的效率

  对于瓶径处的工作应该尽量加快,减少重复,(使用更熟练的人,使用更多的人,使用更好的工具,使瓶径处的工作的深入尽量稳定)对于非瓶径处的工作可以多一些重复,在输入还不确定的情况下也可以尽早开始。
[color=red]
  这些原理的几个结论:[/color]

  1 向一个项目增加人员要花费较大代价(constly),因为原有人员和新人员之间的交流要花费大量时间

  2 团队的规模经常是跳跃的,例子:需要6个熟练的程序员,但是只有4个,于是增加不熟练的程序员,结果团队的大量时间花费在培训不熟练的程序员上面,最后增加到了20个不熟练的程序员。

  3 应该侧重于提高团队的技能而不是扩充团队

  4 对不同的项目使用不同的过程

  5 在适用的条件下,轻量级的方法优于重量级的方法

  6 对不同的项目要裁减过程

  总而言之,敏捷开发方法的原则是“刚刚好”(Light and Sufficient)

敏捷开发是个啥

阅读数 834

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