2010-08-12 16:44:35 jardownload 阅读数 42
  • SCRUM敏捷开发视频教程

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

    10431 人正在学习 去看看 CSDN讲师
1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2.即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3.经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
4.在整个项目开发期间,商务人员和开发人员必须天天都工作在一起。
5.围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。
6.在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。
7.工作的软件是首要的进度度量标准。
8.敏捷过程提倡可持续的开发速度。责任人(sponsors)、开发者和用户应该能够保持一个长期的、恒定的开发速度。
9.不断地关注优秀的技能和好的设计会增强敏捷能力。
10.简单——使未完成的工作最大化的艺术——是根本的。
11.最好的构架、需求和设计出自于自组织的团队。
12.每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。
2016-11-04 18:30:40 moonpure 阅读数 955
  • SCRUM敏捷开发视频教程

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

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

敏捷开发真正的问题是什么?其实敏捷主要还是一种观念,一种意识,通过人来推动。

本文总结了26条有关敏捷开发的关键原则,如何快速迭代式开发,供读者参考借鉴,以指引敏捷软件开发团队。


1、完整地干完一件事后在开始另一件事:用厨房比喻来说就是:“先上这道菜,再开始做下一道”。软件开发的最大问题就是同时开始几件事情,这将不可避免的造成某些工作被废弃,从而造成浪费。专注于一件事;完整地实现其功能;运行测试;编写文档;签入所有,把这当做一项工作完成,然后再开始下一件事。

2、不要破坏构建:非常明显,但必须被包含在任何软件开发建议清单中。程序员在签入之前采取所有合适的预防措施进行测试,则永远不会破坏构建。如果构建被破坏,通常是因为有人偷懒了。

3、在用例需要之前,不要实现程序:当你实现一个特定的类,你应该在脑海中有一个特定的用例,同时应该只实现用例需要的方法。你可以考虑该类潜在的功能,写入注释之中,但直到用例真正需要时,才应去实现它。

4、在用例需要之前,不要添加数据成员:同上一条,不过这是从类的数据成员角度考虑的。似乎显而易见地,“客户”记录需要“送货地址”,但直到有用例明确需要送货地址,才应该实现它。

5、不要害怕做决定,不要害怕改变先前的决定:敏捷开发是关于相应变化和快速相应的。开发初期,你没有完整的信息。你应该尽可能的推迟决策,直到你必须做出决策的时候。没有信息,无法支持你的决定,相反,在有效信息的基础上做出最佳决定。有了新的信息,不要害怕改变先前的决定。(某些“恐龙”称之为摇摆不定,但我称之为响应变化的环境)

6、持续学习如何改善质量:这项工作永不会结束,因此你应经常留意可以改善的事情,并收集质量问题被确认和处理的案例。

7、度量、度量、度量:敏捷开发帮助处理未来不确定性问题,但对于过去应没有不确定性。测试应持续运行,每次运行的性能表现应被度量和记录。

8、为人而设计,而不是系统:开发者常常因技术而使设计误入歧途。绝不要忘记设计的最终目标,那就是帮助人们完成工作。

9、测试是产品的一部分:很多开发者和经理认为产品就是交付给客户的东西,而其它所有东西都不那么重要。测试应被认为是产品实实在在的一个部分,值得在设计时仔细考虑,甚至,在很多情况下,和产品一起交付给客户。(后半部分有争议,但是内建测试作为软件交付的一部分仅仅占用无关紧要的空间,却在必要时提供显而易见的好处,这种方式应该被考虑。)

10、在代码之前编写测试:测试本身可以用来阐释真正需要的设计。设计的缺陷常常是通过测试用例被发现的。想想看,编码之前,通过这些用例,可以节约多少时间。但是,为用例1编写测试,然后编码,然后再开始用例2。

11、消除浪费:坦率的说,这是另一个必须包含在任何开发原则清单中的陈词滥调,因为它太重要了。发现浪费并消除它,这项工作没有尽头。消除任何不能增加客户价值的东西。如果你不能确认客户价值,那很可能你并不需要它。

12、建立对构建破坏立即响应的文化:要明白当构建被破坏,会影响项目中的每一个人,因此,最重要的是确认核心代码被构建并合理测试。我曾见过有些团队放任失败测试持续数月,因为那是其它人的工作。每个人都痛苦,但没人采取行动。想反,必须形成共识,那就是小工作能为团队获得大的回报。

13、所有团队成员应理解客户需要:大型的复杂项目定然被分解为独立的团队,进而被分派给开发人员。但是,不应在此范围内做的是,失去关注最终项目真正用户的期望和目标。

14、把相关定义放在一起:组织代码以使高度相关的事情在一起,或在一个类中。这是标准面向对象设计封装原则。理想情况下,所有的类外的代码不需要知道内部工作细节。一些开发者乐于将细节扩散到多个文件中以便按不同方式组织,如所有相同的数据类型放在一起,或者按字母顺序组织。例如,在他们要用的不同包中,将所有常量放在一个类里,这增加了不必要的程序复杂性。指导原则应该是按相关性分组从而隐藏复杂性。

15、始终在签入之前运行测试:这条准则帮助你满足“不要破坏构建”准则。

16、过早的优化时万恶之源:引用高德纳被证实的话:代码应编写良好以避免微观层面的浪费,但独立方法层次以外的优化应等待整个程序基于真实的最终用户使用情景的压力测试的进行。仅仅基于对代码的静态理解,直觉地判断对整体性能什么是重要的,结论几乎总是错误的。相反,度量整个系统的行为,辨别1%真正影响性能的代码,并专注于此。

17、减少积压未完成的编码任务:当开发人员开始一个用例,会发生成本,跟已修改却未完成和测试的代码相关联。留着未完成的变化几天或几个星期会累积成巨大的重做风险。考虑每个估算需要一天的三个任务,同时开始这三个任务,并在3天内同时进行,意味着9个单位的累计成本。但是顺序进行每个任务,完成一个再开始下一个,意味着只有3个单位的成本。这个不是直觉,直觉告诉我们,在工作完成之前,我们不妨同时做三件事情。但软件不像物理构造。短小,快速和完整的工作不仅减少认知的负担,而且减少未完成工作与他人未完成工作之间冲突的可能。

18、不要过度强调代码的通用性:这就是著名的“YAGNI-你不会需要它”。当编写一个特定类的时候,程序员总喜欢认为该类可能用于其它用途。如果现在的用例需要这些用途,这很好,但是,程序员经常考虑未被提及的用途,或者那些实际上永远不需要的。(这常常让我联想到经典的周六现场滑稽短剧,关于某产品既是地板蜡,也是糕点上的甜食。)

19、两行代码能行,就不要用三行:有人阅读时,简洁的代码总能获得回报。但不要将代码压缩到难以阅读。更小的,编写良好的代码比之冗长的,编写华丽的代码更容易维护,也更容易发现错误。始终尽可能简化,但别过分。

20、不要用行数来度量代码:完成特定任务所需的代码行数,不同的程序员之间和编码风格之间差异很大。代码行数不能告诉你代码完成和质量的些许东西。代码质量可以相差200倍,这足以抵消代码行数的作用。应该统计功能用例的数目。

21、持续地重新设计和重构:谨慎地使用这条准则,因为有些代码脆弱而难以改变,但通常你不应害怕更改代码以符合实际使用情况。一个数据成员过去可能是整数,但是当一个用例要求它是一个浮点数时不要害怕去改变它。

22、删除死代码:涉及到大量不能很好理解的代码是,有个倾向是不自找麻烦。一个例子就是往类中增加新的方法去替换另一个,开发人员常常会留下旧的方法以防万一。必须努力检查方法是否必须,如果没有证据表明它是必须的,那就删除它。最糟糕的就是注释掉大量的代码,并把它留在那儿。注释掉的代码应在测试通过后尽快删除,当然应在签入之前。因此,某个时候你发现一些东西可能并不需要,付出小小的努力去验证并消除此代码能让代码基线更易维护。

23、不要发明新语言:程序员喜爱使用文本文件配置在运行时驱动功能。没有配置文件能够不编译而改变程序的行为。XML的出现推动了无休止的专门定制“脚本语言”的浪潮,以使功能能被最终用户定制而不需要编译。这种推理的缺陷在于,离开某个特定实施的环境,操作行为几乎从来没能很好地精确定义,同时,那些脚本语言只对那些对问题领域代码的内部运行有深入了解的人有用。因此,不具备详尽内部知识的真实最终用户永远不可能知道预料复杂的命令组合的效果需要什么。脚本语言有用,也不能被消除,但是设计者必须采取非常非常保守的态度,尽可能使用现有的语言,避免新的发明。

24、在你准备实现并测试前,别做设计:你应该有行进的总体思路和对系统架构的概览,但是,直到开发迭代允许设计被实现和测试前,不要做详细设计,不要编写功能实现的详细说明。详细设计应当只涉及到处理目前的用例。软件开发中最大的浪费源于将时间花在设计那些不需要,或者因为某些错误的设计假定而需要重新设计的事情之上。

25、设计是可塑的:不像物理制造,软件可以很容易地获得显著改变。事实上,有大量证据证明软件本身比描述软件的设计说明书更容易改变。此外,软件比说明书更有效地传达设计。因此,你应该把时间用于直接实现设计,让客户能看见设计的细节。如果你犯错并改变设计,改变软件比改变规格更容易。但最重要的是,客户看到代码运行后,你关于客户想要什么的信息大为完善。

26、花时间编写发现和报告异常情况的代码中的问题的完整描述:程序员往往很懒惰,抛出粗浅描述错误的异常。认为他们永远是唯一会看到这个问题的人,并且他们从含糊的描述会记得这个问题的意思。但实际上,在客户支持环境,不准确或者不完整的错误报告比其它原因浪费更多的时间。编写每个错误消息,就好像你正向某个正好走进房间并且没有此代码经验的人解释状况。客户和客户支持团队毕竟没有此代码的经验。

这些介绍没有特定的顺序,欢迎留言讨论我忽略的原则,或者(如果是这种情况)你不认同的敏捷开发原则
2008-03-25 13:41:00 wingfeng19800215 阅读数 517
  • SCRUM敏捷开发视频教程

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

    10431 人正在学习 去看看 CSDN讲师
敏捷软件开发的原则

我们遵循以下的原则:
1. 我们最先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。
2. 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3. 经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
4. 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
5. 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。
6. 在团队内部以及团队之间,最有效果并且最富有效率的传递信息的方式,就是面对面的交谈。
7. 可以工作的软件是首要的进度度量标准。
8. 敏捷过程提倡平稳的开发。
9. 发起人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
10. 不断地关注优秀的技能和好的设计会增强敏捷的能力。
11. 简单——使未完成的工作最大化的艺术——是根本的。
12. 最好的架构、需求和设计出自于自我组织的团队。
13. 每隔一定的时间,团队会在如何才能更有效地工作方面进行反省,然后相应地调整自己的行为。

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

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

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

重构

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

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

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

2017-09-06 22:36:56 realDonaldTrump 阅读数 143
  • SCRUM敏捷开发视频教程

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

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

敏捷开发原则

  1. 不要为代码添加基于猜测的、实际不需要或并不一定需要或目前暂时不需要的功能。
  2. 如果不清楚一个系统是否需要某个功能或采用某种设计结构,则一般不要急于去实现它或急于去采用这种设计模式。
  3. 实际上,通过重构来完成新功能或新设计模式并不困难,只有在确认某个功能必需或需要某个设计模式的时候,添加的功能或重构使用的设计模式才有意义。
没有更多推荐了,返回首页