软件工程

一）设计原型  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.写代码时要一定比例的自动化测试代码，要花时间搭建好源码管理和持续集成环境。

如果不具备条件，应该考虑先把其中一些好的实践用起来，比如说持续集成、每日站会、自动化测试等。

瀑布模型面向的是过程，而敏捷开发面向的是人。