??接受项目管理培训至今已经有三年时间了,一直没有机会来整理一下自己在项目管理方面的学习历程和经验。好记性不如烂笔头,从今天开始就一步一步分享一下我在项目管理方面的学习历程以及一些在工作中累积的经验,希望可以帮助到从事项目管理的人!
概念
??软件开发生命周期(Software Development Life Cycle,SDLC),又称为软件开发过程(Software Development Process),为软件的开发定义了一个框架,将自动化工具、软件开发方法和质量管理紧密结合在了一起,其各个阶段实现了软件的需求定义与分析、设计、实现、测试、交付和维护。软件开发过程是在开发与构建系统时应遵循的步骤,是软件开发的路线图。
??在实际的开发过程中,开发者们不断的总结归纳,最终形成了一些比较统一开发模式。这些开发模式就是一个个被称为软件开发过程模型(Software Development Process Models)。其中最著名的就应该是瀑布模型了。如下是一些常用的模型:
??敏捷开发更强调人的主观能动性,其价值观是:个体和互动高于流程和工具,工作的软件高于详尽的文档,客户合作高于合同谈判,响应变化高于遵循计划。其核心主要在于能够充分了解用户的痛点,将用户痛点分级,每次版本都只解决用户当前最大的痛点,然后通过快速开发的版本迭代满足用户需求从而占领市场,这也是 MVP(最小可用产品)的核心思维。
敏捷式开发不仅仅是项目上的一种开发方式,同时也能指点我们在生活中采用 2/8 法则,抓住重点,用最小的力度来实现价值最大化。
??敏捷式开发的特性是能够持续性的对软件本体进行不断改造以及处理客户对软件开发过程中的不断介入。敏捷开发的主要优点在于其灵活性。 经过一次次例行的开发迭代期(iterations)后,在每一次迭代期的开始时小组便会考虑向软件引入新的特性和改变,也就不会特别跟随原有的开发要求。
??敏捷开发是现代软件开发中被广泛使用的范式。敏捷软件开发的框架不断的发展,两个最广泛被使用的是 Scrum 与 Kanban。敏捷软件开发是一个开发软件的管理新模式,用来替代以文档驱动开发的传统开发模式。
??总结一下就是,敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。
?? 每隔一段时间,Digital.ai 就会发布一次关于敏捷开发的调查 STATE OF AGILE 并发布相应的 STATE OF AGILE 告,并在 https://stateofagile.com/# 上进行公布。我们可以下载到对应的 PDF 文档。下面是最新的第 14 调查 告中的 敏捷开发方法使用情况:
敏捷联盟
??敏捷联盟(Agile Alliance)是一个全球性的非盈利性成员组织,致力于支持那些探索和应用敏捷价值、原则和实践的人们,使构建软件解决方案更有效、更人性化、更可持续。官方 址:https://www.agilealliance.org/
- 优点:
- 让软件开发过程有序可控,为项目提供了按阶段划分的检查点。瀑布模型的每个阶段都有明确的任务,每个阶段都有明确的交付产物,都有相应的里程碑。这些让整个过程更可控,而且能及早发现问题
- 当前一阶段完成后,您只需要去关注后续阶段
- 它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
- 让分工协作变成可能。瀑布模型的六个阶段,也让软件开发产生相应的基础分工:项目经理、产品经理、架构师、软件工程师、测试工程师、运维工程师。
- 质量有保障。瀑布模型每个阶段都需要交付相应的文档,而文档的撰写和评审,可以帮助在动手之前把问题沟通清楚,想清楚。瀑布模型在编码结束后,会有严密的测试,只有测试验收通过后,才能上线发布,这些措施都让软件的质量更有保障。
- 缺点:
- 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。
- 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。
- 没有迭代与反馈。瀑布模型对反馈没有涉及,所以对变化的客户需求非常不容易适应,瀑布就意味着没有回头路。
- 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
- 瀑布模型的突出缺点是不适应用户需求的变化。
- 瀑布模型是一种软件文档的开发,把开发者变成流水线上的机器,大量重复性的工作让编程人员提不起兴趣,工作很枯燥,没有激情,编程成了一种没有创意的机械劳动,这让一向以高科技为标志的高级程序人员大为恼火。
??虽然现在瀑布模型已经不是最主流的开发模式。但是不管什么软件项目,不管采用什么开发模式,有四种活动是必不可少的,那就是需求、设计、编码和测试。而这四项活动,都是起源自瀑布模型,也是瀑布模型中核心的部分。 管理人员喜欢瀑布模型的原因是把文档理解为开发的速度,可以方便地界定不同阶段的里程碑。
V 模型
??1978 年 Kevin Forsberg & Harold Mooz 提出了 V 模型(也被称为验证和验证模型)。V 模型是一个著名的、以测试为驱动的开发模型,该模型强调开发过程中测试贯穿始终,是瀑布模型的一个变体。V 模型反映了开发过程和测试过程的关系,在测试软件的过程中起着非常重要的作用。测试依旧是开发生命周期中的阶段,与瀑布模型不同的是,有多个测试级别与开发阶段对应。
- 测试阶段划分得更全面,不仅仅是单元测试、集成测试和系统测试。测试的对象不仅是程序,需求、设计等同样要测试
- 测试与开发是并行的,从需求测试就应该开始介入
- 提出尽早测试的概念,这样可以降低缺陷修复成本
- 测试对象不仅仅是程序,还包括需求或其他的相关文档
W 模型仍然是以文档驱动的传统开发方式的一个变种
- 优点:
- 开发伴随着整个开发周期,需求和设计同样要测试
- 更早的介入测试,可以发现初期的缺陷,修复成本低
- 分阶段工作,方便项目整体管理。
- 缺点:
- 开发和测试依然是线性的关系,需求的变更和调整,依然不方便,样就无法支持迭代的开发模型
- 如果没有文档,根本无法执行 W 模型;对于项目组成员的技术要求更高!
快速原型模型
??快速原型模型(Rapid Prototype Model)又称原型模型,它是增量模型的另一种形式;它是在开发真实系统之前,构造一个原型,在该原型的基础上,逐渐完成整个系统的开发工作。下图显示了快速原型模型开发的基本步骤:
??增量模型与原型实现模型和其他演化方法一样,本质上是迭代的,但与原型实现不一样的是其强调每一个增量均发布一个可操作产品。早期的增量是最终产品的“可拆卸”版本,但提供了为用户服务的功能,并且为用户提供了评估的平台。
??增量模型的特点是引进了增量包的概念,无须等到所有需求都出来,只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求并且更改,但只要这个增量包足够小,其影响对整个项目来说是可以承受的。
增量模型的特征:
- 系统被分解成许多小型开发项目。
- 部分系统是为了生成最终系统而构建的。
- 首先满足最高优先级要求。
- 一旦开发递增部分,部分的需求将被冻结。
增量模型的优缺点:
- 优点
- 采用增量模型的优点是人员分配灵活,刚开始不用投入大量人力资源。如果核心产品很受欢迎,则可增加人力实现下一个增量。因此,增量能够有计划地管理技术风险。
- 每次迭代后,应执行回归测试。在此测试期间,可以快速识别软件的故障元素,因为在任何单个迭代中很少进行更改。
- 测试和调试比其他类型的软件开发方法更容易,因为每次迭代时所做的更改相对较小。这允许对整个产品中的每个元素进行更有针对性的、更严格的测试。
- 客户可以响应功能并查看产品,以了解任何需要或有用的更改。
- 增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型
- 缺点
- 由于各个构件是逐渐并入已有的软件体系结构中的,所以加入构件必须不破坏已构造好的系统部分,这需要软件具备开放式的体系结构
- 在开发过程中,需求的变化是不可避免的。很容易退化为边做边改模型,从而是软件过程的控制失去整体性。
- 如果增量包之间存在相交的情况且未很好处理,则必须做全盘系统分析
- 随着产品增加了其他功能,可能会出现与系统体系结构相关的问题,而早期原型中并不明显
- 由增量产生的成本可能会超过组织的成本。
增量理念也用于敏捷流程模型
螺旋模型
??螺旋模型(Spiral Model)是巴利·玻姆(Barry Boehm)于 1988 年 5 月在他的文章《一种螺旋式的软件开发与强化模型》提出的。它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。螺旋模型最大的特点在于 引入了其他模型不具备的风险分析,使软件在无法排除重大风险时有机会停止,以减小损失。同时,在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。
??螺旋模型采用一种周期性的方法来进行系统开发。这会导致开发出众多的中间版本。使用它,项目经理在早期就能够为客户实证某些概念。该模型是快速原型法,以进化的开发方式为中心,在每个项目阶段使用瀑布模型法。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审 4 个阶段,由这 4 个阶段进行迭代。软件开发过程每迭代一次,软件开发又前进一个层次。采用螺旋模型的软件过程如下图所示:
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!