一)设计原型 Sketch软件,原型工具。
高仿真原型工具:Principle 主要是提供交互效果
老板驱动:极大权利,极小责任
二)快速原型模型:就是为了解决用户的需求不明确和需求多变。原型模型因为可以快速修改,所以可以对用户的反馈和变更做出响应,同时原型模型注重和用户的沟通,所以最终开发出来的模型能真正反馈用户的需求。但这种快速原型开发往往是以牺牲质量为代价的。通常两种策略:抛弃策略和附加策略。现在原型设计以及称为产品经理确认需求的重要手段。
三)大瀑布拆除小瀑布
增量模型:按照模块分批次交付。在每一个模块中,按照小瀑布模型进行,分批次交付产品。
因为增量模型的根基是模块化,所以如果系统不能模块化,那么很难采用增量模型的模式来开发。另外,对模块的划分很抽象,这本身对于系统架构的水平是要求很高的。基于这样的特点,增量模型主要适用于:需求比较清楚,能模块化的软件系统,并且可以按模块分批次交付。
迭代模型:每次迭代都有一个可用的版本。
迭代模型每次只设计和实现产品的一部分,然后逐步完成更多功能。每次设计和实现一个阶段叫做一个迭代。在一个迭代周期中都会包含需求分析、设计、实现和测试,类似于一个小瀑布模型。迭代结束时要完成一个可用运行的交付版本。增量模型是按照功能模块来拆分的;而迭代模型则是按照时间来拆分的,看单位时间内能完成多少功能。迭代模型最难的部分是在于规划每次迭代的内容和要达到的目标。多了可能完成不成,少了可能造成每次迭代工作量不饱和,这需要在实践中去摸索,一个迭代一个迭代的去调整。迭代模型在于在初始迭代时,只清楚当前的迭代需求,而不知道后续需求,设计可能会考虑不周全。这样的话,迭代一多,系统会有不少冗余,一段时间后就需求对系统进行重构。另外每次迭代,用户可能会增加新的需求和对现有需求进行更改,因此开发时间上可能比预期要长。如果你做得是小项目的话,并不建议使用迭代模型开发。
场景一:外包项目,需要阶段验收 V模型,本质上还是瀑布模型,只不过它更重视对每个阶段验收测试的过程模型。
场景二:项目风险高,随时可能会中断 采取增量模型或者迭代模型进行开发,就能有效降低风险,在每次交付的时候,要同时做一个风险评估,如果风险过大就不继续后续开发了,及时止损。这种强调风险,以风险驱动的方式完善项目的开发模型就是螺旋模型。
场景三:山寨一款软件产品,希望能快速上线发布 项目需求是明确的,不会有什么变化,这时可以选择增量模型,划分好模块,先实现核心功能,发行可运行版本,再增量发布其他模块。多模块可以同步开发。
场景四:客户都没想清楚想要什么,但是个大单子
很多项目,客户一开始都没想清楚想要的是什么,需要花很长时间去分析定义需求,但是单子很大,值得认真去做好。这样的项目。可以考虑分为四个阶段:
1.初始阶段:主要是确定需求边界和主要风险,几乎没有什么开发工作。
2.细化阶段:这个阶段主要是确定需求,可以采用快速原型模型开发,和客户对需求反复确认,需要辅助一定量的开发和测试工作。对代码质量可以要求比较低,重点是确认需求。可能需要一个或多个版本迭代。
3.构造阶段:在需求确认清楚后,现在可以使用迭代模型来开发,逐步交付产品。这个阶段重点是开发和测试。如果迭代中,有新的需求加入或者需求变更,也可以在新的迭代中加入。
4.交付阶段:在开发和测试完成后,产品可以交付客户,根据线上运行情况还需要修复一些Bug。这个阶段重点是测试和部署。也会有多个迭代。
此方式即统一软件开发过程(Rational Unified Process,RUP),适用于复杂和需求不明确的软件系统。
总结:现在的软件项目,各种类型都有,根据项目特点,选择好合适的开发模型,降低项目风险,提高项目开发效率,控制项目成本。
1.一个以确认需求为主要目的的项目,就可以不用花太多时间在代码质量上面,低成本、高效做出来才是最重要的。
2.一个高风险的项目,则可以采用螺旋模型,出现问题及时止损。
3.一个很长时间加班加点,却一直没法上线,导致士气低落的项目,可以改成增量模型,先上线一个小模型,让大家看到成绩提高士气,然后再迭代,逐步上线其他模块。
也不必拘泥于这几种开发模型,还可以借鉴其他模型做得好的地方,甚至创造自己的开发模型。比如说你觉得敏捷的“站立会议”适合你的项目,那也可以借鉴过来。
敏捷开发宣言:个体和互动高于流程和工具,工作的软件高于详尽的文档,客户合作高于合同谈判,响应变化高于遵循计划。也就是说尽管右项有其价值,我们更重视左项的价值。敏捷开发不是一种方法论,也不是一种软件开发的具体方法,更不是一个框架或过程,而是一套价值观和原则。各种敏捷框架、方法论和工具,就像是“术”,告诉你敏捷开发的方式,而敏捷则是“道”,是一套价值观和原则,指导你在软件项目开发中做决策。也就是说,当你开发做决策的时候,遵守了敏捷开发的价值观和原则,不管你是不是用Scrum或者极限编程,那么都可以算是敏捷开发。
瀑布模型的典型问题就是周期长、发布烦、变更难、敏捷开发就是快速迭代、持续集成、拥抱变化。
用敏捷开发的方式,不再像瀑布模型那样有严格的阶段划分,会在迭代中不断完善;不在写很多文档,而是和客户一起紧密合作;不再抵制需求变更,而是及时响应变更;不再等到测试阶段才发布,而是随时发布,客户随时可以看到东西。当然,采用敏捷开发的模式也存在一些问题,例如全程需要客户参与,由于测试相对少一些,问题也会相应多一些。
这些年敏捷开发,已经逐步发展出一套“Scrum+极限编程+看板”的最佳实践,Scrum主要用来管理项目过程,极限编程重点在工程实践,而看板将工作流可视化。
1.敏捷开发是怎样做需求分析的?
瀑布模型的一个重要阶段就是需求分析,要有严谨的需求分析,产生详尽的需求分析文档。而敏捷开发的需求,主要是源于一个个小的用户故事,用户故事通常是写在卡片上的一句话,在Sprint的开发中,再去确认需求的细节。好处是减少了大量需求文档的撰写,可以早点进入开发。但这个对开发人员在需求理解和沟通的能力上要求更高了。
2.敏捷开发是怎么做架构设计的?
瀑布模型在需求分析完了以后,就需要根据需求做架构设计。而在敏捷开发中,并不是基于完整的用户需求开发,每个Sprint只做一部分需求,所以是一种渐进式的架构设计,当前Sprint只适合当前需求的架构设计。这种渐进式的架构设计,迭代次数一多,就会出现架构满足不了需求的现象,产生不少冗余代码,通常我们叫它技术债务,需要定期对系统架构进行重构。
3.敏捷开发怎么保证项目质量的?
瀑布模型在编码完成后,会有专门的阶段进行测试,以保证质量。在敏捷开发的Sprint中,并没有专门的测试阶段,这就依赖于开发功能的同时,要编写单元测试和集成测试代码,用自动化的方式辅助完成测试。相对来说,这种以自动化测试为主的方式,质量确实是要有些影响的。
注明:开发不仅要写单元测试,还要写集成测试。但开发都是用模拟数据,假的API。而测试的自动化测试会用真实的数据,调用真实的API,而且也要做一部分手动测试,至于比例多少,还得看项目特点。
4.敏捷开发是如何发布部署的?
瀑布模型通常在编码结束后,开始部署测试环境,然后在测试阶段定期不是测试环境。测试验收通过后,发布部署到生产环境。这种持续集成、持续发布的概念叫持续集成,因为整个过程都是全自动化的,每次完成一个任务,提交代码后都可以触发一次构建部署操作,脚本会拿最新的代码做一次全新的构建,然后运行所有的单元测试和集成测试代码,测试通过后部署到测试环境。持续集成是一个非常好的实践,极大的缩短和简化了部署的流程,而且自动化测试的加入也很好的保证了部署产品的质量。前期搭建整个持续集成环境需要一定技术要求。
5.敏捷开发的Sprint和迭代模型的迭代有什么区别?
迭代模型本质上是一个小瀑布模型,所以在一个迭代里面,需要完整的经历从需求分析,到设计、编码、测试这几个完整的阶段。所以像瀑布模型一样,刚开始测试的时候是不稳定的,到测试后期才逐步稳定下来,一般迭代前期会相对轻松一点,而后期测试阶段可能会时间很紧张。敏捷开发的Sprint中,没有严格的阶段划分,每个Sprint周期里面会完成多个用户故事。在用户故事的开发中,会针对用户故事有编码、自动化测试编码。当一个用户故事开发完成,即可通过持续集成自动发布到测试环境。相对来说,敏捷开发中,整个Sprint的节奏是比较恒定,产品也是相对稳定的,即使用户故事没有完成,也不影响版本的发布。因为,敏捷开发更注重软件开发中人的作用,需要团队成员以及客户之间的紧密协作。
敏捷开发的条件:
1.团队要小,人数超过一定规模要拆分。
2.团队成员之间要紧密协作,客户也要自始至终深度配合。
3.领导们得支持。敏捷需要扁平化的组织结构,更少的控制,更多的发挥项目组成员的主动性。
3.写代码时要一定比例的自动化测试代码,要花时间搭建好源码管理和持续集成环境。
如果不具备条件,应该考虑先把其中一些好的实践用起来,比如说持续集成、每日站会、自动化测试等。
瀑布模型面向的是过程,而敏捷开发面向的是人。