精华内容
下载资源
问答
  • 敏捷项目管理
    千次阅读
    2022-06-20 06:49:26

    敏捷,近几年是火出圈的一个词,以前是软件开发或者往大点说是IT圈的名词,现在已经是各行各业争相追捧的热词。姑且不说此敏捷非彼敏捷的事情,但就这个现象来说,敏捷是有可取的地方,值得去研究。

    咱们还是说回老本行-IT圈吧,很多IT企业尤其是软件企业,随着市场规模不断增大、客户越来越多、员工越来越多,随着而来的问题也就越来越明显,市场竞争越发激烈、客户的需求总在变化、员工的堕怠导致效率降低。很多的企业已经开始敏捷实践,用敏捷项目管理来应对上述问题,并已经有了卓有成效的结果。但如何进行敏捷实践,如何做好敏捷项目管理,对于大多数还没开始的企业或者项目经理来说,还是一件相对困难的事情,笔者根据自己的实践,总结了几条经验,分享给大家。

    一、敏捷项目管理不是颠覆传统的项目管理的理论和方法,而是在原有基础上的提升改进。

        这点在敏捷宣言里就有所体现,可能大家更多的关注的是敏捷宣言里的个体和互动高于流程和工具、可工作的软件高于详尽的文档、客户合作高于合同谈判、响应变化高于遵循计划这四条,其实在这四条之前和之后各有一句话,“我们一直在实践中探寻更好的软件开发的方法”和“尽管右项有一定的价值”,这两句话就很明显的表明了两件事,一个是敏捷是从实践中总结而来,一个是传统的项目管理的方式是有价值的。

                另外我们来看看敏捷的由来吧。敏捷的起源普遍的共识是2001213日发表的敏捷宣言为标志的,敏捷宣言是由17位软件开发领域的领军人物经过两天的时间讨论形成的,这17位参会者分别来自于极限编程ScrumDSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程的代表们,还包括了希望找到文档驱动、重型软件开发过程的替代品的一些推动者。其实仔细分析一下,敏捷就是来自于经验和实践,是对传统软件开发方式的补充、改进的方法的总结,形成了敏捷的普适性的理念-敏捷宣言。也就是敏捷从诞生开始就是在传统软件开发理论或者说传统的项目管理理论的改进和实践,敏捷诞生的过程就是发现问题-制定改进计划-实践改进方法-检查改进效果-再总结改进的过程,这就是朴素的管理理论PDCA循环。由此可以看出敏捷也是要遵从基本的管理理论的,是在此基础上的实践,是经验和实践的积累和总结。

        从以上两点,足以说明敏捷项目管理不是对传统项目管理的理论和思想的颠覆,而是在传统项目管理的基础上,进行提升和改进。

    二、敏捷项目管理要从形式回归本质,重内涵而不注重表象,做到手中无剑心中有剑。

        敏捷有很多的方法和工具,使用最广的是Scrum框架,也就是我们通常说的3355,三种角色(产品负责人、敏捷团队、敏捷教练)、三种工件(产品待办事项、冲刺待办事项、产品增量)、五种仪式(每日站会、冲刺计划会、冲刺回顾会、冲刺评审会、待办事项梳理会)、五种价值观(专注、勇气、开放、尊重、承诺)。很多项目经理在实践敏捷的时候,经常纠结于要不要严格的按照这些去执行,少了一个或者是没有采用同样的方式去做,是不是就不算是敏捷。

        其实,前文我也讲述了敏捷宣言和敏捷原则的由来,就是从众多的敏捷方法中提炼出来的,据不完全统计,敏捷现有500多种方法和工具。从这也就可以看出,在敏捷宣言的框架范围内的就是敏捷,不在乎你采取的是那种方式,或者说不在乎你是不是严格执行了3355。更多的我们是要理解敏捷宣言所要阐述思想的精髓,就是我们如何才能敏捷,我们尊重团队的每个成员、充分沟通;我们使用可工作的软件提升效率;我们拥抱变化、用积极的心态应对变化;我们和客户合作、促使客户深度的参与项目,这些能使我们敏捷,只要我们能够秉持这些理念和思维方式,我们能够总结出或者创新出更多的方式,这就是敏捷。

        用中国的古话来说就是形神兼备,不拘泥于形式,手中无剑心中有剑,将敏捷的思维铭刻于心,自然就有由内而外的敏捷实践。

    三、敏捷项目管理是以激发团队成员的自主自治为终极目标,要润物细无声的让团队不知不觉地践行敏捷。

        传统的项目管理也好,敏捷项目管理也好,最重要的都是如何管理好团队成员。敏捷项目管理更注重激发团队成员的自主性,在充分尊重团队成员的前提下,引导团队成员的积极性,促进团队成员的充分沟通、互帮互助,从而让团队达到不断提升的最佳状态。这里对项目经理就提出了更高的要求,需要项目经理从命令式的管理者,变身为仆人式的促进者,发挥自身的领导力,身体力行的去影响团队,带领团队实践敏捷。通过一点一滴的潜移默化的影响改变团队,让团队不知不觉地践行敏捷。

    总之,敏捷和传统是同根共生的,敏捷项目管理是要和传统项目管理相融合的,是要循序渐进的,润物细无声似的渗透。

     

    更多相关内容
  • 敏捷项目管理-Scrum-PMP考点汇总的敏捷项目管理
  • Jira是Atlassian公司出品的项目与事务跟踪工具,被广泛用于缺陷跟踪、客户服务、需求收集、流程...注意:本课程是接着Jira项目管理之一进行讲解的,也算是Jira项目管理之一的续集,所以如果没有Jira的基础,请慎重。
  • 现在软件领域三大俗,说的是敏捷、大数据、云,说的越多的往往也是处于成熟中,或者需求强调的,我所遇到的项目有幸几乎都触及到这些俗气的元素。不得不说,市场竞争和各厂商客户意识的提升,现在的用户已经被宠坏了...
  • 敏捷项目管理

    千次阅读 2021-12-03 17:30:34
    在理解敏捷项目管理之前,我们先看一下它与传统项目管理之间有什么联系和差异。 传统项目管理模式,一般指瀑布模式。它必须完成上一阶段工作并通过检验才能启动下一阶段工作,将整个项目过程划分为五大过程组。 ...

    与传统项目管理有什么关系?

    在理解敏捷项目管理之前,我们先看一下它与传统项目管理之间有什么联系和差异。

    传统项目管理模式,一般指瀑布模式。它必须完成上一阶段工作并通过检验才能启动下一阶段工作,将整个项目过程划分为五大过程组。

    而敏捷项目管理模式,一般包含迭代和增量。它将整个项目过程拆分为若干个迭代,每个迭代完成一部分用户可感知的完整功能。一般情况下,每个迭代内的项目过程均遵循五大过程组。

    传统项目管理模式与敏捷项目管理模式之间存在的差异,可以总结如下:

    瀑布模式敏捷模式
    核心驱动文档和计划驱动用户可感知的完整功能驱动
    计划提前对整个项目过程进行详细估算、分析、计划提前对整个项目做一个粗略的计划。在每个迭代里做每个迭代的详细计划
    变更严密的合同来减少变更风险,如果改变需求需要走CR流程,整个项目过程需要重新估算和规划基于信任,合约使变更变得简单。鼓励变化,聚焦客户价值,将有益于客户价值实现的变更在后续迭代内进行估算和规划
    风险项目交付晚,意识到风险的时间晚每次迭代都产生可交付的功能,发现风险的时间早
    可视化项目过程是一个“黑盒子”,对于客户和供应商来说可视化较差客户、供应商和开发人员之间是紧密连续的合作关系,项目过程可视化较好
    应用场景消耗成本较高的项目过程。如三峡工程、火箭发射消耗成本较低的项目过程。如软件开发

    我从项目团队的视角出发,归纳了在项目管理中我们通常遇到的几大类问题:

    1、团队目标不一致
    2、团队成员不熟悉
    3、信息发布不顺畅
    4、项目经常发生变更
    5、不清楚,研发团队的工作量,是正常、超负荷、还是有人不饱和
    6、需求延期发布成为了家常便饭,不知道什么时候会发布上线

    作为项目管理的我们,不断地经历一个又一个的项目,一次次地面对相同的问题。如果我们不从中总结和提炼,我们就会反复地徘徊在丰满的理想和骨感的现实中。
    敏捷思想和敏捷实践,为我们提供了一种解决方法,帮助我们解决在项目交付过程中遇到的具体问题

     

    1、团队目标不一致

    用电子墙和物理墙展示用户故事、需求全景图、项目进度燃尽图;

    通过迭代会议和功能演示会议对齐迭代计划,项目进度、识别项目风险。

    2、团队成员不熟悉

    基于敏捷实践,创造更多的沟通机会,比如回顾会议、代码审查和站立会议。通过不断地创造这样的沟通机会让团队成员更加默契。

    3、信息发布不顺畅

    共享信息,制定沟通计划;

    最大程度的可视化。

    4、项目经常发生变更

    基于敏捷实践,鼓励变化,聚焦客户价值。

    5、不清楚,研发团队的工作量,是正常、超负荷、还是有人不饱和

    通过每日站立会议,每周回顾会议,敏捷工具中的任务以及燃尽图判断研发团队的工作量,是否饱和等等

    6、需求延期发布成为了家常便饭,不知道什么时候会发布上线

    通过每日站立会议,每周回顾会议让团队发言遇到什么困难以及敏捷工具中的任务以及燃尽图判断,会不会导致项目延期发布等问题,提早做相应的补救方案等等。


    一、敏捷项目管理定义

    敏捷:是一种通过创造变化和响应变化在不确定和混乱的环境中取得成功的能力。

    敏捷项目管理:指在项目活动中运用敏捷的理念,配合专门的知识、技能、工具和方法 ,使项目能够在有限资源限定条件下,实现或超过设定的需求和期望的过程
     

    二、敏捷软件开发宣言:

    我们一直在实践中探寻更好的软件开发方法,身体力行,同时也帮助他人。由此我们建立了如下价值观:

    个体和互动 高于 流程和工具

    工作的软件 高于 详尽的文档

    客户合作 高于 合同谈判

    响应变化 高于 遵循计划

    也就是说,尽管右项有其价值,我们更重视左项的价值。

     

    三、敏捷开发十二原则:

    1. 我们最重要的目标,是通过及早和持续不断地交付有价值的软件使客户满意。
    2. 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
    3. 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
    4. 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
    5. 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
    6. 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。
    7. 可工作的软件是进度的首要度量标准。
    8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
    9. 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
    10. 以简洁为本,它是极力减少不必要工作量的艺术。
    11. 最好的架构、需求和设计出自自组织团队。
    12. 团队定期地反思如何能提高成效,并依此调整自身的行为表现。


     

    四、敏捷项目管理(方法)

    虽然敏捷项目管理的本质是理念,看起来很玄乎。但是敏捷先驱们基于这种里面已经开发出了非常多的看得见摸得着的敏捷管理框架,日常项目管理工作中常见管理框架有以下几种:

    SCRUM

    SCRUM是一种迭代的增量化过程,用于产品开发或工作管理。它是一种可以集合各种开发实践的经验化过程框架。SCRUM中发布产品的重要性高于一切。

    Kanban(看板管理)

    看板管理在工业企业的工序管理中,以卡片为凭证,定时定点交货的管理制度。

    XP(极限编程)

    极限编程注重的核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化,XP无需开发人员在软件开始初期做 出很多的文档。XP提倡测试先行,为了将以后出现bug的几率降到最低。


    敏捷流程图:
     

    SCRUM框架

    Scrum框架包括3个角色、3个工件、4个事件、5个价值:

    3个角色

    1. 产品负责人(Product Owner):俗称PO,主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果
    2. Scrum Master:流程管理员,为团队赋能,团队核心,主要负责整个 Scrum 流程在项目中的顺利实施和进行
    3. 开发团队:主要负责软件产品在 Scrum 规定流程下进行开发工作,人数控制在 5~10 人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到 Sprint 的目标

    3个工件

    1. 产品Backlog(Product Backlog):产品待办列表,这个列表里面包含所有的需求,都是有价值的,有次序的需求池列表。
    2. SprintBacklog:俗称冲刺需求列表,也表示本次迭代需要完成的任务列表
    3. 燃尽图:查看每日任务,故事燃烧情况

    4个事件(Sprint本身是一个事件,包括了如下4个事件)

    1. Sprint计划会议(Sprint Planning Meeting)
    2. 每日站会(Daily Scrum Meeting)
    3. Sprint评审会议(Sprint Review Meeting)
    4. Sprint回顾会议(Sprint Retrospective Meeting)

    5个价值

    1. 承诺 – 愿意对目标做出承诺
    2. 专注 – 把你的心思和能力都用到你承诺的工作上去
    3. 开放 – Scrum 把项目中的一切开放给每个人看
    4. 尊重 – 每个人都有他独特的背景和经验
    5. 勇气 – 有勇气做出承诺,履行承诺,接受别人的尊重

    敏捷优点和缺点

    敏捷是项目管理和软件开发的一种迭代方法,可帮助团队更快地向客户,交付价,减少麻烦。敏捷团队不是把所有事情都押在“大爆炸”的发布上,而是以小的但可消耗的增量交付工作。需求、计划和结果会得到持续评估,因此团队拥有快速响应变化的机制。

    1、敏捷的优点:

    • 更快交付价值

    敏捷是基于价值驱动交付,项目团队要频繁的且尽快的给客户交付可以使用的产品,并尽早的让让产品投入市场可以尽早的验证其商业模式和商业价值,这是敏捷提倡的核心价值之一。

    • 更低的风险

    敏捷提倡优先交付高价值、高风险的需求,然后交付高价值、低风险的需求、再交付低价值、高风险、最后低价值、低风险的需求。这样的好处是把最高风险的需求在项目的初期就开始做,可以最早发现该产品是否可行(通常只要1~4周)。如果因为市场、技术或者其它原因失败了,可以及时停止该项目,降低项目风险。即使这个项目失败了,这个失败的代价相对来说小一些。

    • 拥抱变化

    在VUCA 迭代开发的后期也接受变更。因为市场在变化,用户的期望和要求在变化,客户的需求也会随着这些因素的变化而变化,只有及时响应这些变化,并尽快予以实施,才能帮助客户在瞬息万变的市场中保证竞争力和吸引力。而敏捷能够帮助团队在小步快跑的过程中能够快速的响应变化。

    • 更好的质量

    敏捷提倡高频率的交付有价值的产品。每天的例会、迭代计划会议、迭代评审会、迭代回顾会议都在对可交付成果质量上进行层层把关,因为在这几个会议中会频繁讨论遇到的问题/解决方案,验收标准,DoD等等。同时,也会邀请项目干系人参加迭代评审会并对可交付成果验收和反馈,这样团队可以及时予以调整,以确保质量。

    • 持续改进

    敏捷提倡不断调整和优化,并在每个迭代的迭代回顾会议进行分析、讨论、总结敏捷当前迭代开发过程中需要改进或者要提升的地方,进而在下个迭代中改进、调整和优化。这是整个团队成员不断学习,不断提升自己经验、技能的一个很好的机会。另外,因为敏捷强调客户参与的重要性,对于客户的反馈意见和建议,开发团队也会及时给与相应以及反馈,让双方可以更好的合作,建立更加信任的合作关系。

    • 更高的客户满意度

    敏捷提倡尽早和频繁的为客户交付有价值的产品,以确保更高的质量,更高的成功率,为客户尽早带来商业投资回报率的机会。

    • 更高的团队满意度

    敏捷提倡仆人式的领导,SM需要给团队工作上的指导、帮助和支持,扫除团队成员工作上遇到的问题和障碍。重视并尊重团队成员的想法和意见,授权团队并引导团队成员自组织和自管理。更重要的是,团队成员可以决定要做什么、怎么做、什么时候做,并自己监控和管理工作进展,对结果负责;团队成员可以一起讨论并确认工作协议,确保考虑并接纳每个人的意见;团队成员可以一起评估故事点;同时,SM要引导团队成员之间相互协作并促进合作。通过这些,团队成员可以更高效的工作,交付的质量也会提高,团队成员的满意度也会大大提高,"A happy employee is a productive employee",不是吗?

    • 更大的灵活性

    敏捷基于价值驱动,它的项目范围是可以灵活调整的,这就给项目干系人很多的灵活性来根据市场不断调整需求范围、变更以及优先级等等。另外,敏捷提倡频率与团队和客户沟通交流,并不断根据反馈和意见调整管理方法、需求流程、开发流程以及运维流程等等。还有,验收标准,都可以根据实际情况进行调整。

    当然敏捷还有很多其它的优点,比如透明、简洁、高效,更早进入开发等等,在这里就不一一介绍了。

     
     

    2、敏捷的缺点和不足:

    尽管敏捷带来了很多改善,但是再次重申它并不是适合所有人和所有情况的。因此,了解敏捷的不足显得特别重要。知道这点后,你心理上是准备好的并且会根据具体情况来做裁剪和优化来规避或减少负面影响。

    由于敏捷团队不是一开始就知道产品“最终的样子”,而是在过程中探索用户的需求逐渐知道产品真正的终局状态,这样一来就给前期的规划(成本,时间,资源)带来了很大的挑战(项目越大越复杂这一点变动更加明细)。

    • 很难准确的定义“轻量的“或必要的文档

    敏捷倡导的是用工作的软件即文档(核心是代码即文档)。整个项目用于产品开发的文档不是一开始准备好的(甚至都没有RP原型设计),而是在过程中”及时的“ just-in-time准备出来的。因此,我们看到的是非常简单的且常常被放在最后处理的文档(在项目中涉及到移交或问题分析时这一点显得尤其突出)

    • 很难把握整体产品的一致性

    增量交付可能有助于更快地将产品推向市场,但这也是敏捷方法论的一大缺点。因为当团队在不同的周期内对各个组件进行开发时,整体的输出往往会变得非常零散,而不是一个内部紧密集合的整体。(当项目对UI和UX有更高的要求时,这个挑战就变得更加明显)。

    • 很难预测有限的终点

    敏捷在一开始要求最低限度的规划,这使得交付新的、意想不到的功能时很容易偏离方向。此外,这意味着项目没有限定的终点,因为从来没有一个明确的 "最终的产品"样子。

     

    那为什么互联网项目要用敏捷开发呢?
    1、出成果(版本)快,互联网就是以快吃慢,一般都是迭代发布的,追求创新,说明了需要快速响应用户的变化,时间就是一切,需求不确定性高,这个在软件行业也很常见;关注用户行为,倡导以用户为中心的产品设计。很典型的例子微信,腾讯一个月开发出来的产品,根据用户体验和反馈,通过反复的小迭代来优化。

    2、互联网项目中市场反响和客户体验尤为重要,需要有一个快速迭代来响应客户的需求,确保客户的满意度。如果是瀑布式开发,迭代慢,更改的成本也比较高。

    3、随时应对变化,因为迭代周期的减小,使得项目的弹性更足,可以更好的适应互联网项目上更多的不确定性。
     



    敏捷项目管理软件:推荐大家使用腾讯的tapd

    展开全文
  • 敏捷项目管理概述

    2021-02-24 15:11:51
    敏捷项目管理作为新兴的项目管理模式,简化了传统项目管理的繁琐流程和文档。以Scrum为代表,欢迎需求变更,在客户需求不明确的时候,以在较短的周期内开发出可用的软件为目标,来帮助客户描述自己的需求。迭代过程...
  • 之一:文化根源分析最近研究敏捷项目管理,发现其中很多的最佳实践体现出了非常多的项目团队的文化变革,在此小结分享。相信很多人还记得五年前曾经非常火过一段的软件工厂的概念,当时有一些公司基于软件工程工具...
  • SCRUM敏捷项目管理.rar

    2019-10-11 16:58:16
    敏捷开发圣经,由敏捷开发创始人结合经典案例,深入剖析敏捷开发的要点以及相关事项。
  • 敏捷项目管理流程-Scrum框架最全总结.txt
  • Scrum敏捷项目管理PPT

    2018-10-01 19:30:14
    Scrum作为一种项目管理方法,已经帮助数百家公司成功走出困境,高质量、快速地成功交付软件产品。Scrum是管理复杂项目的简单方法,它的魅力在于规则和实践方法数量较少,简单好用,容易上手。但与此同时,Scrum的...
  • 敏捷项目管理指南.ppt

    2019-11-01 14:33:42
    敏捷项目管理指南.ppt敏捷项目管理指南.ppt
  • Scrum敏捷项目管理要点总结
  • 敏捷项目管理在软件开发中的实践应用
  • Scrum敏捷项目管理

    2021-03-03 02:55:20
    Scrum 敏捷项目管理ScrumMaster 保证Scrum流程顺利执行ProductManager负责产品质量,保证项目预期价值Group Scrum项目实现团队,具有完全自主性ProductBacklog产品完成logSprint 30天计划Sprint评审审查上一...
  • 本文以笔者的项目管理实践为基础,介绍基于经验过程控制(EmpiricalProcessControl)模型、缺陷预防以及敏捷价值观的敏捷质量管理思想及其实践。希望通过本文为广大项目管理人员提供质量管理的一些思路和经验分享。...
  • 本文以笔者的实际项目管理经验为基础,分享了《孙子兵法》在敏捷项目管理中的应用。希望能够对读者的实际项目管理工作有所启发。谈到“敏捷”首先容易让人想到的是各种优秀实践。这些优秀实践固然有可以借鉴的地方。...
  • 敏捷项目管理学习

    千次阅读 2021-01-03 03:14:47
    7、敏捷项目管理方法:XP、ASD、FDD、TDD、Crystal、DDSM、AUP;8、产品愿景声明和产品路线图;9、用户故事;10、Product Backlog和Sprint Backlog;11、冲刺主要工作、敏捷角色及分工;12、不同折线的燃尽图所说明...

    敏捷项目管理学习

    目录

    1、敏捷工作实践的过程(5个)

    2、敏捷宣言(4个)

    3、敏捷开发原则(12个)

    4、敏捷开发核心思想

    5、Scrum敏捷开发框架

    6、敏捷的角色、工件、仪式

    7、敏捷项目管理方法:XP、ASD、FDD、TDD、Crystal、DSDM、AUP

    8、产品愿景声明和产品路线图

    9、用户故事

    10、Product Backlog和Sprint Backlog

    11、冲刺主要工作、敏捷角色及分工

    12、不同折线的燃尽图所说明的问题(6个)

    13、冲刺评审会议与冲刺回顾会议

    14、Scrum主管的主要工作、与产品负责人工作的区别、两个角色是否可以由一人承担

    16、敏捷工程实践(4个)

    17、组织中实施敏捷管理的步骤(8个)

    18、冲刺结束,发布产品的准备工作(3个)

    19、敏捷项目管理的关键测量指标(10个)

    20、Scrum团队的核心价值观(5个)

    21、敏捷管理的优势(10个)

    22、传统项目管理的五大过程组和十大知识领域(5个 + 10个)

    23、项目的属性

    24、干系人中,客户与用户的区别

    25、适用于敏捷项目管理的项目类型

    26、其他

    参考文献

    备注:本文将以一个项目实例——PlantSCM(Plant Supply Chain Management,工厂供应链管理系统),作为本文中部分示例图的来源。该项目需求简介如下图1所示:

    图1 工厂供应链管理系统需求简介思维导图

    1、敏捷工作实践的过程(5个)

    • 定义产品愿景和产品路线图 
    • 计划发布与冲刺
      • 细化需求和估算 
      • 创建用户故事 
      • 创建Product Backlog 
      • 发布计划 
      • 冲刺:冲刺计划会议、创建Sprint Backlog、 燃尽初始图、冲刺计划
    • 全天的工作
      • 计划每天的工作,活动:每日例会
      • 跟踪每天的进展,工具:燃尽图,任务板
      • 开发并测试每天的工作
        • PO和开发团队的活动:细化、开发、验证
          • 开发活动:完成标准、结对编程、持续集成、测试驱动开发
          • 验证活动:自动化测试、同行评审、PO评审
        • Scrum Master的活动:识别障碍、解决问题
      • 结束一天的工作,更新、调整Sprint Backlog、燃尽图、任务板等
    • 展示工作和集成反馈:冲刺评审会议、冲刺回顾会议
      • 冲刺评审会议:展示工作 + 收集反馈
      • 冲刺回顾会议:评审冲刺 + 改进流程
    • 为发布做准备
      • 发布迭代:准备部署产品
      • 内部准备:组织为产品发布做好准备
      • 外部准备:市场为产品发布做好准备

    2、敏捷宣言(4个)

    • 如图2所示,主要包括:
      • 个体和交互胜过过程和工具 
      • 可用软件胜过完备文档
      • 客户协作胜过合同谈判
      • 响应变化胜过遵循计划
    图2 敏捷价值观之敏捷宣言

    3、敏捷开发原则(12个)

    • 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
    • 即使到了开发的后期,也欢迎改变需求
    • 经常性地交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好
    • 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作
    • 项目由有激情的、值得信任的个体合作完成
    • 在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈
    • 工作的软件是首要的进度度量标准
    • 敏捷过程提倡平稳的开发节奏;发起人、开发者和用户应该能够保持一个长期的、恒定的开发速度
    • 不断地关注优秀的技术和好的设计可以增强敏捷能力
    • 简单化是根本(不做过度设计和预测)
    • 最好的构架、需求和设计是来源于自组织的团队
    • 每隔一定时间,团队会在如何才能更有效地工作方面进行反思,并对自己的行为进行相应调整

    4、敏捷开发核心思想

    • 以人为本,适应变化

    5、Scrum敏捷开发框架

    • 优先开发高优先级需求,在每个迭代结束后,都会开发完成可交付的产品
    • Scurm过程(如图3所示,重复以下过程,直至项目完成):
      • 产品负责人根据价值和工作量,确定需求优先级,并创建Product Backlog
      • 创建Sprint Backlog
      • 团队每日例会
      • 迭代结束,产生潜在可交付的产品增量
      • 冲刺评审会议冲刺回顾会议
    图3 Scrum敏捷开发方法框架

    6、敏捷的角色、工件、仪式

    • 敏捷角色(Scrum Roles):
      • Scrum主管(Scrum Master)
      • 产品负责人(Product Owner)
      • 开发团队(Scrum Team)
      • 干系人(Stakeholder)
      • 敏捷导师(Agile Mentor)
    • 敏捷工件(Scrum Artifacts):
      • 产品待办列表(Product Backlog)
      • 冲刺待办列表(Sprint Backlog)
      • 产品增量(Product Increment)
      • 燃尽图(Burndown Chart)
    • 敏捷仪式(Scrum Ceremonies):
      • 冲刺计划会议(Sprint Planning Session)
      • 每日例会(Daily Scrum)
      • 冲刺评审会议(Sprint Reviews)
      • 冲刺回顾会议(Sprint Retrospectives)

    7、敏捷项目管理方法:XP、ASD、FDD、TDD、Crystal、DSDM、AUP

    • XP:eXtreme Programming的缩写,极限编程开发方法
      • 轻量级,适用于需求快速变动场景,要求客户与开发人员最好以side-by-side方式工作
      • 目标:降低因需求变更而带来的成本
      • 特征:
        • 增量和反复式的改进和改进
        • 结对编程
        • 测试驱动开发
        • 简单设计
        • 反馈
        • 隐喻来组织系统
        • 可持续的速度
      • 四大价值观
        • 沟通
        • 简单
        • 反馈
        • 勇气
    • ASD:Adaptive Software Development的缩写,自适应软件开发方法
      • 强调开发方法的适应性,从更高的组织和管理层次阐述开发方法为什么要具备适应性
      • 目标:更具迭代性和更短间隔
      • 特征:
        • 专注于最终用户
        • 准时交付
        • 鼓励开发团队和客户之间提高透明度
    • FDD:Feature Driven Development的缩写,特征驱动开发方法
      • 特征驱动,模型驱动,适用于需求经常变更、中小型软件开发项目的开发模式,强调简化、实用;
      • 目标:快速迭代
      • 特征:
        • 开发全局模型(Develop an Overall Model)
        • 建立特征列表(Build Feature List)
        • 依据特征规划(Plan By Feature)
        • 依据特征设计(Design By Feature)
        • 依据特征构建(Build By Feature)
    • TDD:Test Driven Development的缩写,测试驱动开发方法,如图4所示
      • 测试作为编程中心,要求在编写代码前,首先编写单元测试用例,测试用例确定需要编写的功能代码,编写的功能代码要通过用例,并不断重构优化
      • 目标:测试工作保证代码质量,帮助客户和开发团队去除模棱两可的需求
      • 特征:
        • 测试自动化运行
        • 保证代码整洁可用,保证代码重构质量
        • 及时重构,小步前进
        • 提高代码可测试性
    图4 测试驱动开发流程图
    • Crystal:水晶族方法
      • 灵活、执行不严格、全透明的工作方式,是个族系列,对不同类型的项目可以采用不同的实践方法
      • 特征(七大体系特征):
        • 经常交付
        • 反思改进
        • 渗透式交流
        • 个人安全
        • 焦点
        • 与专家用户建立方便的联系
        • 配有自动测试、配置管理和经常集成功能的技术环境
    • DSDM:Dynamical System Development Methodology的缩写,动态系统开发方法,如图5所示
      • 倡导以业务为核心,适用于系统升级的二次开发,是一种控制框架,重点在于快速交付并补充如何应用这些控制的指导原则,已成为应用最为广泛地快速应用开发方法
      • 目标:解决复杂项目管理流程
      • 特征:
        • 开发时间固定,功能划定和资源配置配合实际开发效果进行规划
        • 重在利用原型设计
    图5 DSDM模型
    • AUP:Agile Unified Process的缩写,敏捷统一过程
      • 轻量级RUP,可包容许多不同类型的过程
      • 目的:快速构造可执行软件
      • 特征:
        • 全局串行
        • 局部迭代

    8、产品愿景声明和产品路线图

    • 产品愿景声明(Product Vision Statement):样例如图6所示
      • 定义:确定组织未来或长远位置,以客户为导向,满足利益相关者的需求;确定产品目标和需求,与业务战略的关系是否一致
      • 创建步骤:
        • 设定产品目标
        • 创建愿景声明的草案 
        • 与项目干系人共同确认愿景草案,并修改
        • 确定愿景草案,描述项目开发原因和预期目标
    图6 产品愿景示例
    • 产品路线图(Product Road Map):样例如图7所示
      • 定义:产品需求的综合提示图,是产品需求的概览,也是组织开发过程的工具
      • 创建步骤:
        • 分解产品需求
        • 整理产品特性
        • 估算产品特性:对需求价值和工作量打分,确定核心需求
        • 计算相对优先级并排序
        • 决定产品特性的时间框架:按照优先级排序,确定产品迭代时间增量,创建产品路线图
    图7 产品路线图示例

    9、用户故事

    • 定义:一种对某个产品需求的简单描述
    • 用户故事卡片:
      • 标题【名称】
      • 作为【用户】或【角色】
      • 我希望【行动】
      • 以便【获得益处】
    • 创建步骤:
      • 识别项目干系人:专家、管理者、普通用户、技术用户等 
      • 识别客户:即使用该产品的人(角色),细分客户类型和特点 
      • 制作用户画像:描述识别的用户特点,样例如图8所示
      • 创建用户故事: 样例如图9所示
        • 确定产品需求 
        • 和干系人协作完成产品需求描述 
        • 编写用户故事卡片
    图8 用户画像示例
    图9 用户故事示例
    • 优先级确定规则:
      • 优先级 = 价值 / 工作量
        • 价值打分:客户、PO、其他相关干系人
        • 工作量打分:开发团队
      • 风险越高,经济价值越高的功能,优先级越高

    10、Product Backlog和Sprint Backlog

    • Product Backlog:确定了用户故事优先级的用户故事列表,样例如图10所示
      • 如下图所示,表头主要包括:
        • 用户故事编号、用户故事
        • 优先级(其等于价值 / 工作量)、价值、人天评估(工作量)、实际人天
        • 产品特性
        • 预期结果
        • 对应TAPD任务链接
        • 状态
        • 用户角色
        • 填写日期、计划开始时间、计划完成时间、实际开始时间、实际结束时间
    图10 Product Backlog示意图
    • Sprint Backlog:冲刺阶段的重要文档,用于描述任务、时间计划和进度,样例如图11所示
      • 如下图所示,表头主要包括:
        • 编号、用户故事、故事点、故事点预计
        • 任务
        • 负责人
        • 工作量估算
        • 具体每日时间结点及完成情况(绿色:表示计划完成并实际完成;红色表示计划完成但出现延期;蓝色:表示额外完成)
    图11 Sprint Backlog示意图

    11、冲刺主要工作、敏捷角色及分工

    • 主要工作:冲刺计划会议、创建Sprint Backlog、燃尽初始图、 冲刺计划
    • 敏捷角色及分工:
      • 开发团队: 
        • 完成可交付的产品 
      • 产品负责人:
        • 审核产品待办列表和冲刺计划 
        • 解决开发中的技术问题
        • 验证每天的测试结果 
        • 监督指导持续集成的工作 
      • Scrum主管:
        • 每日站会
        • 解决遇到的非技术困难,保护开发团队不受外部干扰 
        • 保持与干系人的良好沟通,建立好的人际关系 

    12、不同折线的燃尽图所说明的问题(6个)

    • 如图12所示,主要包括符合预期、较复杂、较简单、假象、无参与、快速失败等六种。其中图12中蓝色折线为计划燃尽线,绿色折线为实际燃尽线(剩余时数);图13为样例燃尽图
      • 符合预期:开发过程中有细节需补充,但总体可控,属于正常
      • 较复杂:开始无进展,开发团队根据情况,可移除一些用户故事
      • 较简单:进展顺利,后期进度提前,可增加一些用户故事
      • 假象:可能为了考核等原因,不是真正的进度情况,要了解开发团队原因,消除假象
      • 无参与:可能没有更新自己的工作进度,也可能是PO增加了一些已完成的任务
      • 快速失败:可能没有使用燃尽图,或发现项目没进展,快速停止,解决问题
    图12 不同折线的燃尽图
    图13 燃尽图示例

    13、冲刺评审会议与冲刺回顾会议

    • 冲刺评审会议:
      • 目标:
        • 由产品负责人向用户代表和干系人展示用户故事、演示可交付的功能
        • 记录和收集反馈意见,将新的用户故事放到产品Backlog,已有用户故事的修改放到冲刺Backlog
      • 作用:
        • 演示可交付的功能,用以确认项目进度,具有真实性
        • 尽早获得用户反馈,产品更贴合用户需求
      • 需要的准备工作:
        • 邀请参加的人员
        • 确定会议时间、地点
        • 资料准备
        • 日程确定、产品演示及讨论
        • 会议的进程控制,讨论中的时间控制
        • 会议纪要、总结与反馈
    • 冲刺回顾会议:
      • 目标:
        • 开发团队、产品负责人、Scrum主管一起回顾本次冲刺
        • 回顾开发平台、测试工具、管理平台等的选择和使用情况,敏捷过程中沟通、敏捷实践是否合理等
      • 作用:
        • 分享好的经验和发现改进点
      • 需要准备的工作:
        • 确定会议时间地点
        • 回顾内容:工具、结对、分工、问题解决等做成道具
        • 确定开会方式:讨论式、头脑风暴、引领式等
        • 会议纪要、总结与反馈

    14、Scrum主管的主要工作、与产品负责人工作的区别、两个角色是否可以由一人承担

    • Scrum主管的主要工作:
      • 服务于产品负责人
        • 确保Scrum团队中的每个人都尽可能理解目标、范围和产品域
        • 找到高效管理产品待办列表的技巧
        • 理解在经验主义的环境中的产品规划
        • 确保产品负责人懂得如何来安排产品待办列表使其达到最大价值化
        • 理解并实践敏捷性
        • 当被请求或需要时,引导Scrum事件
      • 服务于开发团队
        • 作为教练在自组织和跨职能方面给予开发团队以指导
        • 帮助开发团队创造高价值的产品
        • 移除开发团队工作进展中的障碍
        • 当被请求或需要时,引导Scrum事件
        • 在Scrum还未完全采纳和理解的组织环境中,作为教练指导开发团队
      • 服务于组织
        • 带领并作为教练指导组织采纳Scrum
        • 在组织范围内规划Scrum的实施
        • 帮助员工和干系人理解并实施Scrum和经验导向的产品开发
        • 引发能够提升Scrum团队生产率的改变
        • 与其他Scrum Master一起工作,增强组织中Scrum应用的有效性
      • 二者区别:
        • Scrum主管:主要确保团队是富有成效的,促进日常需求和迭代推进,促进外部干系人和Scrum团队的密切联系,对功能很熟悉,同时还具备扫除障碍,防范干扰的能力
        • 产品负责人:负责项目业务价值,提供项目战略和方向,决定做什么工作以及按照什么顺序完成,然后将其记录到Product Backlog中
      • 两个角色不应该由一人承担。因为产品负责人主要负责与客户互动,创建客户案例,组织积压的产品并确定优先级,以及其他面向客户/用户的问题。而Scrum Master主要处理流程,监督会议,消除障碍并监视项目的整体运行状况,并根据需要进行调整。因此,二者术业有专攻,不应该由一人承担

    16、敏捷工程实践(4个)

    • 结对编程:两位程序员在一台电脑前工作,一位负责编程,另一位实时检查每一行敲入的代码
      • 作用:
        • 促进代码设计质量
        • 提升团队能力和知识传播
      • 研究表明结对生产率比两个单人总和低15%,但缺陷数少15%,考虑修改缺陷工作量和时间都比初始编程大几倍,所以结对编程总体效率更高
    • 持续集成(CI):
      • 提供产品质量的快速反馈,保证随时拥有可工作软件
      • 修复失败的构建是团队最高优先级的任务
    • 测试驱动开发(TDD):见本博客中第七部分【敏捷项目管理方法】中描述
    • 重构:改善既有代码设计

    17、组织中实施敏捷管理的步骤(8个)

    • 制定实施策略
    • 构建意识,培养热情
    • 实施团队转型
    • 确定实验的项目
    • 确定成功的标准:时间、成本、质量、风险、变更、交付的成果
    • 培训计划与实施
    • 总结与改进
    • 推广

    18、冲刺结束,发布产品的准备工作(3个)

    • 发布迭代:准备部署产品

      • 帮助客户正确使用发布的产品

      • 团队做好运营和维护准备

      • 创建用户在线帮助文档

      • 进行性能测试、压力测试、安全测试

      • 如果系统升级重构,检查与旧系统的集成测试

      • 准备产品部署工作

      • 经营许可和法律审查

      • 内部产品发布审批报告准备

    • 内部准备:组织为产品发布做好准备

      • 公司个组织部门要为产品发布做好准备

      • PO和Scrum Master要准备一个发布迭代待办列表

      • 识别和确定完成发布活动的干系人

        • 市场部门:与新产品发布相关的市场活动

        • 销售部门:向哪些客户推销产品、推销策略等

        • 生产部门:如何部署或打包产品

        • 技术部门:如何收集客户反馈,如何响应客户意见

        • 运营部门:帮助运行产品,解决运行中出现的问题

        • 法务部门:产品许可,法律依规,版权纠纷,产权归属

      • 准备评审会的PPT,解释产品的背景、目标、价值,确保干系人充分理解产品和产品客户

      • PO负责迭代发布任务的汇报,市场部门或运营部门主持评审会

    • 外部准备:市场为产品发布做好准备

      • 确定产品推广、品牌营销的时机

      • 运营和市场把客户反馈转化为产品推广的依据

      • 准备产品推广文案、新闻发布会、产品包装等营销物料

      • 支持渠道要畅通

    19、敏捷项目管理的关键测量指标(10个)

    • 冲刺目标成功率
    • 缺陷数量
    • 项目总工期
    • 产品上市时间
    • 项目总成本
    • 投资回报率
    • ROI预算中的新请求(新的产品特性可能转化成更高的产品收入)
    • 资金调配:将项目预算从一个项目移到另外一个项目的操作过程
    • 满意度调查
    • 团队成员流动率

    20、Scrum团队的核心价值观(5个)

    • 承诺(Commitment):团队要对目标做出承诺,并对结果负责
    • 专注(Focus):团队的每一个成员专注在项目上,排除一切干扰
    • 开放(Openness):团队成员要相互信任,保持并鼓励每一个成员采用开放的态度
    • 尊重(Respect):建立相互尊重的工作氛围,积极和快乐的人会对他人友善
    • 勇气(Courage):有勇气做出承诺并坚持这些承诺,有勇气保持专注并向干扰者说“不”,有勇气保持开放并愿意改进,有勇气尊重并包容不同意见

    21、敏捷管理的优势(10个)

    • 更好的产品质量
    • 更高的客户满意度
    • 更高的团队士气
    • 增强合作和责任感
    • 可定制的团队结构(允许团队成员按自己特定的工作风格和个性组建团队,根据成员特定的技能进行分工)
    • 更多的测量标准(燃尽图故事点、速率、ROI投资回报率、时间表和预算)
    • 提高绩效可视性(看板站会冲刺评估
    • 项目更易监控(有多个环节可以控制和调整)
    • 提高项目可预测性
    • 降低风险

    22、传统项目管理的五大过程组和十大知识领域(5个 + 10个)

    • 五大过程组:
      • 启动
      • 规划
      • 执行
      • 监控
      • 收尾
    • 十大知识领域:
      • 项目整合管理
      • 项目范围管理
      • 项目时间管理
      • 项目成本管理
      • 项目质量管理
      • 项目人力资源管理
      • 项目沟通管理
      • 项目风险管理
      • 项目采购管理
      • 项目干系人管理

    23、项目的属性

    • 生成唯一的产品、服务或结果
    • 暂时性
    • 通过逐步完善的方法开发
    • 需要资源来完成,资源通常来自不同的领域
    • 需要有一个主要的客户或项目赞助商
    • 涉及到不确定性

    24、干系人中,客户与用户的区别

    • 二者出发点不同。客户是产品的购买者,用户是产品的使用者。客户是对产品或服务达成买卖关系的实体,用户是使用产品或服务,与产品或服务产生直接交互的实体
    • 二者关注点不同。客户关注价格和效果,用户关注简单性、实用性和提升效率

    25、适用于敏捷项目管理的项目类型

    • 适用类型:
      • 需要进行快速迭代、输出交付的产品
      • 产品复杂,不断有新需求加入
      • 需求方想尽早看到结果,并给予反馈
      • 需要在开发过程中与客户紧密协作,对于客户需求变更给予快速响应
    • 实例:
      • 实例一:公司内部定制化工具类核心产品。因为该类产品的开发主要是为了公司内部服务的,比如公司内部自主研发的算法能力平台、数据采集统一平台、数据统一流程管理平台等等。首先,这些平台都是需要不断的贴合企业内部交付中心团队不断提出的需求的,因此在整个开发过程中,会有新需求加入。其次,这些工具平台能力越快迭代出发布版本越好,因为可以提高交付团队研发效率,避免重复造车轮。因此该类型项目适用于敏捷项目管理
      • 实例二:与其他竞司的竞品形成的高竞争新型产品。该类产品需要快速迭代出版本,迅速抢占市场。再根据用户反馈,不断的迭代优化产品。因此该类型项目适用于敏捷项目管理

    26、其他

    (1)Sprint评审:让利益相关者审阅团队所建设的成果,并为后续计划提供信息

    (2)Sprint推荐的最长周期是:30天

    (3)如果Sprint长30天,Sprint评审会议最多为:4小时

    (4)何时更新发布燃尽图:每个Sprint后

    (5)良好团队的特征:自组织的

    (6)如果敏捷项目运行后出现新需求,应该是:评估重要性,如果对业务来说足够重要,则包括在项目中,取代较不重要的需求

    (7)“拉动”一词是指下工序带动上工序

    (8)“拉动”系统的核心是:准时化

    (9)内部项目的管理方式:管理是共同承担责任,计划由所有成员和资深项目管理人员共同制定,从而不需要强制就可以共同遵从

    (10)外部项目的管理方式:管理是正式的、结构化的,要求周期性进行,并且由一个独立机构进行技术审核

    (11)敏捷项目中推荐的设计方法:前面有足够的设计

    (12)敏捷开发是一种:以人为核心、迭代、循序渐进的开发方法

    (13)看板的三大作用:a)传递生产信息;b)识别浪费;c)控制生产系统动态地自我完善

    (14)实行“看板方式”的基础是:流水线生产

    (15)所有的敏捷开发方法的共同点:迭代开发和增量交付

    (16)精益管理的核心是:消除一切浪费

    (17)自动化测试所占比例应该:大于60%

    (18)敏捷宣言背后的原则对于架构的处理是如何建议的:架构会浮现出来

    (19)使用Scrum时,负责在范围和进度之间作出权衡决策的是:产品负责人

    (20)Scrum的框架核心:Scrum的所有实践都是围绕一个迭代、增量的过程框架展开

    (21)Scrum框架下,对软件的交付负责的是:开发团队

    (22)Scrum的三大支柱:透明性、检验、适应

    (23)冲刺:面向团队;迭代:面向产品;一次冲刺可有N次迭代

    参考文献

    [1]陈泽琳: AgilePM2020-课件1, 华南理工大学软件学院,2020.10;
    [2]陈泽琳: AgilePM2020-课件2, 华南理工大学软件学院,2020.10;
    [3]陈泽琳: AgilePM2020-课件3, 华南理工大学软件学院,2020.10;
    [4]陈泽琳: AgilePM2020-课件4, 华南理工大学软件学院,2020.10;
    [5]陈泽琳: AgilePM2020-课件5, 华南理工大学软件学院,2020.10;
    [6]陈泽琳: 作业1, 华南理工大学软件学院,2020.10.23;
    [7]陈泽琳: 作业2, 华南理工大学软件学院,2020.11.13;
    [8]陈泽琳: 作业3, 华南理工大学软件学院,2020.12.18;
    [9]陈泽琳: 作业4, 华南理工大学软件学院,2020.12.24;
    [10]Project Management Institute: 项目管理知识体系指南(PMBOK指南第六版),[M]北京:电子工业出版社,2018.05;

    展开全文
  • Scrum 敏捷项目管理

    千次阅读 2022-01-13 09:03:24
    在理解敏捷项目管理之前,我们先看一下它与传统项目管理之间有什么联系和差异。 传统项目管理模式:一般指瀑布模式。它必须完成上一阶段工作并通过检验才能启动下一阶段工作,将整个项目过程划分为五大过程组。 ...

    在理解敏捷项目管理之前,我们先看一下它与传统项目管理之间有什么联系和差异。

    传统项目管理模式:一般指瀑布模式。它必须完成上一阶段工作并通过检验才能启动下一阶段工作,将整个项目过程划分为五大过程组。

    要求在项目建设时,需求足够明确、文档足够规范,迭代过程中需求变更越多、越晚,对项目影响越大,会影响到项目的交付质量。

    敏捷项目管理模式,一般包含迭代和增量。它将整个项目过程拆分为若干个迭代,每个迭代完成一部分用户可感知的完整功能。一般情况下,每个迭代内的项目过程均遵循五大过程

    敏捷项目管理到底是什么?

    我从定义、本质、框架、常见实践4个方面总结。

    一、敏捷项目管理定义

    敏捷:是一种通过创造变化和响应变化在不确定和混乱的环境中取得成功的能力。

    敏捷项目管理:指在项目活动中运用敏捷的理念,配合专门的知识、技能、工具和方法 ,使项目能够在有限资源限定条件下,实现或超过设定的需求和期望的过程。

    二、敏捷项目管理本质

    通过敏捷项目管理定义,我想你已经猜到其本质是什么。是的,其本质是一种理念,并基于这种理念进行不断实践在不确定和混乱的环境种取得项目成功,同时将这些实践总结提炼为团队稳定的解决方案。

    这种理念也被先驱者们总结为敏捷软件开发宣言和敏捷开发十二原则。

    敏捷软件开发宣言:

    我们一直在实践中探寻更好的软件开发方法,身体力行,同时也帮助他人。由此我们建立了如下价值观:

    个体和互动 高于 流程和工具

    工作的软件 高于 详尽的文档

    客户合作 高于 合同谈判

    响应变化 高于 遵循计划

    也就是说,尽管右项有其价值,我们更重视左项的价值。

    敏捷开发十二原则:

    1. 我们最重要的目标,是通过及早和持续不断地交付有价值的软件使客户满意。
    2. 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
    3. 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
    4. 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
    5. 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
    6. 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。
    7. 可工作的软件是进度的首要度量标准。
    8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
    9. 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
    10. 以简洁为本,它是极力减少不必要工作量的艺术。
    11. 最好的架构、需求和设计出自自组织团队。
    12. 团队定期地反思如何能提高成效,并依此调整自身的行为表现。

    三、敏捷项目管理框架(方法)

    虽然敏捷项目管理的本质是理念,看起来很玄乎。但是敏捷先驱们基于这种里面已经开发出了非常多的看得见摸得着的敏捷管理框架,日常项目管理工作中常见管理框架有以下几种:

    SCRUM

    SCRUM是一种迭代的增量化过程,用于产品开发或工作管理。它是一种可以集合各种开发实践的经验化过程框架。SCRUM中发布产品的重要性高于一切。

    Kanban(看板管理)

    看板管理在工业企业的工序管理中,以卡片为凭证,定时定点交货的管理制度。

    XP(极限编程)

    极限编程注重的核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化,XP无需开发人员在软件开始初期做 出很多的文档。XP提倡测试先行,为了将以后出现bug的几率降到最低。

    Lean Startup(精益创业)

    精益创业的核心理念可以追溯到软件行业的敏捷开发管理。例如“最小可用品”与“原型建模”非常相似,都追求快速的版本迭代,以及时刻保持与客户的接触并获得反馈等等,精益创业可以理解为敏捷开发模式的一种延续。

    Iterative Development(迭代式开发)

    迭代式开发也被称作迭代增量式开发或迭代进化式开发,是一种与传统的瀑布式开发相反的软件开发过程,它弥补了传统开发方式中的一些弱点,具有更高的成功率和生产率。

    FDD (Feature-Driven Development,特性驱动开发)

    特性驱动开发是一个模型驱动的快速迭代开发过程,它强调的是简化、实用、 易于被开发团队接受,适用于需求经常变动的项目。

    当然,也有很多不是很常见的敏捷框架,如Crystal Methods(水晶方法族)、ASD(Adaptive Software Development,自适应软件开发)、DSDM(动态系统开发方法)、轻量型RUP等,这里不展开描述。

    四、敏捷项目管理常见实践

    2020敏捷年度状态报告中统计,Scrum仍然是运用最广泛的敏捷方法(框架),Scrum和Scrum结合其它方法混合使用占比超过75%。所以当你不知如何选用敏捷项目管理框架时,可以考虑Scrum结合其他方法混合使用。毕竟有时候追随别人是最快的捷径。

     既然Scrum这么受欢迎,在这里总结一下Scrum的要点(以下信息来自:Scrum中文网):

     

    1、SCRUM理论基础

    Scrum以经验性过程控制理论(经验主义)做为理论基础的过程。经验主义主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。

    Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。Scrum的三大支柱如下:

    第一:透明性(Transparency)

    透明度是指,在软件开发过程的各个环节保持高度的可见性,影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面,而且必须理解他们看到的内容。也就是说,当某个人在检验一个过程,并确信某一个任务已经完成时,这个完成必须等同于他们对完成的定义。

    第二:检验(Inspection)

    开发过程中的各方面必须做到足够频繁地检验,确保能够及时发现过程中的重大偏差。在确定检验频率时,需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度,那么就会出现问题。幸运的是,软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。

    第三:适应(Adaptation)

    如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准,并且最终产品是不合格的,那么便需要对过程或是材料进行调整。调整工作必须尽快实施,以减少进一步的偏差。

    Scrum中通过三个活动进行检验和适应:每日例会检验Sprint目标的进展,做出调整,从而优化次日的工作价值;Sprint评审和计划会议检验发布目标的进展,做出调整,从而优化下一个Sprint的工作价值;Sprint回顾会议是用来回顾已经完成的Sprint,并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意,并且工作更快乐。

    2、SCRUM框架

    Scrum框架包括3个角色、3个工件、5个事件、5个价值:

    3个角色

    1. 产品负责人(Product Owner):
    2. Scrum Master
    3. 开发团队

    3个工件

    1. 产品Backlog(Product Backlog)
    2. SprintBacklog
    3. 产品增量(Increment)

    什么是产品Backlog? 什么是Sprint Backlog?

    产品Backlog 指根据初始需求分解出的任务列表,包括功能性的和非功能性的所有功能,由Product Owner 为Product Backlog 中的任务确定优先级别,当开发团队开始某个任务的时候,再精确定义和分解这个任务。
    产品Backlog 是产品所要具备的所有功能的总纲。当一个项目刚刚开始时,没人能够事先预见到所有的任务和需求,并为之制定一个充分、详细而又包罗万象的计划。可行的方式是,先为一个项目写下所有它应该具备的显著特征和功能,数量不必很多,最好够让团队的第1 个Sprint 有活可干。
    随着Sprint 的进行,生产出可发布的产品增量,客户对产品的直观认识也会随之深,他们可以据此建议更改或者添加产品Backlog 中的任务。在Sprint 计划会议上,产品负责人为产品Backlog 中的任务确定优先级,并向Scrum团队描述这些任务。Scrum 团队随后根据团队整体情况,确定他们能在这个即将到来的Sprint 中要完成哪些功能,并把它们挪到Sprint Backlog 中去。

    5个事件

    1. Sprint(Sprint本身是一个事件,包括了如下4个事件)
    2. Sprint计划会议(Sprint Planning Meeting)
    3. 每日站会(Daily Scrum Meeting)
    4. Sprint评审会议(Sprint Review Meeting)
    5. Sprint回顾会议(Sprint Retrospective Meeting)

    5个价值

    1. 承诺 – 愿意对目标做出承诺
    2. 专注 – 把你的心思和能力都用到你承诺的工作上去
    3. 开放 – Scrum 把项目中的一切开放给每个人看
    4. 尊重 – 每个人都有他独特的背景和经验
    5. 勇气 – 有勇气做出承诺,履行承诺,接受别人的尊重
    展开全文
  • 今天我们主要分享敏捷项目管理,介绍敏捷的核心价值观、主要的敏捷管理框架,看板等,在实际项目中的实践和应用 为什么敏捷火了 当前面临的现状和困境 为什么敏捷在现在互联网或是传统行业乃至企业管理都变得如此火...
  • 那么就首先需要了解敏捷项目管理的相关知识以及优势劣势。 首先需要回答一个问题:敏捷是什么? 简单来说:敏捷是来源于软件开发领域的思想、实践、框架;是一种开发方式,以人为核心,迭代、循序渐进的开发方式,...
  • Scrum被认为是目前全球最流行与最有效的敏捷项目管理理念与方法之一,在软件业发达地区被众多知名企业广泛采纳。本书是Scrum理论与实践的重要奠基之作,作者是Scrum的缔造者,深受软件行业人员尊重的敏捷大师。本书...
  • 让我们一起回顾他们公司如何结合CMMI、敏捷项目管理工具提升管理:这是杭州一家专门做政府项目的公司,人数接近300。技术总监一直深信要想可持续的过程改进,必须有自动化工具的配合。以前公司一直使用开源工具来...
  • 敏捷开发的基本特征是迭代开发。而迭代开发的强调的是"小批量、频繁交付"。因此,每次迭代所要实现的需求相对较少。这使得迭代开发中的项目计划制定相对容易,制定项目计划时任务与任务间的逻辑关系也比较容易掌握。...
  • 1、不同的管理方式适用于不同类型的项目,Scrum更适用于未知、不可知或持续变化的项目; 2、传统的管理方式有如计划经济体制,Scrum有如市场经济体制,适应变化的能力不同; 3、极大地缩短了用户与开发者,预期目标...
  • 由国内老牌SaaS 厂商Worktile 打造,成立于2012年,在2021年PingCode 在36氪企服点评发布的研发项目管理工具榜排名 TOP1 。 除此以外,PingCode 在国内多个领域出于领先地位,比如具有国内最先进的研发自动化管理

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 102,589
精华内容 41,035
关键字:

敏捷项目管理