敏捷开发的主要原则_项目管理《敏捷软件开发原则模式与实践》与《敏捷项目管理》 - CSDN
精华内容
参与话题
  • 敏捷过程利用变化来为客户创造竞争优势。 3.经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。 4.在整个项目开发期间,商务人员和开发人员必须天天都工作在一起。 5.围绕...
    1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
    2.即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
    3.经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
    4.在整个项目开发期间,商务人员和开发人员必须天天都工作在一起。
    5.围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。
    6.在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。
    7.工作的软件是首要的进度度量标准。
    8.敏捷过程提倡可持续的开发速度。责任人(sponsors)、开发者和用户应该能够保持一个长期的、恒定的开发速度。
    9.不断地关注优秀的技能和好的设计会增强敏捷能力。
    10.简单——使未完成的工作最大化的艺术——是根本的。
    11.最好的构架、需求和设计出自于自组织的团队。
    12.每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。
    展开全文
  • [b]敏捷开发的几个大的原则[/b]
    1.单一职责 srp
    2.开放-封闭 ocp
    3.liskov替换原则 lsp ?
    4.依赖倒置 dip
    5.接口隔离 isp


    敏捷开发提倡简单设计的实践,“并在实现新需求时抓住机会改进设计”以对同类性质的改动封闭,做到由需求的变化驱动设计的进化(我们不能因为设计的退化而责怪需求的变化),同时经验在此起到十分重要的作用,如有经验的设计人员可以凭经验在初始设计时做出必要的抽象来满足ocp原则等,或是在需求变动时确定系统所需的抽象(所需的封闭),当然应及早的刺激这种变化的出现(如测试驱动的开发方法)。

      OOD承诺了一系列的好处(灵活性可重用性可维护性),用OO语言设计开发,若要方便的得到这些所谓的好处,有一系列的原则是要遵循的,如SRP,OCP,LSP,ISP等。

       SRP(单一职责原则)维护类的简单性,类不应承担一个以上令其变化的原因,否则应考虑分离并重新构造类,但如果的应用的变化方式总是导致类中的职责同时变化,却没必要分离他们

      Ocp(开闭原则)使OO系统做到对扩展开放,对修改封闭。OCP的遵循关键在于抽象,其主要实现方式有:定义接口描绘所需的操作,client只需关注接口的调用,子类型可以以任何其选择的方式实现接口,即所谓的stategy模式,或者定义抽象类并于其中实现公共操作,个性操作定义为abstract或virtual,由子类型负责个性化实现,通过此两法,将功能的通用部分和实现细节分离出来。当然,设计人员应该确定(猜测或凭经验)系统对哪种变化做到封闭,因为不可能对所有变化做到封闭,如《敏捷模式实践》中提到shape类型排序处理问题,为做到对排序安排(或变动)的封闭(使得各子类型间无需相互知晓,也可以做到自由安排排序顺序),选择使用“数据驱动”的方式(即单独构造结构表示排序安排—其中以子类类型在结构中的排列位置表先后),于shape基类中实现一次Precedes操作即可,子类型无需分别实现。OCP作为OOD核心所在依赖抽象来实现,但敏捷设计(或者说好的设计)拒绝不成熟的抽象,程序仅应对频繁变化的部分做出抽象。

      Liskov替换原则是使得ocp成为可能的原则之一,强调“子类型subtype必须能够替换掉它们的基类型basetype”,控制OO的继承关系安排,在OOD用is-a来确定类间的继承关系,LSP指出这种is-a关系是就行为方式(即类的各操作)而言的,而行为方式是可以合理假设的,是客户程序所依赖的。为遵循LSP,可借用DBC(design by contract)的操作前置条件和后置条件,“要使操作得以执行,前置条件必须为真,执行完毕后,该操作要确保后置条件为真”(为每个方法注明其前置和后置条件十分有帮助),如此,则“在重新声明派生类中操作时,只能使用相等或更弱的前置条件来替换原始的前置条件,只能用相等或更强的后置条件来替换原始的后置条件”(interface和其实现类间 抽象方法和其实现 此二者一定满足前述条件)。同时亦可用前述ocp遵循所用的二模式使设计符合LSP,另外子类型中的异常抛出应考虑在遵循LSP的范围内。

      关于提取公共部分的设计工具:“提取公共职责放入超类中,稍后添加的新的子类型可能会以新的方式支持同样的职责,此时原来的超类可能会是一个抽象类”。

    DIP(依赖倒置原则),作为framework的设计核心,其相对于传统软件设计而言,通常(传统)软件设计中采用结构化设计用高层模块直接调用底层模块,这样高层模块将严重依赖于底层模块的变动,在OOD中通过为高层模块定义所需使用的服务接口,底层模块现实这样的接口,高层模块通过抽象接口使用下一层(strategy模式所声明的),如此看来接口的拥有者一般是其使用者而非其实现者。通常为了满足DIP-良好OOD的基本底层机制,我么需要找出系统中潜在的抽象,而抽象通常是那些不随具体细节变化而变化的东东。

    ISP接口隔离原则,如SRP维护类的简单性一样,ISP用于维护接口的简单和必要性,因为接口是为客户调用的,因此其应该是“大小尺寸合适的”,“胖”接口显然对调用者造成累赘,ISP则用于将“胖”接口分离成多个合适的接口。
    展开全文
  • 个人理解的敏捷开发特别强调的几个重要原则 勇气、信任、责任、尊重、简单、主动、自律、沟通、反馈、分享

    个人理解的敏捷开发特别强调的几个重要原则

    勇气、信任、责任、尊重、简单、主动、自律、沟通、反馈、分享

    展开全文
  • 初识敏捷开发原则

    千次阅读 热门讨论 2014-02-15 16:21:34
    在软件开发中,我们经常会遇到类似这样的问题    我们所理解的东西无法和用户想要的达成一致,所以用户提出的要求,经过项目经理、分析师,最后到程序员的就已经被篡改的面目全非,所以,经过程序员们日以继日的...

        在软件开发中,我们经常会遇到类似这样的问题

     

        我们所理解的东西无法和用户想要的达成一致,所以用户提出的要求,经过项目经理、分析师,最后到程序员的就已经被篡改的面目全非,所以,经过程序员们日以继日的努力,终于做出来完全不是用户需要的程序了,于是我们不得不继续夜以继日的修改,终于在放弃了代码的质量、放弃了休息、加班加点的工作后,用户勉勉强强的接受了我们随时都可能奔溃的系统。

        或者我们还会 遇到另一个问题:


     

        

        第一次看到这个图的时候真是心酸,可是我们不是常常处于这种境况吗,只是我们写的是代码,而不是在挖坑,当销售部以牺牲各种签下了丧权辱国的条例之后,当产品经理大概了解了需要项目经理制定出看似争取的需求之后,就是程序员一个人在劳动的时候了,然后还要继续忍受感觉计划不合理向上反应的石沉大海,和测试部分的各种矛盾,和销售部门的各种嫌弃,就连每天加班让保安队长都建议颇多,但是干活的还是只有是自己。

        但是,程序员都是高智商的,既然就问题,就肯定有解决的方法,下面我就介绍一种解决办法——敏捷开发(agile development)。

     

    敏捷开发简介

      敏捷开发(agiledevelopment)

        是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

      敏捷的组成

        它们包括:极限编程(XP),Scrum,精益开发(Lean Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Cristal Clear)等等

       

      和其他开发对比

        我们知道软件开发模型有很多,比如:

        瀑布式

        它首先是由Royce提出,该模式由于酷似瀑布闻名。在该模式中首先确定需求,然后拟定规格说明,在通过验证后方可进入计划阶段。因此,瀑布模式中至关重要的一点是只有当一个阶段的文档获得认可才可以进入下一个阶段。瀑布模式通过强制性规约来确保每个阶段都能很好的完成任务,但是实际上却往往难以办到。因为整个瀑布模式几乎都是以文档驱动的,这对于非专业的用户来说是难以阅读和理解的。虽然瀑布模式有很多很好的思想可以借鉴,但是在过程能力上有天生的缺陷。

        演化模式

        它主要是针对事先不能完整定义需求的软件开发。它的方法是用户先给出待开发系统的核心需求,并且在核心需求实现后,再提出反馈以支持系统的最终设计和实现。也就是说:开发人员首先会根据用户的需求开发核心系统,然后提供给用户试用;用户试用后再提出增强系统能力的需求;最后开发人员再根据用户的反馈,实施迭代开发。实际上,这个模式可看作是重复执行的多个瀑布模式。演化模式要求开发人员把项目的产品需求分解为不同组,以便分批循环开发。但这种分组并不是随意性的,而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。

        螺旋模式:

        它是瀑布模式与演化模式相结合,并加入两者所忽略的风险分析所建立的一种软件开发模式。螺旋模式基本的做法是在瀑布模式的每一个开发阶段之前,引入非常严格的风险识别、风险分析和风险控制。直到采取了消除风险的措施之后,才开始计划下一阶段的开发工作。否则,项目就很可能被暂停。另外,如果有充足的把握判断遗留的风险已降低到一定的程度,项目管理人员还可作出决定让余下的开发工作采用另外的生命周期模式,如演化模式,瀑布模式或自定的混合模式。

           

      过程开发模式:

        它又叫混合模式或元模式,是指把几种不同模式组合成一种混合模式,它允许一个项目能沿着最有效的路径发展。因为上述的模式中都有自己独特的思想,现在的软件开发团队中很少说标准的采用那一种模式的,因为模式和实际应用还是有很大的区别的。实际上,许多软件开发团队都是在使用几种不同的开发方法组成他们自己的混合模式。

           

        最后,我们来总结一下。螺旋模式是典型的迭代式生命周期模式,而RUP则是近代迭代式生命周期的代表。与螺旋模式相比,RUP将风险管理放在更重要的地位。最新的迭代式生命周期模式的代表是模式驱动架构(MDA)和敏捷(Agile)软件开发。MDA模式是基于可执行规格说明的思想,是现代转换模式的代表,其核心技术是组件技术。而敏捷开发生命周期的典型代表是XP编程,是把传统的系统设计和实现由敏捷软件开发过程中的验收测试、重构和测试驱动所取代;把传统的集成和部署由敏捷软件开发中的持续集成和短周期所取代。

    具体介绍敏捷开发的过程

        敏捷开发主要包括三个角色,四个仪式,和三个物件,下面一一介绍

      三个角色


        产品负责人

        产品负责人(Product Owner):它是开发团队和客户或最终用户之间的联络点。

    •     代表产品线的利益,与Scrum Master和Scrum Team合作
    •     负责管理和确定产品记录的优先次序,角色负责产品的远景规划
    •     侧重于投资回报ReturnOf Investment

       

        Scrum Master

        Scrum专家(ScrumMaster):Scrum专家负责指导开发团队进行Scrum开发与实践,它也是开发团队与产品拥有者之间交流的联络点。

    •     为Scrum Team服务,确保每一个成员都认同Scrum价值观和遵守其游戏规则
    •     组织每天的DailyScrum会议
    •     负责保证Scrum Team的持续进展
    •     决策和免除障碍
    •     帮助Scrum Team规划Sprint计划

       

        团队

        团队成员(Team Member):即项目开发人员。

    •     自我管理,自我组织,多功能,通常由6 – 10人组成
    •     负责将ProductBacklog转化成Sprint中的工作项目
    •     所有团队成员协调,合作和完成Sprint中每一个规定的工作
    •     所有团队成员和ScrumMaster负责每一个Sprint的成功

       

      四个仪式


        Sprint计划会议


        每日站会

    •     开发团队成员召开,一般为15分钟。
    •     所有成员必须参加,每个人给全体成员汇报工作进展。
    •     更新燃尽图。
    •     每个开发成员需要向ScrumMaster汇报三个项目:
              今天完成了什么?
              遇到了障碍无法继续下去?
              明天要做什么?
    •     通过该会议,团队成员可以相互了解项目进度。

       

        Sprint评审会议

        Sprint评审会用来演示在这个Sprint中开发的产品功能给Product Owner. Produc Owner会组织

    •     这阶段的会议并且邀请相关的干系人参加。
    •     团队展示Sprint中完成的功能
    •     一般是通过现场演示的方式展现功能和架构
    •     不要太正式
    •     不需要PPT
    •     一般控制在2个小时
    •     团队成员都要参加
    •     可以邀请所有人参加

           

        Sprint回顾会议

    •     团队的定期自我检视,发现什么是好的,什么是不好的。
    •     一般控制在15-30分钟
    •     每个Sprint都要做
    •     全体参加
    •     Scrum Master
    •     产品负责人
    •     团队
    •     可能的客户或其它干系人

    Sprint回顾会议上,全体成员讨论有哪些好的做法可以启动,哪些不好的做法不能再继续下去了,哪些好的做法要继续发扬。

           

    三个物件


      产品Backlog

        一个需求的列表:

    •     一般情况使用用户故事来表示backlog条目
    •     理想情况每个需求项都对产品的客户或用户有价值
    •     Backlog条目按照商业价值排列优先级
    •     优先级由产品负责人来排列
    •     在每个Sprint结束的时候要更新优先级的排列

           

      Sprint Backlog

        将整个产品的backlog分解成Sprint Backlog,这个Sprint Backlog是按照目前的人力物力条件可以完成的。

        团队成员自己挑选任务,而不是指派任务。

        每个团队成员都可以修改Sprintbacklog,增加、删除或者修改任务。

           

      燃尽图

        燃尽图直观的反映了Sprint过程中,剩余的工作量情况,Y轴表示剩余的工作,X轴表示Sprint的时间。随着时间的消耗工作量逐渐减少,在开始的时候,由于估算上的误差或者遗漏工作量有可能呈上升态势。



    当然,知道了敏捷开发的组成部分,更要知道敏捷开发的流程,下面用一幅图来说明:




    敏捷开发的先决条件


    很多人会问,既然敏捷开发这么好,可以解决这么多的问题,为什么不是所有人所有项目都在使用敏捷开发呢,这就涉及到了实行敏捷开发的先决条件:

        一、团队有三名或以上的研发工程师;

        二、团队内有一名合适的Scrum Master。


    当团队内无法找到合适的Scrum Master时,不要轻易推行敏捷。如果你的团队是由新人组成,或者即使有资深员工但是他并不了解或认同敏捷开发的话,那么你需要等待合适的Scrum Master出现。

     

     

     

     

     

     

     


    展开全文
  • 敏捷开发12条原则

    千次阅读 2017-03-14 20:10:09
    我们遵循以下原则: We follow these principles: 1.我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。 Our highest priority is to satisfy the customer through early and ...
  • 《敏捷宣言》及敏捷开发十二原则

    千次阅读 2018-03-24 15:02:16
    敏捷开发宣言《敏捷宣言》我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作,我们形成了如下价值观:个体与交互 重于 过程和工具 可用的软件 重于 完备的文档 客户协作 重于 合同谈判 响应...
  • 曾担任C++ Report杂志主编多年,也是设计模式和敏捷开发运动的主要倡导者之一。 Micah Martin Robert C. Martin之子,也是经验丰富的软件工程师,曾任Object Mentor公司的咨询师,现任8th Light公司总裁。擅长.NET、...
  • 敏捷开发过程中必须遵循的原则 1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 初期交付的系统中所包含的功能越少,最终交付的系统的质量就越高。--构建高质量产品。 2.即使到了开发...
  • 敏捷开发之 12条敏捷原则

    千次阅读 2014-12-30 14:51:55
    上篇敏捷开发之 4句敏捷宣言中讲了敏捷开发的价值观, 从这些价值观中可以引出下面的12条原则,它们是敏捷实践区别于重型过程的特征所在。在Agile Software Development - Principles,Patterns,and Practices...
  • 敏捷开发12个原则

    千次阅读 2018-07-25 17:08:27
    2-欢迎对需求提出变更 - 即使在项目开发后期,要善于利用需求变更,帮助客户获得竞争优势; 3-要不断交付可用的软件,周期从几周到几个月不等,越短越好 4-项目过程中,业务人员与开发人员必须在一起 5-要善于...
  • 敏捷开发-原则 模式与实践(1)

    千次阅读 2015-01-22 21:24:30
    敏捷开发-原则 模式与实践  这的确是一本关于开发者的好书,对于我们开发者、研究人员,它提出了一个开发的全新的价值观(对我来说),甚至人生都有启发。需要认真阅读。 书中总结了敏捷开发的实例,确确实实更够...
  • 敏捷软件开发 - 原则、模式与实践》是我接触到的第一本系统介绍软件设计的书籍,深刻影响了个人的软件开发习惯。它并不难懂,我一直推荐给身边的各个层次的程序员学习。 可对于一本接近500页的图书,很多人还是...
  • 这本综合性、实用性的敏捷开发和极限编程方面的指南,是由敏捷开发的创始人之一所撰写的。1.讲述在预算和实践要求下,软件开发人员和项目经理如何使用敏捷开发完成项目;2.使用真实案例讲解如何用极限编程来设计、...
  • 1.书名:敏捷软件开发原则、模式与实践 高清版PDF(Agile Software Development) 2.非常好的软件设计的书,曾获13界软件开发震撼(Jolt)大奖,做软件的别说不知道这个奖哈。。。。。。 3.想做软件构架师的话,这...
  • 一、面向对象设计原则内容来自《敏捷开发原则、模式与实例》 SRP单一职责原则(Single Responsibility Principle): 就一个类而言,应该仅有一个引起它变化的原因。 OCP开放-封闭原则(Open Closure Principle...
  • 敏捷开发实践总结

    2018-11-25 23:46:06
    敏捷开发实践的认识什么是敏捷开发敏捷开发原则多种敏捷开发的方法一个敏捷团队敏捷开发中常用的术语迭代的典型流程致谢 什么是敏捷开发 敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发...
  • ios敏捷开发的理解

    2019-03-13 14:37:56
    一,根据以下几个问题来谈谈敏捷开发 1.什么是敏捷开发? 2.为什么使用敏捷开发? 3.如实使用敏捷开发? ...4.采用敏捷开发的产品效果?...二.... 敏捷开发以用户需求为核心,采用迭代,循序渐进的方式... 敏捷开发原则...
  •  第一章其实干货不多,主要就是介绍了一下敏捷联盟的一些历史,以及敏捷宣言,以及一些原则。 敏捷宣言:个体交互 胜过 过程和工具;可以工作的软件 胜过 面面俱到的文档;客户合作 胜过 合同谈判;响应变化...
  • 1.遵循敏捷实践去发现问题;应用设计原则去论断问题;应用设计模式去解决问题;软件开发的这三个方面间的相互作用就是设计。敏捷设计是一个过程,不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的...
  • 敏捷软件开发原则、模式与实践》书的电子版本(带书签,包含源代码)
1 2 3 4 5 ... 20
收藏数 40,391
精华内容 16,156
关键字:

敏捷开发的主要原则