精华内容
下载资源
问答
  • ONES 敏捷项目管理,迭代计划流程图文演示

    1. 前言

        创建一个 ONES Project,进入项目管理,创建迭代计划,在迭代计划下创建需求及子需求,根据需求拆分任务及子任务,任务负责人完成任务后发布任务,结束任务的生命周期。对于测试任务,可创建缺陷,缺陷缺陷负责人处理完缺陷,交由团队测试人员回归测试完成后,结束缺陷的声明周期。需求下的全部任务走完任务的声明周期,需求可被关闭,结束当前需求的声明周期。迭代下的全部需求完成后,可变更迭代计划状态为已完成。维护项目的下一个迭代。
        项目可关联需求文档、测试用例等文档;支持任意在项目任意阶段多维度统计报表查看;项目概览仪表盘支持自定义,更加直观的查看项目相关属性及工作项统计等。

        登入系统,创建一个敏捷项目管理 ONES Project,命名为 ABillionProject,本项目已拿到了王先生投资。
        一个亿的项目,就这,就这,就这?
        欸,看官,别动手,别动手,笔下尚有千字未落,容我停下手中这支笔,评论区且战。

    2. 项目管理

    2.1. 迭代计划

        进入我们一个亿的小项目,创建迭代计划,名称还是要规范一点,这里以版本为例命名;

    在这里插入图片描述

    图2-1-1、创建迭代计划图

        这里"1.0.1 版本迭代"迭代中已经创建了一些需求、任务、缺陷等,并完成了部分任务项。可以更加直观看到迭代相关数据统计,基本的迭代计划描述,工作项燃尽图,剩余工时燃尽图;迭代计划状态,项目进度;项目代码相关统计等信息;

    在这里插入图片描述

    图2-1-2、迭代概览图

        我们在迭代计划下,创建一些工作项,每个工作项都会指定负责人,管理层面来讲某个工作项只有负责人和其团队上级管理人员有权限变更工作项信息。当然具体还是看项目工作项权限配置。
        敏捷项目管理模板下工作项类型默认提供了需求、子需求、任务、子任务、缺陷,其实就是需求,任务,缺陷三大类工作项。根据实际工作场景可以扩展工作项类型,此处就以这三类为例。

    2.2 需求

    一般的,需求由团队产品人员管理,跟踪关注需求的生命周期

    在这里插入图片描述

    图2-2-1、需求生命周期图

        创建需求,可以在全部工作项下创建工作项,选中工作项类型为需求创建需求;也可以在需求下直接选择提需求。如果需求过于泛化,描述方向偏大,则可以再创建需求时,直接创建相关子需求拆分细化需求。

    在这里插入图片描述

    图2-2-2、需求创建图

    在这里插入图片描述

    图2-2-3、需求子工作项图

    在这里插入图片描述

    图2-2-4、需求属性配置图

        创建工作项(需求)需要维护工作项必填属性,如标题,类型,负责人等;维护更多属性,比如计划完成实际,预估工时,在项目配置中心维护的新属性实际工时等(实际工时应在工作项完成时由负责人维护);选择性维护子工作项,创建时也可以不维护,在工作项列表支持对工作项维护子工作项;可以选择关联工作项,比如某个缺陷可以关联对应的开发任务,开发任务可以关联对应的需求;可以维护工作项关注者,默认工作项变更会通知到关注人。

    2.3 任务

    一般的,任务由团队开发人员管理,负责跟踪任务的生命周期

    在这里插入图片描述

    图2-3-1、任务生命周期图

        团队开发人员负责人对接产品提出的需求,拆分创建任务及子任务。
        可以先创建任务,后面需要完善时,再创建子任务;也可以创建时通过子工作项直接维护子任务。任务也属于工作项,创建方式和需求相同,需求、任务、缺陷都可以全部工作项下进行维护。
        团队开发人员负责人根据需求拆分任务,分配到团队具体开发人员,开发完成,维护实际工时,实际完成日期等属性,变更任务状态按工作流(生命周期)往下走。

    在这里插入图片描述

    图2-3-2、项目任务列表图

        在工作项发生变更后,团队开发人员(任务负责人)会收到通知。团队成员登入系统进入项目,查看项目概览,仪表盘等大屏信息统计,跟踪具体任务或其他工作项。
        仪表盘居然也支持自定义,只能说 ONES 做的很 Nice,欸,欸,欢呼声不要太大。

    在这里插入图片描述

    图2-3-3、项目仪表盘图

        开发小哥哥(任务负责人)查看所负责的任务,进入工作状态,按排期查看某个任务,变更任务为进行中;完成任务后,编辑更新任务状态为已完成,填写实际工时,完善任务描述或备注等信息,提交测试。

    在这里插入图片描述

    图2-3-4、任务完成图

        此处工作项类型没有设计测试任务,所以开发任务和测试任务没有很好的区分开。
        一个亿的项目,就这,就这,就这?
        欸,看官,别动手,别动手,大家都是读书人。
        所以还是要在项目前期就规划好工作项,工作流程,大团队大制作。没有人在意我,我在一个人的角落~~~

    2.4 缺陷

    一般的,缺陷由团队测试人员管理,负责跟踪缺陷的生命周期
    在这里插入图片描述

    图2-4-1、缺陷生命周期图

        开发任务完成后,由团队测试负责人创建测试任务,分配到团队具体测试人员,进入功能测试工作流。
        开始测试更新测试任务状态为进行中,测试结束且无未关闭的缺陷,则可关闭测试任务。若存在缺陷则团队测试人员提缺陷,创建方式遵循工作项创建方式;缺陷指向负责人,产品设计问题可提给产品人员,功能模块问题可提给开发人员。根据产品迭代实际场景,可基于该模板编辑简化流程或补充缺陷工作流。

        这里就发现测试任务和开发任务重合在一起,且类型都是任务,那工作项类型设计上就可以细化拆分为开发任务,测试任务等。测试任务维护一个"开发人员"工作项属性,开发人员不变更,测试任务负责人可随着缺陷工作流变更。

        果然,测试人员会心一笑,反手提了个缺陷,洋洋洒洒写下 Bug 复现场景就拂袖而去。

    在这里插入图片描述

    图2-4-2、测试任务图

    在这里插入图片描述

    图2-4-3、缺陷创建图

        ONES 右上角通知消息 +1,几许发丝又从开发小哥哥眼前飘过。

        确认缺陷后变更状态为已确认,开始修复时变更为开始修复,修复完成变更为已经修复。并将负责人指向团队测试人员,测试人员回归测试通过变更任务状态为回归通过,结束缺陷工作流,并变更测试任务工作项状态为已完成。

    在这里插入图片描述

    图2-4-5、全部工作项缺陷管理图

        一个亿的项目欸,维护了这么多项目团队成员,也是一笔不菲的人工成本;大团队大制作,其实,其实,这些成员账号都是我一个人,没有人在意我,我在一个人的角落~~~

    3. 项目扩展

    3.1 成员角色管理

        项目成员下可以管理项目中的成员、角色;只能添加项目配置中心已维护的角色,项目中没有创建角色的能力,需要通过项目配置中心维护。

    在这里插入图片描述

    图3-1-1、项目成员角色管理图

    3.2 工作项筛选器

        项目筛选器下可以按条件过滤项目全部工作项。

    在这里插入图片描述

    图3-2-1、全部工作项筛选器图

    3.3 项目概览

        项目概览卡支持编辑自定义,低调一点,低调一点
    在这里插入图片描述

    图3-3-1、项目概览图

    3.4 项目报表

        ONES Project 本身提供了多维度的默认项目报表,也支持创建自定义项目报表。报表支持数据表格、折线统计、柱状统计等类型。

    在这里插入图片描述

    图3-4-1、项目报表图

    在这里插入图片描述

    图3-4-2、任务每日状态趋势图

    ONES Project 配置:WHAT?已经有人在用 ONES 管理一个亿的项目
    Powered By niaonao

    展开全文
  • 传统项目管理VS敏捷项目管理 很多人都知道,项目管理领域有两种管理方式:传统项目管理和敏捷项目管理。很多人在团队引入敏捷的时候,会有一个疑惑,传统项目管理和敏捷项目管理的区别是什么? 各个模式的项目...

    传统项目管理VS敏捷项目管理


    很多人都知道,项目管理领域有两种管理方式:传统项目管理和敏捷项目管理。很多人在团队引入敏捷的时候,会有一个疑惑,传统项目管理和敏捷项目管理的区别是什么?

     

    各个模式的项目管理发展历程


    在1969年以前,不管是制造汽车还是制造轮船,全世界的项目管理都没有太多的章法和规则。

    直到1969年美国成立了PMI组织,推出了PMBOK一整套规则、PMP认证后,全世界的项目管理就有了章法、有了规则。

    直到现在,绝大部分行业还是使用这套标准项目管理方法——传统的项目管理。

    直到2001年,有17个软件行业开发者在犹他州Snowbird滑雪胜地里聚会,他们白天滑雪,晚上喝酒聊天,聊着聊着发现,他们一致认为传统项目管理不适用于软件行业的,然后他们制定并签署了行业最重要的文件之一:敏捷宣言。他们还在这里塑造了许多关于软件的构想、开发和交付的方式,甚至是世界如何运作的方式。

    所以敏捷这个概念是非常新颖的,2006-2007年期间,敏捷就被引入中国,腾讯就是最早使用敏捷的企业之一。同时,对于一些要考虑很多问题的项目,例如:“有没有流量?”、“别人愿不愿意来”等等,所以他们需求是不确定的,按照以前传统项目管理方法是行不通的,所以敏捷就诞生了。

     

    传统VS敏捷项目管理对比


    传统项目管理

    通常采用的是瀑布式、部分迭代开发模式,要求在项目建设时,需求足够明确、文档足够规范,迭代过程中需求变更越多、越晚,对项目影响越大,会影响到项目的交付质量。

    敏捷项目管理

    作为新兴的项目管理模式,简化了传统项目管理的繁琐流程和文档。以 Scrum 为代表,欢迎需求变更,在客户需求不明确的时候,以在较短的周期内开发出可用的软件为目标,来帮助客户描述自己的需求。迭代过程中的需求变更会加入到项目继续迭代需求池,丰富项目的产品功能。

     

    敏捷VS传统项目管理的相同点


    敏捷项目管理

    声称要摆脱繁冗的流程制度文档,但是对于关键的项目文档,比如需求规格说明书等等,也是要求必须具备的。所以,敏捷项目管理的项目流程制度上的管理可以看作是对一套完善的项目管理流程制度的裁剪,只不过这个裁剪的尺度比较大,从而也对敏捷项目团队成员的适应性,自主性提出了较高的要求。

    具体的敏捷方法在每个迭代周期中都存在立会制度,燃尽图、看板监控、计划发布等,这些和PMBOK中对项目生命周期的五个过程组启动、规划、执行、监控和收尾的定义没有冲突矛盾,实际上敏捷项目管理的这些措施可以看作是PMBOK项目生命期五个过程组执行的微缩版,区别在于敏捷项目管理的迭代周期,时间很短,在去执行过程中裁剪了很多规范正式的项目管理流程制度。

     

    敏捷VS传统项目管理的区别


    1、不同的管理方式适用于不同类型的项目,敏捷更适用于未知、不可知或持续变化的项目;

    2、传统的管理方式有如计划经济体制,敏捷有如市场经济体制,适应变化的能力不同;

    3、极大地缩短了用户与开发者,预期目标与实施状况,投资与投资回报之间的反馈回路;

    4、将小型团队转化为自身命运的管理者,团队接受挑战,找寻应对挑战的方法,发挥创意,避开工作障碍,而这一切都无法由中央控制及调度系统预先安排。

     

    当处于快速发展的社会环境、面临复杂而多变的项目时,传统项目管理方式常常面临进度延期、成本超支、质量不过关、客户满意度低、变更频繁等问题,而敏捷项目管理可以说是在原本完善的项目管理流程制度上进行了尺度较大的裁剪,从而对敏捷项目团队成员的适应性,自主性提出了较高要求,可以使项目经理将最大限度的项目资源和活动用于产生增值结果上。

    展开全文
  • 在满足PMI-ACP敏捷项目管理报名条件下,进行下列步骤进行报名: 英文报名--资格审查【有几率抽中审查,抽中后快递材料审核】--中文报名--在线支付费用 一、英文报名 英文报名时间无限制,但有一年的有效期,...

    在满足PMI-ACP敏捷项目管理报名条件下,进行下列步骤进行报名:

    英文报名--资格审查【有几率抽中审查,抽中后快递材料审核】--中文报名--在线支付费用

     

    一、英文报名

    英文报名时间无限制,但有一年的有效期,所以大家尽量提前报名,英文报名网站:www.pmi.org/(PMI官网)

     

    二、审核

    PMI官网对你英文报名的材料进行审核,审核通过后进行下一步,中途还有一种是项目管理类考试审查,是由PMI的计算机系统自动抽查,抽查中的考生需要按要求将材料快递至PMI进行审查,被抽查的几率大约在10%左右。

     

    三、中文报名

    一般于考前两个月左右开通中文报名入口,持续15天左右,届时考生可以登录中文网站进行报名,审核通过后进行下一步。中文报名网站:exam.chinapmp.cn/

     

    四、在线支付费用

    付费实现通道:

    1.考生个人系统:只要符合付费程序的考生,都可以登录中文系统之后进行付费操作;

    2.网页上的付费快速通道(无需登录中文系统)。

    PMI-ACP敏捷项目管理考试报名费用:PMI-ACP认证考试初考费统一为3900元,重考费统一为2500元。

     

    PMI-ACP敏捷项目管理考试报名流程图:

     

    展开全文
  • #Scrum Master——项目负责人、项目经理 保护团队不受外界干扰,是团队的领导和推进者,负责提升 Scrum 团队的工作效率,控制 Scrum 中的“检视和适应”周期过程。与 Product Owner 一起将投资产出最大化,他确保...

    在这里插入图片描述

    Scrum中的角色

    #Scrum Master——项目负责人、项目经理
    保护团队不受外界干扰,是团队的领导和推进者,负责提升 Scrum 团队的工作效率,控制 Scrum 中的“检视和适应”周期过程。与 Product Owner 一起将投资产出最大化,他确保所有的利益相关者都可以理解敏捷和尊重敏捷的理念。
    
    #Team——开发人员、测试人员、美工设计、DBA等全职能性团队
    团队负责交付产品并对其质量负责,团队与所有提出产品需求的人一起工作,包括客户和最终用户,并共同创建 Product Backlog 。团队按照大家的共识来创建功能设计、测试 Backlog 条目交付产品。
    
    #Product Owner——产品负责人、产品经理、运营人员
    从业务角度驱动项目,传播产品的明确愿景,并定义其主要特性。Product Owner 的主要职责是确保团队只开发对于组织最重要的 Backlog 条目,在 Sprint 中帮助团队完成自己的工作,不干扰团队成员,并迅速提供团队需要的所有信息。
    
    #User——最终用户、运营人员、系统使用人员
    很多人都可能成为最终用户,比如市场部人员、真正的最终用户、最好的领域专家,也可能是因其专业知识而被雇佣的资讯顾问。最终用户会根据自己的业务知识定义产品,并告知团队自己的期望,提出请求。
    
    #Manager——管理层、投资人
    管理层要为 Scrum 团队搭建良好的环境,以确保团队能够出色工作,必要的时候,他们也会与 Scrum Master 一起重新组织结构和指导原则。
    
    #Customer——客户、系统使用人员、运营人员
    客户是为 Scrum 团队提出产品需求的人,她会与组织签订合同,以开发产品。一般来说,这些人是组织中的高级管理人员,负责从外部软件开发公司购买软件开发能力。在为内部产品的公司中,负责批准项目预算的人就是客户
    

    Scrum中的产出物

    #Product Backlog——Backlog 待开发项,积压的任务。
    产品 Backlog 包括了所有需要交付的内容,其内容根据业务需求的价值顺序排列,每个 Backlog 的优先级是可以调整的,需求是可以增减的,因此产品 Backlog 将根据不断增长来持续驱动维护。
    
    #Sprint Backlog——Sprint 本意为“冲刺”,指迭代周期,长度通常是一至六周。
    在 Sprint 开始前,定义本次 Sprint 要讨论的“Sprint Backlog”,从中产生本次 Sprint 要完成的 “已定 Product Backlog”。
    已定 Product Backlog是 Sprint 计划会议的产物,它定义了团队所接受的工作量,在整个 Sprint 过程中它将保持不变。
    
    #User Story、Task——用户故事、任务
    用 User Story 来描述 Sprint Backlog 里的项目,User Story 是从用户的角度对系统的某个功能模块所作的简短描述。一个 User Story 描述了项目中的一个小功能,以及这个功能完成之后将会产生什么效果,或者说能为客户创造什么价值。一个 User Story 的大小和复杂度应该以能在一个 Sprint 中完成为宜。如果 User Story 太大,可能会导致对它的开发横跨几个 Sprint,此时就应该将这个 User Story 分解。为了能够及时,高效地完成每个 Story,Scrum 团队会把每个 Story 分解成若干个 Task。每个Task 的时间最好不要超过8小时,保证在1个工作日内完成,如果 Task 的时间超过了8个小时,就说明Task的划分有问题,需要特别注意。
    障碍 Backlog——问题列表,积压的待处理事务。
    列举了所有团队内部和团队相关的和阻碍项目的进度的问题,Scrum Master 需要确保所有的障碍 Backlog 中的问题都已分配并可以得到解决。
    

    通用会议规则

    基本要求
    •每次会议都要准时开始、准时结束。
    •每次会议都采取开放形式,所有人都可以参加。
    
    会前准备
    •提前邀请所有必须参会的人,让他们有时间准备。
    •发送带有会议目标和意图的会议纲要。
    •预订会议所需的全部资源:房间、投影仪、挂图、主持设备,以及此会议需要的其他东西。
    •会前24小时发送提醒。
    •准备带有会议规则的挂图。
    
    会议推进
    •展开讨论时,会议的推进人必须在场。他不能参与到具体讨论中,但是他需要注意讨论进程,如果讨论参与者失去重点,他还要将讨论带回正规。
    •推进人展示会议的目标和意图。
    •有必要时,推进人可以商定由某个撰写会议记录。
    •推进人可以记录团队的意见,或是教授团队如何自己记录文档;而且推进人可能会在挂图上进行记录,将对话可视化。
    •推进人会对会议进行收尾,并进行非常简短的回顾。
    
    会议输出
    •使用手写或挂图说明来记录文档,给白板和挂图上的内容拍照。
    •必须传达会议记录和大家对会议结果的明确共同认知。
    
    让团队坐在一起!
    •大家都懒的动,尽量让“产品负责人”和“全功能团队”都坐在一起!
    •互相听到:所有人都可以彼此交谈,不必大声喊,不必离开座位。
    •互相看到:所有人都可以看到彼此,都能看到任务板——不用非得近到可以看清楚内容,但至少可以看到个大概。
    •隔离:如果你们整个团队突然站起来,自发形成一个激烈的设计讨论,团队外的任何人都不会被打扰到,反之亦然。
    
    团队建设
    •Scrum 团队最佳人数控制在“59”人。
    •全职能性团队:开发组(后台开发、前端开发、测试人员——3~8人)、Scrum Master(项目经理)、产品负责人
    •兼职团队成员:美工、DBA、运维
    

    每日立会(Daily Standup Meeting)——建议下班前开始

    会议目的
    •团队在会议中作计划,协调其每日活动,还可以报告和讨论遇到的障碍。
    •任务板能够帮助团队聚焦于每日活动之上,要在这个时候更新任务板和燃尽图。
    
    构成部分
    •任务板、即时贴、马克笔
    •提示:ScrumMaster 不要站在团队前面或是任务板旁边,不要营造类似于师生教学的气氛。
    
    基本要求
    •成员:团队、Scrum Master
    •无法出席的团队成员要由同伴代表。
    •持续时间/举办地点:每天15分钟,同样时间,同样地点。
    •提示:团队成员在聆听他人发言时,都应该想这个问题:“我该怎么帮他做得更快?”
    
    会议输出
    •团队彼此明确知道各自的工作,最新的工作进度图。
    •得到最新的“障碍 Backlog”
    •得到最新的“Sprint Backlog”
    
    会议过程
    •团队聚在故事板旁边,可以围成环形。
    •从左边第一个开始,向团队伙伴说明他到现在完成的工作。
    •然后该成员将任务板上的任务放到正确的列中。
    •如果可以的话,该成员可以选取新的任务,交将其放入“进行中工作”列。
    •如果该成员遇到问题或障碍,就要将其报告给 Scrum Master。
    •每个团队成员重复步骤2到步骤5。
    
    每个人三个问题:
    •上次会议时的任务哪些已经完成?:把任务从“正在处理”状态转为“已完成”状态。——今天完成了什么?
    •下次会议之前,你计划完成什么任务?:如果任务状态为“待处理”,转为“正在处理”状态。如果任务不在 Sprint Backlog 上,则添加这个任务。如果任务不能在一天成,把这任务细分成多个任务。如果任务可以在一天内完成,把任务状态设为“正在处理”。如果任务状态已经是“正在 处理”,询问是否存在阻碍任务完成得问题。——明天做什么?
    •有什么问题阻碍了你的开发?:如果有阻碍你的开发进度的问题,把该障碍加入到障碍 Backlog中。——今天遇到了什么问题?
    
    注意事项
    •不要迟到
    •不要超出限制时间
    •不要讨论技术问题
    •不要转变会议话题
    •不要在没有准备的情况下参加
    •Scrum Master 不要替团队成员移动任务卡片,不要替团队更新燃尽图。
    •Scrum Master 不要提出问题,团队成员不要向 Scrum Master 或管理层人员报告。
    •如果不能出席会议,需要通知团队,并找一名代表参加。
    

    任务板

    •任务板集合了选择好的 Product Backlog 和 Sprint Backlog,并以可视化方式展示。
    •任务板只能由团队维护,使用不同颜色的“即时贴”来区分开发人员,或者在“即时贴”写上接受任务的姓名。
    •尽量使用大白板,也可以使用软件。
    
    任务板有4列:
    •选择好的 Product Backlog:按照优先级,将团队在当前 Sprint 中要着手的 Product Backlog 条目或是故事放在该列中。
    
    •待完成的任务:要完成一个故事,你得完成一些任务。在 Sprint 规划会议中,或是在进行当前 Sprint 中,收集所有特定 Backlog 条目需要完成的新任务,并将它们放入该列。
    
    •进行中的工作:当团队成员开始某个任务后,他会将该任务对应的卡片放到“进行中的工作”列中。从上个每日 Scrum 例会开始,没有完成的任务都会放在该列中,并在上面做标记(通常是个红点)。如果某个任务在“待完成任务”列中所处时间超过一天,就尽量将该任务分为更小 的部分,然后把新任务放到那一列,移除其所属大任务卡片。如果一个新任务因为某个障碍无法完成,就会得到一个红点标记,Scrum Master 就会记下一个障碍。
    
    •完成:当一个任务卡完成后,完成此任务的成员将其放入“完成”列,并开始选取下一张任务卡
    

    燃尽图

    •跟踪进度要由团队来完成,燃尽图的横轴表示整个Sprint 的总时间,纵轴表示 Sprint 中所有的任务,其单位可以是小时,人天等。一般来说,燃尽图有”Sprint燃尽图”和”Release燃尽图”之分。
    
    •团队每天更新燃尽图。
    •如果燃尽图一直是上升状态,或当 Sprint 进行一段时间之后,Sprint 燃尽图上的Y值仍然与 Sprint 刚开始时相差无几,就说明这个 Sprint 中的 Story 过多,要拿掉一些 Story 以保证这个 Sprint 能顺利完成。 如果Sprint 燃尽图下降得很快,例如 Sprint 刚过半时Y值已经接近0了,则说明这个 Sprint 分配的任务太少,还要多加一些任务进来。在 Sprint 计划会议上,如果团队对即将要做的任务理解和认识不充分,就很可能导致这两种情况的出现。(锻炼团队人员的自我估算时间)
    •燃尽图要便于团队更新,没必要让它看起来很炫,也不要过于复杂,难以维护。
    
    Release 燃尽图:记录整个Scurm项目的进度,它的横轴表示这个项目的所有Sprint, 纵轴表示各个Sprint开始前,尚未完成的工作,它的单位可以是个(Story 的数量),人天等。
    

    Sprint规划会议——第一部分(上午)

    会议目的
    •该会议的工作以分析为主,目的是要详细理解最终用户到底要什么,产品开发团队可以从该会议中详细了解最终用户的真实需要。在会议的结束,团队将会决定他们能够交付哪些东西。
    •产品负责人在会前准备:条目化的需求(用户故事),优先级排序,最近1~2个迭代最希望看到的功能。会前准备至关重要,可帮助产品负责人理清头绪,不至于在迭代期内频繁提出变更、增加或删除故事。
    
    基本要求
    •迭代计划会在每个迭代第一天召开,目的是选择和估算本次迭代的工作项。
    •只有团队成员才能决定团队在当前 Sprint 中能够领取多少个 Backlog 条目的工作。
    
    构成部分:
    •经过估算和排序的 Product Backlog。
    •挂图、马克笔、剪刀、胶水、即时贴、白板、铅笔和蜡笔。
    •假期计划表、重要人员的详细联系信息。
    •参会成员:团队成员、Scrum Master、产品负责人
    
    持续时间:在 Sprint 中,每周该会议占用时间为 60 分钟,在早上召开该会议,这样还有可能在同一天召开 Sprint 规划会议的第二部分。
    
    会议输出
    •选择好的 Product Backlog 条目。
    •各个 Backlog 条目的需求。
    •各个 Backlog 条目的用户验收测试。
    
    会议过程
    •从第一个 Product Backlog 条目(故事)开始。
    •讨论该 Product Backlog 条目,以深入理解。
    •分析、明确用户验收测试。
    •找到非功能性需求(性能、稳定性...)
    •找到验收条件。
    •弄清楚需要“完成”到何种水平。
    •获得 Backlog 条目各个方面的清晰了解。
    •绘制出所需交付物的相关图表,包括流程图、UML图、手绘草图、屏幕 UI 设计等。
    •回到步骤1,选取下一个 Backlog 条目。
    
    流程检查:询问团队能否快速回答下列问题,只需要简要回答即可:“我们能在这个 Sprint 中完成第一个 Backlog 条目吗?”如果能得到肯定的回答,那么继续询问下一个 Backlog 条目,一直到已经分析完的最后一个 Backlog 条目。——接下来,休息一下。在休息后,对下一个 Backlog 条目展开上述流程。
    
    结束流程:
    •在 Sprint 规划会议第一部分结束前留出 20 分钟。
    •再次提问——这次要更加严肃、正式:“你们能否完成第一个 Backlog 条目,...第二个,...?”
    •如果团队认为他们不能再接受更多的 Backlog 条目,那就停下来。
    •现在是非常重要的一步:送走 Product Owner,除了团队和 Scrum Master 之外的所有人,都得离开。
    •当其他人都离开后,再询问团队:“说真的——你们相信自己可以完成这个列表?”
    •希望团队现在能短暂讨论一下,看看他们到底认为自己能完成多少工作。
    •将结果与 Product Owner 和最终用户沟通。
    
    注意事项:不要改变 Backlog 条目大小,不要估算任务。
    

    Sprint规划会议——第二部分(下午)

    会议目的
    •该会议的工作以设计为主,产品开发团队可以为他们要实现的解决方案完成设计工作,在会议结束后,团队知道如何构建他们在当前 Sprint 中要开发的功能。
    
    基本要求
    •只有产品开发团队才能制定解决方案,架构师或其他团队之外的人只是受邀帮助团队。
    
    构成部分:
    •能够帮助团队在该 Sprint 中构建解决方案的人,比如厂商或是来自其他团队的人员。
    •选择好的 Product Backlog 条目。
    •挂图......
    
    注意事项:不要估算任务,不要分配任务。
    
    会议输出
    •应用设计、架构设计图、相关图表
    •确保团队知道应该如何完成任务!
    
    会议过程
    •从第一个 Backlog 条目开始。
    •查看挂图,确定对于客户的需求理解正确。
    •围绕该 Backlog 条目进行设计,并基于下列类似问题: •我们需要编写什么样的接口?
    •我们需要创建什么样的架构?
    •我们需要更新哪些表?
    •我们需要更新或是编写哪些组件?
    •......
    
    当团队明确知道自己应该如何开发该功能后,就可以转向下一个 Backlog 条目了。在会议的最后 10 分钟,团队成员使用即时贴写出初步的任务。这能帮助团队成员知道接下来的工作从哪里开展,将这些任务放在任务板上。
    
    持续时间:在 Sprint 规划会议第一部分完成后,召开该会议。可以将午餐作为两次会议的一个更长久的休息。但是要在同一天完成 Sprint 规划第一部分,在 Sprint 中,每周该会议占用时间为 60 分钟。
    

    估算会议——根据项目情况合并到Sprint第二部分会议

    会议目的
    •要做好战略规划,你需要知道 Backlog 中各项的大小,这是版本规划的必要输入;如果想知道团队在一个 Sprint 中能够完成多少工作,这个数据也是必须的。
    •团队成员可以从会议中知道项目接下来的阶段会发生哪些事情。
    
    基本要求
    •只有团队才能作估算,Product Owner(产品负责人)需要在场,以帮助判定某些用户故事能否拆分为更小的故事。
    
    构成部分:
    •Product Owner 根据业务价值排定 Product Backlog 各项顺序。
    •需要参加的人员:Team、Product Owner、User、Scrum Master
    
    注意事项:
    •不要估算工作量大小——只有团队能这么做。
    •Product Owner 不参与估算。
    
    会议过程
    •Prodcut Owner 展示她希望得到估算的 Product Backlog 条目。
    •团队使用规划扑克来估算 Backlog 条目。
    •如果某个 Backlog 条目过大,需要放到下一个或是后续的 Sprint 中,团队就会将该大 Backlog 条目划分为较小的几个 Backlog 条目,并对新的 Backlog 条目使用规划扑克进行估算。
    •重新估算 Backlog 中当前没有完成、但是可能会在接下来三个 Sprint 中要完成的条目。
    
    持续时间:该会议时间限制为不超过90分钟。如果 Sprint 持续时间长于一周,那么每个 Sprint 举行两次估算会议比较合适。
    
    会议输出
    •经过估算的 Product Backlog。
    •更小的 Backlog 条目。
    

    扑克牌估算

    具体步骤:
    •每个人各自估算后独立出暗牌,听口令一起开牌。
    •数值最大者与最小者PK,其他人旁听也可参考。
    •讨论结束后重新出牌和开牌。
    •重复上述过程,直到结果比较接近。
    
    常见问题
    
    1、为什么任务要分给组而不是个人?
    答:因为怕出错了牌又说不出所以然,这样即使日后他不做这个功能,也对这个功能很了解。
    
    2、为什么不让最后领任务的人自己估算?
    答:因为他很可能因为不知道某代码可用、不知道某软件不行....而选择了错误的实现方法。
    
    3、为什么不让师傅估算大家采纳,他不是最厉害吗?
    答:师傅的想法常常是徒弟们理解不了的,比如为什么不留在女儿国而偏偏去西天取经之类的,共同估算就是让大家在思考中对照自己的实现方法和师傅差异的过程。
    

    Sprint评审会议(Review Meeting)

    会议目的
    •Scrum 团队在会议中向最终用户展示工作成果,团队成员希望得到反馈,并以之创建或变更 Backlog 条目。
    
    基本要求
    •Sprint 复审会议允许所有的参与者尝试由团队展示的新功能。
    
    构成部分
    •有可能发布的产品增量,由团队展示。
    
    会议输出
    •来自最终用户的反馈。
    •障碍 Backlog 的输入。
    •团队 Backlog 的输入。
    •来自团队的反馈为 Product Backlog 产生输入。
    
    持续时间:90分钟,在 Sprint 结束时进行。
    
    会议过程
    •Product Owner 欢迎大家来参加 Sprint 复审会议。
    •Product Owner 提醒大家关于本次 Sprint 的目的:Sprint 目标、Scrum 团队在本次 Sprint 中选定要开发的故事。
    •产品开发团队展示新功能,并让最终用户尝试新功能。
    •Scrum Master 推进会议进程。
    •最终用户的反馈将会由 Product Owner 和/或 Scrum Master 记录在案。
    
    注意事项:
    •不要展示不可能发布的产品增量。
    •Scrum Master 不要负责展示结果。
    •团队不要针对 Product Owner 展示。
    

    Sprint反思会议(Retrospective Meeting)

    会议目的
    •该会议的对应隐喻:医疗诊断!其目的不是为了找到治愈方案,而是要发现哪些方面需要改进。
    
    构成部分
    •参与人员:团队成员、Scrum Master
    
    基本要求
    •从过去中学习,指导将来。
    •改进团队的生产力。
    
    注意事项
    •不要让管理层人员参与会议。
    •不要在团队之外讨论找到的东西。
    
    会议输出
    •障碍 Backlog 的输入。
    •团队 Backlog 的输入。
    
    持续时间:90分钟,在 Sprint 评审会议结束后几分钟开始。
    
    会议过程
    •准备一个写着“过去哪些做的不错?”的挂图。
    •准备一个写着“哪些应该改进?”的挂图。
    •绘制一条带有开始和结束日期的时间线。
    •给每个团队成员发放一叠即时贴。
    •开始回顾。
    •做一个安全练习。
    •收集事实:发放即时贴,用之构成一条时间线。每个团队成员(包括 Scrum Master)在每张即时贴上写上一个重要的事件。
    •“过去哪些做的不错?”:采取收集事实同样的过程,不过这次要把即时贴放在准备好的挂图上。
    •做一个分隔,以区分“过去哪些做的不错”和接下来要产出的东西。
    •“哪些应该改进?”:像“过去哪些做的不错”那样进行。
    •现在将即时贴分组:
    •我们能做什么》团队 Backlog 的输入。
    •哪些不在我们掌控之内?》障碍 Backlog 的输入。
    •根据团队成员的意见对两个列表排序。
    •将这两个列表作为下个 Sprint 的 Sprint 规划会议第一部分和 Sprint 规划会议第二部分的输入,并决定到时候要如何处理这些发现的信息。
    
    展开全文
  • 敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法,是一种软件开发的方法,如,是敏捷开发的主要流程 敏捷开发的三大角色: 产品负责人(product owner):主要负责确定产品的功能和达到
  • 敏捷项目管理学习

    2021-01-03 03:14:47
    7、敏捷项目管理方法:XP、ASD、FDD、TDD、Crystal、DDSM、AUP;8、产品愿景声明和产品路线;9、用户故事;10、Product Backlog和Sprint Backlog;11、冲刺主要工作、敏捷角色及分工;12、不同折线的燃尽所说明...
  • 各位群友大家好,本群ACP敏捷项目管理微课今日主题:敏捷项目管理框架及流程 传统的项目管理,有自己的管理过程,比如我们的5大过程组 那么在敏捷里面,也有自己的流程,简单来说如下: ACP|PMP...
  • 敏捷项目管理--流程管理

    千次阅读 2016-09-05 11:22:59
    敏捷项目管理可以应用于任何的JIRA项目中。无论你是Scrum大师或者是刚刚尝试敏捷开发的新手,JIRA Agile都能够帮助你在整个发布过程中管理待办事项(backlog)、计划冲刺(sprint)并且监测项目进度。 Trello 基于...
  • 敏捷项目管理实战之进度管理

    千次阅读 2014-01-06 12:11:26
    本文以笔者的实际敏捷项目管理经验为基础,分享了关于敏捷项目进度管理中缩短项目工期的实践、进度信息的获取与核实、进度信息的展现、传播及其激励作用。并介绍了项目进度管理与风险管理、期望值管理间的关联。希
  • 敏捷项目管理在软件刚热门起来的时候就存在了,但一直发展平平,在最近几年开始流行,最终的原因还是因为敏捷项目管理适应了当下社会对于软件快速完成的需求,敏捷最主要的两个特点便是灵活和快速。本文将先从管理...
  • scrum敏捷项目管理 我最近和项目经理谈过。 她告诉我她的故事。 我曾经以项目经理的身份为项目团队提供便利。 为什么是项目经理? 因为项目有一个开始和结束。 我们拥有(并且仍然有)太多的产品,无法长时间保持...
  • 敏捷项目管理

    千次阅读 2011-07-08 12:30:33
    敏捷开发管理 敏捷宣言 • 个体与交互 胜过 过程与工具可以工作的软件 胜过 面面俱到的文档客户协作 胜过 合同谈判响应变化 胜过 遵循计划 敏捷开发•
  • 前段时间给大家整理了敏捷开发的流程,最近在整理敏捷开发项目的流程和管理制度,其整理的项目管理规程如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家...
  • SCRUM敏捷项目管理

    千次阅读 2010-12-05 23:08:00
    SCRUM敏捷项目管理作者:elgin 来源:Youshang UED Team 酷勤网收集 2010-02-04Scrum这个词是来自于英式橄榄球,是指两个前锋互相争球的情况。我想Scrum的创始人Ken Schwaber肯定是一个橄榄球迷,呵呵….,这是题...
  • 5.2 程序 敏捷开发的早期采用者是小型的、独立的团队,他们从事小型的、自包含的项目。他们证明了敏捷模式是可行的,这让世界各地的软件制造商感到高兴并得到了改进。... 瀑布之类的传统项目管理风格是...
  • Scrum敏捷项目管理

    千次阅读 2017-04-29 03:56:32
    敏捷的背景与动机软件危机及软件工程的出现 速度是企业竞争致胜的关键因素,软件项目的最大挑战在于 ...这正是Agile Process (敏捷的软件开发流程)于近年来兴起的主要原因。软件项目的复杂性横轴代表需求的复杂度!
  • 众所周知,当前在项目管理领域...敏捷项目管理犹如下班回家,你可以自己选择适当的时间, 选择所需的线路,根据遇到的情况变化,自主调整路线或策略。两种管理方法互 补互通,各有千秋。在实际的工作中,由于项目所...
  • 很多人都知道,项目管理领域有两种管理方式:传统项目管理和敏捷项目管理。很多人在团队引入敏捷的时候,会有一个疑惑,传统项目管理和敏捷项目管理的区别是什么? 传统VS敏捷 传统项目管理通常采用的是瀑布式、部分...
  • 软件项目管理的两大主流管理模式:传统项目管理(预测型项目管理)、敏捷项目...敏捷项目管理作为新兴的项目管理模式,简化了传统项目的流程,从繁琐的流程和详尽的文档中解脱出来。但并不代表敏捷不做计划,有很...
  • 敏捷项目管理模式

    千次阅读 2011-05-17 10:45:00
    from: http://www.tup.tsinghua.edu.cn/Resource/tsyz/035257-01.doc        <br />第      <br />章    <br />敏捷项目管理模式   ...
  • 对于中大型团队,建立高效的研发体系和团队协作流程至关重要。选择正确的敏捷项目管理工具可以极大地提升团队协作效率,帮助企业持续交付价值。那么企业如何选择合适的敏捷项目管理工具呢?Capte...
  • 一、项目管理 按照PMBoK,项目管理就是把各种知识、技能、手段和技术应用于项目活动之中,以达到项目的要求。项目管理是通过应用和整合启动、规划、实施、监控和收尾五大项目管理过程来进行的。 项目管理是伴随着...
  • 我们使用各种敏捷软件写feature,流转、跟踪任务,言必谈敏捷,然而我们是否真的走对了敏捷?...完整医疗商务平台项目管理,包括需求规格说明书SRS,项目管理课程,WBS,BIS,合同,招标书,标书等 下载:...
  • 前言 响应变化高于遵循计划”—敏捷宣言。...接下来老程与大家一起分享敏捷项目管理中的响应变化的知识,旨在让大家了解,敏捷并非是洪水猛兽那么可怕,相反,顺应时代的潮流,引领大家体验敏捷的奥妙! 请各...
  • 敏捷项目管理流程-Scrum框架最全总结!

    万次阅读 多人点赞 2017-01-20 21:21:01
    Scrum Master——项目负责人、项目经理 保护团队不受外界干扰,是团队的领导和推进者,负责提升 Scrum 团队的工作效率,控制 Scrum 中的“检视和适应”周期过程。与 Product Owner 一起将投资产出最大化,他确保...
  • 敏捷项目管理计划 如果您阅读我最近的文章《 比较团队没有用:暴露另一个管理神话》和相关评论,您会发现我对规范故事点以预测程序成本或进度的工作感到rant之以鼻。 这导致了针对程序或其他框架或程序生命周期的...
  • 敏捷开发项目管理流程

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

    千次阅读 2009-03-16 17:22:00
    关于华为敏捷项目管理 IPD – 集成产品开发,华为花重金从IBM购买的一套产品集成开发流程,业界有一本书,PACE讲的就是这一套IPD流程,而IPD并不去讲你的开发要怎么 做,IPD做的就是“投资决策、市场驱动”,更...
  • 敏捷项目管理体会-鸟瞰 说到敏捷(Agile),大家一定能想到很多Agile方式,XP,Scrum等等。互联网的应用开发要求我们稳定的同时,更需要敏捷的速度,其实不管那种敏捷的方法学,都不一定完全合适我们(有组织的原因,...
  • ACP敏捷项目管理—发布CSDN

    千次阅读 2018-02-11 11:49:37
    ***ACP学习用书***《敏捷项目管理——从入门到精通实战指南》 《敏捷项目管理与PMI-ACP应试指南》《精益开发实战:用看板管理大型项目》《轻松Scrum之旅》 《火星人敏捷开发手册》《敏捷软件开发实践 估算与计划》...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 55,755
精华内容 22,302
关键字:

敏捷项目管理流程图