https://www.cnblogs.com/imyalost/p/7653574.html

一、敏捷软件开发宣言

个体和互动高于流程和工具

工作的软件高于详尽的文档

–注重产品本身,而不是形式和流程,文档应简洁易阅读,方便维护和同步

客户合作高于合同谈判

–主动拥抱变化,及时响应,持续交付

响应变化高于遵循计划

–制定可实现的短期清晰的目标,中期的粗略的计划,长期的大方向有大概目标即可

 

二、敏捷宣言遵循的原则

1、我们最重要的目标,是通过持续不断的及早交付有价值的软件使客户满意。

–持续交付,快速迭代

2、欣然面对变化,即使在开发后期也一样,为了客户的竞争优势,敏捷过程掌握变化。

–敏捷更多适用于互联网企业,移动端更甚,一个机会的存在期可能短的可怜,应尽量保持软件的灵活性,减小对系统造成的影响

3、经常交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。

–尽早的、经常的交付可工作的满足需求的软件,在Google,甚至可以做到每天交付一个可工作的软件,即beta版本

4、业务人员和开发人员必须互相合作,项目中的每一天都不例外。

–及时沟通,避免信息断层,减少延时,随时调整

5、激发个体的斗志,以他们为核心搭建项目,提供所需的环境和支援,辅以信任,从而打成目标。

–过程和方法对于项目的影响只有次要的影响,首要的影响是人

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

–邮件听不了语气,语音看不到表情,面对面沟通是最高效的办法

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

–最终产出物是可工作的软件,so,快速迭代交付的重要性不言而喻,这也是衡量一个项目进度的重要的element

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

–目标清晰,设定可实现的短期的详细的目标,当然这种步调需要长时间的培养和锻炼

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

–拒绝平庸,追求卓越,良好的设计能减少很多工作中后期的麻烦,比如技术负债!

10、以简洁为本,它是极力减少不必要工作量的艺术。

–轻文档,轻流程,重产出,重目标

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

–想起一句话:管理的最高境界是为共同的目标,整个团队共同承担责任,而不是单一职权负责制

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

–不断思考总结,调优,减少不必要的资源消耗

 

三、面向对象设计原则

SRP:单一职责原则

   就一个类而言,应该仅有一个引起它变化的原因。

OCP:开放封闭原则

   软件实体(类、模块、函数等)应该是可扩展的,但是不可修改。

LSP:Liskov替换原则

   子类型必须能替换掉他们的基本类型。

DIP:依赖倒置原则

   抽象不应该依赖于细节,细节应该依赖于抽象。

ISP:接口隔离原则

   不应强迫用户依赖于他们不用的方法,接口属于用户,不属于它所在的类层次结构。

REP:重用发布等价原则

   重用的粒度就是发布的粒度。

CCP:共同重用原则

   一个包中所有的类应该是共同重用的,如果重用了包中的一个类,那么就要重用包中的所有类,相互之间没有紧密联系的类不应该在同一个包中。

CRP:共同封闭原则

   一个包中所有类对于同一类性质的变化应该是共同封闭的,一个变化若对一个包影响,则将对包中的所有类产生影响,而对其他包不造成任何影响。

ADP:无依赖原则

   在包的依赖关系中不允许存在环,细节不应该被依赖。

SDP:稳定依赖原则

   朝着稳定的方向进行依赖。

SAP:稳定抽象原则

   一个包的抽象程度应该和其他稳定程度一致。

原文地址:http://www.cnblogs.com/ceshi2016/p/16859369.html

1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长! 2. 分享目的仅供大家学习和交流,请务用于商业用途! 3. 如果你也有好源码或者教程,可以到用户中心发布,分享有积分奖励和额外收入! 4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解! 5. 如有链接无法下载、失效或广告,请联系管理员处理! 6. 本站资源售价只是赞助,收取费用仅维持本站的日常运营所需! 7. 如遇到加密压缩包,默认解压密码为"gltf",如遇到无法解压的请联系管理员! 8. 因为资源和程序源码均为可复制品,所以不支持任何理由的退款兑现,请斟酌后支付下载 声明:如果标题没有注明"已测试"或者"测试可用"等字样的资源源码均未经过站长测试.特别注意没有标注的源码不保证任何可用性