目录
1.项目生命周期
2.预测型项目周期
3.迭代型项目周期
3.1.初始阶段
3.2.精化阶段
3.3.构建阶段
3.4.交付阶段
4.增量型生命周期
5.敏捷开发
5.根据具体项目使用合理的开发方式
1.项目生命周期
2.预测型项目周期
预测型项目周期就是软件开发领域的瀑布流模型,从上往下,不能反过来. 提前进行大量计划工作,连续执行,一次性交付
预测型生命周期适用于需求明确,成本明确,时间明确的项目。会充分利用已知或者已经证明的事物/项目,进行项目开发。例如传统的建筑行业,造车行业,航空航天行业。
软件开发生命周期
3.迭代型项目周期
灰太狼总要抓羊羔,但是每次都没抓到,但是没放弃过
在软件开发领域, 迭代式软件开发模式,即是Rational Unified Process,简称RUP,即统一软件开发过程,它的软件开发周期过程体现出三大特点:软件开发周期是一个迭代式的循环过程,以设计构架为核心,通过Use Case(用例)来推动软件开发周期的持续运行。RUP迭代式软件开发周期可以分为四个阶段,每一个软件开发和设计的阶段都可以细分为多个迭代,通过阶段性地制定开发任务,通每一次迭代目标的实现以及连续,促使软件增量开发。每一个阶段就是实现迭代式软件开发周期的一个里程碑,迭代式软件开发周期的四个阶段可以概括为:
增量和迭代的方式差别
迭代是从粗到细,
3.1.初始阶段
这是迭代式软件开发周期的第一个阶段,只要任务是确定项目开发项目的目标,关注客户对软件项目的业务和需求。初始阶段是迭代软件开发周的第一个里程碑,即定义软件开发项目的目的,确定基本可实施性。
3.2.精化阶段
迭代式软件开发周期的第二阶段,目标是确定详细的软件体系构架,明确需求,编定软件开发计划,以及重要的风险解决方案。对体系结构,包括系统的范围、模块和功能等需求,同时为软件开发准备环境支持,比如:软件开发案例、创建模板、工具等等。这是迭代式软件开发周期中的生命周期结构里程碑。为软件开发建立准则,提供支持。
3.3.构建阶段
迭代式软件开发周期的第三个阶段,是要构建阶段开发并集成所有的迭代构件和应用软件的程序功能,形成软件产品,实质是一个制造过程,实现与集成剩余的软件系统功能,在这个阶段实现软件开发周期的初始功能里程碑,确定软件的部署、运行是否符合客户需求。
3.4.交付阶段
这个阶段实现软件开发周期产品发布里程碑。即将开发出来的软件产品交予客户,确保软件切实满足客户功能需求,由此可以开始下一个迭代开发。
迭代式软件开发周期的开发与确定是众多RUP迭代式软件开发项目的经验总结,对于软件开发企业的开发模式有传统软件开发模式项新型软件卡法模式转变有重大的指导意义。为软件开发行业确立创新的、先进的软件开发标准。
4.增量型生命周期
一部分一部分的交付
使得客户能够随时把控质量
有些项目为了加快交付速度,许多企业和项目无法等待所有事情全部完成,在这种情况下,客户愿意接受整个方案的一个部分,这种少量的频繁交付成为增量型生命周期。
增量型生命周期,团队可以尽快交付一个版本,确认客户尽早获得价值。团队可能获得关于原型的反馈,然后选择最小可行性产品(MVP),客户的反馈则帮助团队了解他们需要为随后的最终功能完善提供什么。
举例子来说:比如你要报考一个学校的博士,第一步联系导师,第二步准备材料报考,第三步参加笔试面试,最后成功上岸。
每一个阶段都有交付。
5.敏捷开发
能够根据需求,根据环境进行快速的适应. 适应能力才是项目开发中的最重要能力
需求池逐步实现 流程
这种方法既有迭代,也有增量,便于完善工作,频繁交付。增量交付会发现隐藏或误解的需求。敏捷生命周期是符合《敏捷宣言》原则的周期。特别是,客户满意度将随着有价值产品的早期交付和持续交付不断提升。此外,功能性的、提供价值的增量可交付成果,是衡量进展的主要尺度。 为了适应更频繁的变更,和更频繁地交付项目价值,敏捷生命周期结合了迭代和增量方法。
a、基于迭代的敏捷:团队以迭代相等持续时间的时间盒形式交付完整的功能;团队不会同时完成所有迭代工作。
b、基于流程的敏捷:从待办事项列表中提取若干功能开始工作,而不是按照基于迭代的进度计划开始工作。团队定义任务板各列的工作流,并管理各列的进行中的工作。完成不同功能所花费的时间可能有所不同。团队让进行中的工作的规模尽量小,以便尽早发现问题,并在需要变更时减少返工。无需利用迭代定义计划和审核点,而由团队和业务相关方决定规划、产品评审与回顾的最适当的进度计划。
如果用软件开发的实例来说:干系人要一个能够对接小米金融和微信的商城。
那我们就采用增量型项目周期的方式:
第一阶段:对接小米金融,对接沃尔玛商城,发布(这就是一个可交付给用户的功能,用户可以用)
第二阶段:对接大润发商城,发布(增强了扩展性)
第三阶段:对接微信,接入沃尔玛商城和大润发商城。发布(所有功能交付)
5.根据具体项目使用合理的开发方式
Stacey矩阵
①Simple:需求明确,技术(解决方案)也确定,这类项目就是简单的项目(Simple);比如注册一个新公司,需求很明确,手续也很清楚,就那么几步规定动作,因此大量代理机构都可以帮你完成这个项目。
既然需求明确,怎么实现也清楚,最好提前把计划做到位,预测型开发模式最适合。
②Complex:需求明确,技术却不确定,也就是说怎么实现不知道,这类项目叫复杂的项目(Complex),也叫棘手的项目。比如“无人驾驶”,这项目需求明确吧?“无人驾驶”四个字把需求说的明明白白,就是不要人开,车自己会走。但是“无人驾驶”研究了几十年,各种方法都试过了,一直也没搞定,最近随着人工智能技术的发展才让无人驾驶离现实越来越接近。
技术不确定,怎么实现不知道,只能摸索着来,推荐用迭代开发。
③Complicated:技术很确定,需求却不明确,这类项目最坑爹,比如我们经常遇到这样的客户,让我们开发一个信息系统,问我们会什么技术。你都不耐烦了:“老子啥都会,这根本就不需要什么新技术,问题不是我会什么,关键是你到底要什么?”这类项目是烧脑型的项目(Complicated),愁死个人!
既然客户要什么还没想明白,那就想明白什么先做什么,你边做他边想,最好增量开发,分成多个阶段交付,减少推到重来的风险。
④Chaotic:需求不清楚,怎么实现也不清楚,这叫混乱状态的项目(Chaotic); 这类项目尽量别碰,基本是要失败的。
⑤Hazy:图中紫色区域,不属于前四种区域的其它项目,属于模糊型(Hazy)项目。
需求和实现方案都不明确,最好用敏捷开发,适应性强,灵活机动,拥抱变化。