敏捷开发项目开展流程_scrum敏捷项目管理 开发流程 - CSDN
  • 敏捷开发流程

    千次阅读 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

    展开全文
  • 敏捷开发项目管理流程

    千次阅读 2017-09-08 13:30:27
    前段时间给大家整理了敏捷开发流程,最近在整理敏捷开发项目流程和管理制度,其整理的项目管理规程如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家在实际...


    前段时间给大家整理了敏捷开发的流程,最近在整理敏捷开发项目的流程和管理制度,其整理的项目管理规程如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家在实际嵌入到公司的过程中可以参考下,不能照搬。

    1.  目的

    规范互联网软件产品开发项目管理过程,指导开展项目研发、管理等活动。

    2.  适用范围

    本章程的作用范围为互联网软件产品开发立项至结项管理过程。

    1.对项目经理开展产品规划及设计活动以及项目管理手段和应遵循的开发流程提供了指导;

    2.对项目团队的日常管理活动及内容进行了指导;

    3.  角色及职责定义

    项目经理:

    进行产品开发过程中的业务目标、进度、成本、质量控制。

    挑选项目团队并进行团队建设,激发、鼓舞和改进团队的生产效率。

    识别项目干系人,定期向干系人汇报,并作为团队和外部的接口,屏蔽外界对团队的干扰。

    确保项目中流程被遵循,组织、监督、培训项目各实践活动。

       

    产品策划

    确定产品的功能,拆分用户故事。

    需求功能确定优先级。

    接受或拒绝开发团队的工作成果。

    参与产品开发过程中的有关会议。

    UI

    根据用户故事,负责产品的功能交互及界面设计

    组织开展人机交互及用户体验,不断跟踪改进,提高产品表现力。

    参与产品开发过程中的有关会议。

    开发

    根据用户故事,负责产品的技术架构设计及功能开发

    评估、设计及维护产品相应模块,确保模块的稳定性、易用性、高效性。

    参加产品开发过程中的有关会议。

    测试

    根据用户故事,设计产品测试标准,确保产品品质满足市场需求。

    合理分配测试资源,组织产品测试并优化测试流程及测试标准,提高测试效率。

    编写产品测试用例,提交测试问题,编写测试总结报告,以测试角度来确定产品版本是否发布。

     

    4. 项目管理过程

    按照互联网软件产品项目开发过程,可将整个项目管理过程分为立项过程、规划过程、执行与监控过程、结项过程。下面分别阐述在每个阶段过程中该如何进行项目管理。

     

    4.1 立项过程

        互联网软件产品开发项目的立项过程,通常是指从准备项目启动会到召开会议这个阶段,在立项过程中,需要完成项目目标,需求范围的初步确认,项目团队成员,其他资源的安排。

         确定项目的初步目标并达成共识

         对于项目目标,需要和干系人在以下几点上达成共识:

         项目的背景、目标用户、核心人员及产品定位是什么

         项目的资源投入预算是多少

         项目的资源投入是多少

         各人员在项目中扮演的角色和对项目的作用是什么

         准备启动会议文档

         文档内容包括:

           用户画像

           产品定位

           市场策略

           业务目标

           技术可行性

           研发成本预算

           路标规划

        召开项目启动会 

         参加人员包括:

           管理层代表

           项目经理及项目团队

           其他干系人代表

         主要议题包括:

           申明项目目标范围及对组织目标的贡献。

           管理层正式任命PM,设定期望,统一思想

           文档内容的宣讲。  

         与PM小组确定项目管理要求

           项目启动会完成后,需要与PM小组成员确定项目立项机制以及公司项目管理要求。

     

    4.2  规划阶段

    在规划阶段,团队需要共同完成产品的版本规划,迭代计划

    版本规划

    从产品的关键特性列表中按照优先级规划产品每个版本需要完成哪些特性,在规划完成后需要在项目干系人内达成共识。具体可参考《版本规划样例》

    迭代如何划分

    迭代划分是指将特性列表拆分形成用户故事列表,并将其对应的主要任务划分到各个迭代中去,形成粗粒度的项目迭代计划。这个过程主要考虑以下几个因素:

        有些任务间是有依赖关系,某个任务的开始或结束是以另一个任务的开始或结束为前提,在划分时必须考虑这种前后依赖关系。

        在安排每个迭代的任务时,需要对各种因素进行综合考虑,如平衡每个迭代中任务的技术难度和价值差异。

        除了进行初步的迭代任务划分,还需要确定项目过程中迭代任务调整的规则,如迭代任务未完成时是将剩余任务延至下一迭代还是延长迭代周期。

    确定人员分工

    项目经理需要根据每个人员的能力和特点,初步拟定大致分工。在进行任务分工时需考虑以下因素:

        任务难度与人员能力相匹配,对于明显超出能力范围或过于简单的任务容易造成负面影响。

        耦合度高的尽量分配给同一个人,避免不必要的沟通消耗。

        鼓励团队内部“任务认领”,提高人员的工作积极性和主动性。

    确定迭代运行模式

            如一周迭代、两周迭代,每个迭代包含的工作内容等。

           具体的迭代计划可参考《迭代计划样例》

    制定其他辅助计划

        制定沟通计划、风险计划和质量计划是必要的,沟通计划主要包含以下几个方面:沟通对象、沟通方式、沟通频率即可,如:


        风险计划包括风险项、负责人、重要性、应对措施,如下:


     

    质量计划包括:bug分布满足何种条件可以发布,有几个致命bug必须停止开发新特性等。。

       搭建基础技术架构

        如果是一个全新的项目,需要重新开发系统框架,则这个工作应该在迭代0完成,否则会影响后期的工作开展。系统框架的每次改动必然会导致大量的重复工作量,从而给稳定的团队节奏带来很大的毛刺。

    3.3    项目执行和监控过程

    迭代N的执行

    A、迭代N的需求细化

    考虑每个迭代需要完成的用户故事;

        用户故事需包含几个部分,工作量评估、功能性需求、非功能性需求。具体的可参考《用户故事模板及样例及拆分说明》

        用户故事编写完成后需要在团队内部进行需求评审,一方面是为了向团队成员解读该需求,另一方面团队成员也可在评审时给出指导性意见。

    B、测试用例评审

        测试人员根据用户故事要求编写对应的测试用例,并组织项目团队进行测试用例评审。根据评审意见修改测试用例

    C、开发

        将用户故事的需求开发的过程。

    D、开发自测

        在开发过程中,每完成一个功能点,都需要及时的进行开发自测并通知产品策划人员进行验收体验。

    E、验收

        开发完成后,产品策划需要对开发完成的成果进行验收,验证其是否符合用户故事的要求,验证通过后方可流到测试环节,否则需与开发详细讨论其不符合性,其验收的checklist可以参考《产品验收checklist及模板》

    F、测试和回归

            提交测试时,必须要有正确的版本。测试人员根据测试用例进行测试,在IT平台中提交测试bug,并根据测试的角度给出产品是否发布的意见,输出《测试报告》

    G、bug修改

        在IT平台中获取分配给自己的bug进行修改。

    H、showCase

        阶段性必须有可体验版本进行showCase.需要

    确定showCase时间:某个迭代开发、自测完成,准备提交测试前

    会议前1-2天发出体验版给到参与人员

    会议期间,由项目经理组织大家体验、反馈问题、记录问题。

    项目经理根据问题情况,与开发或产品确定问题的解决时间并发出会议纪要。

     I、灰度发布

           迭代一定版本后,由项目经理与团队共同决定是否需要进行灰度发布。

     

    监控方式 

    每日站立会

        主持人轮流担任,负责控制节奏,记录问题,以备会后跟踪。

        每人讲自己昨天做了什么,有什么问题,今天的计划是什么;

        其他人了解别人的工作情况,并发现指出可能存在的问题。

        对于发现的问题,鼓励认领,其余由项目经理指定责任人。

        时间通常控制在15分钟内。

        会议期间,更新任务墙,任务墙样式如下:

     

    周报

        反馈项目计划的执行情况,强调本周工作要达成的目标

        暴露出项目的问题,特别是需要领导或其他团队需要协助的问题。

        周报可在IT平台中输出。

    月报

        反馈项目当月的执行情况,包括进度、人力及质量。

        反映项目存在的问题和风险。

    迭代回顾

        每人讲述本次迭代做的好的地方和不好的地方

        回顾上个迭代不好的地方,看看改进情况。

        让每个人发言。

        每次迭代回顾会议完成后,可更新燃尽图

    3.4    结项阶段

    项目经理指导产品策划收集总结项目的产品运营数据,同时指导团队成员从自身角色进行总结,包括测试、开发、UI等。

    项目经理与项目团队成员给出项目总结报告,内容可参考《项目经验教训总结-项目团队》,《项目经验教训总结-项目经理》

    召开结项会议,各成员进行结项汇报。

    PM小组将过程文档和经验教训总结进行归档。

    展开全文
  • 敏捷开发项目管理规程

    千次阅读 2017-05-08 09:49:19
    1.对项目经理开展产品规划及设计活动以及项目管理手段和应遵循的开发流程提供了指导;2.对项目团队的日常管理活动及内容进行了指导;3.角色及职责定义项目经理:进行产品开发过程中的业务目标、进度、成本、质量控制...

    1.目的

    规范互联网软件产品开发项目管理过程,指导开展项目研发、管理等活动。

    2.适用范围

    本章程的作用范围为互联网软件产品开发立项至结项管理过程。

    1.对项目经理开展产品规划及设计活动以及项目管理手段和应遵循的开发流程提供了指导;

    2.对项目团队的日常管理活动及内容进行了指导;

    3.角色及职责定义

    项目经理:

    进行产品开发过程中的业务目标、进度、成本、质量控制。

    挑选项目团队并进行团队建设,激发、鼓舞和改进团队的生产效率。

    识别项目干系人,定期向干系人汇报,并作为团队和外部的接口,屏蔽外界对团队的干扰。

    确保项目中流程被遵循,组织、监督、培训项目各实践活动。

    产品策划

    确定产品的功能,拆分用户故事。

    需求功能确定优先级。

    接受或拒绝开发团队的工作成果。

    参与产品开发过程中的有关会议。

    UI

    根据用户故事,负责产品的功能交互及界面设计

    组织开展人机交互及用户体验,不断跟踪改进,提高产品表现力。

    参与产品开发过程中的有关会议。

    开发

    根据用户故事,负责产品的技术架构设计及功能开发

    评估、设计及维护产品相应模块,确保模块的稳定性、易用性、高效性。

    参加产品开发过程中的有关会议。

    测试

    根据用户故事,设计产品测试标准,确保产品品质满足市场需求。

    合理分配测试资源,组织产品测试并优化测试流程及测试标准,提高测试效率。

    编写产品测试用例,提交测试问题,编写测试总结报告,以测试角度来确定产品版本是否发布。

    4. 项目管理过程

    按照互联网软件产品项目开发过程,可将整个项目管理过程分为立项过程、规划过程、执行与监控过程、结项过程。下面分别阐述在每个阶段过程中该如何进行项目管理。

    4.1立项过程

    互联网软件产品开发项目的立项过程,通常是指从准备项目启动会到召开会议这个阶段,在立项过程中,需要完成项目目标,需求范围的初步确认,项目团队成员,其他资源的安排。

    确定项目的初步目标并达成共识

    对于项目目标,需要和干系人在以下几点上达成共识:

    项目的背景、目标用户、核心人员及产品定位是什么

    项目的资源投入预算是多少

    项目的资源投入是多少

    各人员在项目中扮演的角色和对项目的作用是什么

    准备启动会议文档

    文档内容包括:

    用户画像

    产品定位

    市场策略

    业务目标

    技术可行性

    研发成本预算

    路标规划

    召开项目启动会

    参加人员包括:

    管理层代表

    项目经理及项目团队

    其他干系人代表

    主要议题包括:

    申明项目目标范围及对组织目标的贡献。

    管理层正式任命PM,设定期望,统一思想

    文档内容的宣讲。

    与PM小组确定项目管理要求

    项目启动会完成后,需要与PM小组成员确定项目立项机制以及公司项目管理要求。

    4.2规划阶段

    在规划阶段,团队需要共同完成产品的版本规划,迭代计划

    版本规划

    从产品的关键特性列表中按照优先级规划产品每个版本需要完成哪些特性,在规划完成后需要在项目干系人内达成共识。具体可参考《版本规划样例》

    迭代如何划分

    迭代划分是指将特性列表拆分形成用户故事列表,并将其对应的主要任务划分到各个迭代中去,形成粗粒度的项目迭代计划。这个过程主要考虑以下几个因素:

    有些任务间是有依赖关系,某个任务的开始或结束是以另一个任务的开始或结束为前提,在划分时必须考虑这种前后依赖关系。

    在安排每个迭代的任务时,需要对各种因素进行综合考虑,如平衡每个迭代中任务的技术难度和价值差异。

    除了进行初步的迭代任务划分,还需要确定项目过程中迭代任务调整的规则,如迭代任务未完成时是将剩余任务延至下一迭代还是延长迭代周期。

    确定人员分工

    项目经理需要根据每个人员的能力和特点,初步拟定大致分工。在进行任务分工时需考虑以下因素:

    任务难度与人员能力相匹配,对于明显超出能力范围或过于简单的任务容易造成负面影响。

    耦合度高的尽量分配给同一个人,避免不必要的沟通消耗。

    鼓励团队内部“任务认领”,提高人员的工作积极性和主动性。

    确定迭代运行模式

    如一周迭代、两周迭代,每个迭代包含的工作内容等。

    具体的迭代计划可参考《迭代计划样例》

    制定其他辅助计划

    制定沟通计划、风险计划和质量计划是必要的,沟通计划主要包含以下几个方面:沟通对象、沟通方式、沟通频率即可,如:

    131031333864530.gif

    风险计划包括风险项、负责人、重要性、应对措施,如下:

    131032034951865.gif

    质量计划包括:bug分布满足何种条件可以发布,有几个致命bug必须停止开发新特性等。。

    搭建基础技术架构

    如果是一个全新的项目,需要重新开发系统框架,则这个工作应该在迭代0完成,否则会影响后期的工作开展。系统框架的每次改动必然会导致大量的重复工作量,从而给稳定的团队节奏带来很大的毛刺。

    3.3项目执行和监控过程

    迭代N的执行

    A、迭代N的需求细化

    考虑每个迭代需要完成的用户故事;

    用户故事需包含几个部分,工作量评估、功能性需求、非功能性需求。具体的可参考《用户故事模板及样例及拆分说明》

    用户故事编写完成后需要在团队内部进行需求评审,一方面是为了向团队成员解读该需求,另一方面团队成员也可在评审时给出指导性意见。

    B、测试用例评审

    测试人员根据用户故事要求编写对应的测试用例,并组织项目团队进行测试用例评审。根据评审意见修改测试用例

    C、开发

    将用户故事的需求开发的过程。

    D、开发自测

    在开发过程中,每完成一个功能点,都需要及时的进行开发自测并通知产品策划人员进行验收体验。

    E、验收

    开发完成后,产品策划需要对开发完成的成果进行验收,验证其是否符合用户故事的要求,验证通过后方可流到测试环节,否则需与开发详细讨论其不符合性,其验收的checklist可以参考《产品验收checklist及模板》

    F、测试和回归

    提交测试时,必须要有正确的版本。测试人员根据测试用例进行测试,在IT平台中提交测试bug,并根据测试的角度给出产品是否发布的意见,输出《测试报告》

    G、bug修改

    在IT平台中获取分配给自己的bug进行修改。

    H、showCase

    阶段性必须有可体验版本进行showCase.需要

    确定showCase时间:某个迭代开发、自测完成,准备提交测试前

    会议前1-2天发出体验版给到参与人员

    会议期间,由项目经理组织大家体验、反馈问题、记录问题。

    项目经理根据问题情况,与开发或产品确定问题的解决时间并发出会议纪要。

    I、灰度发布

    迭代一定版本后,由项目经理与团队共同决定是否需要进行灰度发布。

    监控方式

    每日站立会

    主持人轮流担任,负责控制节奏,记录问题,以备会后跟踪。

    每人讲自己昨天做了什么,有什么问题,今天的计划是什么;

    其他人了解别人的工作情况,并发现指出可能存在的问题。

    对于发现的问题,鼓励认领,其余由项目经理指定责任人。

    时间通常控制在15分钟内。

    会议期间,更新任务墙,任务墙样式如下:

    131033062616789.gif

    周报

    反馈项目计划的执行情况,强调本周工作要达成的目标

    暴露出项目的问题,特别是需要领导或其他团队需要协助的问题。

    周报可在IT平台中输出。

    月报

    反馈项目当月的执行情况,包括进度、人力及质量。

    反映项目存在的问题和风险。

    迭代回顾

    每人讲述本次迭代做的好的地方和不好的地方

    回顾上个迭代不好的地方,看看改进情况。

    让每个人发言。

    每次迭代回顾会议完成后,可更新燃尽图

    3.4结项阶段

    项目经理指导产品策划收集总结项目的产品运营数据,同时指导团队成员从自身角色进行总结,包括测试、开发、UI等。

    项目经理与项目团队成员给出项目总结报告,内容可参考《项目经验教训总结-项目团队》,《项目经验教训总结-项目经理》

    召开结项会议,各成员进行结项汇报。

    PM小组将过程文档和经验教训总结进行归档。

    展开全文
  • 前段时间给大家整理了敏捷开发流程,最近在整理敏捷开发项目流程和管理制度,其整理的项目管理规程如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家...

    转:https://blog.csdn.net/wlly1/article/details/77716455
    感谢原文博主!


    前段时间给大家整理了敏捷开发的流程,最近在整理敏捷开发项目的流程和管理制度,其整理的项目管理规程如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家在实际嵌入到公司的过程中可以参考下,不能照搬。

    1.  目的

    规范互联网软件产品开发项目管理过程,指导开展项目研发、管理等活动。

    2.  适用范围

    本章程的作用范围为互联网软件产品开发立项至结项管理过程。

    1.对项目经理开展产品规划及设计活动以及项目管理手段和应遵循的开发流程提供了指导;

    2.对项目团队的日常管理活动及内容进行了指导;

    3.  角色及职责定义

    项目经理:

    进行产品开发过程中的业务目标、进度、成本、质量控制。

    挑选项目团队并进行团队建设,激发、鼓舞和改进团队的生产效率。

    识别项目干系人,定期向干系人汇报,并作为团队和外部的接口,屏蔽外界对团队的干扰。

    确保项目中流程被遵循,组织、监督、培训项目各实践活动。

       

    产品策划

    确定产品的功能,拆分用户故事。

    需求功能确定优先级。

    接受或拒绝开发团队的工作成果。

    参与产品开发过程中的有关会议。

    UI

    根据用户故事,负责产品的功能交互及界面设计

    组织开展人机交互及用户体验,不断跟踪改进,提高产品表现力。

    参与产品开发过程中的有关会议。

    开发

    根据用户故事,负责产品的技术架构设计及功能开发

    评估、设计及维护产品相应模块,确保模块的稳定性、易用性、高效性。

    参加产品开发过程中的有关会议。

    测试

    根据用户故事,设计产品测试标准,确保产品品质满足市场需求。

    合理分配测试资源,组织产品测试并优化测试流程及测试标准,提高测试效率。

    编写产品测试用例,提交测试问题,编写测试总结报告,以测试角度来确定产品版本是否发布。

     

    4. 项目管理过程

    按照互联网软件产品项目开发过程,可将整个项目管理过程分为立项过程、规划过程、执行与监控过程、结项过程。下面分别阐述在每个阶段过程中该如何进行项目管理。

     

    4.1 立项过程

        互联网软件产品开发项目的立项过程,通常是指从准备项目启动会到召开会议这个阶段,在立项过程中,需要完成项目目标,需求范围的初步确认,项目团队成员,其他资源的安排。

         确定项目的初步目标并达成共识

         对于项目目标,需要和干系人在以下几点上达成共识:

         项目的背景、目标用户、核心人员及产品定位是什么

         项目的资源投入预算是多少

         项目的资源投入是多少

         各人员在项目中扮演的角色和对项目的作用是什么

         准备启动会议文档

         文档内容包括:

           用户画像

           产品定位

           市场策略

           业务目标

           技术可行性

           研发成本预算

           路标规划

        召开项目启动会 

         参加人员包括:

           管理层代表

           项目经理及项目团队

           其他干系人代表

         主要议题包括:

           申明项目目标范围及对组织目标的贡献。

           管理层正式任命PM,设定期望,统一思想

           文档内容的宣讲。  

         与PM小组确定项目管理要求

           项目启动会完成后,需要与PM小组成员确定项目立项机制以及公司项目管理要求。

     

    4.2  规划阶段

    在规划阶段,团队需要共同完成产品的版本规划,迭代计划

    版本规划

    从产品的关键特性列表中按照优先级规划产品每个版本需要完成哪些特性,在规划完成后需要在项目干系人内达成共识。具体可参考《版本规划样例》

    迭代如何划分

    迭代划分是指将特性列表拆分形成用户故事列表,并将其对应的主要任务划分到各个迭代中去,形成粗粒度的项目迭代计划。这个过程主要考虑以下几个因素:

        有些任务间是有依赖关系,某个任务的开始或结束是以另一个任务的开始或结束为前提,在划分时必须考虑这种前后依赖关系。

        在安排每个迭代的任务时,需要对各种因素进行综合考虑,如平衡每个迭代中任务的技术难度和价值差异。

        除了进行初步的迭代任务划分,还需要确定项目过程中迭代任务调整的规则,如迭代任务未完成时是将剩余任务延至下一迭代还是延长迭代周期。

    确定人员分工

    项目经理需要根据每个人员的能力和特点,初步拟定大致分工。在进行任务分工时需考虑以下因素:

        任务难度与人员能力相匹配,对于明显超出能力范围或过于简单的任务容易造成负面影响。

        耦合度高的尽量分配给同一个人,避免不必要的沟通消耗。

        鼓励团队内部“任务认领”,提高人员的工作积极性和主动性。

    确定迭代运行模式

            如一周迭代、两周迭代,每个迭代包含的工作内容等。

           具体的迭代计划可参考《迭代计划样例》

    制定其他辅助计划

        制定沟通计划、风险计划和质量计划是必要的,沟通计划主要包含以下几个方面:沟通对象、沟通方式、沟通频率即可,如:


        风险计划包括风险项、负责人、重要性、应对措施,如下:


     

    质量计划包括:bug分布满足何种条件可以发布,有几个致命bug必须停止开发新特性等。。

       搭建基础技术架构

        如果是一个全新的项目,需要重新开发系统框架,则这个工作应该在迭代0完成,否则会影响后期的工作开展。系统框架的每次改动必然会导致大量的重复工作量,从而给稳定的团队节奏带来很大的毛刺。

    3.3    项目执行和监控过程

    迭代N的执行

    A、迭代N的需求细化

    考虑每个迭代需要完成的用户故事;

        用户故事需包含几个部分,工作量评估、功能性需求、非功能性需求。具体的可参考《用户故事模板及样例及拆分说明》

        用户故事编写完成后需要在团队内部进行需求评审,一方面是为了向团队成员解读该需求,另一方面团队成员也可在评审时给出指导性意见。

    B、测试用例评审

        测试人员根据用户故事要求编写对应的测试用例,并组织项目团队进行测试用例评审。根据评审意见修改测试用例

    C、开发

        将用户故事的需求开发的过程。

    D、开发自测

        在开发过程中,每完成一个功能点,都需要及时的进行开发自测并通知产品策划人员进行验收体验。

    E、验收

        开发完成后,产品策划需要对开发完成的成果进行验收,验证其是否符合用户故事的要求,验证通过后方可流到测试环节,否则需与开发详细讨论其不符合性,其验收的checklist可以参考《产品验收checklist及模板》

    F、测试和回归

            提交测试时,必须要有正确的版本。测试人员根据测试用例进行测试,在IT平台中提交测试bug,并根据测试的角度给出产品是否发布的意见,输出《测试报告》

    G、bug修改

        在IT平台中获取分配给自己的bug进行修改。

    H、showCase

        阶段性必须有可体验版本进行showCase.需要

    确定showCase时间:某个迭代开发、自测完成,准备提交测试前

    会议前1-2天发出体验版给到参与人员

    会议期间,由项目经理组织大家体验、反馈问题、记录问题。

    项目经理根据问题情况,与开发或产品确定问题的解决时间并发出会议纪要。

     I、灰度发布

           迭代一定版本后,由项目经理与团队共同决定是否需要进行灰度发布。

     

    监控方式 

    每日站立会

        主持人轮流担任,负责控制节奏,记录问题,以备会后跟踪。

        每人讲自己昨天做了什么,有什么问题,今天的计划是什么;

        其他人了解别人的工作情况,并发现指出可能存在的问题。

        对于发现的问题,鼓励认领,其余由项目经理指定责任人。

        时间通常控制在15分钟内。

        会议期间,更新任务墙,任务墙样式如下:

     

    周报

        反馈项目计划的执行情况,强调本周工作要达成的目标

        暴露出项目的问题,特别是需要领导或其他团队需要协助的问题。

        周报可在IT平台中输出。

    月报

        反馈项目当月的执行情况,包括进度、人力及质量。

        反映项目存在的问题和风险。

    迭代回顾

        每人讲述本次迭代做的好的地方和不好的地方

        回顾上个迭代不好的地方,看看改进情况。

        让每个人发言。

        每次迭代回顾会议完成后,可更新燃尽图

    3.4    结项阶段

    项目经理指导产品策划收集总结项目的产品运营数据,同时指导团队成员从自身角色进行总结,包括测试、开发、UI等。

    项目经理与项目团队成员给出项目总结报告,内容可参考《项目经验教训总结-项目团队》,《项目经验教训总结-项目经理》

    召开结项会议,各成员进行结项汇报。

    PM小组将过程文档和经验教训总结进行归档。

    展开全文
  • 简述敏捷开发中的测试流程

    千次阅读 2019-01-21 18:11:10
    敏捷sprint进程中测试任务的简要描述:   需求讨论:这个阶段测试人员要把自己带入到用户角色中,列举用户角度的场景需求,协助开发和产品制定技术实现方案; 确认验收标准:为了避免sprint进行中产生的扯皮...
  • 敏捷开发 vs 传统模式

    万次阅读 2015-05-28 22:41:00
    说起敏捷开发,并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。 ...
  • DevOps敏捷开发流程

    2019-11-19 17:29:15
    近期根据我们DevOps开发团队敏捷开发项目的实践经验,将完整流程整理如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家在实际过程中可以参考。 1. 目的 规范...
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 敏捷开发中的测试人员敏捷开发团队介绍测试人员需要具备的素质测试人员的主要职责定义质量 (Define Quality)交流缺陷(Communication)及时反馈 (Feedback):敏捷开发中QA的职责之敏捷中的QA敏捷QA的日常活动敏捷QA与...
  • 敏捷开发知识体系笔记

    万次阅读 2015-11-06 10:08:55
    敏捷开发知识体系整体框架敏捷开发工程实践项目管理 迭代开发 风险价值生命周期 多级项目规划 完整团队 每日站立会议 任务板 燃尽图 需求管理 需求订单 业务流程草图 用例驱动开发 用户故事 架构 演进的架构 演进的...
  • 敏捷开发团队 项目分工 敏捷公司认为团队合作对于交付工作软件至关重要,而优秀的敏捷团队则关注“我们”而不是“ I”。 不幸的是,许多公司声称他们拥有敏捷团队,但实际上他们没有。 重要的是要了解敏捷团队的...
  • 项目管理-敏捷开发

    2017-09-11 14:52:16
    说起敏捷开发,并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。 ...
  • 【转载】CMMI与敏捷开发模式比较

    千次阅读 2013-02-20 18:41:23
    CMMI与敏捷开发模式比较 四月 9, 2012 07:07 by FlySky 我曾经参与了一个新产品项目两个版本的开发,分别采用了CMMI与项目级敏捷方式,总结一下两种模式。 CMMI采用的是传统的瀑布模式开发,开发流程是...
  • 敏捷开发模式

    千次阅读 2018-07-01 01:34:06
    1、敏捷开发的概念从1990年代...2、敏捷开发流程(图为禅道敏捷开发流程管理)2.1 产品负责人将整个产品设计成产品代办列表。就是一个个需求列表。(可以理解为需求或者要做的事情)2.2 召开产品迭代计划会议,确...
  • 项目管理之敏捷开发之道

    千次阅读 2017-05-23 15:37:06
    敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于...
  • 敏捷数据科学,它的目标是记录探索数据分析的过程并促进和指导这一过程,以期发现实现一款引人注目的数据分析产品的关键路径,并沿着这条路走下去。敏捷数据科学深入本质,关注探索数据分析的过程,并记录在过程中...
  • Scrum敏捷开发流程主要包扩三个角色、四个会议和个三物件。 三个角色 Scrum团队中包括三个角色,他们分别是产品负责人、开发团队和 项目的直接管理者(Scrum Master)。 Scrum 团队是自组织、跨职能的完整...
  • 什么是敏捷开发

    2019-10-31 15:50:18
    本篇分享的是:【什么是敏捷开发 】 目录: 1.几种开发方法 1.1瀑布式开发 1.2迭代式开发 1.3螺旋式开发 2.敏捷开发 2.1 敏捷开发的诞生 2.2敏捷开发宣言 2.3 敏捷开发 3.敏捷开发方法 ...
  • 敏捷开发的主旨: 一:个体及交互比流程与工具更具价值 二:可用的软件比冗长的文档更有价值 三:与客户的协作比合同谈判更有价值 四:对变化的响应比遵循计划更有价值直接聊宗旨有些抽象了,举些栗子就会发现这...
  • 敏捷开发与敏捷测试

    2020-07-02 15:25:48
    敏捷开发:1.敏捷型方法是“适配性”而非“预设性”。重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划,然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实,...
1 2 3 4 5 ... 20
收藏数 7,949
精华内容 3,179
关键字:

敏捷开发项目开展流程