敏捷开发流程几个名词

2019-04-12 22:52:55 y_279611480 阅读数 1169

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:此文内容,部分摘抄至互联网,如若,原文博主介意,可私聊。谢谢。
自然,此文并不完善,欢迎各位点评。

2011-03-08 23:04:00 chclvzxx 阅读数 633

 随着Agile敏捷开发的流行,越来越多的公司采用敏捷开发用于软件产品和应用的开发。笔者的产品开发团队在两年前开始采用敏捷开发方法,一直实践到现在,并取得不错的成果,包括:产品功能更加符合市场和业务人员的需求,开发效率获得提高。本文从实践的角度介绍笔者所在团队的产品敏捷开发过程和作者的敏捷开发体会。

敏捷开发体会

    实施敏捷开发近两年来,我对在产品开发中应用敏捷方法有着深刻的体会。首先说下产品背景。我参与的产品是面向行业的产品,在全世界都有客户,有10年历史,和一百多个基于不同版本的客户,我们的团队完全负责产品的未来发展方向、发布计划、架构、设计、开发进度、测试、客户支持等。在这样一个面向全球的产品和自主的团队环境中进行敏捷开发体会尤其深刻。

    1) 注重概念和架构设计,而轻详细设计

    敏捷开发中,注重概念和架构设计,而轻详细设计。这里的概念设计,可以看成是为什么要做这个产品或模块,强调的是产品的路线规划、市场趋势、客户价值、技术趋势等。架构设计,可以看成从整体上看,概念设计应该用什么方式实现、分几个层次、多少组件、不同层次和组件之间关系是什么。详细设计,则是具体的设计和做法、API接口等。

    一个产品,特别是面向行业的产品,概念设计和架构设计非常重要,需要考虑行业未来的发展方向,产品在市场中横向和纵向的比较,技术的发展方向,和每个模块的投入和收益的比例等,这样才能尽可能保证产品沿着正确的方向前进。在产品中新增或删除一个模块需要非常谨慎,因为一旦新增模块被客户使用,以后就很难在产品中去掉这个模块。还需要考虑产品各个版本之间的兼容性,以及客户的升级迁移。所以,在开始正式开发之前,通过概念设计和架构设计,梳理思路是非常必要的。

    2) SWOT分析

    以前在做项目时,大多是从技术角度来考虑哪一些功能模块需要做,哪一些功能模块先做,而没有一个系统化的分析方法。造成的结果是有一些功能模块投入很多资源,却并不一定是客户最想要的。

    在敏捷开发中,更加注重客户需求。如果对产品进行SWOT分析,就能选出付出最小工作量,但能获得最大价值的模块。

    SWOT分析阶段会在概念设计和架构设计之后进行,输入是概念设计和架构设计,输出是模块的重要度和需要的时间。这样按照性价比可以进行排序,选出最能符合市场的模块。

    一款产品哪个模块重要,哪个先做,需要花多少资源和时间投入,花这么多时间和资源的模块是否在客户心中有相应的重要程度等,这些都是由这款产品的市场策略来决定。所有产品都是为了市场和赢利为目的,Agile方法更好地帮助企业实现了这一点。

    3) 业务和客户驱动,而非技术驱动

    这点说是体会,也可以说是教训。在我们的产品开发过程中,在某一新版本中重新设计了老版本的某一个重要模块,而引发了几个问题:一是,新版本的模块和老版本模块的兼容性问题,导致老版本客户无法平滑的迁移到新版本;二是,新版本的改进是纯技术方面的重新实现,不管对客户而言,还是对内部的架构而言,都没有明显好处;最后导致的结果是我们花了很多资源和人力去重新实现,但是在最后由于种种考虑还是废弃了重新实现的模块,依然沿用老模块。

    在产品的敏捷开发中,虽说拥抱变化,但不盲目变化。产品的改动需要经过概念设计、架构设计以及SWOT分析后,三思而后行。敏捷开发中也强调"在整个项目开发期间,业务人员和开发人员必须天天都在一起工作",确保技术人员能够开发出客户需要的产品。

    4) 时刻考虑版本兼容性

    敏捷开发,废除了过多冗余的文档和繁杂的设计,强调拥抱变化。但作为产品,敏捷开发不意味着盲目地去变化。

    当设计变动、API接口重构、配置文件变更时,要时刻考虑产品的架构、规划路线图,老版本的兼容性,及迁移平滑性。否则,随着版本的增多,必将面对着大量的维护工作。

    5) 轻文档,但非无文档

    敏捷开发强调沟通的重要性,而轻冗余文档。但敏捷开发并不意味着无文档。在敏捷开发过程中,适量的文档还是很有帮助,有助于整理思路,加快沟通和讨论。

    我们产品中的文档包括:概念设计文档、架构图、当前版本要实现的功能列表,以及SWOT分析。

    这些文档在每个产品版本开始之前会有产生,在每个迭代的过程中根据业务人员和市场的反馈也会有一些变更。通过我们实践证明,这对产品的思路、沟通讨论都非常有帮助。

    而且这些文档,大多是几页PPT,书写和维护工作都很小。

敏捷开发过程

    敏捷开发改进了产品的开发流程,提高了整个团队的效率。下面分析敏捷开发前和敏捷开发后的产品开发的各个阶段。

    1) 敏捷开发"前"的产品开发过程

图1 敏捷前开发流程

    上图是敏捷开发前我们产品一个版本的开发流程,整个开发大概持续一年左右。从图中可以看出,流程中的大多数活动都是串行进行。这样的一种类似瀑布的开发流程,前提是需求在产品的初始阶段就完整的被捕获并正确的分析,这样才能保证最后交付的产品是客户所需要的产品,但通常这样的理想状况很难实现。

    类瀑布的开发流程缺乏灵活性,无法通过开发活动来发现不够确切的需求,导致产品无法随着业务人员和市场的反馈而随需应变,开发出符合业务人员需求的产品。

       2) 敏捷开发"后"的产品开发过程

 

图2 敏捷后开发流程

    上图是敏捷开发"后"我们产品一个版本的开发流程,整个开发大概也是持续一年左右,但每个迭代都是1个月时间。和敏捷开发前相比,有很多的区别和优点,下面是其中几点:

    市场和需求驱动,拥抱变化

    在我们产品敏捷开发中,每个迭代结束,都会有一个产品迭代演示大会,把这个月的开发结果演示给组员、业务人员、售前,甚至客户,并收集反馈。此外,在开发的过程中,产品的业务人员和售前时刻保持与产品开发团队的沟通和工作,保证开发出来的产品是符合业务需求。

    充分利用资源和时间

    敏捷开发前,产品的需求设计阶段占用整个开发流程35%左右的时间,这段时间只需要几个核心的架构师和设计人员,无法充分地利用开发和测试人员。敏捷开发后,迭代开发、强调沟通、缩减文档,在每个迭代初期就可以充分地利用开发、测试人员的时间,达到效率最大化。

    每日交付

    产品开发过程中,每天都会做自动化Build,并生成可以交付的产品。业务人员、客户都可以试用并提供反馈和新需求。

    充分自动化

    敏捷开发强调拥抱变化,这必然带来动荡的产品代码变更。每一个新的功能和修改的功能,都可以影响到其他功能,造成副作用。所以,需要自动化去支持变化,在变化的同时保证质量和开发速度,包括编译自动化、单元测试自动化、功能测试自动化、UI测试自动化、集成测试自动化等。

架构师和Scrum Master的重要性

    流程的变化必将带来岗位和职责的变化,架构师和Scrum Master是在敏捷开发中两个重要的人物角色:

    1) 产品架构师

    在产品的敏捷开发中,特别是我所参与的产品是面向行业的产品,架构师是个举足轻重的角色,需要有深厚的行业背景、创新能力,以及架构能力。

    产品是为了解决一类客户需求而存在。但是,客户的需求往往是会随着业务的发展而变化,而且竞争对手也会有类似产品的推出。所以一个产品推出市场后,所具有的功能模块慢慢地会越来越成熟,并拥有越来越多的竞争对手,慢慢地失去竞争力。一个好的产品,特别是面向行业的产品,要具有长期的生命力,需要具有下图所示的产品模型:

    成熟的模块:指的是推出市场有一段时间,这些功能模块因满足客户的需求而被广泛使用。随着市场趋于稳定,大量竞争对手的产品也推出类似的功能。这些成熟模块都是产品的基本模块,不代表产品的竞争力。产品中如果只具有这些功能模块,随着需求和竞争的激烈,慢慢会走向灭亡。如90年代的BP机一样,当手机一旦推出,这个产品也就走向灭亡。

    发展中的模块:指的是刚推出市场并且具有强劲的市场生命力、符合客户当前几年的业务发展需求,正在被大客户所接受的功能模块。这些功能模块是产品占领市场的动力,是继成熟的功能模块后,产品的新的增长动力。

    研究中的下一代产品方向:指的是还没有推出市场、正在研究中的、符合未来行业五到十年发展方向的模块。当然如果能创造出未来的发展方向,则是最高境界。如任天堂的Wii、苹果公司的iPhone。

    一个行业软件产品要保持长期的生命力,在整个产品的生命周期架构规划中,需要考虑到这三种模块和特性,只有这样才能保持产品的先进性和长久生命力。

    敏捷开发也强调拥抱市场变化,这对产品架构师提出了很高的要求——深厚的业务背景、创新能力、技术洞察力和架构思想。

    2) Scrum Master

    Scrum Master虽然是敏捷开发的新名词,但其工作内容和开发组长没什么太大的区别:安排任务、协调资源、控制进度和解决难题。

    架构师根据对行业的理解和创新,设计出产品的架构。Scrum Master则是进一步分解和实现这个架构中的每个组件。如果形容"奥运会开幕式"是一个产品,架构师则设计整个开幕式的主题、创意、架构和包含的主要环节,而Scrum Master就是整个庞大工程的详细设计者和协调者。

    在我们产品中有三个Scrum Master,各自负责架构中的不同模块,并和开发人员一起把模块分解成一个个单独的、可以衡量的用例,然后协调开发人员高质量的完成任务。

    此外,每天早上需要主持小组成员进行一个10分钟左右Scrum会议。每个组员汇报昨天完成的任务,是否完成任务以及碰到的问题,最后是今天打算完成的任务。Scrum Master会协调解决每天碰到的问题,确保产品进度和质量。

总结

    在笔者的理解中,敏捷开发是一种思维方式和软件过程方法论,以及一系列的最佳实践,它能帮助团队开发出更加符合市场需求的产品。我们的团队在产品两个版本的敏捷开发历程中,不断摸索,找到了一条适合自己的产品敏捷开发流程,我们还将继续用敏捷的思想改进我们的敏捷开发流程,希望能与大家讨论探索,持续改进。

2018-08-20 16:54:42 ddonking 阅读数 6803

敏捷开发(scrum)是一种软件开发的流程,强调快速反应、快速迭代、价值驱动。

Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;运用该流程,你就能看到你团队高效的工作。

敏捷开发的特点就是下面4句话:

「个体与交互」胜过「过程与工具」

「可以工作的软件」胜过「面面俱到的文挡」

「客户协作」胜过「合同谈判」

「响应变化」胜过「遵循计划」

敏捷开发(scrum)适用于竞争激烈,快速变化的市场。 敏捷的客户协作观念,快速迭代能帮助团队以最小成本,最快速度满足客户真正的需求。对比传统开发模式:

传统开发模式以文档为驱动,而敏捷开发提倡少写文档

传统开发模式下开发人员按照产品文档进行研发,过程中客户不参与到产品的验收和体验中,这样就会导致最后开发出来的成品并不是客户想要的。 而敏捷开发模式从开始就强调客户协作,分步提供产品模块客户体验。

敏捷模式采取迭代式开发,传统模式采用瀑布式开发

敏捷开发采取迭代式开发的形式,即每个阶段有每个阶段需要完成、并且能使用的产品,这一阶段只要开发某几个功能,且这些功能的产品必须是可以使用的,这一阶段产品完成之后与客户进行对接交付,再进行下一阶段的开发。

敏捷开发更适应变化

传统开发模式下软件开发过程是执行研发计划,而实际工作中,需求往往在开发过程中会产生巨大变化。敏捷开发更能适应不确定性强的产品和市场。

接下面我们来具体看一下执行scrum的套路。

Scrum的三大角色

产品负责人(Product Owner)

主要负责和客户沟通确定产品的功能和达到要求的标准,并指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果,一般是由产品经理担任。

流程管理员(Scrum Master)

问题清道夫!主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。

开发团队(Scrum Team)

开发主力!主要负责软件产品在Scrum规定流程下进行开发工作。人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;不论过程只问结果!只要能达到目标,不论任何工作时间、方式。

Scrum的组成

Sprint:指的是一次迭代,而一次迭代的周期最好是1-4个星期,也就是我们要把产品需求分布到各个周期完成,这个过程我们称它为Sprint。

Story:用户故事,也可以看做是用户需求点。

Task:story的进一步细分。为了能够及时,高效地完成每个 Story,Scrum 团队会把每个 Story 分解成若干个 Task。每个Task 的时间最好不要超过8小时,保证在1个工作日内完成,如果 Task 的时间超过了8个小时,就说明Task的划分有问题,需要特别注意。

Backlog:Backlog是Scrum中的一个专用名词,意思是待办工作事项的集合。在开发中需要明确2个Backlog。

Product Backlog ——产品待办事项列表,产品负责人量化用户需求,逐条列出实际需要开发的需求(Story)。

Sprint Backlog——任务列表,是一次迭代中需要完成的任务,主要是开发团队细化工作的列表。

燃尽图(Burn Down Chart)

是一个展示开发时间的图,但是展示的是每天累加所有任务的剩余时间。

燃尽图是用来跟踪sprint中未完成工作的情况。每做完一个sprint的用户故事就烧掉,最后烧完sprint也就完成了。用蓝色线表示计划走向,红色线则是实际走向,两条线共同组成了燃尽图。如下图,每一个点代表一个用户故事,或者故事点,或者可度量的工作量。所有点组成sprint。

4个会议

Sprint计划会

Sprint 计划会就是大家坐下来,PO 向大家介绍排好序的产品待办事项(Product Backlog),然后大家共同思考决定如何推进计划,梳理出 Sprint Backlog 来完成后续的工作。

每日站会

每位开发成员都要交代3点

昨天完成了什么

今天计划完成什么

是否有困难需要帮助

每日站会

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

Sprint 评审会

当一个Sprint完成,这时就要进行最重要的演示会议,也称为评审会议,产品负责人和客户都要参加,每一个开发团队的成员都要演示自己完成的软件产品,然后被判定产品合格、成功、需要修改还是重新做。

Sprint 总结会

总结会议以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中。

以上的会议都不需要准备PPT或者大量的文档,但要注意会议的时长。

使用鱼骨Scrum项目的开发步骤

1.产品负责人使用产品Tab收集产品需求(story)。

Product Backlog

2.开发团队根据Product Backlog列表,在Sprint计划会议中做工作量的预估和安排,确定需求提交研发,进入Story看板。

Story看板

3.确定Sprint周期(1-4周)和本次开发迭代冲刺的开发需求(Stories)。进入Sprint的story出现在Task看板。 在Task看板,研发团队可以拆分Story到任务进行协作。

Task看板

5.每日立会,团队更新Task看板,和Story看板,保持信息的同步。

功能强大的鱼骨精益看板能协助开发团队更好的实施SCRUM。

2018-04-22 08:00:57 g1506490083 阅读数 1691

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

首先了解下SCRUM的工作流程的几个名词

Sprint:一个迭代周期的工作计划。一般需要2-4周时间。

Backlog:一个sprint的需求列表,可以看成是小目标的清单。

Task:具体小目标的开发任务。

Planning Meeting:确定这个迭代周期最终的开发任务和其对应的优先级即Sprint Backlog.

Daily meeting:每天早上的站会,用于讲一下自己工作进度和今天要完成的内容。

review meeting:在测试和修复BUG完成后全体人员开评审会议。

Retrospective Meeting:回顾会议每个人讲下这轮迭代过程中做得好的地方和做得不好的地方。


2015-08-31 20:26:19 fangxin_321 阅读数 6271

随着带的团队做的事情越来越多, 发布的产品也越来越多, 关于软件开发的流程的思考也越来越多.前段时间的高效虚拟自适应团队是在历经困难后磨练出来的方法的总结, 在此基础上,又经过几个版本发布的洗礼,对之前的认识又有了更新,更深入的看法. 在此特提炼出一套方法论, 供大家参考.

    一个软件从开发到上市(我们抛去维护部分), 一般需要经历阶段有 需求分析, 方案设计, 开发方案设计(包括概要设计, 详细设计等), 测试, 交付. 相信这些名词在软件工程中大家都能找得到, 那在这些过程中, 具体怎么实施呢?

    先看下面的流程图:

    卓有成效的敏捷开发流程

一. 前期准备阶段

    有很多人不太重视前期的准备, 或者不太在意这方面的事情. 还有一个问题, 前期的准备要准备到什么程度?

    在我这里, 前期要做好三件事: 需求分析工作, 数据分析工作, 概要开发方案

    需求分析: 这部分就是我们的专业需求人员所要处理的事情. 主要负责把本次版本中的功能分析清楚.我们一直强调一点, "需求要明确", 不允许在需求文档中出现类似"跟XXX一样"等这种含混不清的字眼. 一般来讲, 分析到此业务的背景, 解决的问题, 用户的操作场景, 有这些信息有可以了.

    数据分析: 尤其在我们的计价软件中, 定额库是不可缺少的东西. 他是你程序能够运行的前提.对于数据如何制作, 用何种方式制作能,制作成什么格式是最省力的, 对开发, 对数据人员的加工量是最少的, 能否支持程序运行. 数据的存储的介质,格式决定了后面的开发方案

    开发方案分析: 目标达到能说清楚这件事怎么做就可以了. 内容格式方面可以自由扩展. 可以以下面的我的分析方案为参考:

   可参考我之前的博客:<<概要设计 --需求定义及描述方式>>

     http://blog.sina.com.cn/s/blog_48258fbe0100b54a.html

    卓有成效的敏捷开发流程

  图2(需求分析格式)

   

 二. 方案评审

    这一步是必须的. 让业务专家, 或者有经验的人给你把下关.这样对你的方案是一个很大的补充. 一个人的想法很难保证想的很全, 所以, 可以经过这个环节进一步充实你的方案.等这一步完成后, 你会形成项目列表. 就是针对每个开发功能, 拆解为详细的开发步骤, 并估算出工时, 如下图所示:

   卓有成效的敏捷开发流程

  图3(任务分析明细图)

这样有助于你完成更为详细的开发计划. 一定要把任务项列细了, 越细, 对后面的进度控制就越有帮助.

 

三. 项目启动会议

    正如我上上篇文章所说, 这个过程的好坏会对后面的开发任务有很大的影响.在这个过程, 重点是进行需求交底. 把前面的分析结果再加上已经评审通过的内容做成PPT, 给整个团队成员做讲解. 让团队中的每个成员都能知道

     我们很难保证让团队中的每一个人都能把所有的业务都理解的很清楚, 这是很难办到的, 但可以保证的是,当这个任务为某个人做的时候, 他会更专心的去听这块内容, 对于要执行者,他是最为关注的. 这样当需求交底完成的, 可能是大部分人对需求都有所了解, 理解度在20%~60%左右吧, 但执行此任务的人理解度应该能达到90%左右. 不用担心, 我们后面有办法让那些只理解20%的人也能掌握另外的没掌握的内容.

    当需求交底完成后, 就要开始进行方案交底了, 一般你会把之前分析的内容给大家讲出来, 并给出自己的一套默认的开发方案,然后由大家来评审这个方案如何.

    在这个过程,有开发, 有测试, 有需求, 有数据,都会从不同的角度去分析此问题.在讨论过程中,那些本来可能还是太懂的人, 结过这么讨论,就会更明白了许多. 这样, 其理解度会上长到50%应该是没问题的.做为主持者, 当你发现某些人确实不在状态时,可采用单独提问方式来让他加深记忆,这都是可以的.

    还有不太清楚业务的, 没关系, 下面我们就要根据前面敲定的方案来排定任务了. 因为已经经过了前面的方案讨论, 所以对开发的时间应该有所把握, 这时,对于不清楚业务而无法估算出时间, 或者为了估算出正确的时间以至不会让自己任务拖延的, 也要再熟悉一遍需求. 经过这样, 需求基本上就都搞清楚了.那最后就要出我们的作战图了:

   卓有成效的敏捷开发流程

   图4(作战图示例)

 

    之前也说过, 作战图的作用, 就是把事情盘点清楚(当然你也可以理解为"网络图"), 让每一个人所做的的任务都能具体到整个过程的位置, 地位, 清楚自己的任务在整个项目中处在什么样的关键位置上.

    这就是作战图的优势, 把团队的目标凝聚在一起.

四. 迭代开发

   如上幅图所示, 我们有很多任务点, 任务项, 我如何能让在开发过程中, 让我们的团队更具有凝聚力, 更能向上呢, 答案就是自适应团队. 那如何才能实现呢.

    那就是短周期迭代. 我们可以把每一个任务做成一个小周期的迭代. 你这个迭代必须是有交付物的, 没有交付物, 那就没办法验证你的成果.

    在这个过程中, 我们只需要回答两个问题就足够了: 1. 能不能用. 2.有什么用. 当你进行完这个迭代后能回答这两个问题, 那么, 我就可以认为这个迭代完成, 可以进行一下个周期的迭代.

    以前我们在排定任务的时候, 总是在想着这个任务开发完成后再交由测试去测.这样相当于开发与测试在并行, 相互的交集就比较少. 开发只管开发的事, 完了后修改BUG就行了. 而测试呢, 只需求不停的测试版本就行了, 什么也不用管. 这样带来的问题就是修改BUG不及时, 有可能会出现开发成了这个功能好久后测试才提出这个问题, 开发再去修改. BUG越往后修改效率就越差的. 所以, 应该想办法让任务风险前移.

    当我给定一个开发任务时, 当他提交时, 应该是严格结过测试, 需求确认的. 测试的验证, 保证了该功能是"能用"的问题, 而需求的评审通过意味着该功能的"有用的", 自然也就是有价值的. 有用, 但不能用, 价值无法传递出去; 能用(可以使用), 但没用(此功能没有意义), 相当于做无用功. 所以在交付时, 一定是回答了"能不能用", "有什么用"之后的. 

    这样, 在排定任务时, 就把开发, 测试, 需求无形中绑定在一起了, 自适应何愁不来.

    在迭代开发中, 过程监控的方式手段很多, 比如我们常用的: 晨会, 夕会, 周会, 每日汇报. 项目可的可视化方式也有很多, 比如常用的任务燃烧图, BUG趋势图, 明细任务显示图等.   

    说到这不得不提下每日汇报的内容. 每日汇报, 就是把当前的工作内容以可视化的方式呈现出来. 有本书叫"一页纸项目管理", 里面介绍的方法就很好, 我又把它本地化了下, 显示的方式如下图所示:

 卓有成效的敏捷开发流程

  图5(每日汇报明细)

  点击查看大图

 

    这种方式能让你控制每一个小的迭代细节中, 能让你的控制更加周密. 大家可以不防试试.

 

 关于任务任务燃烧图, 他是从整体项目上对你当前产品的进度做出的评价, 有利于你及时调整项目中的瓶颈问题, 如下图所示的燃烧图: 他的做法就是总工时, 已剩余工时之前的关系来决定的.

    卓有成效的敏捷开发流程

 图7(进度控制超前的燃烧图)

卓有成效的敏捷开发流程

 图8(进度失控的项目)

  结合这两种分析方式, 就可以看出项目中存在风险的项目是什么了.

五. 集成测试

    在这个过程中, 最重要的反馈产品质量的就应该属BUG趋势图了, 可以反应出当前产品的BUG曲线, 来预测产品的质量. 关于BUG管理工具方面, 现在市面上也有很多, 比较有名的像BUGFree之类的, TD也不错的, 不要收费比较高.

 

六. 最后就是发版了.

   自然要经过评审, 确认本次版本中依然存在的问题, 解决的问题内容.



敏捷开发(Agile)是现在时髦的一个软件开发工程管理方式,其中的很多特征,例如scrum,pair coding,standup meeting等,有很多文章描述,这里我想聊一下敏捷开发中的文档和需求分析。


在传统的软件工程中,无论是瀑布式还是所谓的V型模式或测试驱动模式,基本上需求分析都是要进行的第一步,然后是概要设计,详细设计,编码和单元测试。传统的软件工程对文档要求比较高,而很多公司也为自己做过的大量文档而骄傲,标榜为规范。对于文档量很少甚至没有的软件项目斥之为山寨。

典型的,在这个项目过程中,需求分析占20-30%的时间,然后概要设计20%左右,详细设计也基本上20%左右,编码通常仅仅占10%-15%,剩余的时间机动给测试和需求变更。一旦需求变更——这个几乎是一定会发生的,根据长鞭效应,就会导致一连串的变更,设计,代码和测试,一切都随之变动。最后往往导致所谓的软件灾变。就是软件本身跟不上业务的变动,发布时间一再推迟。

还有重要的一点,就我看到的程序员,几乎没有一个喜欢写文档的,通常把写文档归于无聊,无用的工作。大量的文档任务对士气是一个很大的打击。


在敏捷开发中,号称拥抱变化,在一定程度上,能够降低需求变更和文档对项目的负面影响。

首先,有两点,是我们看待需求的基础:

第一,需求和设计是不能分开的,设计是要实现需求所要求的功能,需求也是在现在技术条件许可下的对期望值的折中。

第二,绝大多数客户实际上并不了解他们的需要,也不清楚他们想要什么产品。这一点,我相信在传统开发过程中,为不断的需求变更头痛的人一定是有体会的。(不过这个你可不要对你的客户说哦,人家会不高兴的)


于是,在敏捷开发中,需求不再是一个一次性的工作,而是一个伴随整个项目进行的,逐步细化的工作。

我们在开发中,设计和需求是混在一起进行的。设计文档有两种,Feature Design,这个可以说是功能设计,也就是类似与原来软件工程中的需求分析吧,另外一种就是Technical Design, 也就是类似原来软件工程中概要设计。

不过不要把Feature Design想象成传统软件工程中动辄几百页得需求分析,通常一个一年的项目,这个Feature Design也就10页左右的文档量而已,基本上就是非常粗略地大颗粒地描述要实现的功能而已。往往只描述要达到的结果和效果,对具体的UI,业务流程或者游戏角色等不做描述。

至于Technical design呢,文档量也不大,基本上就是模块划分,接口模式(不是格式哦),关键算法和数据结构等等框架的设计。对具体的数据格式和类型不做定义。

至于费时的详细设计,通常由程序员完成的,在敏捷开发中是真正省略了,是依靠代码的可读性来实现。敏捷的观点是:好的代码本身就是最好的文档。

总之,文档已经很弱化了,基本上就是一个design spec,当然对于软件自身的可读性和注释要求要多一些


敏捷开发讲究的轻量快速迭代。

也就是需求和设计实际上在一起进行的,进行的同时几乎就开始写代码。例如有了一个模糊的需求,就有一个前进的方向,例如可以写一些框架代码,定义一些消息机制和自动机的状态等,写一些接口类,基类,制定设计模式等。

进一步细一些的需求出来,就可以写一些派生类和执行逻辑。继续地,更进一步的需求就会表现在一些派生类上成员和成员函数的添加。就这样逐步细化。

敏捷开发中有迭代(Iteration)和里程碑(milestone)的概念,实际上开发的过程是和用户不断交流的过程,每个迭代基本上指实现一个或几个小Features,甚至是Feature中的一个部分,但是敏捷开发要求保证每个迭代出来的产品是能够使用和能够测试的,这样就可以有基础和客户交流获得进一步详细的需求。换句话说,就是每一吃迭代的工作都有可能得到用户的认可。

每个Milestone可以根据时间来划分,更多是按功能实现的需求的来划分,也就是每个milestone能够推出一个部分满足客户一些需求的产品。

所以在开发中,敏捷开发是一个小量递增,小步快走的过程,需求是逐步细化,设计也是逐步深入的,代码也是伴随这个过程不断生长的。需求分析是作为一个交互的过程,是在整个过程中和design/coding/test混合在一起。

在我们的开发过程中,很常见的情况是最初的feature design只实现了其中70%的功能,但是却另外添加了起初没想到的30%的功能。这也许就是敏捷说声称的“拥抱变化”吧。

这个就是现在时髦的敏捷编程啊,我感觉不错,效率比以前高多了,员工士气也比以前高。毕竟绝大多数程序员是不喜欢写文档的。

好一些的项目管理,往往能够把本项目的alpha测试和debugging的时间和下一个项目的design,甚至frame coding的阶段重合在一起,以最大限度提升效率,或者说榨取程序员的价值。


http://blog.sina.com.cn/s/blog_6296cebc0100pybx.html


敏捷开发(Agile development)

目录

[隐藏]

敏捷开发概述

  敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

敏捷开发的路线[1]

  Image:敏捷开发的路线图.jpg

  图:敏捷开发的路线图

  Test-Driven Development,测试驱动开发。

  它是敏捷开发的最重要的部分。在ThoughtWorks,我们实现任何一个功能都是从测试开始,首先对业务需求进行分析,分解为一个一个的Story,记录在Story Card上。然后两个人同时坐在电脑前面,一个人依照Story,从业务需求的角度来编写测试代码,另一个人看着他并且进行思考,如果有不同的意见就会提出来进行讨论,直到达成共识,这样写出来的测试代码就真实反映了业务功能需求。接着由另一个人控制键盘,编写该测试代码的实现。如果没有测试代码,就不能编写功能的实现代码。先写测试代码,能够让开发人员明确目标,就是让测试通过。

  Continuous Integration,持续集成。

  在以往的软件开发过程中,集成是一件很痛苦的事情,通常很长时间才会做一次集成,这样的话,会引发很多问题,比如 build未通过或者单元测试失败。敏捷开发中提倡持续集成,一天之内集成十几次甚至几十次,如此频繁的集成能尽量减少冲突,由于集成很频繁,每一次集成的改变也很少,即使集成失败也容易定位错误。一次集成要做哪些事情呢?它至少包括:获得所有源代码、编译源代码、运行所有测试,包括单元测试、功能测试等;确认编译和测试是否通过,最后发送报告。当然也会做一些其它的任务,比如说代码分析、测试覆盖率分析等等。在我们公司里,开发人员的桌上有一个火山灯用来标志集成的状态,如果是黄灯,表示正在集成;如果是绿灯,表示上一次集成通过,开发人员在这时候获得的代码是可用而可靠的;如果显示为红灯,就要小心了,上一次集成未通过,需要尽快定位失败原因从而让灯变绿。在持续集成上,我们公司使用的是自己开发的产品CruiseControl。

  Refactoring,重构。

  相信大家对它都很熟悉了,有很多很多的书用来介绍重构,最著名的是Martin的《重构》,Joshua的《从重构到模式》等。重构是在不改变系统外部行为下,对内部结构进行整理优化,使得代码尽量简单、优美、可扩展。在以往开发中,通常是在有需求过来,现在的系统架构不容易实现,从而对原有系统进行重构;或者在开发过程中有剩余时间了,对现在代码进行重构整理。但是在敏捷开发中,重构贯穿于整个开发流程,每一次开发者check in代码之前,都要对所写代码进行重构,让代码达到clean code that works。值得注意的是,在重构时,每一次改变要尽可能小,用单元测试来保证重构是否引起冲突,并且不只是对实现代码进行重构,如果测试代码中有重复,也要对它进行重构。

  Pair-Programming,结对编程。

  在敏捷开发中,做任何事情都是Pair的,包括分析、写测试、写实现代码或者重构。Pair做事有很多好处,两个人在一起探讨很容易产生思想的火花,也不容易走上偏路。在我们公司,还有很多事都是Pair来做,比如Pair学习,Pair翻译,Pair做PPT,关于这个话题,钱钱同学有一篇很有名的文章对它进行介绍,名为Pair Programming (结对编程)。

  Stand up,站立会议。

  每天早上,项目组的所有成员都会站立进行一次会议,由于是站立的,所以时间不会很长,一般来说是15-20分钟。会议的内容并不是需求分析、任务分配等,而是每个人都回答三个问题:1. 你昨天做了什么?2. 你今天要做什么? 3. 你遇到了哪些困难?站立会议让团队进行交流,彼此相互熟悉工作内容,如果有人曾经遇到过和你类似的问题,那么在站立会议后,他就会和你进行讨论。

  Frequent Releases,小版本发布。

  在敏捷开发中,不会出现这种情况,拿到需求以后就闭门造车,直到最后才将产品交付给客户,而是尽量多的产品发布,一般以周、月为单位。这样,客户每隔一段时间就会拿到发布的产品进行试用,而我们可以从客户那得到更多的反馈来改进产品。正因为发布频繁,每一个版本新增的功能简单,不需要复杂的设计,这样文档和设计就在很大程度上简化了。又因为简单设计,没有复杂的架构,所以客户有新的需求或者需求进行变动,也能很快的适应。

  Minimal Documentation,较少的文档。

  其实敏捷开发中并不是没有文档,而是有大量的文档,即测试。这些测试代码真实的反应了客户的需求以及系统API 的用法,如果有新人加入团队,最快的熟悉项目的方法就是给他看测试代码,而比一边看着文档一边进行debug要高效。如果用书面文档或者注释,某天代码变化了,需要对这些文档进行更新。一旦忘记更新文档,就会出现代码和文档不匹配的情况,这更加会让人迷惑。而在敏捷中并不会出现,因为只有测试变化了,代码才会变化,测试是真实反应代码的。这时有人会问:代码不写注释行吗?一般来说好的代码不是需要大量的注释吗?其实简单可读的代码才是好的代码,既然简单可读了,别人一看就能够看懂,这时候根本不需要对代码进行任何注释。若你觉得这段代码不加注释的话别人可能看不懂,就表示设计还不够简单,需要对它进行重构。

  Collaborative Focus,以合作为中心,表现为代码共享。

  在敏捷开发中,代码是归团队所有而不是哪些模块的代码属于哪些人,每个人都有权利获得系统任何一部分的代码然后修改它,如果有人看到某些代码不爽的话,那他能够对这部分代码重构而不需要征求代码作者的同意,很可能也不知道是谁写的这部分代码。这样每个人都能熟悉系统的代码,即使团队的人员变动,也没有风险。

  Customer Engagement ,现场客户。

  敏捷开发中,客户是与开发团队一起工作的,团队到客户现场进行开发或者邀请客户到团队公司里来开发。如果开发过程中有什么问题或者产品经过一个迭代后,能够以最快速度得到客户的反馈。

  Automated Testing ,自动化测试。

  为了减小人力或者重复劳动,所有的测试包括单元测试、功能测试或集成测试等都是自动化的,这对QA人员提出了更高的要求。他们要熟悉开发语言、自动化测试工具,能够编写自动化测试脚本或者用工具录制。我们公司在自动化测试上做了大量的工作,包括Selenium开源项目。

  Adaptive Planning,可调整计划。

  敏捷开发中计划是可调整的,并不是像以往的开发过程中,需求分析->概要设计->详细设计->开发 ->测试->交付,每一个阶段都是有计划的进行,一个阶段结束便开始下一个阶段。而敏捷开发中只有一次一次的迭代,小版本的发布,根据客户反馈随时作出相应的调整和变化。

  敏捷开发过程与传统的开发过程有很大不同,在这过程中,团队是有激情有活力的,能够适应更大的变化,做出更高质量的软件。

敏捷开发的特点

  敏捷方法主要有两个特点,这也是其区别于其他方法,尤其是重型方法的最主要特征:

  (1)敏捷开发方法是“适应性”(Adaptive)而非“预设性” (Predictive)。

  这里说的预设性,可以通过一般性工程项目的做法理解,比如土木工程,在这类工程实践中,有比较稳定的需求,同时建设项目的要求也相对固定,所以此类项目通常非常强调施工前的设计规划。只要图纸设计得合理并考虑充分,施工队伍可以完全遵照图纸顺利建造,并且可以很方便地把图纸划分为许多更小的部分交给不同的施工人员分别完成。

  然而,在软件开发的项目中,这些稳定的因素却很难寻求。软件的设计难处在于软件需求的不稳定,从而导致软件过程的不可预测。但是传统的控制项目模式都是试图对一个软件开发项目在很长的时间跨度内做出详细的计划,然后依计划进行开发。所以,这类方法在不可预测的环境下,很难适应变化,甚至是拒绝变化。

  与之相反的敏捷方法则是欢迎变化,目的就是成为适应变化的过程,甚至能允许改变自身来适应变化。所以称之为适应性方法。      (2)敏捷开发方法是“面向人” (people oriented)而非“面向过程”(process oriented)。

  Matin Flower认为:“在敏捷开发过程中,人是第一位的,过程是第二位的。所以就个人来说,应该可以从各种不同的过程中找到真正适合自己的过程。”这与软件工程理论提倡的先过程后人正好相反。 (续致信网上一页内容)

  在传统的软件开发工作中,项目团队分配工作的重点是明确角色的定义,以个人的能力去适应角色,而角色的定义就是为了保证过程的实施,即个人以资源的方式被分配给角色,同时,资源是可以替代的,而角色不可以替代。

  然而,传统软件开发的这些方法在敏捷开发方式中被完全颠覆。敏捷开发试图使软件开发工作能够利用人的特点,充分发挥人的创造能力。

  敏捷开发的目的是建立起一个项目团队全员参与到软件开发中,包括设定软件开发流程的管理人员,只有这样软件开发流程才有可接受性。同时敏捷开发要求研发人员独立自主在技术上进行决策,因为他们是最了解什么技术是需要和不需要的。再者,敏捷开发特别重视项目团队中的信息交流,有调查显示:“项目失败的原因最终都可追溯到信息没有及时准确地传递到应该接受它的人。”

敏捷开发的价值观

  实际上敏捷开发运动在数年前就开始了,但它正式开始的标志是2001年2月的“敏捷宣言”(Agile Manifesto),这项宣言是由17位当时称之为“轻量级方法学家”所编写签署的,他们的价值观是:个人与交互重于开发过程与工具;可用的软件重于复杂的文档;寻求客户的合作重于对合同谈判;对变化的响应重于始终遵循固定的计划。

  个人与交互重于开发过程与工具的原因:一个由优秀的人员组成但使用普通的工具,要比使用优秀的工具但由普通人组成、紊乱的小组做得更好。多年来人们花了很多时间试图建立一种过程,以便把人当作机器上的一个可以替代的齿轮,但结果却并不成功。敏捷过程是承认每个人都有特定的能力(以及缺点)对之加以利用,而不是把所有的人当成一样来看待。更重要的是,在这样的理念下,几个项目做下来,每个人的能力都从中得以提高。这种人的能力的提高,对公司是无价之宝。而不至于把人当成齿轮,随着时间的推移,人的能力慢慢被消耗掉,最后变成留之无用、弃之可惜的尴尬人物。

  可用的软件重于复杂的文档的原因:可用的软件可以帮助开发人员在每次迭代结束的时候,获得一个稳定的、逐渐增强的版本。从而允许项目尽早开始,并且更为频繁的收集对产品和开发过程的反馈。随着每次迭代完成软件的增长,以保证开发小组始终是处理最有价值的功能,而且这些功能可以满足用户的期待。

  寻求客户的合作重于对合同的谈判的原因:敏捷开发小组希望与项目有关的所有团体都在朝共同方向努力,合同谈判有时会在一开始就使小组和客户出于争执中。敏捷开发追求的是要么大家一起赢,要么大家一起输。换句话说,就是希望开发小组和客户在面对项目的时候,以一种合作的态度共同向目标前进。当然,合同是必需的,但是如何起草条款,往往影响到不同的团体是进行合作式的还是对抗式的努力。

  对变化的响应重于始终遵循固定的计划的原因:敏捷开发认为对变化进行响应的价值重于始终遵循固定的计划。他们最终的焦点是向用户交付尽可能多的价值。除了最简单的项目以外,用户不可能知道他们所需要的所有功能的每个细节。不可避免地在过程中会产生新的想法,也许今天看起来是必需的功能,明天就会觉得不那么重要了。随着小组获得更多的知识和经验,他们的进展速度会比开始的时候期望值慢或者快。对敏捷开发来说,一个计划是从某个角度对未来的看法,而具有多个不同的角度看问题是有可能的。

项目的敏捷开发方法

  敏捷方法很多,包括 Scrum、极限编程、功能驱动开发以及统一过程(RUP)等多种法,这些方法本质实际上是一样的,敏捷开发小组主要的工作方式可以归纳为:作为一个整体工作; 按短迭代周期工作; 每次迭代交付一些成果; 关注业务优先级; 检查与调整。下图是典型的敏捷过程总图,下面介绍其有关的特点。

  Image:敏捷过程总图.gif

  1、敏捷小组作为一个整体工作

  项目取得成功的关键在于,所有项目参与者都把自己看成朝向一个共同目标前进的团队的一员。“扔过去不管”的心理不是属于敏捷开发。设计师和架构师不会把程序设计“扔”给编码人员;编码人员也不会把只经过部分测试的代码“扔”给测试人员,一个成功的敏捷开发小组应该具有“我们一起参与其中的思想”, “帮助他人完成目标”这个理念是敏捷开发的根本管理文化。当然,尽管强调一个整体,小组中应该有一定的角色分配,各种敏捷开发方法角色的起名方案可能不同,但愿则基本上是一样的。第一个角色是产品所有者,他的主要职责包括:确认小组成员都在追求一个共同的目标前景;确定功能的优先等级,以便总是处理最有价值的功能;作出可以使项目的投入产生良好回报的决定。产品所有者通常是公司的市场部门或者产品管理部门的人员,在开发内部使用的软件的时候,产品所有者可能是用户、用户的上级、分析师,也可能是为项目提供资金的人。

  2、敏捷小组按短迭代周期工作

在敏捷项目中,总体上并没有什么上游阶段、下游阶段,你可以根据需要定义开发过程在初始阶段可以有一个简短的分析、建模、设计,但只要项目真正开始,每次迭代都会做同样的工作(分析、设计、编码、测试。等等)。迭代是受时间框限制的,也就是说即使放弃一些功能,也必须结束迭代。时间框一般很短,大部分是 2~4周,在 Scrum中采用的是 30个日历天,也就是 4 周。迭代的时间长度一般是固定的,但也有报告说,有的小组在迭代开始的时候选择合适的时间长度。

  3、敏捷小组每次迭代交付一些成果

  比选择特定迭代长度更重要的,是开发小组在一次迭代中要把一个以上的不太精确的需求声明,经过分析、设计、编码、测试,变成可交付的软件(称之为功能增量)。当然并不需要把每次迭代的结果交付给用户,但目标是可以交付,这就意味着每次迭代都会增加一些小功能,但增加的每个功能都要达到发布质量。每次迭代结束的时候让产品达到可交付状态十分重要,但这并不意味着要完成发布的全部工作,因为迭代的结果并不是真正发布产品。假定一个小组需要在发布产品之前对软硬件进行为期两个月的“平均无故障时间”(MTBF)测试,他们不可能缩短这两个月的时间,但这个小组仍然是按照 4 周迭代,除了MTBF测试,其它都达到了发布状态。

  4、敏捷小组关注业务优先级

  敏捷开发小组从两个方面显示出他们对业务优先级的关注。首先,他们按照产品所有者制定的顺序交付功能,而产品所有者一般会按照组织在项目上的投资回报最大化的方式来确定优先级,并且把它组织到产品发布中去。要达到这个目的,需要综合考虑开发小组的能力,以及所需功能的优先级来建立发布计划。在编写功能的时候,需要使工能的依赖性最小化。如果开发一个功能必须依赖其它 3 个功能,那产品所有者这就很难确定功能优先级。功能完全没有依赖是不太可能的,但把功能依赖性控制在最低程度还是相当可行的。

  5、敏捷小组检查与调整

  任何项目开始的时候所建立的计划,仅仅是一个当前的猜测。有很多事情可以让这样的计划失效:项目成员的增减,某种技术比预期的更好或更差,用户改变了想法,竞争者迫使我们做出不同的反应,等等。对此,敏捷小组不是害怕这种变化,而是把这种变化看成使最终软件更好地反映实际需要的一个机会。每次新迭代开始,敏捷小组都会结合上一次迭代中获得新知识做出相应调整。如果认为一些因素可能会影响计划的准确性,也可能更改计划。比如发现某项工作比预计的更耗费时间,可能就会调整进展速度。也许,用户看到交付的产品后改变了想法,这就产生反馈,比如他发现他更希望有另一项功能,或者某个功能并不像先前看得那么重。通过先期发布增加更多的用户希望的功能,或者减少某些低价值功能,就可以增加产品的价值。迭代开发是在变与不变中寻求平衡,在迭代开始的时候寻求变,而在迭代开发期间不能改变,以期集中精力完成已经确定的工作。由于一次迭代的时间并不长,所以就使稳定性和易变性得到很好的平衡。在两次迭代期间改变优先级甚至功能本身,对于项目投资最大化是有益处的。从这个观点来看,迭代周期的长度选择就比较重要了,因为两次迭代之间是提供变更的机会,周期太长,变更机会就可能失去;周期太短,会发生频繁变更,而且分析、设计、编码、测试这些工作都不容易做到位。综合考虑,对于一个复杂项目,迭代周期选择4周还是有道理的。

  MIT Sloan Management Review(麻省理工学院项目管理评论)所刊载的一篇为时两年对成功软件项目的研究报告,报告指出了软件项目获得成功的共同因素,排在首位的是迭代开发,而不是瀑布过程。其它的因素是:

  1、至少每天把新代码合并到整个系统,并且通过测试,对设计变更做出快速反应

  2、开发团队具备运作多个产品的工作经验。

  3、很早就致力于构建和提供内聚的架构。

  从这个报告中所透露出的信息告诉我们,认真研究敏捷过程对软件项目的成功是非常有意义的,它的意义在于:

  1)给开发小组的自组织提供了机会

  经典项目管理就好比一个具备中央调度服务的航空管理系统,这个系统是自治的,而且是封闭的,但现实中更庞大的系统,似乎并不属于中央调度控制系统,但也同样也是有效的。假如我们开车到某个地方,我们可以任意选择所需要的路线,我们甚至不需要准确计算停车,只要我们遵守交通法规,驾驶员可以临时根据路况改变某个转弯点,在驾驶游戏规则的框架内,依照自身最大利益做出决策。成千上万的驾驶者,并不需要中央控制和调度服务,人们仅仅在简单的交通法规的框架内,就可以完成综合起来看是更庞大的目标,很多事情从管理的角度只要抓住关键点,并不需要多么复杂的规则,往往会更有效。随着系统复杂度的提高,中央控制和调度系统面临崩溃。仔细研究交通系统的特点,我们会发现这样的系统中独立的个体在一组适当的规则下运行,并不需要设计每个个体临时变更的方案,而每个个体只需要知道目标和大致的状况,他们完全可以利用自己的聪明才智来决定自己的行为。

  2)缩短了反馈通道

  敏捷过程有效运作的另一个原因是,它极大的缩短了用户与开发者、预测目标与实施状况、投资与回报之间的反馈回路。在面对不断变化的市场、业务过程以及不断发展的技术状态的时候,便需要有一种方法在比较短的时间内发展完善。事实上,所有的过程改进都不同程度的使用着戴明循环,以研究问题、测试解决方案、评估结果,进而根据已知的事实来进行改进,这就称之为基于事实的决策模式,我们都知道,这比前端预测的决策方式更加有效。

  3)易于集思广益

  敏捷过程能有效应用的另一个原因在于,它可以就一个问题集思广益。我们的经验告诉我们当一个问题发生的时候,总有某些人员知道问题所在,但他的观点却遭到忽视。例如航天飞机在起飞阶段发生爆炸,事后分析出了各种原因,但这种调查也提供给我们一个惊人的事实,就是部分工程师早就意识到这些潜在问题,却无法说服他人重视这个担忧。对这些事实的深入思考,促使我们研究我们应该采取何种管理系统,使前线工作人员的经验、观点及担忧得到充分的重视呢?

对敏捷开发的误解

  误解一:敏捷对人的要求很高

  很多人在尝试实施敏捷时说:敏捷对人的要求太高了,我们没有这样的条件,我们没有这样的人,因此我们没法敏捷。可是,敏捷对人的要求真的那么高么? 软件归根到底还是一种创造性活动,开发人员的技术水平和个人能力对软件的质量还是起着决定性的作用,各种过程与方法只是帮助开发人员、测试人员等角色能够更好的合作,从而产生更高的生产力。不管用什么方法,开发人员的水平永远都是一个主要的因素。

  从另一个角度来看:过程和方法究竟能帮开发人员多大忙?对于技术水平较低的开发人员,敏捷方法和传统方法对他的帮助是差不多的,因此看不到显着的效果,甚至有些时候还有反效果;而随着开发人员技术水平的提高,敏捷方法能够解开对人的束缚,鼓励创新,效果也会越来越显着。

  敏捷对人的要求并不高,而且会帮助你培养各种所需的能力,当然前提是你处在真正敏捷的环境中。

  误解二:敏捷没有文档,也不做设计

  这个误解从XP开始就没有停止过,XP鼓励“在非到必要且意义重大时不写文档”。这里面提到的“必要且意义重大”是一个判断标准,并不是所有的文档都不写。例如,用户手册是不是“必要且意义重大”?这取决于客户的要求,如果客户不需要,那就不用写,如果客户需要,就一定要写;再如,架构设计文档要不要写?复杂要写,不复杂不用写。通常架构设计只需要比较简单的文档,对于有些项目,一幅简单的UML图就够了。因此,写不写,怎么写,都要根据这个文档到底有多大意义,产出和投入的比例,以及项目的具体情况决定。实际操作时可以让项目组所有人员表决决定,尽量避免由某一个人(比如lead)来决定。

  至于设计,XP奉行的是持续设计,并不是不设计。这实际上是将设计工作分摊到了每天的日常工作中,不断的设计、改善(重构),使得设计一直保持灵活可靠。至于编码前的预先设计,Kent Beck等人确实实行着不做任何预先设计的开发方式,但是对于我们这些“非大师”级开发人员,必要的预先设计还是需要的,只是不要太多,不要太细,要有将来会彻底颠覆的准备。

  误解三:敏捷好,其他方法不好

  有些人一提到敏捷就大呼好,只要是敏捷的实践就什么都好,而提到CMMI等方法就大呼不好,不管是什么只要沾上边就哪里都不好,似乎敏捷和其他方法是完全对立的。牛顿说过,我是站在了巨人的肩膀上。敏捷同样也吸取了其他方法论的优点,也是站在了巨人的肩膀上,敏捷依然保持了很多历史悠久的实践和原则,只是表现方式不同罢了。

  从另一个方面来看,方法本没有好环,好与坏取决于是否适合解决你的问题。每一种方法都有他最善于解决的问题和最佳的发挥环境,在需求稳定、软件复杂度相对不高的时代,瀑布模型也可以工作的很好,而敏捷恰好适用于变化快风险高的项目 - 这恰恰是现在很多项目的共性。

  因此选择一个方法或过程,并不是根据它是否敏捷,而应根据它是否适合。而要了解一个东西是否适合,还是要尝试之后才知道,任何没有经过实践检验的东西都不可信。

  误解四:敏捷就是XP(极限编程),就是Scrum

  XP 和Scrum只是众多敏捷方法中的两种,还有很多其他的敏捷方法。龙生九子各个不同,敏捷的这些方法看起来差别也是很大的,可是他们之所以被称为敏捷方法,就是因为他们背后的理念和原则都是相同的,这个原则就是《敏捷宣言》。学习敏捷不仅仅要学习实践,还要理解实践后的原则,不仅要理解怎么做,还要理解为什么这么做,以及什么时候不要这么做。

  即使将XP或Scrum完全的应用的你的项目中,也未见得就能成功,适合别人的东西未必就适合你。敏捷的这些实践和方法给了我们一个起点,但绝对不是终点,最适合你的方式还要由你自己在实际工作中探索和寻找。

  误解五:敏捷很好,因此我要制定标准,所有项目都要遵循着个标准

  没有哪两个项目是一样的,客户是不一样的,人员是不一样的,需求是不一样的,甚至没有什么可能是一样的。不一样的环境和问题,用同样的方法解决,是不可能解决的好的。方法是为人服务的,应该为项目团队找到最适合他们的方法,而不是先确定方法,再让团队适应这个方法。因此也不存在适合所有项目的统一的方法。任何企图统一所有项目过程的方法都是不正确的。

  同时,对于同一个团队,随着项目的进行,对需求理解的深入,对技术理解的深入,一开始适合项目的过程和方法也会渐渐的不适合。这时候也需要团队对过程进行及时的调整,保证项目的质量和效率。敏捷是动态的,而非静止不变的,因为这个世界本身就是变化的,在变化的世界使用不变的方法,是不现实的。银弹从来就没有过,在有限的将来也不会存在。


敏捷开发流程

阅读数 2732