敏捷开发的原则_项目管理《敏捷软件开发原则模式与实践》与《敏捷项目管理》 - CSDN
  • [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 ...
    我们遵循以下原则:

    We follow these principles:


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

    Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.


    2.欢迎需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。

    Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.


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

    Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.


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

    Business people and developers must work together daily throughout the project.


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

    Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.


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

    The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.


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

    Working software is the primary measure of progress.


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

    Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.


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

    Continuous attention to technical excellence and good design enhances agility.


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

    Simplicity--the art of maximizing the amount of work not done--is essential.


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

    The best architectures, requirements, and designs emerge from self-organizing teams.


    12.团队定期地反思如何能提高成效,并依此调整自身的举止表现。
    At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
    展开全文
  • 敏捷开发12个原则

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

    1-我们的最高目标是通过尽早和持续第交付有价值的软件来满足客户;

    2-欢迎对需求提出变更 - 即使在项目开发后期,要善于利用需求变更,帮助客户获得竞争优势;

    3-要不断交付可用的软件,周期从几周到几个月不等,越短越好

    4-项目过程中,业务人员与开发人员必须在一起

    5-要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务

    6-无论是团队内还是团队间,最有效的沟通方法是面对面的交谈

    7-可用的软件是衡量进度的主要指标

    8-敏捷过程提倡可持续的开发,项目方,开发人员和用户应该能够保持恒久稳定的进展速度

    9-对技术的精益求精以及对设计的不断完善将提升敏捷性

    10-要做到简洁,尽可能减少不必要的工作,这是一门艺术

    11-最佳的架构,需求和设计出自于自组织的团队

    12-团队要定期反省如何能够做到更有效,并相应调整团队的行为。

    展开全文
  • 敏捷开发宣言《敏捷宣言》我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作,我们形成了如下价值观:个体与交互 重于 过程和工具 可用的软件 重于 完备的文档 客户协作 重于 合同谈判 响应...
  • 敏捷开发的一些原则

    2018-10-19 14:42:51
    敏捷过程利用变化来为客户创造竞争优势。 3.经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。 4.在整个项目开发期间,商务人员和开发人员必须天天都工作在一起。 5.围绕...
  • 在过去8年里,我一直工作于“Agile”开发小组,所以让我用敏捷开发原则来告诉你事实,或许你会明白为什么那些在像Google这样巨头公司工作的开发者会认为敏捷开发是废话。 1.及早并持续的交付有价值软件来满足客户...
  • [探讨]敏捷开发原则

    2012-07-17 11:38:55
    [探讨]敏捷开发原则 最近,“敏捷”、“敏捷开发”这类词常常围绕在我们耳边。对于它的含义,我们是否真正了解?它是如何让开发变的有趣和高效?如何使用“敏捷”来进行商务沟通,并且使这种沟通更容易和更有...
  • 敏捷开发原则

    2007-02-28 20:58:00
    敏捷开发原则 1. 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。2. 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。3. 经常性地交付可以工作的软件,交付的...
  • 敏捷开发原则

    2009-10-27 22:09:00
    ~学点新东西 敏捷开发原则 1.尽早的,经常性的进行交付。努力在项目刚开始的几周内交付一个具有基本功能的系统,然后努力坚持每两周就交付一个功能渐增的系统。 2.团队努力保持软件结构的灵活性。这样能够欢迎...
  • 敏捷开发原则(转)

    2011-05-14 11:27:00
    敏捷开发原则作为 <现代软件工程> 的一个作业, 我要求同学们把 英文的敏捷开发原则 翻译成中文并解释。 大部分同学都提供了持续重构, 不断提高的版本。 技术翻译专家余晟老师也对其中较难翻译的三条原则提了很好的...
  • 敏捷开发过程中必须遵循的原则 1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 初期交付的系统中所包含的功能越少,最终交付的系统的质量就越高。--构建高质量产品。 2.即使到了开发...
  • 曾担任C++ Report杂志主编多年,也是设计模式和敏捷开发运动的主要倡导者之一。 Micah Martin Robert C. Martin之子,也是经验丰富的软件工程师,曾任Object Mentor公司的咨询师,现任8th Light公司总裁。擅长.NET、...
  • 上篇敏捷开发之 4句敏捷宣言中讲了敏捷开发的价值观, 从这些价值观中可以引出下面的12条原则,它们是敏捷实践区别于重型过程的特征所在。在Agile Software Development - Principles,Patterns,and Practices...
  • 时间到了2020年,敏捷开发早就已经是软件行业内一个几乎既成事实的标准,几乎每个软件研发团队都说采取了敏捷开发流程。 老司机以自己长期以来的软件实践,以及混迹于敏捷圈子近10年的体会,可以负责地说,敏捷原本...
  • 1.书名:敏捷软件开发原则、模式与实践 高清版PDF(Agile Software Development) 2.非常好的软件设计的书,曾获13界软件开发震撼(Jolt)大奖,做软件的别说不知道这个奖哈。。。。。。 3.想做软件构架师的话,这...
  • ios敏捷开发的理解

    2019-03-13 14:37:56
    一,根据以下几个问题来谈谈敏捷开发 1.什么是敏捷开发? 2.为什么使用敏捷开发? 3.如实使用敏捷开发? ...4.采用敏捷开发的产品效果?...二.... 敏捷开发以用户需求为核心,采用迭代,循序渐进的方式... 敏捷开发原则...
  • 1.遵循敏捷实践去发现问题;应用设计原则去论断问题;应用设计模式去解决问题;软件开发的这三个方面间的相互作用就是设计。敏捷设计是一个过程,不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的...
  • 今天部门大佬让我去设计并且开发一个为游戏中的AI精灵小助手的数据提供接口,强调了是敏捷开发原则。由于不太明确敏捷开发原则是什么,就去设计了一个AI精灵小助手中问题的后台管理页面,以及DB中表的设计。然后设计...
  • 敏捷软件开发原则、模式与实践(全) 敏捷软件开发原则、模式与实践(全)
1 2 3 4 5 ... 20
收藏数 39,725
精华内容 15,890
关键字:

敏捷开发的原则