敏捷开发的核心原则_项目管理《敏捷软件开发原则模式与实践》与《敏捷项目管理》 - 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则用于将“胖”接口分离成多个合适的接口。
    展开全文
  • 敏捷不是某一种方法论、过程或框架,更不是字面意义上的敏捷,而是一组价值观与原则

     敏捷不是某一种方法论、过程或框架,更不是字面意义上的敏捷,而是一组价值观与原则。

    敏捷开发的核心理念:

    • 敏捷开发的核心理念:敏捷开发的核心理念就是以最简单有效的方式快速地达成目标,并在这个过程中及时地响应外界的变化,做出迅速的调整。
    • 敏捷开发的第一条价值观就是“ 以人为本”,强调“ 个体(人)” 及“ 个体” 间的沟通与协作在软件开发过程中的重要性。这个顺序不是偶然而为之的,敏捷开发将重视个体潜能的激发和团队的高效协作作为其所推崇的第一价值观。
    • 敏捷开发的第二条价值观就是“ 目标导向”。同其他众多管理理论和模型一样,敏捷开发认同目标导向是成功的关键,因为没有目标也就无所谓成功。敏捷开发的价值观中清楚地阐明,软件开发的目标是“ 可工作的软件”,而不是面面俱到的文档。而遗憾的是,很多软件项目已经在纷繁的文档之中迷失了自己的目标。
    • 敏捷开发的第三条价值观就是“ 客户为先”。虽然敏捷开发强调的第一价值观是“ 以人为本”,但敏捷宣言的缔造者们并没有忘记客户,相反他们真正的理解客户的需求、懂得如何与客户合作。敏捷价值观里强调的“ 客户为先”即不是简单地把客户当作“ 上帝”、刻板的推崇“ 客户至上”,客户要求什么、我们就做什么;也不是把客户当作“ 谈判桌上的对手” 甚至“ 敌人”,去斗智斗勇。敏捷价值观把客户当成了合作者和伙伴,把自己的使命定位为“ “ 帮助客户取得竞争优势”。
    • 敏捷开发的第四条价值观就是“ 拥抱变化”。人们常说“ 世界上唯一不变的就是变化”,大多数人也相信事实确实如此。而以往很多的软件项目却忽视了这一点,或者更准确地说是他们不愿意“ 正视”。他们总是试图用详尽的计划去预先穷举这些变化,然后又试图通过严格遵循计划来控制变化的发生,而结果往往是被不断涌现的变化击垮。敏捷开发价值观中承认变化是软件开发的一部分、并相信正是客户在不断变化其需求的过程中明晰了其真正的需要。因而敏捷开发欢迎变化、拥抱变化,并可坦然应对变化,正是这些变化为客户和项目带来了价值。
    • 最后,还应记住敏捷宣言中的最后一句话:“ 尽管右项有其价值,我们更重视左项的价值”—敏捷宣言并未否定或贬损“ 右项” 的价值,在敏捷开发的价值观中承认“ 流程和工具”、“ 详尽的文档”、“ 合同谈判” 以及“ 遵循计划” 的重要性,只是两相比较,“ 更重视左项的价值”。

    敏捷开发的十二条原则:

    1)我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
    2)欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
    3)经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
    4)业务人员和开发人员必须相互合作,项目中的每一天都不例外。
    5)激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
    6)不论团队内外,传递信息效果最好和效率最高的方式是面对面的交谈。
    7)可工作的软件是进度的首要度量标准。
    8)敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
    9)坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
    10)以简洁为本,它是极力减少不必要工作量的艺术。
    11)最好的架构、需求和设计出自组织团队。
    12)团队定期地反思如何能提高成效,并依此调整自身的举止表现。
    - 敏捷开发原则是对敏捷价值观的解释和实践,它将敏捷的价值观落实到具体的可操作的原则之上,遵循这十二条原则,是敏捷软件开发项目得以成功的基石。
    - 这十二条原则囊括了软件项目管理的所有基本流程,而且这些流程足够具体,它告诉我们项目管理的第一步就是要明确目标,而软件项目的终极目标就是“ 不断地及早交付有价值的软件使客户满意”;它提示我们软件工程的起始点是需求,而需求的固有特征就是不断变化,敏捷开发过程要响应变化;它强调“ 可工作的软件是进度的首要度量标准”,因而需要以尽可能短的周期“ 经常地交付可工作的软件”;它重视相关干系人的协调(“ 业务人员和开发人员必须相互合作”、“ 责任人、开发人员和用户要能够共同维持其步调稳定延续”),重视激发个人潜能(“ 激发个体的斗志”),要求团队使用最高效的沟通方式(“ 面对面的交谈”);它推崇技术变革所具备的强大能量(“ 坚持不懈地追求技术卓越和良好设计”);它强调精益生产(“ 简洁为本”),要求项目采用自组织团队管理模式,并指出“ 定期总结反思” 是校准团队行为、最终达成目标的有效途径。

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

    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出现。

     

     

     

     

     

     

     


    展开全文
  • 下面就是能够指导敏捷软件开发团队的26条核心原则。 用例一完全能够运行后再开发用例二。 厨房里有一种说法正好可以印证这个问题:“做好一盘菜后你再做下一盘”. 对于软件开发来说一个最大的问题就是人们...

     

    避免提交一个半成品。 

    这一点大家似乎都知道,但这条原则必须列入任何一个开发指导里。 能够听取这些忠告进行开发测试然后提交代码的程序员一定不会发生代码提交到版本库使整个项目无法编译码通过情况。如果系统编译失败,那一定是有人抄近道到了。

     

    不要在还没有任何使用案例的情况下设计通用模块。 

    只有在你知道有具体用例的情况下,你才可以实现一个具体的类,而且你在该类中只应该实现当前该用例需要的方法。你也许会想到将来这个类会有其它的用途,你可以用注释的方式记录一下,但不要去实现它,只有在有了具体用例后你才可以实现它。

     

    用例一完全能够运行后再开发用例二。

    厨房里有一种说法正好可以印证这个问题:“做好一盘菜后你再做下一盘”. 对于软件开发来说一个最大的问题就是人们喜欢并行开发多个任务。因为不可避免的,我们设计的功能中总会有一部分会被放弃砍掉,如果提前开发,很可能做无用功。一次只开发一个用例(或很少几个用例,这根据你的开发团队的大小而定); 让这个用例功能完整; 让相应的测试用例都能通过; 相应的文稳都补齐; 只有在当前的用例完全开发完成后,才做为一个整体提交到版本库,才进行下一个用例。

     

    一定不要在没有使用例的情况下往类里添加成员方法。 

    这跟上面一条极其相似,除了这里针对的是数据成员。 开发人员很容易想到:一个‘客户记录’里应该有‘送货地址’的信息,但一定不要在没有任何用例要求这个属性的时候实现这个属性。

     

    不要害怕做决定;不要害怕改变以前的决定。 

    敏捷开发的目的是应对客户需求的不确定。 开发前期你不可能获到全部的信息。 你应该尽可能的拖延做决定的时间,但一旦到了你该做决定的时候,你应该当机立断,让项目向前推进。你不能说一直等到有了足够的信息才做决定。 相反,你要依赖现有的信息作出最正确们决定。 之后,当有新的信息出现后,不要害怕对以前的决定作出更改。(老辈人有的称之为触发器,但我称之为随环境而变)

     

    不断的了解如何改进系统。 

    这项工作没有尽头,你应该做好思想准备,持续不断的寻找可以改进的地方,收集各种关于如何找到质量问题、解决质量问题的案例。

     

    审查,审查,审查。 

    敏捷开发可以帮助我们应对需求在将来的不确定,但过去的事情也存在不确定性。 测试工作永远不能停下来。程序每次运行的表现都要被评审和记录。

     

    软件的设计要以人为本,而不是系统。 

    很多开发人员退而求其次、以技术为中心,让设计为技术服务。 永远不要忘记软件的终极目标是什么,是帮助人们完成工作。

     

    测试是产品的一部分。

     许多开发人员和经理都认为产品就是你打包给客户的东西,其余的都不重要。 其实测试也应该看作是产品的实际一部分,应该在设计时给予相当的重视,甚至,在很多时候,测试功能也应该同产品一起提交给客户。(后面说的这部分很多人都不认可,一个内置的能自我测试软件包并不会占用多少额外的资源,但当你需要用到它时,你会发现它的巨大价值。)

     

    先写测试用例,后写代码。 

    测试用例可以用来精确的说明我们的设计需求。 很多时候我们都是通过运行测试用例后发现我们的设计中存在问题。想想吧,先写测试用例后编码能节省多少时间。 但是:写完测试用例1,然后编写用例1,完后才开始用例2。

     

    清理垃圾代码。 

    很显然,又是一个尽人皆知的道理,但它也必须写入任何的开发原则里,因为它是如此的重要。查找垃圾代码的工作永远没有尽头,找到它,消灭它。 要去除掉所有的不能给实际用户带来价值的代码。 如果你不能指出某段代码对用户有什么用处,那它很可能就是没用的。

     

    培养对集成失败问题立即做出反应的习惯。 

    你要明白,当集成构建失败时,它会影响项目中的每一个人,所以没有比让核心程序能正确的集成和测试通过更重要的事情了。我曾经见到过有的团队的集成构建中断几个月都不去管它,因为他们有其他的工作要做。 每个人都在忍受这种情况,但没人采取措施。 我们应该明白,应该广泛的认识到,只要做出一点点工作,整个的团队会因此得到非常大的回报。

     

    团队的每个成员都要知道客户的需求。

    大型复杂的项目必须要分割到几个独立的团队去开发,然后派发到每个开发人员的手中,但这绝对不能变成程序员可以不明白最终产品的使用用户的需求和目标是什么。

     

    把意义相关的东西放在一起。 

    组织好代码,让高度相关的东西都放在一起,也就是放在一个类里。 这是标准的面向对象设计原则里的封装的概念。理想情况下,类之外的程序并不需要知道类里面的工作细节。 有些开发人员喜欢把代码放到好几个文件里,这样是为了按另一种方式组织它们:例如把相同的数据类型的放到一起,或按字母顺序分类。举个例子,有人会把所有的常量放在单独一个包下的一个类里,他们这样做毫无必要,增加了程序的复杂性。 按照指导原则,它们应该按照相关性进行分组,从而减少复杂性。

     

    先测试后提交代码。 

    这个准则能让你确保“永远不要让集成构建失败”的准则。

     

    过早优化是灾难之源 

    这句话是引用Don Knuth的,今天听起来一点不错。在内核里的代码应该尽力的写好来避免不要的浪费,但针对高于单个方法的级别的优化应该在整个项目测试通过、针对最终实际用户的压力测试用例通过之后才能进行。 仅仅根据静态的代码来判断哪些是影响整个性能最主要的问题的论断往往是错误的。相反,评审整个系统的运行表现,找出真正影响性能的1%的代码,只针对这些代码做优化。

     

    最小化未完成的编码任务的工作包(backlog)。 

    当开发人员开发一个设计用例时,有的功能会牵涉到所有修改着的但未完全开发完成、充分测试的代码。把未修改完成的代码保存到本地数天或数星期,这样增加了工作浪费的风险,会出现返工。 想象有三个任务,每个估计都要一天。 如果三个一起开发,并行起来每个都需要3天,这样一累计会有9个’单位’的风险。 如果顺序的开发,一个开发完成后再开发另一个,只会有3个‘单位’的风险。 这个并不符合我们的直觉。 我们的直觉告诉我们,当我们在这种情况下时,我们希望三个一起完成。 但是软件不像盖房子。小的、迅速的、完整的任务不仅仅会降低我们的认知负荷,也减少了进行中的开发对其他人正在进行的开发的相互影响。

     

    不要过度功能范化。 

    程序员在编写一个类时喜欢料想:这个类可能在其它地方其它类中会有其它用途用. 如果这些用途是被当前的用例用到,那这样思考是没错的,但常常开发人员想到的这些用途都是目前不存在的用途,实际上可能是永远不会用到的用途。

     

    如果两行代码能完成就不要写成三行。 

    简洁的代码永远都会给需要阅读这段代码的人带来好处。 但千万不要把代码压缩的难以理解了。精简的、书写规范的代码易于维护和查找错误,冗长的、太多修饰的代码则相反。 尽可能的简化但不要过度。

     

    永远不要按行数多少来评价代码头。 

    编写某个任务所产生的代码行数会因程序员而异,因编码风格而异。 代码的行数不会提供任何关于程序完成情况和代码质量的信息。代码质量可以相差200倍之多,这是计算代码行数的方法不能胜任的。 应该计算功能性的用例数。

     

    我们应不断的再设计、再分析。

     应用这一条时你要非常的小心,因为有些代码很脆弱、难以维护。但不要害怕修改这些代码、让它符合真正的需求。 一个数据成员以前是整数型的,但现在有个用例需要它是浮点型,不要害怕去改变它,只要你按步骤:测试,写文档,布署。

     

    删除死代码。 

    当发现有一大段不能理解的代码时我们习惯的做法是“让死狗躺在哪”。 比如说,我们需要往类里添加一个新方法来替换以前的旧方法,通用人们会保留老方法‘以防不测’。其实,我们应该花一些功夫去检查看看这个老方法是否还有用,如果没有证据显示它还有用,就该删掉它。 更糟糕的错误做法是把这些代码注释掉,留下一堆注释码。 注释掉的代码一旦发现就该被删掉,不能留到测试时还有、甚至提交到代码库。添加代码总是容易的,删除代码总是困难的。 因此,一旦发现有可能没用的代码,你应该花点时去确认它、删除它,这样会让代码更加可维护。

     

    不要自创新语言。 

    程序员喜欢使用文本文件来实现功能性的趋动,这样可以使程序变的可配置。 通过配置文件来改变软件行为所产生的后果是不过控的。 XML的诞生促使了一系列的特别的自定义的‘脚本语言‘的出现,人们试图通过文件的配置以让最终用户‘编程’来控制软件的功能、避免重新编译。这种设计上的缺陷是:软件里的各种操作的准确定义在脱离了具体上下文的特定实现的情况下不可能被准确的定义。这些各式各样的脚本型语言只是对那些对软件代码的内部工作机理有着相关的知识背景的人才会价值。所以,真正的最终用户是不可能知道软件的内部工作机理的,不可能推理出这些复杂的指令组合会产生什么样的预期结果。 脚本有它的用途,也不应该被抵制,但设计人员必须以非常非常安全的方式使用它们,尽可能使用现有的语言,必免使用新发明的语言。

     

    只有当准备好了实现和测试才去确定设计。 

    我应该有一个总体的认识我们要做什么,应该有个总体架构目标,而不是详细设计、详细的具体方法的实现,只有当开发迭代到一定程度后、足以让我们定下设计细节后才去把它表现成文档。详细设计只应该包括当前需求用例中需要覆盖的部分。 软件开发中最大的浪费就是你花时间设计出来东西后被告知不需要了,或者是你的设计一开始就建立在错误的假设上。

     

    软件是可塑的。 

    软件不像盖房子,我们可以轻易的改的面目全非。 无数事实表明软件比它的规格说明书善变的多。而且,软件产品和设计之间的互动明显比规格说明书有效率。 所以,你应该直接实现你的设计,这样客户就能很容易明白你的设计细节。 当发现有问题、要改变设计时,修改软件要比修改文档容易的多。更重要的是,当客户看到了能运行的程序后,你也就更能搞清客户的需求是什么了。

     

    对被检测到的和被报告的异常情况请多花一点时间对其进行详细描述。 

    程序员一般都非常的懒,抛出异常时只描述错误的表面现象。 设想如果只是作者自己会遇到这种错误,他会记得这种一直使用的错误描述信息是什么意思。但站在客服技术支持的处境,他们因为这种不准确的、不完整的错误描述浪费了大量时间。 这些信息应该达到让一个刚走进屋里没有任何经验的人能看明白的程度。 客户和客服基本都是对编程不懂的人。

     

    不断更新中…


    展开全文
  • 敏捷开发原则及方法

    2020-03-10 11:46:37
    敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可...
  • 敏捷开发核心思想

    2011-04-20 09:08:00
    敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可...
  • 敏捷开发的一些原则

    2018-10-19 14:42:51
    敏捷过程利用变化来为客户创造竞争优势。 3.经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。 4.在整个项目开发期间,商务人员和开发人员必须天天都工作在一起。 5.围绕...
  • 【什么是敏捷开发?】资深程序员之路(5)--agile开发 敏捷开发(scrum, agile)相对于瀑布流开发(waterfull)更适合现在快节奏的商业模式需求,它将一整个项目拆分为相互独立的小块,我们成为sprint(冲刺),每个...
  • 敏捷开发实践总结

    2018-11-25 23:46:06
    敏捷开发实践的认识什么是敏捷开发敏捷开发原则多种敏捷开发的方法一个敏捷团队敏捷开发中常用的术语迭代的典型流程致谢 什么是敏捷开发 敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发...
  • 看了一下XP编程和敏捷开发,越来越见识到了原来开发中面临的各种问题, 在这里把看到的一些原则、方法小结一下,我会不断补充有关的内容:交流是敏捷开发必须的用户是敏捷开发团队的一员,而不像传统那样跟开发没...
  • 敏捷性是以微小增量的方式构建软件,那么我们该如何设计软件呢?在敏捷团队中,全局视图和软件一起演化。每次迭代,团队都改进系统设计...在《敏捷软件开发原则、模式和实践》一书中提出几种设计原则: 单一职责原
  • 1,敏捷宣言和原则 1.1 敏捷宣言 敏捷联盟在敏捷大会上发布了他们最主要的主张,称之为敏捷宣言。其主要表述如下: 1,个人和交互胜过过程与工具 2,可以工作的软件胜过面面俱到的文档 3,客户合作胜过合同...
  • 浅谈敏捷开发

    2020-04-11 14:29:17
    浅谈敏捷开发 敏捷开发(agile development)是非常流行的软件开发方法。据统计,2018年90%的软件开发采用敏捷开发。 但是,到底什么是敏捷开发,能说清的人却不多。本文尝试用简洁易懂的语言,解释敏捷开发。 章节 ...
  • 敏捷开发(agile development)是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目...
  •  第一章其实干货不多,主要就是介绍了一下敏捷联盟的一些历史,以及敏捷宣言,以及一些原则。 敏捷宣言:个体交互 胜过 过程和工具;可以工作的软件 胜过 面面俱到的文档;客户合作 胜过 合同谈判;响应变化...
  • ios敏捷开发的理解

    2019-03-13 14:37:56
    一,根据以下几个问题来谈谈敏捷开发... 敏捷开发以用户需求为核心,采用迭代,循序渐进的方式开发软件,目的在于快捷覆盖,响应市场需求。 大项目划分小项目,分别完成,独立运行。 敏捷开发特征。 敏捷开发原则...
  • 敏捷开发和迭代开发

    2019-06-27 17:05:44
    敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发,在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。...
  • [探讨]敏捷开发原则

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

    2019-09-26 23:39:17
    遵从敏捷开发原则(强调遵守) 2.测试被包含在整体开发流程中(强调融合) 3.跨职能团队 二.敏捷测试的特点 1.更强调协作 敏捷开发人员和测试人员工作得更加紧密,喜欢更直接的沟通方式而不是通过...
  • ThoughtWorks的敏捷开发

    2018-07-23 11:19:45
    ThoughtWorks的敏捷开发方法一直是一种神秘存在。在敏捷开发还没有主流化的年代,为了让外界理解ThoughtWorks全球团队怎么做敏捷,我们商定了一个“60% Scrum + 40% XP”的经典答案。当然其实ThoughtWorks的敏捷开发...
1 2 3 4 5 ... 20
收藏数 20,673
精华内容 8,269
关键字:

敏捷开发的核心原则