2010-07-13 12:13:00 lanyd 阅读数 1165
  • SCRUM敏捷开发视频教程

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

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

敏捷开发(XP)的宗旨:“崇尚个人和交流而不是过程和工具;崇尚软件开发而不是文档;崇尚客户合作而不是合同条款;崇尚随需应变而不是简单计划”。如果我们把敏捷开发定式化成某种过程或者工具集合,实际就呆板了。
敏捷开发(XP)的表现:结对编程,代码共有,持续集成,代码复审,测试驱动开发,不断重构,保持简单。

先建立一个迭代开发和测试的流程,每个迭代周期在1-2周左右。以这种简单却又必要的敏捷过程来了解和熟悉敏捷过程。由于是试点新的方法,各种项目干系人对此报有希望,同时也会有怀疑。所以在试点过程中一定要做到项目的透明,包括进度、问题、解决的方案、下一次迭代的改进、本次迭代实现的目标。及时有效的沟通会减少很多干扰,增加很多支持。 清晨的例会、成果展示、迭代开发都是容易理解、容易做到的,那就坚持下来吧。一定要做好版本控制。

完全走敏捷开发,人力成本很高,对管理要求也很高,中国人想法很多,很难做到结对编程的好处,还需要一个摸索和实践的过程。敏捷开发,其实国内早就在推行,只不过推行的方式一直拿不上台面而已。至于推行的效率高低,于这个敏捷的团队成员的个人素质要求较高,3--5年经验的,只属于刚刚一只脚踏入软件开发的门槛,对设计架构似懂非懂,这种情况下,推进慢是必然的。首先我们要知道,敏捷模式不是全能的,也不是什么人都能的,一定先要有针对的人,然后再做针对的事。


没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档,来对系统及其设计决策的依据进行描述。
然而,过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间,并且要使这些文档和代码保持同步,就要花费更多的时间。如果文档和代码之间失去同步,那么文档就会变成庞大的、复杂的谎言,会造成重大的误导。
对于团队来说,编写并维护一份系统原理和结构方面的文档将总是一个好主意,但是那份文档应该是短小的(short)并且主题突出的(salient)。“短小的”意思是说,最多有一二十页。“主题突出的”意思是说,应该仅论述系统的高层结构和概括的设计原理。
至于如何来培训新的团队成员,使他们能够从事与系统相关的工作呢?我们会非常密切地和他们在一起工作。我们紧挨着他们坐下来帮助他们,把我们的知识传授给他们。我们通过近距离的培训和交互使他们成为团队的一部分。在给新的团队成员传授知识方面,最好的两份文档是代码和团队。代码真实地表达了它所做的事情。虽然从代码中提取系统的原理和结构信息可能是困难的,但是代码是惟一没有二义性的信息源。在团队成员的头脑中,保存着时常变化的系统的脉络图(road map)。人和人之间的交互是把这份脉络图传授给他人的最快、最有效的方式。
许多团队因为注重文档而非软件,导致进度拖延。这常常是一个致命的缺陷。有一个叫做“Martin文档第一定律(Martin’s first law of document)”的简单规则可以预防该缺陷的发生: 直到迫切需要并且意义重大时,才来编制文档。

 

2010-11-14 14:53:35 wo406850897 阅读数 18
  • SCRUM敏捷开发视频教程

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

    10419 人正在学习 去看看 CSDN讲师
常见的敏捷开发流程比较
速度是企业竞争致胜的关键因素,软件项目的最大挑战在于一方面要应付变动中的需求,一方面要在紧缩的时程内完成项目,所以软件团队除了在技术上必须日益精进,更需要运用有效的开发流程,以确保团队能够发挥综效。这正是Agile Process ( 敏捷的软件开发流程) 于近年来兴起的主要原因,本文将介绍数种广为接受的软件开发流程,及其在运用上的建议。

1 Agile Process -敏捷的开发流程
几乎所有的软件项目都会在起始阶段面临选择开发流程的困难,一种是完备的开发流程,另一种是简易轻便的流程。 虽然我们了解采用完备的开发流程可以提高软件的质量,但是因为欠缺人力、工具与时间,我们常会被迫采用简化的流程,但事与愿违,大部分的情况我们仍然难以在预算内及时完成项目。 Agile Process ( 敏捷的开发流程) 是一种软件开发流程的泛称,Agile Process 具有下列几项共通的特性: 1. 客户与开发人员形成密切合作的团队,因为客户无法于初期定义完整的规格,而开发人员于开发过程中也常常无法知悉外在环境或业务的变动,所以需要两者密切合作方能开发适用的软件。 2. 项目最终的目标是可执行的程序,因此所有的中间产品必须经过审慎评估,确认有助于最终目标,才需要制作中间产品。 3. 采用Iterative 与Incremental 方式分阶段进行,密集review 是否符合需求。 4. 流程可以简单,但规划与执行必须严谨。 5. 强调团队合作,赋予高度的责任,团队有自主权得以因应变化做调整。

2 RUP开发流程- Rational Unify Process
RUP 为IBM Rational 公司经过多年的研发与经验所提出的软件开发流程,其内容含盖Business modeling, Requirement Modeling, Logical Design, Implementation, Testing, Deployment 等软件开发生命周期的直接工作,与Project Management, Change & Configuration Management ,Environment support 等支持性工作。 RUP 的内容非常丰富,不同的项目需要不同调整,IBM Rational 提供RUP workbench 工具,方便调整RUP ,并公布于Web ,方便项目成员遵循统一的流程规范进行工作。 RUP 的主要精神为:1. 项目进行采用Iterative 程序分阶段渐进地完成项目功能;2. 广泛使用Visual Modeling 于商业需求分析、系统分析与系统设计;3. 强调架构设计;4. 对每项工作所需要的技术、工具、做法、模板、检查项目均有详细的定义,架构 完备且具有可调整的弹性。 因为RUP 的流程规范与相关技术较复杂,所以导入时必须注意几个因素:1. 主管的支持以确保足够的资源投入;2. 分 阶段导入;3. 适当的训练与密切的顾问咨询;4 . 使用Modeling 技术时需要考虑Coding 的实作环境;5. 良好团队的管理,以沟通、耐心与坚持解决变革的人性阻力。

3 XP开发流程- eXtreme Programming
XP 亦称为终极流程,是最轻量级的开发流程,其最主要的精神是『在客 户有系统需求时,给予及时满意的可执行程序』,所以最适合需求快速变动的项目。XP 经过6 年的实作与修改,已演化为精致的开发流程,但仍不失其精简的特性,它强调客户所要的是workable 的执行码,所以把与撰写程序无关的工作降 至最低,并要求客户与开发人员最好以side-by-side 的方式一起工作。 XP 开发流程的基本步骤为:1. 开发人员随时可以和客户进行 有效沟通,撰写user stories 以确认需求。 2. 简易快速的系统设计,撰写独立的验证程序以解决特殊困难的问题,找出算法即可丢弃验证程序。 3. 规划多次小型阶段的项目计划,以最快速度完成每一阶段的程序交付客户,客户负责Acceptance tests ;4. Coding 前必须完成Unit Test 与Acceptance tests 程序,所有模块整合前都须经过Unit Tests ;5. 开发人员必须快速响应Bug 与需求变更;6. 要求二人一组使用一台计算机设计程序,当一人coding 时,另一人负责思考与设计;7. 程序 必须符合程序规范,并常做程序的重整(Refactoring) 。 XP 属于较精简的流程,于导入应注意几件事情:1. 最好有顾问给予协助;2. 持续的Review ;3. 可适当调整流程,但不可失去其基本精神。

4 SCRUM开发流程
SCRUM 开发流程是Agile Process 的一种,以英式橄榄球争球队形(Scrum) 为名,基本假设是『开发软件就像开发新产品,无法一开始就能定义Final Product 的规程,过程中需要研发、创意、尝试错误,所以没有一种固定的流程可以保证项目成功』。 Scrum 将软件开发团队比拟成橄榄球队,有明确的最高目标,熟悉开发流程中所需具备的最佳典范与技术,具有高度自主权,紧密地沟通合作,以高度弹性解决各种挑战,碓保每天、每个阶段都朝向目标有明确的推进,因此SCRUM 非常适用于产品开发项目。 SCRUM 开发流程通常以30 天为一个阶段,由客户提供新产品的需求规格开始,开发团队与客户于每一个阶段开始时挑选该完成的规格部份,开发团队必须尽力于30 天后交付成果,团队每天用15 分钟开会检视每个成员的进度与计划,了解所遭遇的困难并设法排除。 SCRUM 与传统开发流程及项目管理差异较大,于导入时最好有顾问协助。

5 总结
Agile Process 的精神已经成为共识,但是没有一种固定的流程可以重复使用在不同的项目上。 而且不管是RUP 、XP 、SCRUM 、或其它的开发流程都允许相当大的弹性,我们必须按项目性质的不同,调整或混合出适合的开发流程,并允许团队于进行中做必要的弹性修改,方能达成目标。
2017-12-03 20:21:19 wk843620202 阅读数 2022
  • SCRUM敏捷开发视频教程

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

    10419 人正在学习 去看看 CSDN讲师
敏捷开发实践总结

前言
敏捷开发它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和XP的区别是,Scrum偏重于过程,XP则偏重于实践,但是实际中,两者是结合一起应用的,这里我主要讲Scrum。

什么叫敏捷开发?
敏捷开发(Agile Development)是一种以人为核心迭代循序渐进的软件开发方法。敏捷开发作为CMM神话崩溃后被引入的一套新的软件开发模式。

对概念的理解:
以人为核心:敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。而瀑布开发模型,它是以文档为驱动的,整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据。
迭代:迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

敏捷开发的4句宣言
1,个体与交互 胜过 过程与工具
2,可以工作的软件 胜过 面面俱到的文挡
3,客户协作 胜过 合同谈判
4,响应变化 胜过 遵循计划

我对这4句宣言的理解:
产品结果大于形式,先把产品做出来,然后再整理出完善的文档
在互联网软件产品开发过程中,需求是不断发生变化的,需要对原有的计划及时更改,应对变化。

为什么要使用敏捷开发模式?
敏捷开发注重人与人之间的交流和合作,可以快速实现功能,以小步快跑的形式,不断试错,不断调整方向,不断完善产品。总结起来就是:适应变化,不断迭代。

scrum流程图:


scrum 开发中的三种角色:
1,product owner:产品负责人,确定大家要做什么(一般产品经理)。
2,scrum master:scrum的推动者,掌握大节奏的人。
3,team:一般由多个developer组成,开发的主力。

scrum 开发中的三大神器
1,production backlog(产品待办事项列表)
2,print backblog(详细任务列表)
3,sprint burn down(计划走向和实际走向组成燃尽图)

scrum 开发中的四个会议:
1,sprint计划会(理解需要做什么,然后讨论怎么做)
2,每日站会(昨天做了什么,今天打算做什么)
3,sprint 评审会(大家评审sprint产出,然后对待办事项做相应调整)
4, sprint回顾会(讨论哪里完成好,哪里需要改进)

SCRUM敏捷开发流程是什么?

1、Product Backlog(产品需求列表)我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由Product Owner 负责的;
2、Scrum Team根据Product Backlog列表,做工作量的预估和安排;
3、Sprint Planning Meeting(Sprint计划会议)有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;
4、Sprint Backlog(迭代任务列表) Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);
5、Daily Scrum Meeting(每日站立会议)在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图);
6、Daily Build(每日集成) 做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员;
7、Srpint Review Meeting(评审演示会议) 当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);
8、Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;
9,重构 因为迭代开发模式在项目早期就开发出可运行的软件原型,一开始开发出来的代码和架构不可能是最优的、面面俱到的,因此在后续的Story开发中,需要对代码和架构进行持续的重构。
10,TDD(测试驱动开发)。测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。

下面是crum开发流程中的一些场景图:
上图是一个 Product Backlog 的示例,产品需求列表

上图就是每日的站立会议了,参会人员可以随意姿势站立,任务看板要保证让每个人看到,当每个人发言完后,要走到任务版前更新自己的燃尽图。

上图就是任务看板了,任务看版包含 未完成、正在做、已完成 的工作状态,假设你今天把一个未完成的工作已经完成,那么你要把小卡片从未完成区域贴到已完成区域。每个人的工作进度和完成情况都是公开的,如果有一个人的工作任务在某一个位置放了好几天,大家都能发现他的工作进度出现了什么问题(成员人数最好是5~7个,这样每人可以使用一种专用颜色的标签纸,一眼就可以从任务版看出谁的工作进度快,谁的工作进度慢)。

作为客户端开发人员在实际的迭代开发过程中,有以下感想和总结:
1,每日的站会迫使人去对昨天的工作做一个小总结和今天的工作计划,无形中让让人做事更加的积极
2,及时是敏捷开发,也要尽可能的有详细的需求
3,在实际的开发过程中也需要写api文档,并且尽可能写上注释,以便于其他人的理解
4,严格按照开发流程去走,但不要流于形式,否则就是浪费时间
5,坚决杜绝以下问题的出现:
需求拍脑袋随意改动,叫快速试错迅速响应用户需求;
代码质量低劣不停出更新版本,叫快速迭代中;
不写正规设计文档,叫降低沟通成本和最好的文档是代码;
领导站身后指挥码农写代码,叫结对编程;
产品质量不靠设计靠测试的,叫测试驱动研发;


参考:


2017-09-19 21:18:49 williamyi96 阅读数 549
  • SCRUM敏捷开发视频教程

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

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

一段时间以来,由于学习的需要,涉及到了很多软件系统分析与设计以及软件体系结构相关的问题。而软件系统开发流程中,不得不提到的,便是敏捷开发。

接下来,将由浅入深地来分析分析敏捷开发的基本概念,然后说明一下敏捷开发的代表–XP(极限编程)与Srcum过程。

敏捷开发概念与价值观

敏捷开发运动历史相对于整个软件开发而言算是较为悠久的,其真正开始的标志是01年2月提出的”敏捷宣言(Agile Manifesto)”,这项宣言由17位当时称之为“轻量级方法学家”所编写签署的,他们的核心价值观是:

这里写图片描述

以上来自于敏捷宣言的官方网站,敏捷宣言作为指导敏捷开发的核心思想,下面简单地解释一下其内容的基本含义。

  • 个体和互动高于流程和工具。往往勤于沟通合作,目标明确的个人优秀的团队比那些使用最高级工具的团队做得更好,因为软件产品是人完成的,中间有太多的不确定性,因此互动与个人能力对变化的适应性就显得尤为重要;

  • 工作的软件高于详尽的文档。能够让软件能够顺利给用户交付使用是最终的目的,并不在乎将项目开发的过程文档写得多么漂亮,由于敏捷开发注重效率,而如此耗时的工作在后期并没有很好的效益。

  • 客户合作高于合作谈判。让客户参与到软件开发的过程中,能够更好地了解客户的需求。

  • 响应变化高于遵循计划。软件开发的过程中,往往会有诸如需求,设计等的改变,对于传统的瀑布模型将软件开发定义地过于死板,不具有对变化的适应性,开发出来的产品很可能并不是满足需求的“高质量”产品。

敏捷开发特征总结

关于敏捷开发的特征问题,网上已经有相当多的介绍资源,以下仅仅按照个人的体会针对一些与传统开发方式差异较大的部分进行总结。

  • 以瀑布模型为代表的开发方式有着严格的过程化,没有较强的响应变化的能力,不利于了解用户变化的真正需求。而敏捷开发实际上是测试驱动的。了解了用户的需求之后设计测试用例,编写测试代码,如果产品能够通过所有测试,那么其就是一个可以release的版本。

  • 敏捷开发的主要文档是测试文档。传统的开发过程中特别看中需求分析,设计与实现等部分的文档,而敏捷开发则更为注重测试文档。其本质原因是因为敏捷开发的过程中,伴随着极其快的软件版本迭代,如果注重实现等的文档,很容易产生代码修改不一致的问题。而如果以测试文档为主要文档,则便于项目的管理。同时也可以减轻团队成员调整带来的学习成本。

  • 敏捷开发以合作为中心,也就是实现代码共享。敏捷开发过程的代码不是为一人所有,任何人都有权利看到所有代码并原则上允许修改所有代码,并不需要征得原作者同意。这在很大程度上就降低了人员调动所带来的风险。

  • 敏捷开发要求开发人员的水平基本相当,一般而言,较高。由于敏捷开发的代码共享性以及代码的高需求适应性,其对开发人员的整体水平要求较高,同时开发人员之间的水平基本相当。

敏捷开发典型代表

当下用得比较多的,有两类敏捷开发的方法。一类是XP(极限编程),另外一类是Scrum。由于两者都是基于敏捷开发价值观的具体实现,因此下面简单地谈谈两者之间的差异。

区别之一: 迭代长度的不同

XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周.

区别之二: 在迭代中, 是否允许修改需求

XP在一个迭代中,如果一个User Story(用户素材, 也就是一个需求)还没有实现, 则可以考虑用另外的需求将其替换, 替换的原则是需求实现的时间量是相等的。 而Scrum是不允许这样做的,一旦迭代开工会完毕, 任何需求都不允许添加进来,并有Scrum Master严格把关,不允许开发团队收到干扰。

区别之三: 在迭代中,User Story是否严格按照优先级别来实现

XP是务必要遵守优先级别的。 但Scrum在这点做得很灵活, 可以不按照优先级别来做,Scrum这样处理的理由是: 如果优先问题的解决者,由于其它事情耽搁,不能认领任务,那么整个进度就耽误了。 另外一个原因是,如果按优先级排序的User Story #6和#10,虽然#6优先级高,但是如果#6的实现要依赖于#10,则不得不优先做#10.

区别之四:软件的实施过程中,是否采用严格的工程方法,保证进度或者质量

Scrum没有对软件的整个实施过程开出养个工程实践的处方。要求开发者自觉保证,但XP对整个流程方法定义非常严格,规定需要采用TDD, 自动测试, 结对编程,简单设计,重构等约束团队的行为。因此,原作者认为, 这点上,XP的做法值得认同的,但是却把敏捷带入了一个让人困惑的矛盾, 因为xp的理念,结合敏捷模式,表达给团队的信息是“你是一个完全自我管理的组织, 但你必须要实现TDD, 结对编程, …等等”

不难发现,这四个区别显见的是: Scrum非常突出Self-Orgnization, XP注重强有力的工程实践约束。

一般建议, 在管理模式上启用Scrum, 而在实践中,创造一个适合自己项目组的XP(“start with Scrum and then invent your own version of XP.”)

总结

通过对敏捷开发相关理念以及突出特点的了解,个人觉得其思想是一种很不错的范式。后续承担的某项目本人将尝试使用敏捷开发。

参考文献

  1. 敏捷软件开发宣言
  2. 敏捷开发 From MBALib
  3. Differences Between Scrum and Extreme Programming
  4. 敏捷方法之极限编程(XP)和 Scrum区别
2009-02-15 11:46:46 philips170s7 阅读数 13
  • SCRUM敏捷开发视频教程

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

    10419 人正在学习 去看看 CSDN讲师
速度是企业竞争致胜的关键因素,软件项目的最大挑战在于一方面要应付变动中的需求,一方面要在紧缩的时程内完成项目,所以软件团队除了在技术上必须日益精进,更需要运用有效的开发流程,以确保团队能够发挥综效。这正是 Agile Process (敏捷的软件开发流程) 于近年来兴起的主要原因,本文将介绍数种广为接受的软件开发流程,及其在运用上的建议。

Agile Process - 敏捷的开发流程

几乎所有的软件项目都会在起始阶段面临选择开发流程的困难,一种是完备的开发流程,另一种是简易轻便的流程。虽然我们了解采用完备的开发流程可以提高软件的质量,但是因为欠缺人力、工具与时间,我们常会被迫采用简化的流程,但事与愿违,大部分的情况我们仍然难以在预算内及时完成项目。

Agile Process (敏捷的开发流程) 是一种软件开发流程的泛称,Agile Process 具有下列几项共通的特性:

客户与开发人员形成密切合作的团队,因为客户无法于初期定义完整的规格,而开发人员于开发过程中也常常无法知悉外在环境或业务的变动,所以需要两者密切合作方能开发适用的软件。
项目最终的目标是可执行的程序,因此所有的中间产品必须经过审慎评估,确认有助于最终目标,才需要制作中间产品。
采用 Iterative 与 Incremental 方式分阶段进行,密集 review 是否符合需求。
流程可以简单,但规划与执行必须严谨。
强调团队合作,赋予高度的责任,团队有自主权得以因应变化做调整。
RUP 开发流程 - Rational Unify Process

RUP 为 IBM Rational 公司经过多年的研发与经验所提出的软件开发流程,其内容含盖 Business modeling, Requirement Modeling, Logical Design, Implementation, Testing, Deployment 等软件开发生命周期的直接工作,与 Project Management, Change & Configuration Management,Environment support 等支持性工作。RUP 的内容非常丰富,不同的项目需要不同调整,IBM Rational 提供 RUP workbench 工具,方便调整 RUP,并公布于 Web,方便项目成员遵循统一的流程规范进行工作。

RUP 的主要精神为:

1. 项目进行采用 Iterative 程序分阶段渐进地完成项目功能;

2. 广泛使用 Visual Modeling 于商业需求分析、系统分析与系统设计;

3. 强调架构设计;

4. 对每项工作所需要的技术、工具、做法、模板、检查项目均有详细的定义,架构完备且具有可调整的弹性。

因为 RUP 的流程规范与相关技术较复杂,所以导入时必须注意几个因素:

1. 主管的支持以确保足够的资源投入;

2. 分阶段导入;3. 适当的训练与密切的顾问咨询;

4. 使用 Modeling 技术时需要考虑 Coding 的实作环境;

5. 良好团队的管理,以沟通、耐心与坚持解决变革的人性阻力。

XP 开发流程 - eXtreme Programming

XP 亦称为终极流程,是最轻量级的开发流程,其最主要的精神是『在客户有系统需求时,给予及时满意的可执行程序』,所以最适合需求快速变动的项目。XP 经过 6 年的实作与修改,已演化为精致的开发流程,但仍不失其精简的特性,它强调客户所要的是 workable 的执行码,所以把与撰写程序无关的工作降至最低,并要求客户与开发人员最好以 side-by-side 的方式一起工作。

XP 开发流程的基本步骤为:

1. 开发人员随时可以和客户进行有效沟通,撰写 user stories 以确认需求。

2. 简易快速的系统设计,撰写独立的验证程序以解决特殊困难的问题,找出算法即可丢弃验证程序。

3. 规划多次小型阶段的项目计划,以最快速度完成每一阶段的程序交付客户,客户负责 Acceptance tests;

4. Coding 前必须完成 Unit Test 与 Acceptance tests 程序,所有模块整合前都须经过 Unit Tests;

5. 开发人员必须快速响应 Bug 与需求变更;

6. 要求二人一组使用一台计算机设计程序,当一人 coding 时,另一人负责思考与设计;

7. 程序必须符合程序规范,并常做程序的重整 (Refactoring)。

XP 属于较精简的流程,于导入应注意几件事情:

1. 最好有顾问给予协助;

2. 持续的 Review;

3. 可适当调整流程,但不可失去其基本精神。

SCRUM 开发流程

SCRUM 开发流程是 Agile Process 的一种,以英式橄榄球争球队形 (Scrum) 为名,基本假设是『开发软件就像开发新产品,无法一开始就能定义 Final Product 的规程,过程中需要研发、创意、尝试错误,所以没有一种固定的流程可以保证项目成功』。Scrum 将软件开发团队比拟成橄榄球队,有明确的最高目标,熟悉开发流程中所需具备的最佳典范与技术,具有高度自主权,紧密地沟通合作,以高度弹性解决各种挑战,碓保每天、每个阶段都朝向目标有明确的推进,因此 SCRUM 非常适用于产品开发项目。

SCRUM 开发流程通常以 30 天为一个迭代周期,每个迭代周期叫做一个Sprint,由客户提供新产品的需求规格开始,开发团队与客户于每一个阶段开始时挑选该完成的规格部份,开发团队必须尽力于 30 天后交付成果,团队每天用 15 分钟开会检视每个成员的进度与计划,了解所遭遇的困难并设法排除,决定第二天的任务安排,这样的短会就叫做scrum。

  SCRUM较为有特色的,是它特别强调开发队伍和管理层的交流协作。每天,开发队伍都会向管理层汇报进度,如果有问题,也会向管理层要求帮助解决。

SCRUM 与传统开发流程及项目管理差异较大,于导入时最好有顾问协助。

总结

Agile Process 的精神已经成为共识,但是没有一种固定的流程可以重复使用在不同的项目上。而且不管是 RUP、XP、SCRUM、或其它的开发流程都允许相当大的弹性,我们必须按项目性质的不同,调整或混合出适合的开发流程,并允许团队于进行中做必要的弹性修改,方能达成目标。

【作者】林耀珍为 Microsoft.NET 技术代言人,目前任职第三波信息技术总监,历任第三波信息教育训练处处长及育碁数字科技总经理。专长于信息系统规划及软件开发技术,拥有 Microsoft MCSD / MCSE / MCDBA,Rational OOAD,Lotus Notes / Domino 等认证资格,并为 Microsoft.NET / Java J2EE / 对象导向系统分析设计的资深讲师及多家公民营机构的 e 化顾问。

————————————————————————————————

评论:开发团队使用什么样的开发流程、方法没有固定的模式,只有思想理论的指导。就像一个虚拟的类,建立了一个没有具体实现的方法,只是指明了前进的道路。当我们要应用这种思想时,只有把这个虚拟类实例化,重写这个方法,具体怎么实现是要根据这个实体类的运行环境、功能来决定,这也就是所谓的弹性。一定要选择适合自己团队的,适合系统特性的,适合项目目标的开发方法,才可以降低项目的风险,顺利完成项目的交付。

敏捷开发之Scrum

阅读数 25

敏捷开发

阅读数 11

敏捷测试流程

阅读数 1761

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