聊聊软件项目开发模型

软件项目开发，这是一个既费脑力也费时间的作业过程，为了提高产出效率，按时优质的交付产品上线，其开发背后也是由一套适合自己团队的开发模型管控的。

先来说说中小团队常用的一种瀑布式模型开发，这也是我刚开始带团队时常用的开发管理模式，最容易让只注重开发不关心业务的小伙伴理解与接受。

该模型好处是每个环节都能无缝结合，一环接一环，流程上没有什么毛病，直至最后交付验收， 不过该模型对于需求方要求较高，要求对自己的产品业务及管控逻辑很清晰并能给与详细的业务文案资料，同时有精历配合产品需求分析人员进行完整的产品细节需求梳理，总之需求分析梳理必须要准确清晰，设计人员设计产品原型高度还原实际业务场景。

缺点，如果需求梳理不准确最直接的结果就是好不容易测试完成部署上线的版本，交由需求方体验，发现并不是自己想要的，开始提出修改调整要求，又要重新需求梳理，瀑布模型再走一遍，外一需求方提的要求与设计背离的太厉害，需要变动软件架构，那基本上就是相当于推倒重来了。

在我经历众多的软件项目开发上， 实际在需求整理过程中，往往是不尽人意的，需求方提的需求是很粗的，常用的方式是嘴述或写一点大纲，自己有可能也讲不清楚，需求在脑子中，没法精确、完整的描述，当问到细节之处，需求方可能仅会回一句细节你帮我想想，找找市场上有没有同类型的产品抄一抄，那可想而知开发出来的产品势必没法达到需求方预期的。

迭代式模型开发才是最佳， 接下来讲讲迭代式开发模型。

注意，迭代式开发，不是把瀑布模型重复来几遍，每个迭代版本是快速实现有价值的需求，打通核心的业务流程闭环。

每个迭代版本，首先由需求分析人员梳理出所有需求点，这些需求点不要求细，而后拉通会议把大家达成共识的有价值的、核心的需求点筛出来，快速实现打通业务可操作的全流程，

筛出的需求标准：

1）具有重要构架意义的： 会影响软件核心架构

2）高价值的：对用户有高价值的

3）高风险的：实现起来有潜在风险的

每个迭代版本依然如此循环。

迭代式模式开发好处在于对于需求方不需要等待太长时间就能去看到软件成品，感受一下最终打磨的软件是不是自己想要的原型，同时也减轻了需求方来回沟通细节需求的时间成本。

迭代模式开发特点：

迭代前期，对需求认识不充分、波动较大、经过反馈，不断向真实业务功能靠近

迭代后期，需求稳定

迭代化开发，要懂得不要在开发之前，就“冻结”需求和设计，软件开发是有不可避免的变更的特点，必须通过不断地反馈和调整，才能达到目标。

延伸一下，对于目标精准的一些项目开发又该怎么去论呢，这里说的是目标精准，需求需要挖掘整理，在开发模式中还有一种叫敏捷式开发，敏捷式开发适合多个团队，或者大团队多小组工作协同式开发，它的核心点在于基于目标对齐整理出开发需求列表，在开发协同过程中由下而上及时反馈目标进度，必须有一个总的项目负责人，这个负责人必须是既要懂产品设计也得懂技术架构，否则在开发过程吵架伴嘴是常用的事，小公司尽量不要走敏捷式开发路线，会滩太多的试错成本，得不偿失。

上摘抄了一段文字，敏捷开发流程的8个步骤包括：

1、目标制定，目标对齐：通过市场调研、业务思路、风险评估制定公司规划和目标，根据这一目标产生所有部门的目标并实现对齐；

2、产品规划：产品研发部门根据目标制定产品关键路线图，这个路线图中分布着不同的产品特性和其完成时间；

3、组织产品待办列表：产品规划产生的需求、客户需求、市场人员收集到的缺陷等将组成产品待办列表；

4、需求梳理：产品负责人(Product Ower)对这个列表进行梳理，并在需求梳理会(Backlog Grooming Meeting)讲解具体每一个需求，团队成员根据需求的复杂程度评估每个任务的工作量，输出本次迭代的待办事项列表，完成优先级排序等工作；

5、迭代规划：通过Sprint计划会，明确要执行的工作、冲刺目标等，

6、迭代开发：期间会进行每日站会、性能测试、CodeReview、Demo、测试等工作；

7、Sprint评审：由每个任务的负责人演示其完整的工作，由PO确定Sprint目标是否完成，版本什么时候对外发布，新增bug的紧急程度等等。

8、开回顾会议：回顾会议由Scrum团队检视自身在过去的Sprint的表现，包括人 、关系、过程、工具等，思考在下一个Sprint中怎么样可以表现得更好，更高效，怎么样可以和团队合作地更愉快。