敏捷开发的流程 - CSDN
  • 什么是敏捷开发流程

    千次阅读 2019-05-11 19:34:29
    【什么是敏捷开发流程 】 这个词猛一听起来感觉很高大上,其实现在已经是主流的团队开发流程 了。 一. 先说一下官方的定义: 敏捷不是指某一种具体的方法论、过程或框架,而是一组价值观和原则。符合敏捷价值观....

    这里是修真院后端小课堂,每篇分享文从

    【背景介绍】【知识剖析】【常见问题】【解决方案】【编码实战】【扩展思考】【更多讨论】【参考文献】

    八个方面深度解析后端知识/技能,本篇分享的是:

    【什么是敏捷开发流程 】

    这个词猛一听起来感觉很高大上,其实现在已经是主流的团队开发流程 了。
    一. 先说一下官方的定义:

    敏捷不是指某一种具体的方法论、过程或框架,而是一组价值观和原则。符合敏捷价值观和原则的开发方法包括:极限编程(XP),Scrum,精益软件开发(Lean Software Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Crystal Clear)等等。所有这些方法都具有以下共同特征:

    1. 迭代式开发。即整个开发过程被分为几个迭代周期,每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短,通常为一到六周。

    2. 增量交付。产品是在每个迭代周期结束时被逐步交付使用,而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。

    3. 开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时,团队对于用户的需求也能及时提供反馈意见。

    4. 持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成,有些项目则每天都在这么做。

    5. 开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队,是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制,而非把过程和机制强加给人。

    二. 然后是我理解的敏捷

    主要说一下我们公司自己的开发流程,因为接触时间尚浅,所以有点地方可能说的不是很到位,希望大家多多包含。

    需求评审(参与人员是 客户+产品+UI+开发+测试,也就是所有人员)
    主要是产品人员讲解需求,用户需要给出反馈或者提出意见,其他人员可以相应的提出自己的见解。

    Story划分(产品+UI+开发)
    产品根据UI做出来的原型图给开发人员讲解系统构成和运行,将整个网站按照功能划分成一个个细粒度的story来说明,开发人员(前端和后端)也需要明白自己应该关注那些关键点。

    人员划分(leader+开发)
    主要是项目小组的leader 根据story划分,给前端和后端开发人员划分story,开发人员根据自己的情况去估算所需时间。

    方案设计(数据库设计文档、接口设计文档、方案设计文档)
    先根据系统的实际情况去设计DB,包括数据库和表的名字,以及具体的字段。
    然后设计接口文档,按照页面和功能进行设计,包括具体的请求地址和入参出参。
    最后是根据接口文档中出现的疑难点去做方案设计文档,对遇到的问题进行分析并拿出至少两种具体的解决方案。

    方案评审(所有人员)
    对前端和后端给出的方案评审其它人员给出各自的意见,有问题的话下次再次开始。

    禅道任务拆分(开发人员)
    方案评审通过以后开发人员就需要按照预估的总开发时间去拆分story,可以分成多个小的任务,但是一个任务的时间最好不要超过4个小时。

    开发(项目日报+工作日报+进度邮件)
    每天实际开发过程中遇到问题可以写成项目日报;每天的任务完成情况写成工作日报;相比较整个系统的进度完成情况需要写进度邮件。

    端对端(接口)测试(开发人员)
    前端写好了页面,后端完实现了接口,就可以进行端到端的测试,可以远程测试,也可以本地测试。

    压力测试+集成测试
    系统完成以后需要用Jmeter 进行模拟用户访问,通过设置线程来提高并发量的方式达到一定的效果,测试生成的数据需要总结成测试报告。

    Demo
    对于复盘来说,这就是最后一个程序了,在前后端大师兄的评审下,主要是前端人员进行系统演示,各个功能是否实现、页面是否达到用户要求、有没有什么需要完善的地方。点评过之后如果有问题那就修改之后再次评审;如果没有问题那就算完成复盘项目了。

    这么一个流程走下来,特别期间各个环节的良好运行以及团队合作的情况都是确保项目能够正常实现并交付的重要因素,敏捷开发强调的是人的充分能动性,通过这种相互合作的开发模式,相信在前后端分类开发的盛行时代,公司或者团队可以在约定的时间内较好地完成用户委托的项目。

     

     



     

    【欢迎加IT交流群565763832与大家一起讨论交流】

    展开全文
  • 敏捷开发流程

    千次阅读 2017-01-04 16:37:50
     在敏捷软件开发领域,更注重的以人为核心,迭代,循序渐进的开发方法。相比传统的开发方法,这种方法能更快速的开发,上线,反馈,调整、迭代。以敏捷的姿态去发展产品。 敏捷与传统开发的区别  
    反应快速灵敏。


      在敏捷软件开发领域,更注重的以人为核心,迭代,循序渐进的开发方法。相比传统的开发方法,这种方法能更快速的开发,上线,反馈,调整、迭代。以敏捷的姿态去发展产品。


    敏捷与传统开发的区别                                                                                  


      有个非常有意思的游戏能够帮助大家理解敏捷和传统开发的差异。游戏有两个角色,一个是“老板”,另一个是“员工”,在 2 分钟内,“员工”需要在“老板”的完全指挥下,即“向前一步,向后一步,停,向左一步,向右一步”,完成 60步移动的任务。“员工”需要执行“老板”的每一个指令,不允许做出相违背的动作。“老板”则不参与行动,只发出指令指挥“员工”的活动。我们体验这个游戏 时,当场 60% 的参与者成功完成了任务,大致估计出我们的工作效率是50%*60%=30%。游戏后,参与者被问及对这种行为方式的感受时,无论是“员工”还是“老板”都表示非常不满。


      接着,大家又做了另一组游戏。2 分钟内参与者被要求独立的、自主的完成 60 步移动任务,在这次游戏里,所有参与者任务相同,大家可以自行决定、并依据自己的判断随时调整其步伐方向,快慢。最后,我们发现所有参与者不但毫无折扣的 按时完成了任务,因而工作效率也达到 100%*100%=100%,而且所有人对于这种新的工作方式更是产生了极大的兴趣。

    敏捷开发与传统开发的比较




    通过上面有趣的两种游游戏的对比,以及价值表述的对比就折射出了传统开发与敏捷开发的方式的对比,其中的优劣不言而喻。


     
    敏捷开发                                                                                                       


    敏捷宣言:



    敏捷方法分类:


    除了图例中的方法外还有 Crystal, Lean Software Development, Feature  Driven Development, Xbreed, RUP 等等。


     


    敏捷方法的共性: 


    虽然各种敏捷方法的名称、所需环境、适合的团队有很大差异,但是他们拥有相似、相同的以下几大特点:


    * 拥抱变化


      “唯一不变的就是变化”所以,需求的变动是必不可少的,每次的决定和需求的调整都是将产品开发推向更正确的方向。而在接受变化的同时,我们应该积极的反馈显示活动中暴露出来的可能的设计缺陷和错误。


    * 客户的参与


      最终使用者、内部使用者、客户代表、商业伙伴都可以是我们的客户。对于客户的参与更能使我们做出客户真正需要的产品。


    * 较少的文档


       传统开发的文档在敏捷中仍有大用,只是我们可以将原来的文档进行精简。在敏捷中文档不是最佳的沟通方式,更鼓励通畅的交通和沟通,而沟通的效率远高于文档。


    * 最大化的生产力


      敏捷开发模式要最大化的提高团队的工作效率。无论是依靠剪除冗余的文档工作,还是提供民主的、通畅的沟通平台都是为了帮助 团队能够集中有限的精力处理。


    * 测试驱动开发


      是让开发人员在编写功能代码之前,根据对需求的理解先设计和编写单元测试代码。先思考如何对将要实现的功能进行验证,再考虑功能的实现。然后迭代的增加新功能的单元测试和功能代码编写,直到完成全部功能的开发。


    * 自动化冗余工作


      将团队成员从冗余的劳动中解放出来,无论是自动化的测试还是自动化工具的开发只要能够节约成本都是敏捷开发、敏捷测试的目标。


    * 民主的团队


    敏捷团队是一支民主的团队,团队关系是平行的,每个团队成员能够平等的参与讨论,决策。传统开发的垂直的官僚机构在敏捷开发中已是过时的。


     


     


    敏捷测试                                                                                              


      不是说敏捷测试么?这怎么看上去测试跟敏捷没一毛钱的关系。人家都敏捷了,还要测试做什?


      在敏捷开发流程中,测试不再是瀑布试开发流程的一个环节,而是全程参与整个开发流程。通过各种方式来保证产品的质量,无论是原则中的“频繁交付”,还是对“可工作的软件”的度量,或是敏捷开发实践中的“测试驱动开发”,“行为驱动开发”,都离不开测试的支持。 当然,敏捷测试对测试人员提出了更高的要求,对测试人员来说也是新的挑战。


     


    敏捷测试人员的定义


      专业的测试人员,适应变化,与技术人员和业务人员展开良好的协作,并理解利用测试记录需求和驱动开发的思想。


      敏捷测试人员往往具有优秀的技术能力,知道如何与他人合作以实现自动化测试,同时也擅长探索性测试,他们希望了解客户在做什么,以此更好地理解客户的软件需求。


     


    敏捷测试思想


      对于一个敏捷团队而言,需要持续关注如何最出色地工作并发布最优秀的产品。根据我们的经验,这需要大量的训练、学习、时间、试验和协同工作。


      对于一个敏捷测试人员,他(她)会乐于收集和分享信息,与客户或者产品负责人协作以帮助他们充分展示自已的需求,从而得到他们需要的功能,同时向所有人提供项目进展的反馈。


    基本要求就是敏捷测试人员和其它敏捷团队成员一样,乐于学习新技能和面对新挑战,不会仅仅局限于测试问题。这不只是测试人员的特征,所有敏捷团队人员都应具有。敏捷测试人员帮助开发人员和客户团他解决可能出现的任何问题。测试人员提供信息以帮助团队回顾和了解哪些方案有效,哪些无效。


      测试人员可能在测试领域拥有特殊的技能和经验,但一名优秀的测试人员并不惧怕参与一场设计讨论,提供有且于测试性或者构建更良好方案的建议。敏捷测试思想是面向结果的、技术性的、协作的,乐于学习的、勇于不断生产业务价值的。


     


    测试人员的十条法则                                                                                   


    敏捷测试人员的十条法则:


    提供持续反馈
    为客户创造价值
    进行面对面的沟通
    勇气
    简单化
    持续改进
    响应变化
    自我组织
    关注人
    享受乐趣
     


    提供持续反馈


      既然是测试驱动敏捷项目,那么很显然反馈在敏捷团队中占据重要的地位 。既然是测试驱动敏捷项目,那么很显然反馈在敏捷团队中占据重要的地位 。


    为客户创造价值


      敏捷开发就是在较低的版本发布中提供客户目前最迫切需要的功能。这通常意味着限定范围。我们经常在客户团队中遇到较酷功能的需求。任何人都可以质疑这些内容,但是测试人员会判断其对故事的影响,因为他们需要考虑测试后果。 


    进行面对面的沟通


      一个团队如果沟通不好则难以协作。如今,许多团队分布于多个地理位置,沟通变得更加重要和富有挑战性。敏捷测试人员应该尽力促进沟通。这是把工作做好的关键因素。 


    勇气


      勇气是极限编程的核心价值,类似测试自动化和持续集成的方式允许团队实践这种价值。 测试人员固守于自己的领域,不与其他业务相关者和技术团队进行任何讨论。虽然你找机会进入了协作的敏捷环境,可能会对找客户索要实例或者找开发人员帮忙自动化测试或者在每日例会时提出一个难题等感到不习惯。 


      当最初加入敏捷团队或者当前的团队开始过渡到敏捷开发模式时,通常你会产生恐惧感,并且存在大量的问题需要答案。我们到底如何才能在如此短的时间内完成对每一个用户故事的测试任务?测试如何跟上开发的节奏?如何确定需要多少测试?又或者你是功能测试经理或者质量过程经理,但不清楚在敏捷团队中如何定位自己的角色,也没人知道答案。敏捷测试人员需要勇气找到这些问题的答案,但需要勇气的原因不仅限于此。 


    简单化


      敏捷测试人员和他们的团队面临的挑战不仅是生产最简单的有效软件而且还需要采取简单的方法以确保软件符合客户需求。这并不意味着团队不应该花时间分析主题和故事、思考合适的架构和设计。而是说,当业务部门的需求比较复杂的时候,团队可能需要将方案退回给他们,更简单的解决方案也会产生同样的价值。 


      简单并不意味着容易。对于测试人员来说,这意味着采用能够找到的最轻量级的工具和技术恰到好处地测试。工具可以简单到只是一张电子表格或者清单。需要自动化回归测试,但是应该把它们分解到最底层以获取快速反馈。甚至简单的冒烟测试也可能满足面向业务的测试自动化。 


    持续改进


      想办法把工作做得更出色是敏捷测试人员应牢记的。 


      敏捷测试人员和他们的团队总是在寻找工具、技能或者实践以帮助他们增加更多价值或者得到更好的客户投资回报。敏捷开发的短期迭代更易于尝试新事物,以验证是否值得长期采用。 


    学习新技能和提高专业技能水平对敏捷测试人员非常重要。可利用各种免费的资源提高专业技能。


    响应变化


      响应变化是敏捷实践的重要价值,但是我们发现这对测试人员来说却是最困难的概念之一。测试人员渴望的是稳定,所以他们会说:“我已经测试过了,任务完成了”。持续的需求变化是测试人员的噩梦。但是,作为一名敏捷测试人员,我们不得不拥抱变化。周三,我们可能期望启动故事A和B,下周五做故事C。但是到了周五,客户重新设定了优先级,现在需要故事A、X和Y。只要我们持续与客户交流,我们就能处理这些变化,因为我们与团队的其他成员保持同步。 


    自我组织


      敏捷测试人员是自组织敏捷团队的组成部分。团队文化贯彻于敏捷测试理念。当开发人员、系统管理员、分析员、数据库专家和客户团队持续关注测试和测试自动化,测试人员就会获得全新的视角。自动化测试很困难,但是当整个团队都在为此努力时就会简单得多。当大家具有多重技能和多层次视角时,任何测试问题都会更容易解决。 


      当敏捷团队面对一个严重问题时,比如进度障碍或者构建失败,该问题将是所有人的问题。最高优先级的问题需要整个团队解决。团队应该立刻讨论并决定解决的办法和相关参与人员。 


    关注人


      只有优秀的员工出色地工作,项目才会成功。敏捷价值和准则的宗旨是确保个人和团队成功。敏捷团队成员应该有安全感。不必担心因犯错受指责或者失去工作。敏捷团队成员互相尊重并认可个人成就。敏捷团队的所有人应该有机会提高和发展他们的技能。敏捷团队以可持续的步伐前进,使他们能够遵循严格的实践和保持崭新的视角。正如敏捷宣言所说,我们重视个人和合作超过过程和工具。 


    享受乐趣


      在我们看来,测试人员的理想团队是:所有成员协作,从项目的开始一直到结束,利益相关者与开发团队共同工作,整个团队负责质量和测试。相信很多人都认为每个人都应该在工作中找到乐趣。敏捷开发珍视敏捷测试人员对工作的激情。 


      敏捷测试人员的工作特别令人满意,因为我们的角度和技能对团队产生了真正的价值。 


     


     


    敏捷测试人员应该做什么?                                                                           


     


    看了这么多,你一定问:


    测试人员在敏捷团队中应该具备什么技能?


    测试人员在敏捷团队中从事哪些具体的工作?


     


      在敏捷软件开发过程中开展的测试就可以被称作是敏捷软件测试。因此,敏捷软件测试并不是一个与敏捷软件开发同一层次的划分,而是敏捷软件开发中的一部分,与传统的测试不同,敏捷软件测试并不是一个独立的过程,相反,它与整个敏捷开发中的其他活动交织在一起,处处都能看到它的影子。由于敏捷软件测试并不倾向于一个单独的过程定义,本人认为从敏捷软件测试与传统测试观点的比较、敏捷软件测试中采用的方法、测试工程师在敏捷软件测试过程中的工作等方面来阐述。


     


    回答的很含糊,个人认为敏捷测试人员应该具备的两个主面。


      首先,接纳并理解敏捷的核心价值观(沟通,简单,反馈,勇气,尊重、学习、分享)。


          其次,测试人员应该具备测试基本技能,当然,可以擅长某个领域,如,探索性测试、单元测试。善于学习与分享,以学习的方式不断的提高自身去适应团队的需求。 


         我想说的是,不管是从传统开发模式转到敏捷测试,还是重新组建一个敏捷的测试团队。并不是一蹴而就的事儿,需要长期的学习、摸索与改进。当然,前提是以敏捷的价值观为指导思想。


     


    -------------------------------------------------------------


    本文引用资料:


    段念《什么是敏捷软件测试》


    《IBM敏捷测试的最佳实践》


    《敏捷软件测试:测试人员与敏捷团队的实践指南》

    虫师 http://www.cnblogs.com/fnng/archive/2013/02/03/2891246.html

    展开全文
  • 敏捷开发流程

    千次阅读 2015-08-31 20:27:22
    随着带的团队做的事情越来越多, 发布的产品也越来越多, 关于软件开发流程的思考也越来越多.前段时间的高效虚拟自适应团队是在历经困难后磨练出来的方法的总结, 在此基础上,又经过几个版本发布的洗礼,对之前的认识...

    随着带的团队做的事情越来越多, 发布的产品也越来越多, 关于软件开发的流程的思考也越来越多.前段时间的高效虚拟自适应团队是在历经困难后磨练出来的方法的总结, 在此基础上,又经过几个版本发布的洗礼,对之前的认识又有了更新,更深入的看法. 在此特提炼出一套方法论, 供大家参考.

        一个软件从开发到上市(我们抛去维护部分), 一般需要经历阶段有 需求分析, 方案设计, 开发方案设计(包括概要设计, 详细设计等), 测试, 交付. 相信这些名词在软件工程中大家都能找得到, 那在这些过程中, 具体怎么实施呢?

        先看下面的流程图:

        卓有成效的敏捷开发流程

    一. 前期准备阶段

        有很多人不太重视前期的准备, 或者不太在意这方面的事情. 还有一个问题, 前期的准备要准备到什么程度?

        在我这里, 前期要做好三件事: 需求分析工作, 数据分析工作, 概要开发方案

        需求分析: 这部分就是我们的专业需求人员所要处理的事情. 主要负责把本次版本中的功能分析清楚.我们一直强调一点, "需求要明确", 不允许在需求文档中出现类似"跟XXX一样"等这种含混不清的字眼. 一般来讲, 分析到此业务的背景, 解决的问题, 用户的操作场景, 有这些信息有可以了.

        数据分析: 尤其在我们的计价软件中, 定额库是不可缺少的东西. 他是你程序能够运行的前提.对于数据如何制作, 用何种方式制作能,制作成什么格式是最省力的, 对开发, 对数据人员的加工量是最少的, 能否支持程序运行. 数据的存储的介质,格式决定了后面的开发方案

        开发方案分析: 目标达到能说清楚这件事怎么做就可以了. 内容格式方面可以自由扩展. 可以以下面的我的分析方案为参考:

       可参考我之前的博客:<<概要设计 --需求定义及描述方式>>

         http://blog.sina.com.cn/s/blog_48258fbe0100b54a.html

        卓有成效的敏捷开发流程

      图2(需求分析格式)

       

     二. 方案评审

        这一步是必须的. 让业务专家, 或者有经验的人给你把下关.这样对你的方案是一个很大的补充. 一个人的想法很难保证想的很全, 所以, 可以经过这个环节进一步充实你的方案.等这一步完成后, 你会形成项目列表. 就是针对每个开发功能, 拆解为详细的开发步骤, 并估算出工时, 如下图所示:

       卓有成效的敏捷开发流程

      图3(任务分析明细图)

    这样有助于你完成更为详细的开发计划. 一定要把任务项列细了, 越细, 对后面的进度控制就越有帮助.

     

    三. 项目启动会议

        正如我上上篇文章所说, 这个过程的好坏会对后面的开发任务有很大的影响.在这个过程, 重点是进行需求交底. 把前面的分析结果再加上已经评审通过的内容做成PPT, 给整个团队成员做讲解. 让团队中的每个成员都能知道

         我们很难保证让团队中的每一个人都能把所有的业务都理解的很清楚, 这是很难办到的, 但可以保证的是,当这个任务为某个人做的时候, 他会更专心的去听这块内容, 对于要执行者,他是最为关注的. 这样当需求交底完成的, 可能是大部分人对需求都有所了解, 理解度在20%~60%左右吧, 但执行此任务的人理解度应该能达到90%左右. 不用担心, 我们后面有办法让那些只理解20%的人也能掌握另外的没掌握的内容.

        当需求交底完成后, 就要开始进行方案交底了, 一般你会把之前分析的内容给大家讲出来, 并给出自己的一套默认的开发方案,然后由大家来评审这个方案如何.

        在这个过程,有开发, 有测试, 有需求, 有数据,都会从不同的角度去分析此问题.在讨论过程中,那些本来可能还是太懂的人, 结过这么讨论,就会更明白了许多. 这样, 其理解度会上长到50%应该是没问题的.做为主持者, 当你发现某些人确实不在状态时,可采用单独提问方式来让他加深记忆,这都是可以的.

        还有不太清楚业务的, 没关系, 下面我们就要根据前面敲定的方案来排定任务了. 因为已经经过了前面的方案讨论, 所以对开发的时间应该有所把握, 这时,对于不清楚业务而无法估算出时间, 或者为了估算出正确的时间以至不会让自己任务拖延的, 也要再熟悉一遍需求. 经过这样, 需求基本上就都搞清楚了.那最后就要出我们的作战图了:

       卓有成效的敏捷开发流程

       图4(作战图示例)

     

        之前也说过, 作战图的作用, 就是把事情盘点清楚(当然你也可以理解为"网络图"), 让每一个人所做的的任务都能具体到整个过程的位置, 地位, 清楚自己的任务在整个项目中处在什么样的关键位置上.

        这就是作战图的优势, 把团队的目标凝聚在一起.

    四. 迭代开发

       如上幅图所示, 我们有很多任务点, 任务项, 我如何能让在开发过程中, 让我们的团队更具有凝聚力, 更能向上呢, 答案就是自适应团队. 那如何才能实现呢.

        那就是短周期迭代. 我们可以把每一个任务做成一个小周期的迭代. 你这个迭代必须是有交付物的, 没有交付物, 那就没办法验证你的成果.

        在这个过程中, 我们只需要回答两个问题就足够了: 1. 能不能用. 2.有什么用. 当你进行完这个迭代后能回答这两个问题, 那么, 我就可以认为这个迭代完成, 可以进行一下个周期的迭代.

        以前我们在排定任务的时候, 总是在想着这个任务开发完成后再交由测试去测.这样相当于开发与测试在并行, 相互的交集就比较少. 开发只管开发的事, 完了后修改BUG就行了. 而测试呢, 只需求不停的测试版本就行了, 什么也不用管. 这样带来的问题就是修改BUG不及时, 有可能会出现开发成了这个功能好久后测试才提出这个问题, 开发再去修改. BUG越往后修改效率就越差的. 所以, 应该想办法让任务风险前移.

        当我给定一个开发任务时, 当他提交时, 应该是严格结过测试, 需求确认的. 测试的验证, 保证了该功能是"能用"的问题, 而需求的评审通过意味着该功能的"有用的", 自然也就是有价值的. 有用, 但不能用, 价值无法传递出去; 能用(可以使用), 但没用(此功能没有意义), 相当于做无用功. 所以在交付时, 一定是回答了"能不能用", "有什么用"之后的. 

        这样, 在排定任务时, 就把开发, 测试, 需求无形中绑定在一起了, 自适应何愁不来.

        在迭代开发中, 过程监控的方式手段很多, 比如我们常用的: 晨会, 夕会, 周会, 每日汇报. 项目可的可视化方式也有很多, 比如常用的任务燃烧图, BUG趋势图, 明细任务显示图等.   

        说到这不得不提下每日汇报的内容. 每日汇报, 就是把当前的工作内容以可视化的方式呈现出来. 有本书叫"一页纸项目管理", 里面介绍的方法就很好, 我又把它本地化了下, 显示的方式如下图所示:

     卓有成效的敏捷开发流程

      图5(每日汇报明细)

      点击查看大图

     

        这种方式能让你控制每一个小的迭代细节中, 能让你的控制更加周密. 大家可以不防试试.

     

     关于任务任务燃烧图, 他是从整体项目上对你当前产品的进度做出的评价, 有利于你及时调整项目中的瓶颈问题, 如下图所示的燃烧图: 他的做法就是总工时, 已剩余工时之前的关系来决定的.

        卓有成效的敏捷开发流程

     图7(进度控制超前的燃烧图)

    卓有成效的敏捷开发流程

     图8(进度失控的项目)

      结合这两种分析方式, 就可以看出项目中存在风险的项目是什么了.

    五. 集成测试

        在这个过程中, 最重要的反馈产品质量的就应该属BUG趋势图了, 可以反应出当前产品的BUG曲线, 来预测产品的质量. 关于BUG管理工具方面, 现在市面上也有很多, 比较有名的像BUGFree之类的, TD也不错的, 不要收费比较高.

     

    六. 最后就是发版了.

       自然要经过评审, 确认本次版本中依然存在的问题, 解决的问题内容.



    敏捷开发(Agile)是现在时髦的一个软件开发工程管理方式,其中的很多特征,例如scrum,pair coding,standup meeting等,有很多文章描述,这里我想聊一下敏捷开发中的文档和需求分析。


    在传统的软件工程中,无论是瀑布式还是所谓的V型模式或测试驱动模式,基本上需求分析都是要进行的第一步,然后是概要设计,详细设计,编码和单元测试。传统的软件工程对文档要求比较高,而很多公司也为自己做过的大量文档而骄傲,标榜为规范。对于文档量很少甚至没有的软件项目斥之为山寨。

    典型的,在这个项目过程中,需求分析占20-30%的时间,然后概要设计20%左右,详细设计也基本上20%左右,编码通常仅仅占10%-15%,剩余的时间机动给测试和需求变更。一旦需求变更——这个几乎是一定会发生的,根据长鞭效应,就会导致一连串的变更,设计,代码和测试,一切都随之变动。最后往往导致所谓的软件灾变。就是软件本身跟不上业务的变动,发布时间一再推迟。

    还有重要的一点,就我看到的程序员,几乎没有一个喜欢写文档的,通常把写文档归于无聊,无用的工作。大量的文档任务对士气是一个很大的打击。


    在敏捷开发中,号称拥抱变化,在一定程度上,能够降低需求变更和文档对项目的负面影响。

    首先,有两点,是我们看待需求的基础:

    第一,需求和设计是不能分开的,设计是要实现需求所要求的功能,需求也是在现在技术条件许可下的对期望值的折中。

    第二,绝大多数客户实际上并不了解他们的需要,也不清楚他们想要什么产品。这一点,我相信在传统开发过程中,为不断的需求变更头痛的人一定是有体会的。(不过这个你可不要对你的客户说哦,人家会不高兴的)


    于是,在敏捷开发中,需求不再是一个一次性的工作,而是一个伴随整个项目进行的,逐步细化的工作。

    我们在开发中,设计和需求是混在一起进行的。设计文档有两种,Feature Design,这个可以说是功能设计,也就是类似与原来软件工程中的需求分析吧,另外一种就是Technical Design, 也就是类似原来软件工程中概要设计。

    不过不要把Feature Design想象成传统软件工程中动辄几百页得需求分析,通常一个一年的项目,这个Feature Design也就10页左右的文档量而已,基本上就是非常粗略地大颗粒地描述要实现的功能而已。往往只描述要达到的结果和效果,对具体的UI,业务流程或者游戏角色等不做描述。

    至于Technical design呢,文档量也不大,基本上就是模块划分,接口模式(不是格式哦),关键算法和数据结构等等框架的设计。对具体的数据格式和类型不做定义。

    至于费时的详细设计,通常由程序员完成的,在敏捷开发中是真正省略了,是依靠代码的可读性来实现。敏捷的观点是:好的代码本身就是最好的文档。

    总之,文档已经很弱化了,基本上就是一个design spec,当然对于软件自身的可读性和注释要求要多一些


    敏捷开发讲究的轻量快速迭代。

    也就是需求和设计实际上在一起进行的,进行的同时几乎就开始写代码。例如有了一个模糊的需求,就有一个前进的方向,例如可以写一些框架代码,定义一些消息机制和自动机的状态等,写一些接口类,基类,制定设计模式等。

    进一步细一些的需求出来,就可以写一些派生类和执行逻辑。继续地,更进一步的需求就会表现在一些派生类上成员和成员函数的添加。就这样逐步细化。

    敏捷开发中有迭代(Iteration)和里程碑(milestone)的概念,实际上开发的过程是和用户不断交流的过程,每个迭代基本上指实现一个或几个小Features,甚至是Feature中的一个部分,但是敏捷开发要求保证每个迭代出来的产品是能够使用和能够测试的,这样就可以有基础和客户交流获得进一步详细的需求。换句话说,就是每一吃迭代的工作都有可能得到用户的认可。

    每个Milestone可以根据时间来划分,更多是按功能实现的需求的来划分,也就是每个milestone能够推出一个部分满足客户一些需求的产品。

    所以在开发中,敏捷开发是一个小量递增,小步快走的过程,需求是逐步细化,设计也是逐步深入的,代码也是伴随这个过程不断生长的。需求分析是作为一个交互的过程,是在整个过程中和design/coding/test混合在一起。

    在我们的开发过程中,很常见的情况是最初的feature design只实现了其中70%的功能,但是却另外添加了起初没想到的30%的功能。这也许就是敏捷说声称的“拥抱变化”吧。

    这个就是现在时髦的敏捷编程啊,我感觉不错,效率比以前高多了,员工士气也比以前高。毕竟绝大多数程序员是不喜欢写文档的。

    好一些的项目管理,往往能够把本项目的alpha测试和debugging的时间和下一个项目的design,甚至frame coding的阶段重合在一起,以最大限度提升效率,或者说榨取程序员的价值。


    http://blog.sina.com.cn/s/blog_6296cebc0100pybx.html


    敏捷开发(Agile development)

    目录

    [隐藏]

    敏捷开发概述

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

    敏捷开发的路线[1]

      Image:敏捷开发的路线图.jpg

      图:敏捷开发的路线图

      Test-Driven Development,测试驱动开发。

      它是敏捷开发的最重要的部分。在ThoughtWorks,我们实现任何一个功能都是从测试开始,首先对业务需求进行分析,分解为一个一个的Story,记录在Story Card上。然后两个人同时坐在电脑前面,一个人依照Story,从业务需求的角度来编写测试代码,另一个人看着他并且进行思考,如果有不同的意见就会提出来进行讨论,直到达成共识,这样写出来的测试代码就真实反映了业务功能需求。接着由另一个人控制键盘,编写该测试代码的实现。如果没有测试代码,就不能编写功能的实现代码。先写测试代码,能够让开发人员明确目标,就是让测试通过。

      Continuous Integration,持续集成。

      在以往的软件开发过程中,集成是一件很痛苦的事情,通常很长时间才会做一次集成,这样的话,会引发很多问题,比如 build未通过或者单元测试失败。敏捷开发中提倡持续集成,一天之内集成十几次甚至几十次,如此频繁的集成能尽量减少冲突,由于集成很频繁,每一次集成的改变也很少,即使集成失败也容易定位错误。一次集成要做哪些事情呢?它至少包括:获得所有源代码、编译源代码、运行所有测试,包括单元测试、功能测试等;确认编译和测试是否通过,最后发送报告。当然也会做一些其它的任务,比如说代码分析、测试覆盖率分析等等。在我们公司里,开发人员的桌上有一个火山灯用来标志集成的状态,如果是黄灯,表示正在集成;如果是绿灯,表示上一次集成通过,开发人员在这时候获得的代码是可用而可靠的;如果显示为红灯,就要小心了,上一次集成未通过,需要尽快定位失败原因从而让灯变绿。在持续集成上,我们公司使用的是自己开发的产品CruiseControl。

      Refactoring,重构。

      相信大家对它都很熟悉了,有很多很多的书用来介绍重构,最著名的是Martin的《重构》,Joshua的《从重构到模式》等。重构是在不改变系统外部行为下,对内部结构进行整理优化,使得代码尽量简单、优美、可扩展。在以往开发中,通常是在有需求过来,现在的系统架构不容易实现,从而对原有系统进行重构;或者在开发过程中有剩余时间了,对现在代码进行重构整理。但是在敏捷开发中,重构贯穿于整个开发流程,每一次开发者check in代码之前,都要对所写代码进行重构,让代码达到clean code that works。值得注意的是,在重构时,每一次改变要尽可能小,用单元测试来保证重构是否引起冲突,并且不只是对实现代码进行重构,如果测试代码中有重复,也要对它进行重构。

      Pair-Programming,结对编程。

      在敏捷开发中,做任何事情都是Pair的,包括分析、写测试、写实现代码或者重构。Pair做事有很多好处,两个人在一起探讨很容易产生思想的火花,也不容易走上偏路。在我们公司,还有很多事都是Pair来做,比如Pair学习,Pair翻译,Pair做PPT,关于这个话题,钱钱同学有一篇很有名的文章对它进行介绍,名为Pair Programming (结对编程)。

      Stand up,站立会议。

      每天早上,项目组的所有成员都会站立进行一次会议,由于是站立的,所以时间不会很长,一般来说是15-20分钟。会议的内容并不是需求分析、任务分配等,而是每个人都回答三个问题:1. 你昨天做了什么?2. 你今天要做什么? 3. 你遇到了哪些困难?站立会议让团队进行交流,彼此相互熟悉工作内容,如果有人曾经遇到过和你类似的问题,那么在站立会议后,他就会和你进行讨论。

      Frequent Releases,小版本发布。

      在敏捷开发中,不会出现这种情况,拿到需求以后就闭门造车,直到最后才将产品交付给客户,而是尽量多的产品发布,一般以周、月为单位。这样,客户每隔一段时间就会拿到发布的产品进行试用,而我们可以从客户那得到更多的反馈来改进产品。正因为发布频繁,每一个版本新增的功能简单,不需要复杂的设计,这样文档和设计就在很大程度上简化了。又因为简单设计,没有复杂的架构,所以客户有新的需求或者需求进行变动,也能很快的适应。

      Minimal Documentation,较少的文档。

      其实敏捷开发中并不是没有文档,而是有大量的文档,即测试。这些测试代码真实的反应了客户的需求以及系统API 的用法,如果有新人加入团队,最快的熟悉项目的方法就是给他看测试代码,而比一边看着文档一边进行debug要高效。如果用书面文档或者注释,某天代码变化了,需要对这些文档进行更新。一旦忘记更新文档,就会出现代码和文档不匹配的情况,这更加会让人迷惑。而在敏捷中并不会出现,因为只有测试变化了,代码才会变化,测试是真实反应代码的。这时有人会问:代码不写注释行吗?一般来说好的代码不是需要大量的注释吗?其实简单可读的代码才是好的代码,既然简单可读了,别人一看就能够看懂,这时候根本不需要对代码进行任何注释。若你觉得这段代码不加注释的话别人可能看不懂,就表示设计还不够简单,需要对它进行重构。

      Collaborative Focus,以合作为中心,表现为代码共享。

      在敏捷开发中,代码是归团队所有而不是哪些模块的代码属于哪些人,每个人都有权利获得系统任何一部分的代码然后修改它,如果有人看到某些代码不爽的话,那他能够对这部分代码重构而不需要征求代码作者的同意,很可能也不知道是谁写的这部分代码。这样每个人都能熟悉系统的代码,即使团队的人员变动,也没有风险。

      Customer Engagement ,现场客户。

      敏捷开发中,客户是与开发团队一起工作的,团队到客户现场进行开发或者邀请客户到团队公司里来开发。如果开发过程中有什么问题或者产品经过一个迭代后,能够以最快速度得到客户的反馈。

      Automated Testing ,自动化测试。

      为了减小人力或者重复劳动,所有的测试包括单元测试、功能测试或集成测试等都是自动化的,这对QA人员提出了更高的要求。他们要熟悉开发语言、自动化测试工具,能够编写自动化测试脚本或者用工具录制。我们公司在自动化测试上做了大量的工作,包括Selenium开源项目。

      Adaptive Planning,可调整计划。

      敏捷开发中计划是可调整的,并不是像以往的开发过程中,需求分析->概要设计->详细设计->开发 ->测试->交付,每一个阶段都是有计划的进行,一个阶段结束便开始下一个阶段。而敏捷开发中只有一次一次的迭代,小版本的发布,根据客户反馈随时作出相应的调整和变化。

      敏捷开发过程与传统的开发过程有很大不同,在这过程中,团队是有激情有活力的,能够适应更大的变化,做出更高质量的软件。

    敏捷开发的特点

      敏捷方法主要有两个特点,这也是其区别于其他方法,尤其是重型方法的最主要特征:

      (1)敏捷开发方法是“适应性”(Adaptive)而非“预设性” (Predictive)。

      这里说的预设性,可以通过一般性工程项目的做法理解,比如土木工程,在这类工程实践中,有比较稳定的需求,同时建设项目的要求也相对固定,所以此类项目通常非常强调施工前的设计规划。只要图纸设计得合理并考虑充分,施工队伍可以完全遵照图纸顺利建造,并且可以很方便地把图纸划分为许多更小的部分交给不同的施工人员分别完成。

      然而,在软件开发的项目中,这些稳定的因素却很难寻求。软件的设计难处在于软件需求的不稳定,从而导致软件过程的不可预测。但是传统的控制项目模式都是试图对一个软件开发项目在很长的时间跨度内做出详细的计划,然后依计划进行开发。所以,这类方法在不可预测的环境下,很难适应变化,甚至是拒绝变化。

      与之相反的敏捷方法则是欢迎变化,目的就是成为适应变化的过程,甚至能允许改变自身来适应变化。所以称之为适应性方法。      (2)敏捷开发方法是“面向人” (people oriented)而非“面向过程”(process oriented)。

      Matin Flower认为:“在敏捷开发过程中,人是第一位的,过程是第二位的。所以就个人来说,应该可以从各种不同的过程中找到真正适合自己的过程。”这与软件工程理论提倡的先过程后人正好相反。 (续致信网上一页内容)

      在传统的软件开发工作中,项目团队分配工作的重点是明确角色的定义,以个人的能力去适应角色,而角色的定义就是为了保证过程的实施,即个人以资源的方式被分配给角色,同时,资源是可以替代的,而角色不可以替代。

      然而,传统软件开发的这些方法在敏捷开发方式中被完全颠覆。敏捷开发试图使软件开发工作能够利用人的特点,充分发挥人的创造能力。

      敏捷开发的目的是建立起一个项目团队全员参与到软件开发中,包括设定软件开发流程的管理人员,只有这样软件开发流程才有可接受性。同时敏捷开发要求研发人员独立自主在技术上进行决策,因为他们是最了解什么技术是需要和不需要的。再者,敏捷开发特别重视项目团队中的信息交流,有调查显示:“项目失败的原因最终都可追溯到信息没有及时准确地传递到应该接受它的人。”

    敏捷开发的价值观

      实际上敏捷开发运动在数年前就开始了,但它正式开始的标志是2001年2月的“敏捷宣言”(Agile Manifesto),这项宣言是由17位当时称之为“轻量级方法学家”所编写签署的,他们的价值观是:个人与交互重于开发过程与工具;可用的软件重于复杂的文档;寻求客户的合作重于对合同谈判;对变化的响应重于始终遵循固定的计划。

      个人与交互重于开发过程与工具的原因:一个由优秀的人员组成但使用普通的工具,要比使用优秀的工具但由普通人组成、紊乱的小组做得更好。多年来人们花了很多时间试图建立一种过程,以便把人当作机器上的一个可以替代的齿轮,但结果却并不成功。敏捷过程是承认每个人都有特定的能力(以及缺点)对之加以利用,而不是把所有的人当成一样来看待。更重要的是,在这样的理念下,几个项目做下来,每个人的能力都从中得以提高。这种人的能力的提高,对公司是无价之宝。而不至于把人当成齿轮,随着时间的推移,人的能力慢慢被消耗掉,最后变成留之无用、弃之可惜的尴尬人物。

      可用的软件重于复杂的文档的原因:可用的软件可以帮助开发人员在每次迭代结束的时候,获得一个稳定的、逐渐增强的版本。从而允许项目尽早开始,并且更为频繁的收集对产品和开发过程的反馈。随着每次迭代完成软件的增长,以保证开发小组始终是处理最有价值的功能,而且这些功能可以满足用户的期待。

      寻求客户的合作重于对合同的谈判的原因:敏捷开发小组希望与项目有关的所有团体都在朝共同方向努力,合同谈判有时会在一开始就使小组和客户出于争执中。敏捷开发追求的是要么大家一起赢,要么大家一起输。换句话说,就是希望开发小组和客户在面对项目的时候,以一种合作的态度共同向目标前进。当然,合同是必需的,但是如何起草条款,往往影响到不同的团体是进行合作式的还是对抗式的努力。

      对变化的响应重于始终遵循固定的计划的原因:敏捷开发认为对变化进行响应的价值重于始终遵循固定的计划。他们最终的焦点是向用户交付尽可能多的价值。除了最简单的项目以外,用户不可能知道他们所需要的所有功能的每个细节。不可避免地在过程中会产生新的想法,也许今天看起来是必需的功能,明天就会觉得不那么重要了。随着小组获得更多的知识和经验,他们的进展速度会比开始的时候期望值慢或者快。对敏捷开发来说,一个计划是从某个角度对未来的看法,而具有多个不同的角度看问题是有可能的。

    项目的敏捷开发方法

      敏捷方法很多,包括 Scrum、极限编程、功能驱动开发以及统一过程(RUP)等多种法,这些方法本质实际上是一样的,敏捷开发小组主要的工作方式可以归纳为:作为一个整体工作; 按短迭代周期工作; 每次迭代交付一些成果; 关注业务优先级; 检查与调整。下图是典型的敏捷过程总图,下面介绍其有关的特点。

      Image:敏捷过程总图.gif

      1、敏捷小组作为一个整体工作

      项目取得成功的关键在于,所有项目参与者都把自己看成朝向一个共同目标前进的团队的一员。“扔过去不管”的心理不是属于敏捷开发。设计师和架构师不会把程序设计“扔”给编码人员;编码人员也不会把只经过部分测试的代码“扔”给测试人员,一个成功的敏捷开发小组应该具有“我们一起参与其中的思想”, “帮助他人完成目标”这个理念是敏捷开发的根本管理文化。当然,尽管强调一个整体,小组中应该有一定的角色分配,各种敏捷开发方法角色的起名方案可能不同,但愿则基本上是一样的。第一个角色是产品所有者,他的主要职责包括:确认小组成员都在追求一个共同的目标前景;确定功能的优先等级,以便总是处理最有价值的功能;作出可以使项目的投入产生良好回报的决定。产品所有者通常是公司的市场部门或者产品管理部门的人员,在开发内部使用的软件的时候,产品所有者可能是用户、用户的上级、分析师,也可能是为项目提供资金的人。

      2、敏捷小组按短迭代周期工作

    在敏捷项目中,总体上并没有什么上游阶段、下游阶段,你可以根据需要定义开发过程在初始阶段可以有一个简短的分析、建模、设计,但只要项目真正开始,每次迭代都会做同样的工作(分析、设计、编码、测试。等等)。迭代是受时间框限制的,也就是说即使放弃一些功能,也必须结束迭代。时间框一般很短,大部分是 2~4周,在 Scrum中采用的是 30个日历天,也就是 4 周。迭代的时间长度一般是固定的,但也有报告说,有的小组在迭代开始的时候选择合适的时间长度。

      3、敏捷小组每次迭代交付一些成果

      比选择特定迭代长度更重要的,是开发小组在一次迭代中要把一个以上的不太精确的需求声明,经过分析、设计、编码、测试,变成可交付的软件(称之为功能增量)。当然并不需要把每次迭代的结果交付给用户,但目标是可以交付,这就意味着每次迭代都会增加一些小功能,但增加的每个功能都要达到发布质量。每次迭代结束的时候让产品达到可交付状态十分重要,但这并不意味着要完成发布的全部工作,因为迭代的结果并不是真正发布产品。假定一个小组需要在发布产品之前对软硬件进行为期两个月的“平均无故障时间”(MTBF)测试,他们不可能缩短这两个月的时间,但这个小组仍然是按照 4 周迭代,除了MTBF测试,其它都达到了发布状态。

      4、敏捷小组关注业务优先级

      敏捷开发小组从两个方面显示出他们对业务优先级的关注。首先,他们按照产品所有者制定的顺序交付功能,而产品所有者一般会按照组织在项目上的投资回报最大化的方式来确定优先级,并且把它组织到产品发布中去。要达到这个目的,需要综合考虑开发小组的能力,以及所需功能的优先级来建立发布计划。在编写功能的时候,需要使工能的依赖性最小化。如果开发一个功能必须依赖其它 3 个功能,那产品所有者这就很难确定功能优先级。功能完全没有依赖是不太可能的,但把功能依赖性控制在最低程度还是相当可行的。

      5、敏捷小组检查与调整

      任何项目开始的时候所建立的计划,仅仅是一个当前的猜测。有很多事情可以让这样的计划失效:项目成员的增减,某种技术比预期的更好或更差,用户改变了想法,竞争者迫使我们做出不同的反应,等等。对此,敏捷小组不是害怕这种变化,而是把这种变化看成使最终软件更好地反映实际需要的一个机会。每次新迭代开始,敏捷小组都会结合上一次迭代中获得新知识做出相应调整。如果认为一些因素可能会影响计划的准确性,也可能更改计划。比如发现某项工作比预计的更耗费时间,可能就会调整进展速度。也许,用户看到交付的产品后改变了想法,这就产生反馈,比如他发现他更希望有另一项功能,或者某个功能并不像先前看得那么重。通过先期发布增加更多的用户希望的功能,或者减少某些低价值功能,就可以增加产品的价值。迭代开发是在变与不变中寻求平衡,在迭代开始的时候寻求变,而在迭代开发期间不能改变,以期集中精力完成已经确定的工作。由于一次迭代的时间并不长,所以就使稳定性和易变性得到很好的平衡。在两次迭代期间改变优先级甚至功能本身,对于项目投资最大化是有益处的。从这个观点来看,迭代周期的长度选择就比较重要了,因为两次迭代之间是提供变更的机会,周期太长,变更机会就可能失去;周期太短,会发生频繁变更,而且分析、设计、编码、测试这些工作都不容易做到位。综合考虑,对于一个复杂项目,迭代周期选择4周还是有道理的。

      MIT Sloan Management Review(麻省理工学院项目管理评论)所刊载的一篇为时两年对成功软件项目的研究报告,报告指出了软件项目获得成功的共同因素,排在首位的是迭代开发,而不是瀑布过程。其它的因素是:

      1、至少每天把新代码合并到整个系统,并且通过测试,对设计变更做出快速反应

      2、开发团队具备运作多个产品的工作经验。

      3、很早就致力于构建和提供内聚的架构。

      从这个报告中所透露出的信息告诉我们,认真研究敏捷过程对软件项目的成功是非常有意义的,它的意义在于:

      1)给开发小组的自组织提供了机会

      经典项目管理就好比一个具备中央调度服务的航空管理系统,这个系统是自治的,而且是封闭的,但现实中更庞大的系统,似乎并不属于中央调度控制系统,但也同样也是有效的。假如我们开车到某个地方,我们可以任意选择所需要的路线,我们甚至不需要准确计算停车,只要我们遵守交通法规,驾驶员可以临时根据路况改变某个转弯点,在驾驶游戏规则的框架内,依照自身最大利益做出决策。成千上万的驾驶者,并不需要中央控制和调度服务,人们仅仅在简单的交通法规的框架内,就可以完成综合起来看是更庞大的目标,很多事情从管理的角度只要抓住关键点,并不需要多么复杂的规则,往往会更有效。随着系统复杂度的提高,中央控制和调度系统面临崩溃。仔细研究交通系统的特点,我们会发现这样的系统中独立的个体在一组适当的规则下运行,并不需要设计每个个体临时变更的方案,而每个个体只需要知道目标和大致的状况,他们完全可以利用自己的聪明才智来决定自己的行为。

      2)缩短了反馈通道

      敏捷过程有效运作的另一个原因是,它极大的缩短了用户与开发者、预测目标与实施状况、投资与回报之间的反馈回路。在面对不断变化的市场、业务过程以及不断发展的技术状态的时候,便需要有一种方法在比较短的时间内发展完善。事实上,所有的过程改进都不同程度的使用着戴明循环,以研究问题、测试解决方案、评估结果,进而根据已知的事实来进行改进,这就称之为基于事实的决策模式,我们都知道,这比前端预测的决策方式更加有效。

      3)易于集思广益

      敏捷过程能有效应用的另一个原因在于,它可以就一个问题集思广益。我们的经验告诉我们当一个问题发生的时候,总有某些人员知道问题所在,但他的观点却遭到忽视。例如航天飞机在起飞阶段发生爆炸,事后分析出了各种原因,但这种调查也提供给我们一个惊人的事实,就是部分工程师早就意识到这些潜在问题,却无法说服他人重视这个担忧。对这些事实的深入思考,促使我们研究我们应该采取何种管理系统,使前线工作人员的经验、观点及担忧得到充分的重视呢?

    对敏捷开发的误解

      误解一:敏捷对人的要求很高

      很多人在尝试实施敏捷时说:敏捷对人的要求太高了,我们没有这样的条件,我们没有这样的人,因此我们没法敏捷。可是,敏捷对人的要求真的那么高么? 软件归根到底还是一种创造性活动,开发人员的技术水平和个人能力对软件的质量还是起着决定性的作用,各种过程与方法只是帮助开发人员、测试人员等角色能够更好的合作,从而产生更高的生产力。不管用什么方法,开发人员的水平永远都是一个主要的因素。

      从另一个角度来看:过程和方法究竟能帮开发人员多大忙?对于技术水平较低的开发人员,敏捷方法和传统方法对他的帮助是差不多的,因此看不到显着的效果,甚至有些时候还有反效果;而随着开发人员技术水平的提高,敏捷方法能够解开对人的束缚,鼓励创新,效果也会越来越显着。

      敏捷对人的要求并不高,而且会帮助你培养各种所需的能力,当然前提是你处在真正敏捷的环境中。

      误解二:敏捷没有文档,也不做设计

      这个误解从XP开始就没有停止过,XP鼓励“在非到必要且意义重大时不写文档”。这里面提到的“必要且意义重大”是一个判断标准,并不是所有的文档都不写。例如,用户手册是不是“必要且意义重大”?这取决于客户的要求,如果客户不需要,那就不用写,如果客户需要,就一定要写;再如,架构设计文档要不要写?复杂要写,不复杂不用写。通常架构设计只需要比较简单的文档,对于有些项目,一幅简单的UML图就够了。因此,写不写,怎么写,都要根据这个文档到底有多大意义,产出和投入的比例,以及项目的具体情况决定。实际操作时可以让项目组所有人员表决决定,尽量避免由某一个人(比如lead)来决定。

      至于设计,XP奉行的是持续设计,并不是不设计。这实际上是将设计工作分摊到了每天的日常工作中,不断的设计、改善(重构),使得设计一直保持灵活可靠。至于编码前的预先设计,Kent Beck等人确实实行着不做任何预先设计的开发方式,但是对于我们这些“非大师”级开发人员,必要的预先设计还是需要的,只是不要太多,不要太细,要有将来会彻底颠覆的准备。

      误解三:敏捷好,其他方法不好

      有些人一提到敏捷就大呼好,只要是敏捷的实践就什么都好,而提到CMMI等方法就大呼不好,不管是什么只要沾上边就哪里都不好,似乎敏捷和其他方法是完全对立的。牛顿说过,我是站在了巨人的肩膀上。敏捷同样也吸取了其他方法论的优点,也是站在了巨人的肩膀上,敏捷依然保持了很多历史悠久的实践和原则,只是表现方式不同罢了。

      从另一个方面来看,方法本没有好环,好与坏取决于是否适合解决你的问题。每一种方法都有他最善于解决的问题和最佳的发挥环境,在需求稳定、软件复杂度相对不高的时代,瀑布模型也可以工作的很好,而敏捷恰好适用于变化快风险高的项目 - 这恰恰是现在很多项目的共性。

      因此选择一个方法或过程,并不是根据它是否敏捷,而应根据它是否适合。而要了解一个东西是否适合,还是要尝试之后才知道,任何没有经过实践检验的东西都不可信。

      误解四:敏捷就是XP(极限编程),就是Scrum

      XP 和Scrum只是众多敏捷方法中的两种,还有很多其他的敏捷方法。龙生九子各个不同,敏捷的这些方法看起来差别也是很大的,可是他们之所以被称为敏捷方法,就是因为他们背后的理念和原则都是相同的,这个原则就是《敏捷宣言》。学习敏捷不仅仅要学习实践,还要理解实践后的原则,不仅要理解怎么做,还要理解为什么这么做,以及什么时候不要这么做。

      即使将XP或Scrum完全的应用的你的项目中,也未见得就能成功,适合别人的东西未必就适合你。敏捷的这些实践和方法给了我们一个起点,但绝对不是终点,最适合你的方式还要由你自己在实际工作中探索和寻找。

      误解五:敏捷很好,因此我要制定标准,所有项目都要遵循着个标准

      没有哪两个项目是一样的,客户是不一样的,人员是不一样的,需求是不一样的,甚至没有什么可能是一样的。不一样的环境和问题,用同样的方法解决,是不可能解决的好的。方法是为人服务的,应该为项目团队找到最适合他们的方法,而不是先确定方法,再让团队适应这个方法。因此也不存在适合所有项目的统一的方法。任何企图统一所有项目过程的方法都是不正确的。

      同时,对于同一个团队,随着项目的进行,对需求理解的深入,对技术理解的深入,一开始适合项目的过程和方法也会渐渐的不适合。这时候也需要团队对过程进行及时的调整,保证项目的质量和效率。敏捷是动态的,而非静止不变的,因为这个世界本身就是变化的,在变化的世界使用不变的方法,是不现实的。银弹从来就没有过,在有限的将来也不会存在。


    展开全文
  • 敏捷开发流程总结

    2014-06-24 16:58:49
    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以达到...

    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以达到管中窥豹的目的。
    
    敏捷开发宣言——
    个体和交互 胜过 过程和工具
    可以工作的软件 胜过 面面俱到的文档
    客户合作 胜过 合同谈判
    响应变化 胜过 遵循计划
    虽然右项也有价值,但是我们认为左项具有更大的价值。

    以上的宣言比较抽象,基于该理念,以下是ThoughtsWork咨询公司的推崇的n个敏捷开发实践:
    Iteration
    迭代开发。可以工作的软件胜过面面俱到的文档。因此,敏捷开发提倡将一个完整的软件版本划分为多个迭代,每个迭代实现不同的特性。重大的、优先级高的特性优先实现,风险高的特性优先实现。在项目的早期就将软件的原型开发出来,并基于这个原型在后续的迭代不断晚上。迭代开发的好处是:尽早编码,尽早暴露项目的技术风险。尽早使客户见到可运行的软件,并提出优化意见。可以分阶段提早向不同的客户交付可用的版本。
    IterationPlanningMeeting
    迭代计划会议。每个迭代启动时,召集整个开发团队,召开迭代计划会议,所有的团队成员畅所欲言,明确迭代的开发任务,解答疑惑。
    Story Card/Story Wall/Feature List
    在每个迭代中,架构师负责将所有的特性分解成多个Story Card。每个Story可以视为一个独立的特性。每个Story应该可以在最多1个星期内完成开发,交付提前测试(Pre-Test)。当一个迭代中的所有Story开发完毕以后,测试组再进行完整的测试。在整个测试过程中(pre-test,test),基于Daily build,测试组永远都是每天从配置库上取下最新编译的版本进行测试,开发人员也随时修改测试人员提交的问题单,并合入配置库。
    敏捷开发的一个特点是开放式办公,充分沟通,包括测试人员也和开发人员一起办公。基于Story Card的开发方式,团队会在开放式办公区域放置一块白板,上面粘贴着所有的Story Card,按当前的开发状态贴在4个区域中,分别是:未开发,开发中,预测试中,测试中。Story Card的开发人员和测试人员根据开发进度在Story Wall上移动Story Card,更新Story Card的状态。这种方式可以对项目开发进度有一个非常直观的了解。
    在开发人员开始开发一个Story时,ta需要找来对应的测试人员讲解Story功能,以便测试人员有一致的理解,同时开始自动化系统测试脚本的开发。
    Standup Meeting
    站立会议。每天早上,所有的团队成员围在Story Wall周围,开一个高效率的会议,通常不超过15分钟,汇报开发进展,提出问题,但不浪费所有人的时间立刻解决问题,而是会后个别沟通解决。
    Pair Programming
    结对编程是指两个开发人员结对编码。结对编程的好处是:经过两个人讨论后编写的代码比一个人独立完成会更加的完善,一些大的方向不至于出现偏差,一些细节也可以被充分考虑到。一个有经验的开发人员和一个新手结对编程,可以促进新手的成长,保证软件开发的质量。
    CI/Daily Build
    持续集成和每日构建能力是否足够强大是迭代开发是否成功的一个重要基础。基于每日构建。开发人员每天将编写/修改的代码及时的更新到配置库中,自动化编译程序每天至少一次自动从配置库上取下代码,执行自动化代码静态检查(如PCLint),单元测试,编译版本,安装,系统测试,动态检查(如Purify)。以上这些自动化任务执行完毕后,会输出报告,自动发送邮件给团队成员。如果其中存在着任何的问题,相关责任人应该及时的修改。
    可以看到,整个开发组频繁的更新代码,出现一些问题不可避免。通过测试部又在不停地基于最新的代码进行测试。新增的问题是否能够被及时发现并消灭掉,取决于自动化单元测试和系统测试能力是否足够强大,特别是自动化系统测试能力。如果自动化测试只能验证最简单的操作,则新合入代码的隐患将很难被发现,并遗留到项目后期,形成大的风险。而实际上,提升自动化测试的覆盖率是最困难的。
    Retrospect
    总结和反思。每个迭代结束以后,项目组成员召开总结会议,总结好的实践和教训,并落实到后续的开发中。
    ShowCase
    演示。每个Story开发完成以后,开发人员叫上测试人员,演示软件功能,以便测试人员充分理解软件功能。
    Refactoring
    重构。因为迭代开发模式在项目早期就开发出可运行的软件原型,一开始开发出来的代码和架构不可能是最优的、面面俱到的,因此在后续的Story开发中,需要对代码和架构进行持续的重构。迭代开发对架构师要求很高。因为架构师要将一个完整的版本拆分成多个迭代,每个跌倒由拆分成很多Story,从架构的角度看,这些Story必须在是有很强的继承性,是可以不断叠加的,不至于后续开发的Story完全推翻了早期开发的代码和架构,同时也不可避免的需要对代码进行不断完善,不断重构。
    TDD
    测试驱动开发。正如上面讲的,迭代开发的特点是频繁合入代码,频繁发布版本。测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。
    
    敏捷方法反思:
    自己参与的敏捷开发项目总的来说不是很成功,这可能也是业界遇到的通病:
    1、对于全新的软件,在项目早期测试人员就参与并实现自动化测试脚本,但实际上软件的界面等非常不稳定,导致测试人员返工的工作量很大。
    2、对于全新的软件,资料人员过早参与,后期返工工作量大,原因同第一点。
    3、自动化系统测试工作量大,测试人员投入大量的精力在使测试自动化起来,而没有足够的精力放在真正的测试软件的功能是否正常。即便是这样,自动化系统测试脚本也多流于形式,测不出深层次的问题。
    4、代码动态检查工具执行不理想,流于形式。没有人对Purify有深刻的理解和应用经验,报告中查出来很多告警,但不知如何消除。
    5、由于快速搭建原型,没有在架构上进行严谨的设计,导致后期一直堆砌代码。
    6、异地开发模式下无法实现快速构建、快速交付,团队普遍感觉很疲惫。
    7、敏捷开发不提倡加班,但实际上不管是CMM还是Agile哪一种开发模式跟是否加班都没有必然联系。

     

    ---------------------------------------------------------------

    下面介绍一篇用敏捷开发管理项目的经验:

    http://www.cnblogs.com/huige-you/p/3802542.html.   ------在外包的这几年,技术和管理经验总结

    展开全文
  • 【互联网公司的“敏捷开发流程是怎么样的,每个职位的角色和分工是什么?】 前言================================================ 1.本回答从属于“IT修真院”收藏夹系列第二篇,第一篇是IT职业介绍。 第一...
  • 基于scrum的敏捷开发流程总结

    千次阅读 2018-11-05 16:39:40
    本文主要来源于华为软件开发流程,同时根据在创业团队的实践在细节上稍有修改。 需求管理 先了解几个概念: IR(Initial Requirement):原始需求。这种需求来自客户,一般由产品经理/需求经理编写。如果是研发内部...
  • 什么是敏捷开发流程

    千次阅读 2018-08-22 08:15:51
    今天给大家分享一下,java项目中需要使用的敏捷开发流程   1.背景介绍   在很久以前,软件项目的开发都是以年来计算的,这代表什么意思呢 ?需求设计了半年多,方案设计做了半年多,开发了三年多, 测试了半年...
  • Scrum敏捷开发流程

    千次阅读 2017-05-01 14:17:56
    Scrum敏捷开发流程的要点
  • 敏捷开发流程学习笔记

    千次阅读 2018-04-03 21:50:24
    什么是敏捷开发敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。我理解它仅仅是一种开发方法,更是为了应对激烈竞争和快速需求变化的一种价值观和商业模式。敏捷提倡以人为核心,敏捷...
  • Scrum敏捷开发流程主要包扩三个角色、四个会议和个三物件。 三个角色 Scrum团队中包括三个角色,他们分别是产品负责人、开发团队和 项目的直接管理者(Scrum Master)。 Scrum 团队是自组织、跨职能的完整...
  • 移动互联网敏捷开发流程

    千次阅读 2016-07-13 11:43:58
    一周或者两周一个版本,由于ios的发版流程需要appstore审核,流程比较复杂,可安排android的发版时间比ios提前两三天,由android版本经过灰度用户验证后,再灰度ios   2. 输出需求列表 由产品经理,产品经理...
  • 我的敏捷开发流程

    千次阅读 2017-03-31 19:25:18
    敏捷开发流程: 按尺度大小新建问题类型:epic->story->sub-tast->bug ===========================================part0:需求收集============================================================= ====...
  • 敏捷计划典型的敏捷开发将整体工作分为一系列的发布过程,每个发布过程都是一个迭代
  • 时序图(敏捷开发流程的所有环节)

    千次阅读 2017-11-30 09:49:09
  • 软件开发模式之敏捷开发(scrum)

    万次阅读 多人点赞 2018-08-08 19:25:59
    这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...
  • 敏捷开发项目管理流程

    千次阅读 2017-09-08 13:30:27
    前段时间给大家整理了敏捷开发流程,最近在整理敏捷开发项目的流程和管理制度,其整理的项目管理规程如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家在实际...
  • 敏捷开发流程中,自动化测试涉及到下面重要四种类型的测试。 1、单元测试(Unit Test, UT) 关注某一个函数,模块的正确性,一般需要开发人员编写相关的测试代码来进行自动化测试。 可以使用对应的测试驱动...
1 2 3 4 5 ... 20
收藏数 55,688
精华内容 22,275
热门标签
关键字:

敏捷开发的流程