聊聊开发模式

刚工作那几年经历过一段时间的敏捷开发，但最近几年的工作又接触到传统的瀑布开发模式，最近跟技术VP聊到了目前公司的开发模式，有瀑布也有敏捷开发模式。对于目前的二种流行的开发模式，有一些自己的理解，开发模式只是解决问题或者达到目标的一种方法，而我们需要结果是"团队效率"的提升，这是问题的存在。得思考一个问题，先有方法再有问题，还是先有问题再有方法？

那我的观点还是在于先有问题，再形成的具体的方法，对于某个问题对症下药去解决，同时解决问题的方法也不只一种。所以，很多时候各开发模式之间是没有好与坏之分，更取决于项目的业务，项目的迭代程度，团队人员的组成、团队战斗力等等。

因此，我们再回归到理论上来，叙一叙开发模式。

首先来介绍一下各个开发模式的定义。

瀑布开发模式：

1.严格把软件项目的开发分隔成各个开发阶段：需求分析，要件定义，基本设计，详细设计，编码，单体测>试，结合测试，系统测试等。
使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展>开。
2.重视和强调过程文档，在开发的中后期才会看到软件原型，早起只能通过文档来了解系统的模样。
在这种情况下，文档的重要性仿佛已经超过了代码的重要性。
3.瀑布模型把每个开发阶段都定义为黑盒，希望每个阶段的人员只关心自己阶段的工作，不需要关注其他阶段>的工作。

优势：
可以让开发人员能够更专注于本职工作，提高阶段效率。
劣势：
a.由于各阶段的开发人员只能接触到自己工作范围内的东西，所以对客户需求的理解程度高低不等，开发人员>更像是定义为流水线上的工人。
b.对于客户需求变更，编码人员会比设计人员更容易产生很强的抵触情绪。
c.在每个开发阶段都会有一些信息刻意的不让其他开发阶段的人员知道（本意是为了提到效率，但实际上有时>候产生的是互相的理解偏差）。
4.瀑布模型产生的管理文档(计划书，进度表)等，能让不太了解该项目的人也能看懂项目的进度情况（只有能>看懂百分比就行），很适合向领导汇报用。所以管理人员比较喜欢瀑布模型，但是开发人员不喜欢，因为它>束缚了开发人员的创造性。
5.既然叫做瀑布，就意味着不应该走回头路。否则如果出现返工，付出的代价会很大。
软件生命周期前期造成的Bug的影响比后期的大的多。代价比较大的主要原因还是每个开发阶段的步子过大，>每一次调整都可能伤筋动骨。
6.更适合需求相对稳定的大型项目。

敏捷开发模式：

核心是快速迭代，拥抱变化。
因为最终目标是让客户满意，所以能够主动接受需求变更，这就使设计出来的软件有灵活性，可扩展性。

宣言：
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划

敏捷开发模式有以下显著的特点：

1.story细化。
2.简单设计，避免过度设计。
3.重复迭代。
4.减少不必要的文档。
5.客户最关心的功能最先完成。
6.要求客户有时间对每次迭代的成果进行确认，提出改进意见。
7.showcase。
8.沟通是非常重要的，所有的开发人员对项目活动的理解应该是一致的。加强团队之间和客>户之间的沟通。
9.测试驱动开发（TDD）
10.需要更强的个人和团队能力。
11.敏捷的管理是团队的自我管理和项目经理的服务式管理。
12.敏捷开发不能在一开始就给出项目完整的成本计划。
13.在有技术问题还没有解决的情况下不适合展开迭代。
14.敏捷实践：晨会，deadline，负责人制等等。

Crum流程框架 timg (3).jpg

实施思路：

实施思路

迭代开发模式：

1、迭代式开发也被称作迭代增量式开发或迭代进化式开发，是一种与传统的瀑布式开发相>反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。
什么是迭代式开发？
每次只设计和实现这个产品的一部分,
逐步逐步完成的方法叫迭代开发,
每次设计和实现一个阶段叫做一个迭代.
在迭代式开发方法中，整个开发工作被组织为一系列的短小的、
固定长度（如3周）的小项目，被称为一系列的迭代。
每一次迭代都包括了需求分析、设计、实现与测试。
采用这种方法，开发工作可以在需求被完整地确定之前启动，
并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。
再通过客户的反馈来细化需求，并开始新一轮的迭代。
迭代式开发的优点：
1、降低风险
　2、得到早期用户反馈
　3、持续的测试和集成
　4、使用变更
5、提高复用性

螺旋开发模式：

定义：螺旋开发，1988年，巴利·玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。
“螺旋模型”刚开始规模很小，当项目被定义得更好、更稳定时，逐渐展开。
“螺旋模型”的核心就在于您不需要在刚开始的时候就把所有事情都定义的清清楚楚。您轻松>上阵，定义最重要的功能，实现它，然后听取客户的意见，之后再进入到下一个阶段。如此>不断轮回重复，直到得到您满意的最终产品。
（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；
（3）实施工程：实施软件开发和验证；
（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。
螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。

四者对比区别：

传统的瀑布式开发，也就是从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段都要做到最好。
特别是前期阶段，设计的越完美，提交后的成本损失就越少。

迭代式开发，不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，
最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。

螺旋开发，很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。

敏捷开发，相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。

适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化.

目前我们团队现阶段较适用的模式:

瀑布+敏捷开发模式：

此模式核心是减小瀑布模型的粒度，采用敏捷开发的优秀实践方式，提高开发的沟通效率，提供项目的全景视图。转换为实际的项目，我们需要在需求规划时把一个版本的需求定义的更小一点 。每周一，三，三的站会，让团队沟通更多，以及项目进度白板可以更好的把控所有进度等等。
但总的来说，在现在管理项目过程中，并没有严格的按照完全的敏捷或者完全的瀑布模式，都是各自掺杂了其他的方式。在实际项目过程中，过于强调模式并没有意义，重要的是能不能预防问题的发生，在问题发生之后能不能用最小的成本解决，模式更多起一个参考作用

最后借用民国时候的一句话：少研究一些主义，多关注一些实际问题。