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

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

    10408 人正在学习 去看看 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:团队定期反思如何提升效率,并依此调整

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

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

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

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

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

重构

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

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

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

2007-02-28 20:58:00 heyang22118952 阅读数 727
  • SCRUM敏捷开发视频教程

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

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

敏捷开发原则

 

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

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

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

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

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

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

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

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

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

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

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

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

2015-04-10 20:50:14 c1990h 阅读数 87
  • SCRUM敏捷开发视频教程

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

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

【编者按】这是一个来自Quora的问题。Rocket程序员Jasmine Adamson在文中表达了敏捷开发原则是废话的观点,他觉得现实生活中没有什么人会推崇这些原则来工作,不过他们仍然在说其所做的是敏捷,这是非常让人沮丧的。

以下为译文:

敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在过去8年里,我一直工作于“Agile”开发小组,所以让我用敏捷开发原则来告诉你事实,或许你会明白为什么那些在像Google这样巨头公司工作的开发者会认为敏捷开发是废话。

1.及早并持续的交付有价值软件来满足客户需求的优先级是最高的。

“我的客户一直由其他业务部门接洽,我从未见过我的客户,我不知道他们是做什么的。”这是现如今大多数公司的真实写照。

2.欢迎需求变更,即便是在开发的后期。为了客户的竞争优势。

没有人愿意接受改变需求。这就是第二个敏捷原则,普遍被厌恶的一个。

3.频繁交付软件,倾向于较短时间跨度。

部分公司在这方面做的很好,但是大多数团队无法很好的掌控敏捷时间的尺度。交付时间表通常是基于大的更新,而大更新不属于敏捷。

4.业务人员与开发者的绑定模式一直贯穿项目始末。

开发者和业务人员一起工作是罕见的,大多数公司都会有一个中间人来促进这种关系,然后效果是不理想的。开发者需要直接对话的应该是直接使用程序的人,而不是他们的经理。现实生活中的需求往往是由几个个层次以外的人来决定,而不是直接从用户到开发者那来的。

5.激发个体的斗志,以他们为核心创建项目——大多数人都不知道这表达了什么。

这意味着低水平的员工对软件有最好的注意,并且他们积极的去解决问题。项目围绕这些欲望来构造,而这也了直接影响公司的底线。

5a.为他们提供所需的环境和支援,辅以信任,从而达成目标。

这是关于开发者的,你曾经有过这样的工作环境吗?你所需要的工具、访问权限和配件都有。或许不用多说什么了,不是吗?

6.不论团队内外,传递信息效果最好、效率也最高的方式是面对面交谈。

这句话的意思是告诉我不能用IM和邮件来交流吗?如果团队的成员分散于各地呢?我改进现有软件的最有效方法是站在某人后面看他使用。然而在大多数公司中,你做不到这样,即便你知道客户是谁。他们也是忙的无暇顾你,也有可能是其他原因。现如今的人际交往不再像从前那样。不是吗?

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

我们所在测量的都是类似于缺陷率、工作时间等事情,几乎从来没测量过这些事项:顾客得到可工作的功能了吗?我们发布了多少个可工作的功能?这些功能是大、中还是小的?没人知道。

8.敏捷过程倡导可持续开发。负责人、开发者和用户要能够共同维持其步调稳定延续。

这意味着每个人每周都要花30个小时在开发上,还需要花10个小时管理自己和工作负载、与他人沟通等等。这样才能保证这种做法持续下去。更多公司所做的是不定时的加班,有的则是经常加班。这是不可持续的。敏捷模式很少进入这样的紧急模式,而你则是经常性的。

9.坚持不懈的追求技术卓越和良好设计,增强敏捷能力。

在我看来这是对原则1和7的正确权衡。

10.以简洁为本,极力减少不必要的工作量

坦白来讲,大多数团队并没在这上面花费足够多的时间,我们最终不仅复杂了软件,也复杂了开发习惯、复杂了代码,这减缓了维护和新开发。

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

团队是由管理层组织的,几乎没有他们自己的事。不过这只是一个企业文化的问题,并很难被克服。有时在初创公司和小公司你可以发扬这种原则并让其工作,但是在大多数大公司,还是算了吧。

12.团队定期地反思如何能提高成效,并以此调整自身的举止表现。

这更多地算是一种常见的绩效考核形式,没有我们真正想要的层面。敏捷想要的是“作为一个团队,一起坐下来看看我们做了什么,如何在下一次做的更好”。然而实际上所发生的是个人主观上的计算和测量,基于这些团队几乎得不到任何实际的改进。

所以说敏捷是废话,因为没有人会推崇这些原则来工作,不过他们仍然在说其所做的是敏捷,这是非常让人沮丧的。

敏捷方法存在很多废话,但是同样的废话也会存在于新的软件开发中,从面向对象到面向服务的体系结构等等。一个真正的敏捷方法不适用于紧急状况,更多的是为了产品创新。如果作为准备,他可以改变整个组织,Salesforce从2007年就开始使用Scrum,这使它们能够创建一个可预测的发布周期。并因此而创建越来越多令人印象深刻的功能和产品。

需要明确的是,敏捷方法不是良方,有能力的人、勤奋、专注和自律造就优秀的软件开发。

极客头条正式开通了微信公众号,刊选每日精华内容和最新的资讯文章,在微信搜索“csdn_geek”或扫描下方的二维码:

http://img.my.csdn.net/uploads/201504/10/1428669801_7994.jpg

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

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

    10408 人正在学习 去看看 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周。

敏捷开发的价值观

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

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

十二条原则

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

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

浅析敏捷开发

阅读数 137

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