2017-11-12 23:16:16 mark_my_code 阅读数 204
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13655 人正在学习 去看看 张传波

1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来是客户满意

2.即使到了开发的后期,也欢迎需求的改变。敏捷过程利用变化来为客户创造竞争优势

3.经常性地交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间越短越好

4.在整个项目开发期间,业务人员和开发人员必须天天在一起工作

5.围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持,并且信任他们能够完成工作

6.在团队内部,最有效果并且富有效率的传递信息的方式,是面对面的交谈

7.工作的软件是首要的进度度量标准

8.敏捷过程提倡可持续的开发速度,责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度

9.不断地关注优秀的技能和好的设计会增强敏捷能力

10.简单-使未完成的工作最大化的艺术-是根本的

11.最好的构架、需求和设计出自于自组织的团队

12.每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应的对自己的行为进行调整

2019-03-09 07:49:28 u013464787 阅读数 31
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13655 人正在学习 去看看 张传波

敏捷实践

敏捷原则

捷软件开发宣言
  我们正在通过亲身实践以及帮助他人实践,揭示更好的软件开发方法。通过这项工作,我们认为:
  * 个体和交互    胜过   过程和文档
  * 可以工作的软件  胜过   面面俱到的文档
  * 客户合作     胜过   合同谈判
  * 响应变化     胜过   遵循计划
  虽然右项也有价值,但是我们认为左项具有更大的价值。

从上述的价值观引出了下面12条原则,它们是敏捷实践区别于重型过程的特征所在。

  1. 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

  2. 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

  3. 经常性的交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好。

  4. 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。

  5. 围绕被激励起来的个人来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。

  6. 在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。

  7. 工作的软件是首要的进度度量标准。

  8. 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

  9. 不断的关注优秀的技能和好的设计会增强敏捷能力。

  10. 简单—使未完成的工作最大化的艺术—是根本的。

  11. 最好的架构、需求和设计出自于自组织的团队。

  12. 每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。

    每一位软件开发人员、每一个开发团队的职业目标,都是给他们的雇主和客户交付最大可能的价值。可是,我们的项目以令人沮丧的速度失败,或者未能交付任何价值。虽然在项目中采用过程方法是出于好意的,但是膨胀的过程方法对于我们的失败至少是应该付一些责任的。敏捷軟件开发的原则和价值观构成了一个可以帮助团队打破过程膨胀循环的方法,这个方法关注的是可以达到团队目标的一些简单的技术。

最重要的敏捷过程—极限编程

极限编程实践

  1. 客户作为团队成员

  2. 用户素材

  3. 短交付周期
    3.1 迭代计划
    3.2 发布计划

  4. 验收测试

  5. 结对编程

  6. 测试驱动的开发方法

  7. 集体所有权

  8. 持续集成

  9. 可持续的开发速度

  10. 开放的工作区间

  11. 计划游戏

  12. 简单的设计
    1) 考虑能够工作的最简单的事情
    2) 你将不需要它。
    3) 一次,并且只有一次。

  13. 重构

  14. 隐喻
    极限编程是一组简单、具体的实践,这些实践结合在一起形成了一个敏捷开发过程。该过程已经被许多团队使用过,并且取得了好的效果。极限编程是一种优良的、通用的软件开发方法。项目团队可以拿来直接采用,也可以增加一些实践,或者对其中的一些实践进行修改后再采用。

重构

在不改变代码外在行为的前提下对代码做出修改,以改进代码的内部结构的过程。

可是我们为什么要改进已经能够工作的代码的结构呢?不是还有句古老的谚语:如果它没有坏,就不要去修理它 !

每一个软件模块都具有三项职责。第一个职责是它运行起来所完成的功能。这也是该模块得以存在的原因。第二个职责是它要应对变化。几乎所有的模块在它们的生命周期中都要变化,开发者有责任保证这种改变应该尽可能地简单。一个难以改变的模块是拙劣的,即使能够工作,也需要对它进行修正。第三个职责是要和阅读它的人进行沟通。对该模块不熟悉的开发人员应该能够比较容易的阅读并理解它。一个无法进行沟通的模块也是拙劣的。同样需要对它进行修正。

2019-08-06 17:46:05 qq_33189961 阅读数 137
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13655 人正在学习 去看看 张传波

目录

什么是敏捷

什么是敏捷开发

敏捷宣言

敏捷宣言12条原则

敏捷开发的优势

瀑布模型开发

敏捷开发


什么是敏捷

Agile(敏捷)来源于敏捷宣言,宣言明确指出,“敏捷”:

  • 不是一种方法论
  • 也不是开发软件的具体方法
  • 更不是一个框架或者过程

“敏捷”是一套价值观(理念)和原则,帮助团队在软件开发过程中更好地做出决策。

 

什么是敏捷开发

简而言之就是遵循了“敏捷”这一开发原则的开发方法,敏捷并不意味着一味强调速度,而是轻量和高效

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

敏捷开发流程如下:

 

敏捷宣言

  • 个体和互动   高于    流程和工具
  • 工作的软件   高于    详尽的文档
  • 客户合作       高于    合同谈判
  • 响应变化       高于    遵循计划

注:这并不意味摒弃了右边的原则,而是应该更加注重左边的原则。

 

敏捷宣言12条原则

  1. 最重要的是通过尽早和不断交付有价值的软件满足客户需要。
  2. 我们欢迎需求的变化,即使在开发后期。敏捷过程能够驾驭变化,保持客户的竞争优势。
  3. 经常交付可以工作的软件,从几星期到几个月,交付时间尺度越短越好
  4. 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作
  5. 围绕斗志高昂的人进行软件开发,给开发者提供适宜的环境,满足他们的需要,并相信他们能够完成任务。
  6. 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈
  7. 可以工作的软件是进度的主要度量标准
  8. 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。
  9. 对卓越技术与良好设计的不断追求将有助于提高敏捷性。
  10. 简单——尽可能减少工作量的艺术至关重要。
  11. 最好的架构、需求和设计都源自自我组织的团队。
  12. 每隔一定时间,团队都要总结如何更有效率,然后相应地调整自己的行为。

比如就“简单”和“尽早交付”而言:

当我们在构建某个功能时,发现其可能会需要数据库支持,一般情况下我们会去构建数据库并为其编码,然而敏捷认为:为这个功能构建数据库就意味着要浪费很多时间,软件就不得不延迟交付给客户,如果能找到一种替代的简单方法完成该功能,那就更符合我的敏捷原则。

但是敏捷原则并不是让我们盲目模仿,应当结合实际情况和敏捷的价值理念做出正确决策。比如scrum可能倡导小组会议站着开,但是如果结合实际情况也可以完全选择适合自己的方式开会,坐着更高效就坐着,切记盲目模仿一些成功的敏捷案例。

 

敏捷开发的优势

相比于瀑布模型:

瀑布模型开发

  1. 客人到餐馆来点菜(新项目)
  2. 不确定客户想吃什么的时候,通常选好餐厅后会先看看餐厅的菜单(客户往往提不出具体的需求)
  3. 根据图文菜单,客人点了十个菜(根据原型和设计稿,基本确定了需求)
  4. 后厨开始准备(项目启动)
  5. 根据客人的下单配菜,炒菜(基本上不会主动去了解完整需求)
  6. 半个小时了,菜还没上桌,客人饿极了(项目启动后很长一段时间客户什么都看不到)
  7. 再过了二十分钟,十个菜都一起上来了(项目最终一次交付)
  8. 客人说,有几个菜挺好的,但是有个菜味道淡了,有两个不够辣,还有两盘重复了想换掉(我是买单的,我要变需求)
  9. 这时候大堂经理来了,说,“味道淡了可以加盐,不辣可以加辣,但是换菜不行,已经炒好的那两盘菜也是要算成本的”(瀑布的坏处,需求变更比较麻烦)
  10. 于是,后厨只给客户加了盐,加了辣
  11. 客人吃完,不是很满意,下次不来了(没有满足需求)

敏捷开发

  1. 客人到餐馆来点菜(新项目)
  2. 不确定客户想吃什么的时候,通常选好餐厅后会先看看餐厅的菜单(客户往往提不出具体的需求)
  3. 根据图文菜单,客人点了是个菜(根据原型和设计稿,基本确定了需求)
  4. 后厨开始准备(项目启动)
  5. 配菜、炒菜,先上了两盘,让客人尝了尝味道(先提供可用实例给客户用)
  6. 客人说还不错,后厨继续准备后面的菜,陆续上菜(不断迭代,不断测试)
  7. 上菜过程中,客人突然发现有个菜的味道太淡了,让后厨加了点盐又端上来了(敏捷的好处,可以不断测试和需求变更)
  8. 又上了两盘,不够辣,又拿到后厨加了辣(敏捷的坏处,需求没有提前明确,反复迭代,增加了工作量)
  9. 到最后两盘时,客人要求换两个菜,还好没炒(迭代的好处,随时接受需求变更)
  10. 客人吃完,很满意(基本满足了全部的要求)

 

总结:在理解了“敏捷”的价值和原则后,将其带入到软件开发过程中做出正确的决策,就是所谓的敏捷开发了。


参考:

  1. https://www.cnblogs.com/itbuyixiaogong/p/9056918.html
  2. https://baike.baidu.com/item/%E6%95%8F%E6%8D%B7%E5%BC%80%E5%8F%91/5618867?fr=aladdin#8
  3. https://zhuanlan.zhihu.com/p/33472102
  4. https://www.bilibili.com/video/av22511095/?spm_id_from=333.788.videocard.0

 

 

2018-05-10 09:31:13 An1090239782 阅读数 3173
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13655 人正在学习 去看看 张传波



记录一些优秀的敏捷开发案例或经验:

敏捷开发:项目管理的一些思考
w_fsovereign:三个月(敏捷)项目收获
RobinsonZhang:敏捷开发入门



一、敏捷过程

敏捷开发是一种以人为核心,以迭代方式循序渐进开发的方法,其软件开发的过程称为“敏捷过程”。
在这一过程中,软件项目的构建被切分成多个子项目,各个子项目的成功都经过测试,具备集成和可运行的特征。
在2001年年初,一些业界专家成立了敏捷联盟,起草了敏捷软件开发宣言。该宣言针对一些企业的现状,提出了让软件开发团队具有快速工作、快速应变能力的若干价值观和原则,其中包括4个简单的价值观以及敏捷开发方法应遵循的12条原则。

1.1 敏捷开发的价值观

  1. 个人和交互胜过过程和工具。
  2. 可以运行的软件胜过面面俱到的文档。
  3. 客户合作胜过合同谈判。
  4. 响应变化胜过遵循计划。

1.2 敏捷开发应遵循的12条原则

  1. 通过尽早的、不断地提交有价值的软件来使客户满意。
  2. 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
  3. 以从几个星期到几个月为周期,尽快、不断地提交可运行的软件。
  4. 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
  5. 以积极向上的员工为中心,建立项目组,给他们提供所需的环境和支持,并对他们的工作予以充分的信任。
  6. 在团队内部,最有效、效率最高的传递信息的方法,就是面对面的交流。
  7. 测量项目进展的首要依据是可运行软件。
  8. 敏捷过程提倡可持续的开发,责任人、开发者和用户应该为能够保持一个长期的、恒定的开发速度而努力。
  9. 时刻关注技术上的精益求精和好的设计,以增强敏捷能力。
  10. 简单是最根本的。
  11. 最好的构架、需求和设计出于自组织的团队。
  12. 每隔一定时间,团队要反省如何才能更有效地工作,然后相应地调整自己的行为。

敏捷组织提出的敏捷开发模型的整体框架主要有三个:
Scrum、XP(eXtreme Programming)、OpenUP 这3个敏捷实践。



二、敏捷开发的原则

  1. 凝聚人的力量,紧密协(合)作。包括业务负责人、开发团队、客户、管理者之间的关系,所有这些关系在以前都是造成项目危机的原因之一,那么,在敏捷时代,我们需要这些角色 紧密合作,最大限度的发挥各个角色的力量.
  2. 聚焦客户价值,消除浪费(如何聚焦用户价值,即频繁的交付用户可工作的软件,快速收到用户反馈)

2.1 敏捷团队运作机制

  1. 一个团队有自己的代办事项,对代办事项进行拆小。
  2. 按客户价值进行优先级排序,产品经理负责价值排序。
  3. 小而稳定,跨职能团队。
  4. 多个团队松耦合(依赖性比较低),对齐迭代时间和战略目标。

2.2 关键的团队角色

  • 产品负责人
  • Scrum主管(流程主管)
  • 开发团队

2.3 产品负责人(Product Owner)

  • 负责管理产品backlog(代办事项)的唯一负责人
  • 代表客户/项目如责任人
  • 定义产品的所有特性
  • 负责产品的投入产出
  • 负责最大化产品和开发团队工作的价值

2.4 Scrum Master(流程主管)

  • 起到教练的职责,领导团队完成Scrum的实践以及体现其价值。
  • 排除团队遇到的困难,使得团队紧密合作,使得团队个人具有多方面职能的工作能力。
  • 确保团队能胜任其工作,并保持高效的生产率。
  • 保护团队不受到外来无端影响

2.5 关键的团队活动

  • 每日例会:每日5分钟左右的一个简单例会,尽可能多的开发人员参与进来对紧要问题的讨论。
  • 评审会:需要在迭代周期的最后一天召开,1个小时左右就可以了,需要客户出席,如果客户不能出席,则需要产品经理出席
  • 迭代回顾会:迭代回顾会是在每个迭代结束时进行,总结工作中的经验和教训,时间维持在30-60分钟内,整个团队都需要参加(Scrum Master、Product Owner、开发团队以及客户)。迭代回顾会包括两部分,第一部分是定量分析,第二部分是定性分析。其中定量分析又包含团队是否完成了迭代目标,收集并评审迭代度量指标(包括速率、迭代燃尽图、迭代计划故事和实际完成故事、计划发布日期与实际发布日期、客户满意度、团队满意度、生产环境Bug数、生产Bug解决时间、用户故事等)。定性分析包含哪些工作良好(应该继续保持),哪些做的不好(应该停止)?哪些可以改进(团队选出1-2条在下一个迭代实现)?

敏捷开发
作者:木可大大

三、敏捷团队的五个约定

3.1 约定1. 业务分析师们,我们其实是同一个角色的两种面孔,请叫上我们参加客户需求会议

我们的团队需要让客户频繁的得到可用的软件,客户的不断反馈会给软件的未来做出最正确的方向指引。

如果我们交付的软件有很多质量的问题,存在大量的缺陷,客户会被这些缺陷的奇怪行为干扰,没有办法把注意力放在软件本身的价值是否符合他们的真正需求上,
不能给出最有价值的反馈。所以,我们只有频繁的做测试,在每次交付之前都把质量问题找出来告诉我们的团队,问题才能及时的得到改正。

而我坚信“prevention is better than
cure”(预防胜于治疗),我会要把工作的重点放在预防缺陷上,这样可以节省Dev们很多修复缺陷的时间与精力。

为了达到这个目的,我需要跟你一起参加客户需求会议,尽早的了解客户需求与使用软件的惯常行为。那么在你完成需求的验收条件的定义的时候,我也基本完成了测试用例的准备。

我们可以赶在开发人员们写代码之前就告诉他们我要测什么,让他们减少因为过于乐观而漏掉的一些重要的有破坏性的情况,减少缺陷的发生。这是我测试的一项重要任务。

如果你们在大部分需求都整理好了再交给我们,我会浪费掉等待的时间。更重要的是,开发好的软件里面已经有很多本来可以不存在的缺陷在里面了,开发人员们可能需要加班加点来保证在项目最终交付时间之前把它们改好。这样很容易产生新的缺陷的。

所以,请让我尽早了解需求,请不要让我到项目后期才能开始测试。

3.2 约定5. 测试人员们,那些敏捷实践对于我们也是有用的。

如果你发现开发人员们做出的架构决定使测试工作变得更困难。那么请大声地告诉他们,design for testability(提高你们设计的可测性)。

如果你发现业务分析师写的需求无法验证,定义的客户行为不够具体,一个用户故事中包含太多了功能点,等等,那么也请大声地告诉他,INVEST(独立,可协商,价值,可估算,短小,可测)。

也请你们多跟开发人员结对写自动化测试,既可以帮助你们学习怎样更好的编写自动化测试,也能帮助开发人员们结对更多的了解用户行为。

我和敏捷团队的五个约定

四、敏捷开发的前置条件

4.1 比较固定的流程,文档,需求

  1. 需求是控制稳定性的根本,对于需求一定是整体可控的,并且是可以由迭代内进行调整的,而不是定死的
  2. 流程是指什么时间什么人该做什么事是高效的,明确的
  3. 文档是指每个流程阶段具有可交付或者可查阅参考文档,不是口头或者个人评定。

4.2 可灵活调整,允许试错

  • 检查

检查是指在每天的站会中检查每个人的工作状态,是否能完成自己的任务,存在什么问题,完成效果如何。另外就是保证整体在每天的进度,是否有有整体效果,如果没有完成今天的整体效果,需要检查是否符合整体迭代。

  • 调整

调整是指检查发现迭代的进度或者外界环境发生变化时,及时调整当前迭代的开发任务,保证迭代最终产物的准确及时性变动。当然,这种变动是不允许太多的,一般情况下在需求没有做详细分析时,不接受;在当前有风险的情况下,撤销某些需求;其他情况不做描述。

  • 试错

正是由于检查以及调整的策略,保证了迭代的灵活性,我们可以在敏捷团队中尝试一些较革新、新的功能点或者技术点,如果实验成功则可以对外拓展;如果不行,可以快速切换方案。

4.3 问题场景&&错误认识

  • 一个团队闭关开发一个项目就是敏捷

正确理解:敏捷不等于闭关,只是可能坐一起效率更高,其倡导的是何时都可以发生沟通,并准备一白板可以随时讨论方案;敏捷团队质量以及效率高于一般团队;敏捷团队开发的是以迭代为单位,不是项目;

  • 有了任务细分,开发白板,站会就是敏捷

正确理解:任务细分、白板、站会都是其形式,关键还是其将迭代的内容进行细化,可执行化,用高频的沟通反馈提高开发、沟通、理解的效率。

  • 敏捷团队没有特殊前置条件

正确理解:前面有讲到敏捷对团队,需求,文档,流程,调整等都有比较完整的规定。

  • 敏捷团队做的事情没有差别性

正确理解:敏捷完成的任务具有明细化,分阶段性,可调整性。所以在开发相关任务时,也具有类似的特点。

  • 敏捷团队会完整完美的交付产物

正确理解:敏捷在迭代结束只交付该阶段的可交付产物,很可能不完整不完美,对于可交付也有不同的理解。

2019-08-12 20:39:23 yjn1995 阅读数 761
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13655 人正在学习 去看看 张传波

前言

  

迭代开发

  敏捷开发的核心是迭代开发(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周。

敏捷开发的价值观

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

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

十二条原则

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

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

敏捷开发原则

阅读数 26

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