敏捷开发-原则 模式与实践(1)

敏捷开发-原则 模式与实践

这的确是一本关于开发者的好书,对于我们开发者、研究人员,它提出了一个开发的全新的价值观(对我来说),甚至人生都有启发。需要认真阅读。

书中总结了敏捷开发的实例,确确实实更够感觉到对于项目的完成大有裨益,有种相读恨晚的感觉。想想自己之前的开发状态,想想自己导师安排公司项目的情况,就是低效率,就是小儿科,就是书上批评讽刺的那样,这正是开发者十几年开发智慧的结晶,前人的经验,前人的智慧,激发了我的阅读的快感,我获取知识的兴奋感,激发了我的成就感。

阅读前两天(结合思维导图)

敏捷开发联盟:开发团队需要具有快速工作、相应变化的能力的价值观和原则。

敏捷过程,最重要的是极限编程。

极限编程(extreme programming):一种适用于中小型团队在需求不明或者快速多变的情况下。(参考:http://www.docin.com/p-752508108.html

学到的新名词:

项目涉众:产品或项目相关所有人员,包括:客户、用户、需求分析员、开发人员、测试人员、文档编制人员、项目经理、法律人员、生产人员、市场营销、技术支持及其他与产品和客户打交道的人员。

用户素材:项目需要相关的卡片,包括估算代价、优先级

项目迭代:每两周实现一些涉众的需求,每次迭代完成时,会演示迭代生成的系统,获得反馈。

结对编程:结对的程序员,在同一台电脑上完成代码。

发布计划:一次发布大约需要3个月的时间,即约6次迭代。

QA部门:即quality assurance,质量保证部门。

UML图:统一建模语言,是用来对软件密集系统进行可视化建模的一种语言。

重构:重构(Refactoring)就是通过调整程序代码改善软件的质量、性能,使其程序的设计模式和架构更趋合理,提高软件的扩展性和维护性。

时间: 2024-08-24 02:25:25

敏捷开发-原则 模式与实践(1)的相关文章

为何Google这类巨头会认为敏捷开发原则是废话?

[编者按]这是一个来自Quora的问题.Rocket程序员Jasmine Adamson在文中表达了敏捷开发原则是废话的观点,他觉得现实生活中没有什么人会推崇这些原则来工作,不过他们仍然在说其所做的是敏捷,这是非常让人沮丧的. 以下为译文: 敏捷开发以用户的需求进化为核心,采用迭代.循序渐进的方法进行软件开发.在过去8年里,我一直工作于“Agile”开发小组,所以让我用敏捷开发原则来告诉你事实,或许你会明白为什么那些在像Google这样巨头公司工作的开发者会认为敏捷开发是废话. 1.及早并持续的

敏捷开发原则

尽可能早地提供宝贵的软件,不断满足客户需求 敏捷流程欢迎需求的变化,并利用这一变化来提高用户的竞争优势 经常发布可用的软件,发布间隔可以从几周到几个月,可以长或短 商业人士和开发人员应在项目开发过程中每天合作 为了项目核心人才,充分支持他们的信任 面对面沟通永远是团队内外沟通最有效的沟通方式 可用的软件是项目进展的关键指标 敏捷流程应该能够持续维持发展.领导,团队和用户应该能够继续合作 只有继续关注技术和设计,才能越来越敏捷 保持简单 - 尽可能简化工作的技能非常重要 只有自我管理的团队才能创造

敏捷开发原则-SRP(单一职责原则)

SRP(Single Responsibility Principle): 定义:就一个类而言,应该仅有一个引起它变化的原因.(类,接口,方法等,都应该使用该原则) 如果一个类承担了过多的职责,那么引起该类变化的原因也会随之变多. 例如: 一个图形类中包含了draw() 绘画功能和 area(), setWidth(), setHeight() 等图形自身的属性. 这样的话 如果图形属性的计算方式发生改变,则这个类就要做出对应的修改.同样的,如果图形的绘画功能做出改变 那么这个类也要同步的做出修

敏捷开发在实践中确实更加有效

在Scrum的方法里面,使用Sprint的一个方式,就是在构建产品的过程中,产品的设计和开发是逐步完善的,也就是说,产品并不是一次设计完成的,这里就有一个问题,Scrum是否适合于大多数的软件产品开发?相对于传统的方式,我们编码前是否需要一个完整的明确的代码的设计? 这里有两个例子可以考虑,如果我们要开发一个操作系统,或者是开发一个Office系列软件,我们能否使用敏捷开发的模式? 对于操作系统而言,Unix开发的哲学是最好的实践方法. Unix开发哲学中其中一点是,做一件事情,把它做好,这意味

敏捷开发是一个什么样的开发模式

在信息技术高速发展的今天,有很多的开发任何要求开发人员增量交付,迭代式开发,能够持续集成.很显然传统的瀑布开发模式已经不能满足需要了,于是,敏捷开发这种模式就出现了. 接触过敏捷开发的朋友可能会知道,敏捷开发有如下的价值观: 个体与互动 胜于 过程与工具,可工作软件 胜于 复杂文档 用户协作 胜于 合同谈判,响应变化 胜于 遵循计划 下面新霸哥将会用一个真实的案例的给大家讲讲敏捷开发. 每天早晨上班前一项重要的任务那就是晨会(由于时间很短,所以大家都是站立开会的),主要就是回报一下昨天自己的工作

利用敏捷开发的原则开发自己的大学生校园博客系统

  敏捷开发原则 我们的做法 1 尽早并持续交付有价值的软件以满足顾客需求 软件暂时未完成,但目前已经交付某些文档,可以通过文档与用户进行交互. 2 欢迎需求的变化,并利用这种变化来提高用户的竞争优势 不时向同学询问或自我思考看自己所要做的能否使大学生满意. 3 经常发布可用的软件,发布间隔可以从几周到几个月,能短则短 由于我们的项目是要求在一个月内进行交付,所以我们并没有进行软件的交付,但是我们每周都会交一些设计文档,对项目及完成进度进行说明. 4 业务人员和开发人员在项目开发过程中应该每天共

浅谈敏捷软件开发与传统软件工程的对比与敏捷开发产生的原因

引言 在"计算机程序的蛮荒时代",人们对于程序的设计.编写是随想随写.灵活变化的.正如我们初学各种编程语言时那样,似乎把程序写对也不是什么很难的事情.然而,这种程序设计模式或许适用于几百行至几千行的小程序,而当我们面对更大的软件规模.更多的代码行数以及更复杂的人员架构时,这种随想随写的程序开发模式似乎不再适用,于是使人们遇到了「软件危机」,进而促使了软件工程这样一门学科的产生. 在我上一门程序设计的课程的时候,老师讲过,当我们学习各种语言.算法和数据结构时,我们学习的是怎样进行&quo

软件工程的传统开发与敏捷开发

     引言 随着计算机的普及,软件工程成为了计算机产业中特别重要的一个产业.自从瀑布式开发模式提出之后,软件工程就走上了规范化的道路.随着软件工程的发展,逐步衍生出各种各样的软件开发模式.其中最受瞩目的就是敏捷开发模式.敏捷开发在短期的发展后,逐步从传统开发模式中脱离出来,逐渐占据了软件开发行业的半壁江山.本文从传统开发与敏捷开发的模式出发,对比敏捷开发与传统开发,浅析现代软件开发模式. 软件的传统开发 软件的传统开发具有悠久的历史,从20世纪60年代末开始提出软件工程这个概念,到如今传统开

敏捷开发的26条至理名言 快速迭代式开发使用方法总结

敏捷开发真正的问题是什么?其实敏捷主要还是一种观念,一种意识,通过人来推动. 本文总结了26条有关敏捷开发的关键原则,如何快速迭代式开发,供读者参考借鉴,以指引敏捷软件开发团队. 1.完整地干完一件事后在开始另一件事:用厨房比喻来说就是:"先上这道菜,再开始做下一道".软件开发的最大问题就是同时开始几件事情,这将不可避免的造成某些工作被废弃,从而造成浪费.专注于一件事:完整地实现其功能:运行测试:编写文档:签入所有,把这当做一项工作完成,然后再开始下一件事. 2.不要破坏构建:非常明显