敏捷软件开发原则

  敏捷软件开发原则 ----《敏捷软件开发原则、模式与实践》学习笔记

最近在系统地学习并且有意地在工作中实践敏捷软件开发,文章乍看起来,都是一些说教性、理论性,比较无聊的东西。

  但是如果静下心来结合自己自身的经历、思考地去阅读,可能会发现,有的观点确实很赞同,然而有的可能会有自己的想法。

  以下是在《敏捷软件开发 原则、模式与实践》一些读书笔记,斜体字是直接摘录于书本,非斜体字是自己的一些理解。

 

一、尽早的,持续地交互有价值的软件来使客户满意。初期交付的系统功能越少,最终交付的系统的质量越好。逐渐增加功能的方式,经常地交付系统和最终质量之间有非常强的相关性。交付得越频繁,最终产品的质量越高。

关于交付对象,这里指的交付给客户,我们能做的不一定是交付给客户,还可以是提交给上级、开发、产品、测试同事看一下,看是否有不合理的地方,可以及时更正。如果等到差不多完了才交付,可能出现了问题也不好改了。

关于交付的时间点,可以是软件有一部分完整可以展示的功能即可。

二、欢迎需求的变化,即使到了开发后期,敏捷过程能够驾驭变化,为客户创造竞争力。

其实欢迎需求变化,个人觉得只是一种无奈、坦然的说法,有谁闲着没事希望天天改需求丫。这里的意思只是说,开发软件的时候,要努力的保持软件结构的灵活性,当需求有变化的时候,让系统改动最小化。

三、经常地交付可以工作的软件,从几个星期到几个月,时间越短越好,不赞成交付大量的文档与计划,我们关注的目标是交付满足顾客使用的软件。

这个和第一点是类似的,尽早、经常交互,尽早发现各自对需求理解的差异、集思广益地提出对系统改进的意见。之前在一个公司,开发提交代码到SVN,每天服务器会自动把提交的代码自动编译到开发环境,这样就可以很方便地看到最新的系统。好的工具和流程,对推动交付也是很有帮助的。

四、在整个项目开发期间,开发人员和业务人员必须朝夕在一起工作。客户、开发人员、利益的相关者,必须进行有意义的,频繁的交互。软件项目不像发射出去了,就能够自动导航的武器。必须对软件项目持续不断地进行导航。

 

五、依靠斗志高昂的人构建项目。给他们提供所需要的环境和支持,并相信他们能够完成任务。人是项目取得成功的重要因素,其他因素(过程、环境、管理等)都被认为是次要的,当他们对人有负面影响的时候,就要对他们进行改变。

对于这点的理解,我很认同强调人的影响,看重人的作用。过程、环境、管理,并不是没有用,也不是随便被抛弃,而是,不能够一成不变,要根据人的正确反馈,不断地被改进。因为,一定的规范、管理、约束并不是一开始就是最完善的,而且也不适用于所有的场景和项目。

六、在团队内部,最有效率,也是最有效果的信息传达方式,就是面对面交谈。书面文档会按照和软件一样的时间来编写和更新,但是仅在需要的时候才这样做。

 

七、可以工作的软件是进度的主要度量标准。仅当30%的功能可以工作时,才确定完成了进度的30%。

 

八、敏捷过程提倡可持续地开发。出资人、开发者和用户应该总是保持稳定的开发速度。敏捷项目不是50米短跑而是马拉松长跑。团队不是全速启动,并且在开发的时候保持这个速度,相反,他们以快速,但是可持续的速度进行。

项目开发前期,就死命加班,可能坚持不了几天就身心疲惫,这样的话对项目也不好,这样到后期可能变得很松散。不过在为了完成阶段性目标,做阶段性冲刺还是可以的。

九、对卓越的技术和良好设计的不断追求,有助于提高软件的敏捷性。高的产品质量是获得高的开发速度的关键。不要制造了混乱后,对自己说,等有更多的时间的时候再来清理它。今天制造了混乱就必须今天清理干净。

对于这点的理解,主要有两方面:

第一、对于,花不是很长时间就能改进的东西,不要想着下次有时间再改,因为,一方面,要相信程序员的时间永远都不够用,另一方面,下次来改,可能会生疏了,花费的成本会更大。

第二、快就是慢。不要为了赶进度,而忽略了产品质量,连自己的那关也过不了。否则和测试人员的反复交互,反而会使得效率更低,最终只是眼前快而已,进度最终反而变得更慢。

十、简单,尽量减少工作量的艺术是相关重要的。敏捷团队不会去构建那些华而不实的系统,他们总是更愿意采用跟目标一致的最简单的方法。

这里说的有三个层面的意思,第一,是投入与产出的问题。不要花很大功夫去开发一些对于实际应用没多大意义的功能;第二,是要多思考,看看有无更简单的方法实现需求;第三,对于系统不要过度设计。

十一、最好的架构、需求和设计都源于自我组织的团队。敏捷团队都是自我组织的团队,责任不是从外部分配给某个团队成员,而是分配给某个团队,然后由团队来确定履行职责的最好方法。每个成员都能够共同解决项目中涉及各个方面的问题。

在实际项目中,具体的工作可能由团队不同的人来负责。虽然,即使是某一项工作不是由自己负责,但是自己有责任去提供帮助和提出意见。

十二、每隔一段时间,团队都要总结如何更有效率地完成工作,然后相应调整自己的行为。敏捷团队应该知道所处的环境是不断变化的,而自己也应该随着环境一起变化。

以上十二个原则,有一个大的原则,就是强调人、团队和沟通的重要性。在日常的工作中,其实可能都在有意或无意地实践着这些原则。

在往后的工作中,将会有计划地实践一下以上十二个原则, 并且将实践过程、效果记录下来。

如果有人也有兴趣一起践行这些原则,欢迎一起督促、交流、探讨。

时间: 2024-10-08 00:10:16

敏捷软件开发原则的相关文章

敏捷软件开发:原则、模式与实践(笔记)

一.敏捷软件开发宣言 1.个体和交互 > 过程与工具 a)人是获得成功最为重要的因素: b)合作.沟通以及交互能力要比单纯的编程能力更为重要: c)团队的构建要比环境的构建重要. 2.可以工作的软件 > 面面俱到的文档 a)文档应该短小并突出主题: b)在给新的团队成员传授知识方面,最好的两份文档是代码和团队: c)直到迫切需要并且意义重大时,才来编制文档. 3.客户合作 > 合同谈判 a)成功的项目需要有序.频繁的客户反馈. 4.响应变化 > 遵循计划 a)构建计划时,应该确保计

[书摘]《敏捷软件开发: 原则、模式与实践》第一部分:敏捷开发

面向对象设计的原则 单一职责 开放-封闭 Liskov替换原则 依赖倒置原则 接口隔离原则 重用发布等价原则 共同封闭原则 共同重用原则 无环依赖原则 稳定以来原则 稳定抽象原则 人的重要性 交付产品的关键因素是人,而不是过程.(敏捷 Agile) 人与人之间的交互式复杂的,并且其效果从来都是难以预期,但却是工作中最为重要的方面. ------ Tom DeMacro 和 Timothy Lister<人件> 有凝聚力的团队将具有最强大的软件开发力量. 敏捷软件开发宣言 我们一直在实践中探寻更

读书笔记-敏捷软件开发 原则,模式与实践

看了一下夹在书中的发票,2010年在当当网购买的. 断断续续的也看过几次,一直没有看完过. 这次试着写写读书笔记.看看能不能坚持住.

敏捷软件开发 – OCP 开放-封闭原则

软件实体(类.模块.函数等)应该是可以扩展的,但是不可修改的. 如果程序中的一处改动就会产生连锁反应,导致一系列相关模块的改动,那么设计就具有僵化性的臭味.OCP建议我们应该对系统进行重构,这样以后对系统再进行这样那样的改动时,就不会导致更多的修改.如果正确地应用OCP,那么以后再进行同样的改动时,就只需要添加新的代码,而不必改动已经正常运行的代码. OCP概述 遵循开放-封闭原则设计出的模块具有两个主要的特征.它们是: 对于扩展是开放的(open for extension).这意味着模块的行

敏捷软件开发 – SRP 单一职责原则

SRP:单一职责原则  一个类应该只有一个发生变化的原因. 为何把两个职责分离到单独的类中很重要呢?因为每一个职责都有变化的一个轴线.当需求变化时,该变化会反映为类的职责的变化.如果一个类承担了多于一个的职责,那么引起它变化的原因就会有多个. 如果一个类承担的职责过多,就等于把这些职责耦合在了一起.一个职责发生变化可能会削弱或抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏. 有两个不同的应用程序使用Rectangle类.一个应用程序是有关计算几何

敏捷软件开发 – ISP 接口隔离原则

如果类的接口不是内聚的,就表示该类具有“胖”接口.换句话说,类的“胖”接口可以分解成多组方法.每一组方法服务于一组不同的客户程序. ISP承认有一些对象确实需要有非内聚的接口,但是ISP建议客户程序不应该看到它们作为单一的类存在.相反,客户程序看到的应该是多个具有内聚接口的抽象基类. 接口污染 考虑一个安全系统.在这个系统中,有一些Door对象,可以被加锁和解锁,并且Door对象知道自己是开着还是关着.这个Door编码成一个接口,这样客户程序就可以使用那些符合Door接口的对象,而不需要依赖于D

敏捷软件开发 – LSP Liskov替换原则

Liskov替换原则:子类型(subtype)必须能够替换掉它们的基类型(basetype). 违反LSP的情形 对于LSP的违反常常会导致以明显违反OCP的方式使用运行时类型检查.通常,会使用一个显式的if语句或者if/else链去确定一个对象的类型,以便于可以选择针对该类型的正确行为. struct Point { double x, y;} public enum ShapeType { square, circle }; public class Shape { private Shap

敏捷软件开发 – DIP 依赖倒置原则

DIP 依赖倒置原则 高层模块不应该依赖于低层模块.二者都应该依赖于抽象. 抽象不应该依赖于细节.细节应该依赖于抽象. 依赖于低层模块的高层模块意味着什么?正是高层模块包含了应用程序中重要的策略选择和业务模型.这些高层模块使得其所在的应用程序区别于其他.然而,如果这些高层模块依赖于低层模块,那么对于低层模块的改动会直接影响到高层模块,从而迫使它们依次做出改动.如果高层模块独立于低层模块,那么高层模块就可以非常容易地被重用.该原则是框架设计的核心原则. 层次化 糟糕的层次关系. 更为适合的模型.每

小议敏捷软件开发与传统软件工程

敏捷软件开发与传统软件工程 一.前言 随着社会和科技的不断发展,信息产业己经和人们的生活息息相关,成为不可或缺的一部分.软件工程作为信息产业的核心部分发生了翻天覆地的变化.传统的软件工程思想己经越来越不适应快速变化的信息社会,为此一种新软件工程思想-----敏捷软件开发进入了我们的视野. 二.软件工程 (一)概述 Software engineering is the application of engineering to the design, development, implement