2011-05-29 19:39:00 lxxlql 阅读数 1606
  • SCRUM敏捷开发视频教程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2017-11-12 23:16:16 mark_my_code 阅读数 204
  • SCRUM敏捷开发视频教程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2019-03-09 07:49:28 u013464787 阅读数 31
  • SCRUM敏捷开发视频教程

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

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

敏捷实践

敏捷原则

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

从上述的价值观引出了下面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 阅读数 139
  • SCRUM敏捷开发视频教程

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

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

目录

什么是敏捷

什么是敏捷开发

敏捷宣言

敏捷宣言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

 

 

2019-10-31 09:29:28 janeqi1987 阅读数 26
  • SCRUM敏捷开发视频教程

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

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

原则1:最优先要做的是尽早、持续地交付有价值的软件,让客户满意。

这条原则包含了三个独立的重要概念:尽早发布软件、持续交付价值,以及让客户满意。

    客户在真正拿到可工作的软件之前,都很难想象软件到底应该如何工作。这样说来,既然客户只有在看到了可工作的软件之后才可能给你真实有信息量的反馈,那么获得反馈的最佳方式就是尽早交付(early delivery):尽早给客户交付第一个可工作的软件版本。即便是只交付了一个可以工作的特性给客户使用,这也是一种突破。这对整个团队都是有益的,因为客户可以给出有价值的反馈,这样开发团队才能朝着正确的方向推进敏捷原则项目。这对客户来说也是有益的,因为拿到了软件就可以使用。也就是说,开发团队实际交付了真正的价值。尽管只是一小部分价值,但是比到最后一点价值都不交付要好,特别是在客户因为等了很长时间还没有看到软件而越来越愤怒的情况下。

真正与客户协作的团队可以在开发过程中任意进行任何有必要的改变。这就是持续交付(continuous delivery)的意义所在。

    敏捷方法通常采用迭代,原因就在于此。敏捷团队选择出能交付最大价值的特性和需求,并据此计划项目的迭代。团队确定哪些特性能交付价值的唯一方法就是与客户协作,并利用前一次迭代收到的反馈。从短期看,团队可以通过尽早交付价值让客户满意,从长期看,交付最终产品的时候可以实现价值最大化。

原则2:欣然面对需求变化,即使是在开发后期。敏捷过程利用变化为客户维持竞争优势

欣然面对需求变化的第一步是尝试从客户的角度看问题。

    客户最初提出的需求有了变动,实际上客户承认自己犯了错误。尽管开发团队不能按期交付产品,客户也是一样不能按时使用新变化的产品特性的,如果新需求能够产生客户需要的价值,那么这个项目需求的改动就可以产生价值。而不是你开发出来的产品特性不是客户想要的需求,导致产品没有价值。

欣然面对需求变化意味着什么呢?它意味着以下几点:

• 不要认为有变化就会有人“倒霉”。允许犯错并及时发现问题及时得到解决。

•  开发团队和客户都是一条绳上的蚂蚱。客户和开发团队都对需求的变化负责,需求的错误对开发团队和客户同样严重,抱怨没有任何意义。

• 我们不把变化拖到最后。尽早修复错误,才能把损失降低到最低。

• 我们不要再把变化当成犯错。根据当时的信息,我们已经尽力了,出了错事情才会变得更加明朗,让我们看到现在必须如何改变决策。

• 我们通过变化学到东西。这是团队成长的最有效方式,也是团队学会更好地合作开发软件的最有效方式。

原则3:频繁交付可工作的软件,从数周到数月,交付周期越短越好

    团队通过每一轮迭代,发布可工作的软件。每一轮迭代结束时,回顾、探讨本轮迭代的过程并吸取教训,并且通过客户的尽早反馈(需求变化或本次交付的某些特性不满足客户需求等)进行可预测的进度安排,让团队尽早掌握变化,把接下来一轮迭代中最有价值的特性优先开发。所以,欣然接受变化的同时不引入混乱的关键,在于频繁发布可工作的软件。

原则4:在团队内外,面对面交谈是最有效、也是最高效的沟通方式

    面对面的沟通让大家的思考方式保持同步,用同样的方式去看待世界,而且都能开放地讨论正面和负面的想法,那么大家最终会有一致的视角。如果此时发生了一个变化需要重新思考,团队成员不需要花时间互相解释。

    团队沟通的终极目标是形成一种集体意识,在成员之间建立不必直说也能领悟的共同知识,因为反反复复解释同样的事情实在太过低效。如果没有集体意识,团队中不同职责的人需要付出更大的努力才能匹配视角。一个团队越能形成集体意识,越能共享同样的视角,就越容易对同样的问题形成一致的答案。这就为团队构筑了处理变化的坚实基础,可以跳过冲突,立即编写代码,而且不会因为维护文档而分心。

原则5:在整个项目过程中,业务人员和开发人员必须每天都在一起工作

    当业务人员和开发人员同在团队中开发软件的时候,最有效的方法是让他们在项目完整周期内每天坐在一起工作。业务人员及时检查开发团队的工作并给出反馈,业务人员也能及时给开发人员解答业务问题。这样修改的成本就很低。从整个项目的过程来看,每天与开发团队一起工作,每个业务人员的实际时间开销要少得多。这也是频繁发布可工作软件的开发团队应该把最有价值的特性优先开发的原因,这样的话,业务人员就可以第一时间享用到这些价值。敏捷团队与传统团队存在这样巨大的差异:传统的开发团队把业务用户看作是要谈判的客户;而敏捷团队则是与客户(通常是产品所有者)合作,在项目执行的时候客户具有平等的发言权。(这就印证了“客户协作高于合同谈判”的敏捷核心价值观!)

原则6:以受激励的个体为核心构建项目,为他们提供环境和支持,相信他们可以把工作做好

    如果公司里每一位同事都意识到团队开发的软件是有价值的,而且团队中所有人(包括产品所有者)都能理解软件是怎样为公司创造价值的,那么项目就可以以最佳状态运行。

    常见的情况是,公司绩效审查机制和补偿制度不利于员工采用高效的敏捷方式开发软件,这些做法对项目无益。这背后的问题往往包括以下几点。

• 在代码审查中,如果不断发现bug,程序员就会获得糟糕的评价,如果没有发现bug,程序员就会获得奖励。(这会导致程序员在代码审查中不愿意找bug。)

• 根据发现的bug 数奖励测试员。(这会导致测试员挑刺并降低报告质量。这种方式给程序员和测试员之间设置了敌对关系,会阻碍测试员和程序员之间的合作。)

• 根据业务分析员产出的文档量判定其绩效评级(而不是根据他们与团队分享的知识量评级)。

    最终,所有人的绩效都应该根据团队交付的成果来评定,而不是根据每个人自己的角色来判定。对于一个团队来说,好的环境会奖励下面几种人:认识到软件并没有解决的某个业务问题并将其修复的程序员,以及能够发现代码或架构中的问题并提交给团队的测试员。在持有同甘共苦态度的敏捷团队中,每一位成员都对项目有责任感,并且为项目的成功与否负责。

原则7:可工作的软件是衡量进度的首要标准

    状态汇报很难获得项目的真正状态。汇报本身就是一种不完美的沟通工具:也许有三个人读的是完全相同的状态汇报,但他们往往对项目进度持有完全不同的理解。此外,对于项目经理来说,状态汇报也会有极强的政治色彩。几乎所有的项目经理都有过这样的巨大压力:有时候需要在状态报告中略去一些会让经理和团队主管难堪的东西,而别人常常需要用这些信息进行决策。如果状态报告并不够好,进度该怎样汇报呢?答案就在可工作的软件中。只要真切地看到了软件在眼前工作,那么你就“得到了”项目的进展。你可以看到软件实现了什么,以及没有实现什么。如果经理承诺了要交付的功能没有

在软件中,那会很难堪,但是又不可能不去沟通这个问题,因为软件本身就足以说明问题。

可工作的软件可以更好地给所有人汇报项目最新进展,因为这是团队用来交流当前已经完成工作的最好方式。

     敏捷团队使用迭代式开发有这样一个理由:在每一轮迭代结束的时候交付可工作的软件,通过真实的产品向大家展示具体成果,团队可以让大家掌握项目进展的最新情况,而且这种方式几乎不可能会让人产生误解。

原则8:敏捷过程倡导可持续开发。赞助商、开发人员和用户要能够共同、长期维持其步调,稳定向前

    保持团队最高生产效率的方法就是:保持可持续的开发节奏,不要逞强,不要匆忙赶工,避免加班。

    硬性的截止时间是命令− 控制式的工具,是不切实际的截止时间。从长远来看,这种做法是不可靠的。众所周知,一个团队可以拼命工作几个星期干更多的活,但是团队的工作效率一般都会在这段时间过后一落千丈。这是有道理的:人们都会感到疲劳并且失去动力。为了加班,他们推掉了很多重要的公事和私事,然而最终这些事情总是会重新找上门来的。实际上,那些严重加班的团队不会比正常工作的团队交付更多实质工作,而且往往工作质量更糟。

    敏捷团队信奉的是维持可持续的开发节奏。他们会针对预留的时间制订切实可完成的计划。通过迭代式的开发,这种计划的可行性很高,因为预估接下来两周、四周或六周的工作量远比预估未来一年半的工作量要简单得多。因为只承诺交付能开发的内容,所以团队不会动不动就加班到深夜或周末。

    如果团队采用迭代式开发方法,不断交付可工作的软件,那么大家就可以对每一轮迭代制订计划,从而保持一个可持续的开发节奏。通过更简单、更适时的方法设计出来的架构更灵活更可扩展。如果团队使用了更好的设计、架构和编码实践,那么就可以开发出更易维护和扩展的代码。

原则9:坚持不懈地追求技术卓越和设计优越,以此增强敏捷的能力

    从长远来看,避免bug 比过后修复bug 要快得多。设计良好的代码维护起来也要简单得多,因为其开发方式易于扩展。敏捷团队在每一个软件项目开始的时候并不意味着要花大量时间进行大规模的设计。敏捷开发人员会培养起非常好的编程习惯,从而帮助自己编写设计良好的代码。他们不停地寻找设计和代码的问题,一旦发现问题,立即将其修复。在项目的开发过程中,只需要在当下多花那么一点点时间编写可靠的代码并及时修复问题,那么留下的这份代码库在未来就会非常好维护。

原则10:简单是尽最大可能减少不必要工作的艺术,是敏捷的根本

    敏捷团队避免开发不必要的特性以及过于复杂的软件,保证给出的解决方案尽可能简单。

    在已有项目中添加代码会让项目变得更复杂,如果还继续添加更多依赖这些代码的代码,项目会变得尤为复杂,会产生多米诺骨牌效应。采用迭代式开发以及在项目初期将文档量控制到最小,可以帮助你的团队避免交付不必要的软件。

    在软件项目中,最有破坏性的事情就是编写代码,然后编写更多依赖这些代码的新代码,再然后再编写更多进一步依赖的最新代码。代码的连锁变化会产生可怕的多米诺效应,最终出现一大堆无法维护的意大利面条式代码。

    把待定的工作最大化可以避免这种困境,而最好的实现方式就是开发没有太多依赖和不必要代码的系统。而要实现这个目标最有效的方式就是与你的客户以及利益干系人在一起工作,确保只开发最有用且最有价值的软件。如果某一项特性没有价值,那么对于公司来说,更节省成本的方法就是根本不要开发这项特性。为维护这些代码而产生的成本往往比这项特性给公司带来的实际价值要高。编写代码的时候,如果团队可以基于一些只实现单一功能的小型自包含的单元(例如类、模块和服务等)进行设计,那么这个团队就可以避免多米诺骨牌效应。

原则11:最好的架构、需求和设计来自自组织的团队

    自组织的团队对项目的所有方面都负有共同的责任:从产品构思到项目管理到项目的设计和实现。

    自组织的团队(self-organizing team)并没有明确的需求和设计环节。自组织团队会用合作的方式对项目进行规划(而不是依赖某个“负责”计划的人),而且会持续地作为一个团队改进计划。采用这种工作方式的团队通常会把项目分解为多个用户故事或其他类型的小块,从能够给公司带来最大价值的块着手,然后再考虑详细的需求、设计和架构。

    在敏捷团队中,所有人都对架构负有责任。尽管高级软件架构师和设计师仍然很重要,但是他不再孤立工作。实际上,如果团队从最重要的分块开始逐块构建软件,那么架构师的工作会更有挑战性(而且也更有意思):敏捷团队不会在一开始就创建一个覆盖所有需求的大设计,而是采用增量式的设计,这就要求设计的系统不仅完整,而且还在项目变化的时候方便团队修改。

原则12:团队定期反思如何提升效率,并依此调整

    敏捷团队在每一轮迭代结束的时候和项目结束的时候会花时间总结过去,讨论总结经验,提高开发软件的能力。

    敏捷团队会不断地检查并调整,成员会检查自己项目运转的方式,并通过检查的结果对未来进行改进。增强团队实力的唯一方法就是经常回顾自己已经做的事情,然后评估作为一个团队这些事情做得怎么样,最后提出能改进的计划。如果在开始每一个项目的时候,给每一轮迭代以及每一个项目的收尾阶段预留了开会时间,总结并评估已经完成的事情,而且制订出改进计划,那么团队更有可能真正地坐在一起讨论他们已经完成的事情。这样可以从经验中吸取教训,提高效率。

敏捷开发

阅读数 767

敏捷的12条原则

阅读数 3603

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