敏捷开发工作进度表_敏捷开发的需求和进度表之间关系 - CSDN
  • 很多时候,我们感觉什么都没干一天就过去了,但对...燃尽图就是用来反映此类项目数据的工具,常用于敏捷软件开发中,如Scrum。它可以呈现剩余工作量和可用剩余时间,并通过可视化的图示表述繁复文字无法表述的意思...

    很多时候,我们感觉什么都没干一天就过去了,但对领导者来说,事情最好已经提前做完了,而且是越快越好。聪明的管理者知道,“时间”是需要花大功夫去把控的限制因素,只有掌握了更多关于时间和工作的数据,我们才能更好地执行计划,在预算范围内按时完成项目。

    燃尽图就是用来反映此类项目数据的工具,常用于敏捷软件开发中,如Scrum。它可以呈现剩余工作量和可用剩余时间,并通过可视化的图示表述繁复文字无法表述的意思。

     

    燃尽图是什么.png

     

    一、燃尽图是什么?

    燃尽图可以呈现团队处理用户故事进度,是一种对工作完成情况可视化展示的工具,燃尽图可显示每次迭代工作总量中仍需完成的工作余量。

    燃尽图的横轴显示工作天数,纵轴显示剩余工作,反映了项目启动以来的进度情况,它让每个团队成员都能够看到当前的进度,团队需定期更新燃尽图以保持其准确性。

    目前存在两种形式的燃尽图,Sprint燃尽图用于显示迭代中的剩余工作量,而产品燃尽图则用于说明整个项目的剩余工作量。

    二、如何解读燃尽图

    燃尽图有下面几个要点,它有一个X轴,代表项目或迭代的时间;有一个Y轴,代表需要在项目中完成的工作,用户故事剩余的工作量也由该轴表示。

     

    燃尽图2.png

     

    项目起点位于图表左侧最高点,发生在项目或迭代的第0天。项目完结点位于最右侧,标志着项目或迭代的最后一天。

    计划曲线

    燃尽图中的计划曲线是一条连接起点和终点的直线。因为代表了需要完成的所有预估任务的总和,计划曲线的终点应穿过X轴,表示已经不存在任何剩余的工作。但鉴于它以估算值为基础,因此并不总是准确的。

    实际曲线

    燃尽图中还存在一条实际曲线,显示项目或迭代中实际剩余的工作量。在起点,计划剩余工作量和实际剩余工作量是相同的,但随着项目或迭代的进行,实际剩余工作曲线将在计划工作线的上下方波动。实际的剩余工作线每天都会添加一个新的点,直至项目或迭代完成,以确保尽可能准确。

    如果实际工作线高于计划曲线,则意味着剩下的工作量比预期多,换句话说,意味着项目进度落后于计划。但如果实际曲线低于计划曲线,则意味着剩余工作量少于预计,项目进度快于既定计划。

    三、燃尽图有什么好处?

    燃尽图最显著的好处是,能提供关于项目进度和更新状态的最新报告,并对这些重要数据进行直观展示,可以确保每个人都统一进度。

    此外,将燃尽图展示到所有人面前,能够让团队所有成员都积极参与项目,并激励成员提前处理可能出现的问题。因此图表越大越显眼就越好。燃尽图应该成为办公室的视觉焦点,进而引发对项目和进度的相关讨论。

     

    7.0迭代开发.png

     

    简洁明了的燃尽图十分有用,因为它是查看项目历史速度(Velocity)的最佳工具。速度(Velocity)是一个敏捷术语,表示迭代期间完成的用户故事相关的预估工作量总和。

    四、燃尽图有何局限?

    燃尽表无法呈现所有信息

    例如,它仅显示已经完成的用户故事工作量,无法预知任何变化,例如在工作范围内估算待办列表(backlog)的所有points。因此,我们很难判断燃尽图中的变化是由于已经完成的backlog,还是由于故事点的增加或减少引起的。在燃尽图中增加一个专门显示backlog总量的图表可以解决这个问题。

    但是,燃尽图(向下或向上线条显示)都无法显示哪些产品backlog已经完成。燃尽图能显示项目的进度,但无法显示团队是否在做正确的事,也无法判断团队是否在交付正确产品backlog。

    燃尽图需依赖精准的预估

    燃尽图的另外一个问题是理想剩余工作线。实际工作线是高于还是低于理想工作线需要取决于对任务原始时间估计的准确性。因此,如果团队过高估计时间要求,则项目实际进度可能会看似正常或略超前。但如果低估了时间要求,则看起来会落后于计划。

    将效率因素纳入燃尽图可以解决这个问题。因此,在项目的第一次迭代之后,重新计算效率因素能够获得更高的准确性。

    五、燃尽图的历史回顾

    燃烧图表是从Scrum社区开发出来的,并且在2000年左右首次用于管理软件项目和其他相关工作。Ken Schwaber首次对燃尽图进行了描述,因此也被认为是燃尽图的发明者。当时正在Fidelity Investments工作的Ken Schwaber创建了燃尽图,来为Scrum团队提供一个可以帮助他们绘制项目进度图的简单工具。

    到2002年,燃尽图在Scrum社区中越来越受欢迎。从那以后,燃尽图开始运用于scrum之外的其他领域,成为了管理者控制项目进度的有用工具。

    Worktile提供专业的敏捷项目管理模板工具,包括需求管理、迭代规划、缺陷追踪、报表统计、团队协作等功能,能实时查看和监控项目进度,提高团队成员工作效率。10人以下团队可免费使用,免费注册Worktile

     

    文章来源:Worktile敏捷博客

    欢迎访问交流更多关于技术及协作的问题。

    文章转载请注明出处。

    转载于:https://www.cnblogs.com/worktile/p/10916425.html

    展开全文
  • PMI 所定义的项目时间管理过程被分为 6 个子过程,分别是定义活动,排列活动顺序,估算活动资源,估算活动持续时间,制定项目进度计划和控制项目进度计划。这 6 个过程在项目过程中并不一定是顺序进行的,而是穿插在...

    PMI 所定义的项目时间管理过程被分为 6 个子过程,分别是定义活动,排列活动顺序,估算活动资源,估算活动持续时间,制定项目进度计划和控制项目进度计划。这 6 个过程在项目过程中并不一定是顺序进行的,而是穿插在项目管理的整个流程中,遵循渐进明细的规律,其中前 5 个子过程时间上属于项目进度的制定,第六个过程属于项目进度的监控。

    043009_0926_Pmbok3

    定义活动

    即识别为完成项目可交付成果而采取的具体行动的过程。也就是在确定了项目的基本范围基准的基础上,将 WBS 分解为更为具体的,粒度更小的工作 item 方便落实到确实可行的具体工作上,过程输出通常会包括具体的活动清单,相关的属性(如资源需求,制约因素,假设条件,活动名称等)以及里程碑活动。该过程并不是一蹴而就的,通常会以渐进明细的方式进行,对于近期要完成的工作详细规划,而对远期要进行的工作只做粗略规划。在项目进行过程中,某些活动的完成意味着项目取得了关键性的进展或是某个项目阶段的结束 . 这些重要的时间点被称作为里程碑。里程碑事件可以用里程碑图进行表示,有利于就项目的状态与用户和组织的上级进行沟通。

    排列活动顺序

    项目所需要完成的具体活动条目之间并不是完全独立的,存在一定的逻辑关系,该过程就是要识别活动与活动之间的逻辑关系,并进行排序以决定活动之间的先后完成顺序并形成项目的进度网络图。活动与活动之间的逻辑关系包括以下几种:

    1. 完成到开始(FS):前一个活动完成之后后续活动才能开始
    2. 完成到完成(FF):两个活动中只有一个完成之后另一个才能完成
    3. 开始到开始 (SS):两个活动中只有其中一个开始了另外一个才能开始
    4. 开始到完成 (SF):一个活动的开始意味着另一个活动的完成。

    在该过程中,常用的方法是在识别活动之间逻辑关系的基础上利用紧前关系绘图法(PDM)编制进度,同时需要确定相关依赖关系,包括强制性依赖,选择性依赖以及外部依赖关系,其中强制性依赖是由工作本身的性质或者客观条件相关所限制产生的必须满足的依赖,而外部依赖往往与活动相关却又不在项目的控制范围内。此外为了更为准确的表示活动之间的逻辑关系,需要考量时间提前量和时间滞后量。该过程一个重要的输出是项目进度网络图,在绘制项目进度网络图的时候可以利用标准化的进度网络图模板,可加快活动网络图的编制进度。除了首尾两项,每项活动和每个里程碑都至少有一项紧前活动和一项紧后活动。

    估算活动资源

    资源即财力,物力,人力,设备用品等,该子过程识别为了完成具体的某一项活动所需要的相关资源的配备,使用和规划情况。它与活动的具体属性以及资源的特性和限制等客观因素相关,因此在该过程中需要将活动属性和资源日历作为一个具体的输入之一,资源日历包括资源的可用性,时间性等相关信息。该过程输出的准确性与否与项目成员的经验以及所采用的估算技术密切相关,因此经常需要借助专家判断,以及一些较为权威的估算数据(如以往类似项目的经验),或者进行自下而上的估算方法,即先将活动细分,然后估算资源需求然后再进行汇总。

    估算活动持续时间

    根据资源估算的结果估算完成活动所需要的时间的过程,通常由项目团队中最熟悉具体活动的小组或个人来提供输入,该过程也是一个渐进明细的,当项目相关的信息越来越准确,详细的时候,该过程的输出也就越准确。估算往往会受到一些因素的影响,如人员的熟练程序和工作效率,对于未知和突发事件的风险预测,沟通和冲突损失以及活动细节等。如果将风险因素考虑进来,可以采用三点估算法,该方法给予 PERT 技术,在估算最可能时间 TM,最乐观时间 TO,最悲观时间 Tp 的基础上采用加权平均(TO+4TM+TP)/6。

    制定项目进度计划

    该过程通过分析活动顺序,持续时间,资源需求以及进度约束来编制项目的进度计划,目的是确定项目活动的计划开始日期和计划完成日期,并确定相应的里程碑。在该过程中常用需要用到多种技术的综合,如进度网络分析,关键路径法,资源平衡,进度压缩等,其中关键路径法与网络分析较为常用,有些进度计划编制工具会直接实现这些方法以达到自动分析的目的,借助项目管理工具也是一个较为明智的选择。关键路径决定了项目完成所需要的最短时间,它是网络图中具有最长总工期的活动序列。在关键路径的计算过程中,需要针对每个活动确定以下四个参数:

    1. 最早开始日期 (ES):活动能够开始的最早日期(根据该活动的约束和依赖关系确定)。
    2. 最早完成日期 (EF):活动的最早开始时间加上完成此活动所需的时间。
    3. 最晚完成日期 (LF):在不会导致计划延误的情况下可以完成活动的最晚时间(根据该活动的约束和依赖关系确定)。
    4. 最晚开始日期 (LS):最晚完成时间减去完成此任务所需的时间。

    而关键活动就是位于关键路径上的这些活动,这些活动有一些共同特征,即活动的最早开始时间与最晚开始时间的偏差或最早完成时间与最晚完成时间之间的时间差为零。因此该活动的延迟将会导致项目的延迟。

    控制项目进度计划

    该过程监控项目的状态和进展,在进度基准的基础上比较项目的实际情况和计划情况之间的偏差,并通过分析这些偏差以及对进度变更的因素施加影响来促使项目向健康和可控的方向发展。因此该过程不仅依赖于项目的初始进度基准,同时还依赖于具体的项目绩效信息以及相关的变更状态,在实际过程中可以借助一些优秀的项目管理软件,如 RTC,它不仅能自动收集项目相关的绩效信息,而且提供了较为人性的进度管理接口,方便进行偏差分析和资源平衡等来达到进度控制的目的。

    表一列出了 PMI 所定义的时间管理的各个子过程的输入,输出,工具和技术。

    时间管理各子过程的输入,输出和工具

    子过程

    输入

    工具和技术

    输出

    定义活动

    范围基准

    分解、滚动式规划

    活动清单,活动属性

     

    事业环境因素和组织过程资产

    模板,专家判断

    里程牌清单

    排列活动顺序

    活动清单,活动属性,里程碑清单

    紧前关系绘图法(PDM)

    项目进度网络图

     

    项目范围说明书

    确定依赖关系,进度网络模板

    项目文件(更新)

     

    组织过程资产

    利用时间提前量和滞后量

     

    估算活动资源

    活动清单,活动属性

    专家判断,备选方案分析

    活动资源需求

     

    资源日历

    出版的估算数据,自下而上估算

    资源分解结构

     

    事业环境因素和组织过程资产

    项目管理软件

    项目文件(更新)

    估算活动持续时间

    活动清单,活动属性

    专家判断

    活动持续时间估算

     

    活动资源需求

    类比估算

    项目文件(更新)

     

    资源日历

    参数估算

     
     

    项目范围说明书

    三点估算

     
     

    事业环境因素和组织过程资产

    储备分析

     

    制定进度计划

    活动清单,活动属性

    进度网络分析

    项目进度计划

     

    活动资源需求

    关键路径法和关键链法

    进度基准

     

    项目进度网络图和资源日历

    资源平衡与进度压缩

    进度数据

     

    活动持续时间估算

    利用时间提前量和滞后量

    项目文件(更新)

     

    项目范围说明书

    假设情景分析

     
     

    事业环境因素和组织过程资产

    进度计划编制工具

     

    控制进度

    项目管理计划

    绩效审查,偏差分析

    项目绩效测量结果

     

    项目进度计划

    项目管理软件

    组织过程资产(更新 )

     

    工作绩效信息

    资源平衡与进度压缩

    变更请求

     

    组织过程资产

    进度计划编制工具

    项目管理计划(更新)

       

    利用时间提前量和滞后量

    项目文件(更新)

       

    假设情景分析

     

     

    现实中需要实施有效的进度控制

    1. 制定详尽的、可行的项目进度的基准计划

    我们知道,计划是行动的指导,是行动成功的关键所在。对于项目进度控制而言,计划尤显重要,它影响到资源能否被合理使用,项目能否顺利进行,直接关系到项目的成功与否。

    进度计划包括:任务、资源、时间等三部分内容。

    任务来源于工作分解结构和活动定义。要进行有效的进度控制,就要求必须有细致的、可执行的、可检查的、可控制的活动定义(任务)。任务的粒度要求适中。对于不成熟项目和管理水平不高、资源能力不强的项目而言,粒度不能太大,否则难以实现项目的控制;反之任务的粒度可以适当大一些。每项任务需要有明确的责任人、起止时间和工期。

    如果项目管理的水平不是很高的情况下,欲实现有效的进度控制,每项任务的工作量以不大于项目的总体工作量的5%为宜,工期以不大于项目总工期的10%为宜。

    2. 建立有效的风险防范计划。

    有效的风险防范计划可以降低不确定性因素对项目工期的影响,保证项目的顺利进展。风险防范的工作可以包含以下方面:

    (1) 制定一套项目风险防范的体系,包含:风险识别,风险确认,风险应对等方面的完整内容。这部分工作一般来讲,会由公司级项目管理体系来进行定义和规范。

    (2) 针对项目,提出项目风险的协调负责人,及相应的协调措施。

    (3) 在项目组内部建立对风险识别的特殊机制,如:每个人可以根据自己的工作内容,定期列举风险指数最高的5个风险,并提出相应的应对方案。

    3. 建立良好的项目组内部及项目干系人之间的沟通管理制度。

    沟通是掌握各方信息,进行项目决策和项目协调的基础。实现有效进度控制对于沟通的要求,主要强调以下几点:

    (1) 及时与项目客户进行沟通,了解其对于项目的特殊进度要求,以实行对工作任务的特殊处理。

    (2) 对于需要项目组之外的资源进行配合的工作,及时通过有效的沟通途径提交给相关人员,以提早准备好配合的工作,免得影响项目的进展。

    (3) 充分发挥项目组成员的作用,使之参与到问题解决当中来,如项目偏差的处理,风险的预防等。

    (4) 定期举办项目进展的沟通会议,了解各成员的任务执行情况,通报项目的整体进展情况。

    4. 进行进展检查,并针对检查结果采取相应的对策。

    在进度控制当中,进度检查是最重要的和最关键的工作,如果不能了解项目实际进展情况,也就很难说执行什么进度控制了。

    进度检查可以定期进行或不定期进行。

    定期执行的进度检查是指在预定的检查周期内执行的检查工作。检查周期是由项目组根据项目的实际情况来预先确定,可以为月、半月、周、半周、日等时间阶段。对于时间跨度比较大的项目,可以周期相对长一些,如:工期超过两年的项目,检查周期可以定为一个月;工期在3个月左右的项目,检查周期可以定义为1周。对于管理水平较高、资源能力较强,实施较成熟的项目,检查周期可以适当的长一些,反之亦然。建议检查周期应该以不高于工期的5~10%为宜,检查工期不超过1个月,根据工作汇报机制的惯例,对于普通项目检查工期可以定为1周。

    不定期的进度检查,可以在关键任务或里程碑任务的计划完成时间进行,一般不定期的任务检查,是有一定的针对性和目的性。

    进度检查工作可以分为四个步骤执行:

    第一步:收集项目任务的进展信息。

    收集项目的进展信息,是进度控制的基础,它主要是通过各种方式,收集项目的进展信息,作为执行下步工作的依据。

    主要的工作方法有两种:进度汇报和进度查验。通常情况下,项目经理采用由下属进行主动汇报的方式来完成项目进展信息的收集工作,这被称为进度汇报;针对于某些工作,项目经理也可以采用直接检查的方式来获取进展信息或验证汇报信息的准确性,也就是进度查验。为了获得准确的项目进展信息,项目经理必须将两种方法进行有效的结合使用。

    需要收集的项目进展信息包括:任务执行状况和变更信息。任务执行状况包括:任务的实际开始和结束时间,当前任务完成的程度等;变更信息包括:范围变更、资源变更等诸多与项目进度相关联的变更内容。

    另外,合理选择任务执行状况中的任务粒度也是必需掌握的技能。一般情况下,会根据项目进度基准计划中的工作分解来进行。具体的情况,可以根据实际状况来决定。对于项目组织内部有较细的结构划分时,需要采用由下向上逐级检查,逐级汇报的方式。

    这一步骤的工作要求收集的信息必须准确,否则下面的工作将没有如何意义,同时也就根本不可能实现有效的进度控制。

    第二步:进行项目实际进展信息与进度基准计划的比较

    将收集到的项目实际进展信息与项目的进度基准计划进行比较,看是否出现了进度偏差。如果没有偏差,进展检查到此结束,否则执行下一步工作。

    第三步:针对出现的进度偏差,寻求最佳解决方案

    如果出现了进度偏差,针对这些偏差进行分析和研究,发现其中的问题。如果需要问题解决,则针对问题寻找解决方案;如果需要进度计划的调整,则修改进度计划。

    项目实施过程中出现进度偏差是在所难免的,实施进度控制就要求能对偏差能进行有效的控制,提出相应的解决方案,使之有利于项目的进展。通常我们可以采取的措施有:

    2015020251

    第四步:执行进度调整后的进度计划和确定的解决方案

    根据偏差的处理决定,执行解决方案,调整项目进度计划。如果需要的话,通知项目干系人。

    当进度偏差比较大时,需要考虑缩小检查周期,以便更好监视纠正措施的效果,以保障项目的按期完成。

    5. 预见性的发现和解决项目实施中的问题

    在项目的实施过程中,项目的进度延期,实际上有很多的苗头可以预见性的去发现,发现后就可以及时去采取对策进行问题的解决,这种将问题消灭在萌芽状态的做法,可以有效的保障项目的顺利进行。下面列举说明可以预见性发现的问题及解决方法:

    问题预见性发现问题的方法(解决的方法):

    2015020252

    敏捷项目的进度管理

    关于敏捷项目进度管理中缩短项目工期的实践、进度信息的获取与核实、进度信息的展现、传播及其激励作用。并介绍了项目进度管理与风险管理、期望值管理间的关联。

    优化项目计划

    敏捷开发的基本特征是迭代开发。而迭代开发的强调的是"小批量、频繁交付"。因此,每次迭代所要实现的需求相对较少。这使得迭代开发中的项目计划制定相对容易,制定项目计划时任务与任务间的逻辑关系也比较容易掌握。但是,由于迭代开发往往采用时间盒(Time-box)的方式进行,即要求每次迭代的时间是固定的(业界推荐的是 2~4 周)。而每次迭代所要实现的需求(Story)的个数及其难度都不尽相同。这就要求我们在某些情况下要尽可能地优化项目计划,以保证工期不会超出时间盒的范围。

    优化项目计划的常见方法是尽可能地使各个任务并行。比如,有两个功能的开发任务,其中一个功能 A 依赖于另外一个功能 B。但这并不意味着我们必须将这两个功能的开发任务串行安排(即先开发 B 功能,再开发 A 功能)。此时,可以使用测试桩(Testing Stub)来模拟 B 功能的实现,这样使得 A 功能的开发和测试可以先独立于 B 功能的实现。因此这两个功能的开发可以并行。

    计划安排时考虑避免重复劳作也是缩短工期的一个常见方法。在 Story 驱动的一个迭代开发过程中,从第二个迭代开始,往往存在多个 Story 的实现涉及同一个模块的代码修改。此时,计划可以安排多个人并行开发这几个 Story、但是转 Story 测试时,这几个 Story 可以合并成一个"大 Story"一起转测试。从而避免了多次测试同一个模块带来的浪费。

    出于应对风险的需要在安排计划时留出所谓的缓冲时间有其合理性。但是,这个缓冲时间延长了任务的持续时间。而关键任务持续时间的延长则延长了整个迭代持续的时间。值得注意的帕金森定律(Parkinson's Law)所阐述的现象却给了我们在某些情况下要适当压缩任务尤其是关键任务的持续时间。帕金森定律告诉我们:只要还有可用的时间,一件工作消耗的时间就会不断地扩展,直到用完所有的可用的时间。也就是说,一件任务如果需要 3 天时间完成,而计划安排的持续时间是 5 天的话,这个任务会消耗 5 天甚至更多的时间才能完成。这种现象的方面给了我们一个启示:如果一件任务如果需要 3 天时间完成,而计划安排的持续时间是 2 天,那么这件任务真的可能在 2 天内完成,最多也可能是 4 天时间完成。这也比将该任务计划为 5 天完成节省时间。可见,过于宽松的机会反而可能拖慢了进度,而有一定紧迫感的计划所带来的适当压力可以激发人的动力和潜能反而可以加快进度。

    对于迭代中的技术风险点要优先安排进行验证。比如,对于从未使用过的技术或者新技术,要优先安排原型的验证,避免中途才发现技术障碍。

    进度信息的获取

    由于团队开发中的每个团队成员的日常工作之间都存在或多或少的依赖关系:某个人的工作要以其他人的一件工作产出为输入,同时其工作的输出又是另一个人的某件工作的输入。

    从团队自我管理的角度来说,进度信息是将团队成员的工作自主得衔接起来的重要因素。因此,敏捷开发团队中,进度不应该是只有项目经理才关心的事情,而是整个团队成员都应该关心的事情。但事实上,团队成员往往倾向于只关心自己手头上的工作。因此,项目经理需要引导和鼓励团队成员主动关注自己手头上的任务所依赖的任务的进度。

    另一方面,进度是整个团队应该关心的事情,这就要求在团队内有一个统一的进度信息获取与发布的平台和途径。这个平台可以是一个管理软件,比如工作流软件。也可以是一个即时通讯软件。不管采用什么样的平台,项目经理应该引导和鼓励团队成员主动将各自的进度信息推送到这个平台,而不是每个人进度还要等其他人来询问。

    站立会议也是进度信息的发布和获取的一个常见途径。站立会议中,每个团队成员都要介绍自己昨天完成了什么,今天计划做什么。这样,每个人的进度信息都可以让其他人了解到。

    定义完成的标准和进度信息的核实

    获取进度信息后,要及时对其进行核实。敏捷开发中的优秀实践"定义完成的标准"(Definition of Done)可以帮助我们对进度信息进行核实。

    下面我们讨论什么是完成的标准、定义完成的标准的作用以及如何定义完成的标准。

    曾经有个刚刚开始带领团队的人向我咨询这样一个问题:他向他的组员分配一个任务,然后他不定期得检查这个任务的进度。可是每次他检查进度的时候,他的结论都是这个组员的工作成果没有达到他所期望的,而这个组员却是认为自己已经完成了当天的任务。这种情形导致这种组员不断得为返工而加班,最后导致其身心俱疲,提出离职申请。事实上,这样一个问题产生是因为任务的分配者和执行者事先没有约定好什么叫做"完成"。双方都只是在依照自己心中的"标准"来判断是否完成,从而导致了对于进度认定的冲突。

    可见,在我们断定一个任务是否完成、进行到什么情况前,首先要规定什么叫"完成",否则就会在衡量进度的时候产生上述例子中的冲突。这种对于什么才叫做完成的规定就叫做完成的标准。显然,进度不能在脱离质量的前提下孤立得衡量,因此完成的标准不仅定义了质量要求(通常是最低质量标准),也是进度衡量的重要依据。

    比如,如果你让一个没有什么工作经验的人去安装一个数据库管理系统(DBMS),他很可能就是把安装程序执行一遍,若执行过程中没有遇到安装程序提示错误就认为是完成了软件的安装。而最后,其他人都不知道这个已经安装"完成"的软件的访问信息,比如它所在机器的 IP 地址、侦听端口。甚至知道了这些信息后,在实际使用时却发现所安装的软件根本就无法正常运作。

    其实,对于这样一个任务我们可以定义一个完成标准:所安装的 DBMS 要经过验证(比如使用 SQL 能够在数据库中插入一条记录,并能够使用相应 SQL 查询到插入的记录),并输出软件的相关使用信息(如软件所在机器的 IP 地址、软件的侦听端口)。

    可见,完成的标准不仅定义了质量要求(通常是一个最低质量要求),也定义了任务所要交付的产出物。完成的标准所定义的产出物和质量要求正是评估任务进度的依据。一个任务在整个团队中有了一个大家一致认同的完成标准时,任务完成的质量和进度的衡量才不会出现冲突。

    进度风险控制

    进度管理中很重要的一个方面是进度风险控制。

    提高进度信息的获取频率可以尽可能早得发现进度障碍,为消除障碍争取了最大时间,从而有效减低进度风险。由于敏捷开发中的一个迭代周期持续的时间较之传统项目要短得多,进度信息的获取频率也要相应有所体现。笔者通常每天对项目进度信息进行汇总。

    任务采用认领的方式而非采用分配的方式落实到人,也有助于规避人力风险导致的进度风险。

    比如,在需求评审与分析的时候,笔者并不指定谁负责哪个 Story,而是要求全体成员对本次迭代的所有需求都要有所理解,并能够讲解自己对本次迭代中的任意一个需求的理解。敏捷开发采用迭代的方式,每次迭代所要实现的需求量同传统项目比较要少得多,这使得每个团队成员对本次迭代的所有需求都进行理解成为可能。在确认每个团队成员对本次迭代所要实现的所有需求都有所理解之后,笔者才让团队成员对相应需求的开发测试任务进行认领,具体落实到人。采用这种任务认领的方式,使得每个团队成员对本次迭代的所有需求都有所理解。从而,在人力变更(如原先负责某个需求的开发人员请假了)时,可以快速得找到能够承接任务的人。进而规避了进度风险。从一开始就将需求落实到相应的开发测试人员,很容易就造成团队成员只关注自己手头上的"一亩三分田",从而使得对于需求的理解没有备份人力,一旦人力变更则很容易影响项目进度。

    笔者在项目组中强调一个个人规避进度风险的原则。该原则要求团队成员在遇到问题时,通过个人的努力消耗了 30 分钟而仍然未能将问题解决时,要及时寻求帮助,而不是继续在问题上打转,甚至于走进问题的死胡同。当然,团队成员在遇到自己无法解决的问题时,可能会觉得不好意思让被人知道,而项目经理要消除他们的这种顾虑。尤其是一些工作经验不长的员工,由于个人经验、能力等方面的限制,在遇到问题时候,往往容易只是一门心思地想着要解决问题,而完全没有顾及到时间。这往往使得他们对于问题的解决就像是走进了一条死胡同,心里明明想要走出去,可是越是往前走,就越是走不出去,而时间却悄然而逝!

    进度信息的展示、传播及其激励作用

    Scrum 中提倡的采用燃尽图(Burn-down Chart)来直观得展现项目总体进度。它展示了时间和项目剩余总体工作量间的关系,如图 1 所示。

    图 1. 燃尽图

    image001

    笔者认为,燃尽图更多得是给人以一种压迫感---让人清晰直观得感受到随着时间的推移,项目所剩的工作量逐天减少!因此,燃尽图也受到了一定的批判。

    而燃起图(Burn-up Chart)则直观地展现了时间与已完成的工作间的关系,如图 2 所示。

    图 2. 燃起图

    image002

    传统项目由于项目周期较长,团队成员往往在漫长的开发过程中看不到自己的工作成果,慢慢得失去工作的热情。因此,让团队成员看见其工作成果,对其来说也是一种激励。敏捷开发由于采用迭代的方式,一定程度上能够让员工更快得看到自己的劳动成果。而燃起图则更加有助于展示团队的工作成果。因为它将团队成员的工作成果直观得展现出来。因此,某种程度上燃起图不仅仅展示了项目进度,也是对团队成员的一种激励形式。

    状态墙则直观得展示了每个任务的进度。许多推行敏捷项目管理的团队,都采用这种方式来管理进度。如图 3 所示。

    图 3. 状态墙

    image003

    消除浪费

    时间是软件开发过程中最为稀缺并不可替代的资源。其浪费将直接影响项目的进度。而软件开发过程中存在各种各样的浪费。因此,消除浪费是加快进度的一种重要途径。

    返工则是软件开发过程中常见的一种浪费。避免返工不仅有利于加快进度,同时也能够提升软件的质量。敏捷开发中的一些优秀实践,如"定义完成的标准"、"结对编程"、"测试驱动开发"(TDD)等都有助于避免返工。

    "定义完成的标准"通过定义质量要求和产出物避免返工。"结对编程"通过及时的 code review 避免缺陷在后期才被发现而造成返工。"测试驱动开发"则是通过明确需求,避免因需求理解错误引入缺陷而造成的返工。

    过度设计也是一种常见的浪费。所谓"过度设计",指在设计阶段为未来可能发生的变化做过多的预测,并针对这些预测在设计上做过多预防。正如俗话所说"计划不如变化快",过早地为这些可能根本就不会出现的变化做处理成了一种浪费。因此,敏捷开发中提倡的是"简单设计"(Simple Design)。所谓简单设计并不是没有设计,而是采用尽可能简单的设计方案。事实上,真正能够以"不变应万变"的设计方案是不存在的。如果它存在,它必然是一种简单的方案,因为其简单,它可以被轻易得推倒重来,这才是适应"万变"的方法。

    迭代速率(Velocity)与期望值管理

    迭代速率反映了一个团队在固定的时间(一个迭代周期)内所能交付的 Story 个数。它反映了团队的生产能力。前文我们讨论的是如何从进度的角度提升这个生产能力――加快以及如何保证迭代进度。另外值得注意的是,有时候我们有必要适当得放慢进度,进而"减低"团队生产力。所谓"得寸进尺",这反映了项目管理中很重要的一面――期望值管理。"得寸进尺"式的期望值提升告诉我们当团队生产能力越大,组织上层和客户对团队的期望值也就越大。但是,作为团队的管理者要适当控制他们的期望值的提升,因为团队的生产能力应该有它的上限,而期望值的提升取可能远比团队的生产力的提升要来得快,但这无论对于组织和客户还是团队来说都不是好事。因此,在进度管理中使得控制迭代进度,不要使其让人感觉过快,也是进度管理中很重要的一方面。

    计划偏差分析与控制

    布鲁克斯法则 ( Brook's Law ) 告诉我们往一个已经滞后的项目增加人力会使这个项目更加滞后。不幸的是,当一个项目滞后的时候,往往管理层首先想到的是增加人力,因为这样他们会安心些。值得注意的是,此时增加的人是否反而使项目更加滞后,某种程度上说取决于我们如何使用新增的人力。虽然新增的人力由于对本项目并不熟悉、而本项目原有人力也不可能抽出时间给这些"新人"培训。但是,我们却可以以扬长避短的方式去发挥新增人力的作用――把一些不需要项目背景知识的工作交由这些人做,从而使原有的开发人员能够集中精力做他们最值得做的事情。比如,可以把开发过程需要使用的与项目背景没有直接联系的函数交给"新人"开发。也可以将一些非项目开发相关的而平时大家又不得不做的一些例行任务(即通常所谓"项目干扰")交由这些人做。

    从长期的角度看,对计划偏差进行分析和控制要求我们做以下几件事情:

    精确记录任务消耗的实际时间

    爱因斯坦曾经幽默地解释什么是相对论:坐在美女旁边一小时就像是一分钟,坐在火炉旁一分钟则像一小时。可见,人对时间的感知在缺乏时间衡量的情况下是多么不可靠。所以,要计算计划偏差(通常是偏慢了),必须要有精确的实际消耗时间。一些软件比如 JIRA 可以帮助我们轻松得记录每个任务的实际消耗时间。

    量化任务的计划偏差

    度量计划偏差通常有持续时间偏差和进度偏差,其计算公式如下:

    持续时间偏差 (%) =(( 实际持续时间 - 计划持续时间 )/ 计划持续时间 )*100[持续时间不包含非工作日]

    进度偏差 (%)=(( 实际结束时间 - 计划结束时间 )/ 计划持续时间 )*100

    持续时间偏差反映了任务实际消耗工作时间与任务计划持续工作时间的偏移程度,而进度偏差则反映了任务实际结束时间与计划结束时间的偏移程度。对于项目中的关键任务,进度偏差反映了项目总体进度的偏差。

    将任务的计划偏差进行量化可以让人清晰、准确认识到偏差的程度。通常,笔者会让导致计划偏差的人员自己去计算这两个指标的值,而不是由"专职人员"来计算。因为只有让问题的引入者自己清晰得地意识到问题,这个问题才能从根本上解决。

    对计划偏差进行根因分析(Root Cause Analysis)

    有了计划偏差度量值后,固然要对这些度量值进行根因分析,以便找到规避和改进的措施。

    但是,这些规避和改进措施,通过由专人(比如,项目经理自己)给出然后交由开发、测试人员去执行其效果不见得落实到位,因为这些措施对于其执行者来说,它们都是"别人"的,不是执行者"自己"的东西。

    笔者则将根因分析的方法教给团队成员,然后由团队成员自行对偏差进行分析,并给出他们自己的规避和改进措施。笔者在组织全体成员对这些分析和改进措施进行讨论,然后帮助团队成员跟踪和落实这些改进措施。

     

    说明:本文转自https://www.cnblogs.com/wintersun/p/5516327.html

     

    转载于:https://www.cnblogs.com/itsharehome/p/10978869.html

    展开全文
  • 对大多数开发小组来说,每3-6个月会进行一次发布,但是根据开发的软件类型不同,更频繁或者更少的发布也不少见。最简单的情况下,发布规划可以说是微不足道的:用预期的速度乘以计划得迭代次数,然后选择用户故事,...

    1 发布规划基础

      发布计划是覆盖了比一次迭代更长时间范围的高层次计划。对大多数开发小组来说,每3-6个月会进行一次发布,但是根据开发的软件类型不同,更频繁或者更少的发布也不少见。最简单的情况下,发布规划可以说是微不足道的:用预期的速度乘以计划得迭代次数,然后选择用户故事,让他们的规模估计值之和充满这次发布。

      发布计划并不需要精确说明在每次迭代中要完成那些工作。实际上,很少会需要这一水平的细节。对大多数项目而言,指出第一次迭代中要处理的用户故事就足够了,可以把剩下的用户故事留到以后再按优先级分配到其他的迭代中。

      发布规划是一个迭代的过程,首先要确定产品所有者对这个项目的满意条件。这些条件通常包括了进度、范围和资源方面的目标。如果无法规划一个项目来满足最初的满意条件集,就需要重复规划过程,看是否能够满足一个缩小了的满意条件集,这就需要重复规划过程,看是否能够满足一个缩小了的满意条件集;不然的话,也许可以晚一些交付某些要求的功能,或者采用一个更大的开发小组。

      一旦建立了发布计划,不要把它挂在墙上发霉。通常要在每次迭代开始时更新它。

    2 迭代规划

      与发布计划不同,迭代计划更仔细的审视单次迭代中的特定工作。迭代计划所看到的范围不会超出一次迭代,而不是像典型的发布计划那样达到3-9个月。在发布计划中相当大的用户故事在迭代计划中被分解成任务。对每项任务,都要按照完成该任务所需要的理想小时数进行估计。

      概括起来有两种进行迭代规划的方法:速度驱动的方法和承诺驱动的方法。这两种方法有很多相同的步骤,而且常常会建立起一样的迭代计划。

     3  选择迭代长度

      大多数敏捷开发小组采用2周或4周的迭代长度。没有适用于所有小组的绝对正确的迭代长度,每个小组都应该考虑自己所处的独特环境,选择对自己合适的迭代长度。进行这个决策时需要考虑的因素包括:

    1)正在处理的发布的时间长度:发布时间更短的项目需要更短的迭代长度,以便有更多的机会进行展示软件,度量开发进度,以及调整优先级和开发计划;

    2)不确定性的多少:不确定性越多,迭代应该越短,以便有更多的机会获得客户反馈;

    3)获得反馈的难以程度

    4)优先级可以保持多久不改变:一个迭代中完成的功能优先级不变很重要,同时迭代周期越长,想法转变为可用软件的时间就越长,需要综合考虑;

    5)不用外部反馈自行工作的意愿的强弱:接受外部反馈的频率越低,就越有可能误入歧途,造成的损失也就会越大;

    6)迭代的系统开销:每次迭代都会有成本,例如完成的回归测试成本,需要考虑在内;成功的敏捷开发小组的目标之一就是减少每次迭代的系统开销;

    7)紧迫感的产生有多快:选择一个合适的迭代长度,让小组感受到的压力更平均。

    4 估计速度

      有3中估计速度的方法:

    1)如果有历史平均值的话,可以使用它们。不过需要考虑开发小组,使用的技术,针对的领域,产品所有者,使用的工具,工作环境,估算人等方面有没有显著的变化;

    2)可以推迟对速度的估计,直到进行了几次迭代,这通常是最好的选择;

    3)通过把一些用户故事分解成任务,看看多少任务可以充满一次迭代来对速度进行预测,这一个过程与迭代规划很相似。

      无论采用哪种方法,都应该以一个范围来给出对速度的估计值,这个范围反映了估计值中蕴含的不确定性。不确定性锥形为要使用的范围大小提供了建议。

     5 为不确定性缓冲计划

      大多数项目都包含大量的不确定性。项目小组简历的进度表和最后期限中往往没有完全反应这种不确定性。有时候,如果这种不确定性非常大或者非常显著,就需要在估计项目持续时间的时候采取一些额外的步骤。这些不确定的情况可能包括:提前很多进行项目规划、项目必须绝对满足最后期限,同时交付一组相当严格的功能集,项目是外包的,需求仍然处于非常表面的层次,或者在日期出错时会产生严重的影响等。

      功能缓冲区和进度缓冲区是两类常见的缓冲区,当确定了项目中所有需求的优先级,然后发现可能不能交付所有功能的时候,就要建立一个功能缓冲区。例如,敏捷开发过程DSDM建议把一个项目中的30%的工作看做是可选的,从而为项目建立功能缓冲区。如果时间不够用,可以通过放弃功能缓冲区中的事项来达到进度表的时间要求。

      另一方面,可以在进度表中包含一定量的时间来建立进度缓冲区,这个时间的量反映了蕴含在项目规模中的不确定性。可以通过同时估计每个用户故事具有50%可能的规模和具有90%可能的规模来构造进度缓冲区。通过对每对50%和90%估计值采用平方和的平方根公式,可以估计出合适的进度缓冲区大小。

      项目应该用功能缓冲区来预防功能不确定性,用进度缓冲区来预防进度不确定性。可以把功能缓冲区和进度缓冲区结合起来。实际上,这常常是个好办法,因为它可以让每个缓冲区的规模都更小。

    6 规划多小组的项目

     敏捷开发项目倾向于在开发大型项目的时候避免使用很大的开发小组,而是使用多个小组。当有多个小组工作于一个项目时,他们就需要相互协调工作。有4种帮助多个小组共同处理一个项目时很有效的方法:

    1)小组应该为他们的估计建立一个共同的基础。所有小组都应该同意按照相同的单位进行估计,要么是故事点,要么是理想日。他们还应该通过对已小组故事形成一致的估计值来对使用的单位的含义达成一致;

    2)当多个小组需要一起工作的时候,尽早给他们的用户故事增加细节常常很有帮助。进行这一个工作的最佳办法是确认产品所有者对用户故事的满意条件。这些满意条件就是一旦完全实现了这个故事,就可以显示为真的那些事;

    3)在发布规划过程中结合一个滚动前瞻计划,可以让多个小组收益。滚动前瞻计划简单地向前看几次迭代,通过共享在不久的将来每个小组分别会处理哪些工作的信息,让小组之间可以协调工作。

    4)在具有很多小组件依赖性的高度复杂项目中,把馈送缓冲区结合到计划中是有益的。估计缓冲区是在计划中的一段时间,可以避免一个小组推迟交付导致另一个小组推迟启动。

      一般可以按照说明这些方法的顺序把它们纳入项目中,不过也可以按照所希望的任何顺序来使用它们。

    转载于:https://www.cnblogs.com/angela217/p/10823309.html

    展开全文
  • 敏捷开发中对进度的把握

    千次阅读 2015-11-29 07:46:37
    51CTO推荐专题:初探敏捷开发 项目经理被问到最多的问题就是,“这个项目什么时候才能完成?” 被问的时候,可能项目才定下来,仅仅知道大概的功能模块,非功能性需求还模糊不清,甚至团队成员都没到位。但是...

    转载至:http://developer.51cto.com/art/200906/130031.htm

    51CTO推荐专题:初探敏捷开发

    项目经理被问到最多的问题就是,“这个项目什么时候才能完成?”

    被问的时候,可能项目才定下来,仅仅知道大概的功能模块,非功能性需求还模糊不清,甚至团队成员都没到位。但是上级、销售、客户急切地要知道,这个项目什么时候才能完成?

    被问的时候,也可能项目已临近结束,或者说临近当初计划的交付日期。然而待完成的功能还有一堆,测试出来的bug有一大堆,客户又提出了新的需求,团队正有人要离职 …。但是上级、销售、客户非常急切地要知道,这个项目到底什么时候才能完成?

    这还不算糟糕。更头疼的问题是:“再有三周,项目应该完成了吧?”

    因为后者根本不是问题,而是命令。项目经理必须要能够合理解释为什么三周不能够完成项目;或者说明在三周内,能够完成什么。

    我们都用过MS Project, 但是那上面的漂亮表格对这样的困境毫无帮助。相反,正是Project 中的甘特图和日程表,埋下了陷阱。因为,在Project 中无法预估需要多少工作日才能完成模糊不清的需求,也无法体现实际情况发生变化后对进度的影响。

    当我们讨论进度的时候,其实包含了两个未知的变量。第一是完成需求所要的工作量,包括需求定义、开发内容边界;第二是团队的工作能力,包括成员的行业知识专业技能,成员之间、成员和外部的沟通能力,等等。

    关键就在于,这两项都是变量。如果任务是搬一千块砖头,每分钟每人能搬10块,那么结果是显而易见的。

    在敏捷开发中,采用相对估算和迭代求精的方法来处理项目进度的问题。

    首先是工作量。用估算代码行数或者界面元素的方式,就像论斤卖书一样,只适用于粗制滥造的软件生产过程。用户需要的并不是代码或者按钮,而是可靠易用的功能。

    在敏捷开发方式中,先由用户和设计人员粗略估计各个功能模块的相对规模和难度,给出一定的分值。分值不代表具体人月,起相对比较的作用。例如有查询、显示、修改三个模块,如果实现显示模块的工作量是10分,那么查询模块可能是15分,而修改为20分。

    下一步,选择一个工作量估分最低的模块,例如这里是显示模块,然后进一步考量其工作量。例如要准备数据库、设计界面、执行查询,显示内容等等。假设这轮估算得出此模块需要10人天,从而得出单位分值对应的人天为1;那么,整个项目就需要45人天。

    这个估算建立在对项目的初步了解上,主要依赖项目经理的经验。有偏差?没关系。接下来通过迭代来求精。先来实现显示模块,如果事实上花费了12人天,那么根据比例关系,剩余内容的估算大约就是42人天。

    当然,比例关系也不是一成不变的。随着模块的逐个完成,项目经理对项目的认识也在加深,他可以再调整剩余模块的相对分值。

    在实际操作中,项目经理首先按照优先级排列功能模块。然后把高优先级的模块尽可能地细分,再选择分值最小的模块开始开发。统计总工作量时,按比例累加其他模块的工作量,并加一定的调整系数,因为模块的复杂度不是线性增长的。每次迭代开发完成后,逐步降低调整系数。通常4~5次迭代后,可以将调整系数归零。

    在上面的例子中,第一次估算的初步结果是45人天,因为完全是凭经验,因此要给较大的调整系数,比如说0.4,因此给出的估算工作量区间为[45*0.6,45*1.4],即27到63人天之间。为保险起见,项目经理上报的工作量为70人天。

    第二次估算,剩余内容的初步估算为42,调整系数下降为0.3,因此给出估算区间为30到50人天之间。依此类推,通过不断迭代,对剩余工作量的估算将越来越精确。

    这样估算的好处在哪里?

    首先,工作量变量的很大一部分因素,存在于非功能需求,例如界面的美观程度。而同一项目的不同模块之间,非功能需求往往是一致的,相对估算法过滤了这一层复杂度。团队能力这一变量因素也是如此。当然,随着项目的进展,成员的开发能力应该有一定的上升,但随着加班出差等因素,投入程度也可能下降,因而会相互抵消。总之在周期6个月以内的项目中,很少出现团队工作能力戏剧性变化的情形。因此相对估算也过滤了这个复杂度。

    其次,迭代求精的方式让项目经理对估算时间更有把握。最初出现偏差是必然的,但只要团队稳定,没有大的需求变动,估算范围将迅速收缩。这比一次性报数更准确。

    它的额外好处是,敏捷开发是遵循优先级的,即使对剩余时间(即低优先级模块的开发时间)的估算不十分准确,影响也不是非常大。

    对比一下甘特图方式,在开发初期就要把各个模块的开发时间估算出来以统计总量,这就是瀑布开发的模式。

    进度问题的另一方面,是项目经理如何了解团队以及每个开发人员的开发速度。当任务分配之后,项目经理如何做到心中有数,估算任务实际完成时间。

    敏捷开发过程中,由开发人员自己来估算完成该任务所需要的时间。当然,每个人的能力不同;每个人的心态也不同,有的人保守,有的人乐观。没关系,还是靠迭代来逐步求精。

    在每天的例会上,开发人员被要求对当前任务的剩余开发时间做重估。不同于Project 统计每人每天在任务中花费了多少时间,敏捷方式只关心这项任务还需要多少时间去完成,直到归零,然后再来统计实际的工作时间。

    为什么?因为统计开发过程中的花费时间是毫无意义的。这和搬砖头不同,也许昨天用了8个小时没有一点进展,今天一旦想通了就事半功倍。我们真正关心的,就是到底还需要多少时间来完成任务,而不是已经花费掉不可恢复的时间成本。

    在每天例会中,项目经理需要注意时间曲线保持水平的成员,他是不是遇到瓶颈了,是否需求帮助?也要留意时间曲线下降幅度过大的成员,他发现了什么好的办法,有没有低估需求?这样,项目经理会更面向结果,只要按计划保证质量完成任务就行,成员到底花了多少时间是个人的事。传统做法记录每个人每天的工作内容,第一是因繁琐而失真。其次,一旦上级发现某人工作时间不够(即便他完成了任务),忍不住会派新任务,从而造成越干活越多,反过来打击程序员的积极性。

    敏捷估算的关键之处,是把成员能力这个变量的估算,交给最合适的人去做,即程序员本人。然后通过比较历次迭代时的预估和实际时间,给出校正系数,以避免程序员过于保守或过于乐观。这肯定不是绝对准确的,但效果往往比项目经理自己拍脑袋估算,然后强行指定deadline 要好得多。

    在敏捷开发中,做计划比计划本身更重要。项目经理需要时刻向前考虑,考虑各种动态因素,而不是死报着计划本身。在进度估算的时候,项目经理应该在不同阶段,根据实际情况,给出合乎情理的回答。

    展开全文
  • 这是敏捷开发绩效管理的第一篇。(之一,之二,之三,之四,之五,之六,之七)“敏捷开发绩效管理”本身是个伪命题,因为敏捷开发本身不想涉及绩效管理,这就像“C++绩效管理”的搭配差不多。但是人们选择敏捷开发...
  • 这是敏捷开发一千零一问系列的第十四篇。(在这里提问,之一,之二,之三,问题总目录)正逢周末,又是愚人节,群中...有些程序员认为,敏捷开发制度上要求不加班(可持续的步调),因此会说“老板,现在你不是推敏捷
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 敏捷开发 vs 传统模式

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

    2019-08-01 23:36:56
    谈谈敏捷开发模型 我对敏捷开发是源于10多年前看了一本关于迭代开发的书,从而对迭代开发有了一些...但是在接触敏捷开发这个体系之前,自己有机会做一个项目,那个时候我开始将自己认为更有利于项目的管理工作做了...
  • 敏捷开发实施方案

    2019-06-06 14:12:32
    本文认为,要想实施敏捷开发方案,必须首先建立一个高效的工作团队,并依据流程沟通需求,进行程序研发和产品构建,并不断测试,最终实现项目。 本文在本方案中,会按照创建高效工作团队,敏捷匹配需求,敏捷研发与...
  • 敏捷开发项目管理流程

    千次阅读 2017-09-08 13:30:27
    前段时间给大家整理了敏捷开发的流程,最近在整理敏捷开发项目的流程和管理制度,其整理的项目管理规程如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家在实际...
  • 说一下你对敏捷开发的理解,为什么要使用敏捷开发? 》瀑布模型的典型问题就是周期长,发布烦,变更难。 》敏捷开发就是快速迭代,持续集成,拥抱变化。     所谓“敏捷”,顾名思义,可以通俗...
  • 敏捷开发是一个什么样的开发模式

    千次阅读 2016-08-29 07:26:45
    很显然传统的瀑布开发模式已经不能满足需要了,于是,敏捷开发这种模式就出现了。  接触过敏捷开发的朋友可能会知道,敏捷开发有如下的价值观:  个体与互动 胜于 过程与工具,可工作软件 胜于 复杂文档...
  • 敏捷开发工作中总结

    千次阅读 2012-10-22 16:41:42
    1、事无巨细,需求要弄清楚,每步都要确定,不要怕反复开会讨论占用时间,系统开发需求、设计先行!!!!!!!!!!!!!!!! 2、在讨论、开会前要只对目标做好功课!!!!!!!!不打没把握的仗  决策类...
  • 敏捷开发-快速迭代

    千次阅读 2018-05-28 20:56:21
    今天跟大家分享的是“敏捷开发、快速迭代”。我们大都采用的是“瀑布开发模式”,有了问题,就得返工,虽然最终的产品会比较齐全完善,但是开发周期太长,开发人员会产生排斥,甚至厌恶的心理。经过YH系统的开发,也...
  • 什么是敏捷开发流程

    千次阅读 2019-05-11 19:34:29
    【什么是敏捷开发流程 】 这个词猛一听起来感觉很高大上,其实现在已经是主流的团队开发流程 了。 一. 先说一下官方的定义: 敏捷不是指某一种具体的方法论、过程或框架,而是一组价值观和原则。符合敏捷价值观....
  • 觉得这篇文章写的非常好,非常有助于大家了解敏捷开发,原文链接在下面 https://www.jianshu.com/p/eb8f4448c5c8 什么是敏捷开发敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。在...
  • 敏捷开发加班吗?

    2012-10-08 17:43:32
    有些程序员认为,敏捷开发制度上要求不加班(可持续的步调),因此会说“老板,现在你不是推敏捷开发吗,那我们就不能加班了,因为敏捷开发不能加班。”结果肯定是:“敏捷要敏捷,加班也要继续加班。” “存在...
  • 瀑布开发模式和敏捷开发模式的区别和思考

    万次阅读 多人点赞 2017-04-12 14:18:54
    瀑布开发模式: 瀑布开发模式有以下显著的特点: 1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。 使用里程碑的方式,严格定义了...
  • 敏捷开发人员结构 本文旨在分享在敏捷组织中使用开发软件接口运行项目的经验。 为了有机会加入团队,使用了这种方法来查看不同的观点。 通过阅读或听取他人的意见,我认为这对于研究和应用读者很有用。 或补充现有的...
1 2 3 4 5 ... 20
收藏数 14,474
精华内容 5,789
关键字:

敏捷开发工作进度表