JavaWeb开发设计（七）开发模式

常讲到的开发模式包括：瀑布式开发、敏捷开发、极限编程等。传统开发模式都是瀑布式开发，按部就班一步步达成目标，但互联网产品节奏紧凑、业务需求多变，瀑布式开发显得太笨重，于是出现了极限编程、敏捷开发等应对。

一、瀑布式开发

瀑布式开发是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。

瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

二、敏捷开发（Agile Development）

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。其中一些原则是从XP中借鉴而来的，实际上敏捷开发的出现一定程度上就是XP和类似的开发思路综合而来。

敏捷开发核心原则：

1、最重要的是通过尽早和不断交付有价值的软件满足客户需要。

2、我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。

3、经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。

4、业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。

5、围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。

6、在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。

7、可以工作的软件是进度的主要度量标准。

8、对卓越技术与良好设计的不断追求将有助于提高敏捷性。

Scrum

 

 

1、列需求列表

首先确定一个Product Backlog，即按优先级排列的一个产品需求列表，由Product Owner 负责；

2、评估工作量

Scrum Team根据Product Backlog列表，做工作量的预估和安排；

3、定冲刺任务

有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；

4、任务细化

Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；

5、每日站会

在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；

6、每日集成

做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；

7、演示会议

当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；

8、总结会议

最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；

三、极限编程

XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

XP的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。

XP的一个成功因素是重视客户的反馈——开发的目的就是为了满足客户的需要。

四、项目执行

项目执行一般包括如下步骤：需求收集整理、需求方案评审、制定技术方案、技术方案评审、技术开发、联调测试、发布上线、线上观察。各种流派的开发模式只是在上述步骤中强调各自的重点，对项目产出做了方向性的规划，在人力成本、沟通成本、开发成本甚至硬件成本上做协调。

以下根据实际项目经验，做一些不全面的总结。

1、需求整理和需求方案评审

需求整理一般是产品经理（业务专家）独自完成的工作，其产出就是需求方案。这一过程往往不被项目组重视，且很难制定量化的指标，因此需求方案往往是作为结论性的文档抛出，至于其中有多少问题，强依赖于需求方案评审那一两个小时的评估。

个人认为需求整理应该采取多次的、小范围沟通的方式，逐步细化和达成方案，并将一些细节方案的选择形成基本的结论，而不是将这些工作方案需求方案评审会议上。这样才能将团队的力量集中打在业务痛点上。

需求方案评审不应只是评估技术实现成本，这个是技术方案评审的重点，需求方案评审更应集中在抓住业务实质，剖析领域模型。

2、制定技术方案和技术方案评审

首先强调一下，单测应该是技术方案的重要一部分。极限编程要求先单测后代码实现，强调单测实际上就是强调结果，从结果倒推。这种方式有个问题就是单测一开始很难评估全，且评估成本很高。但思路是值得借鉴的，因为单测的评估可以激发项目成员思考方案完备性和边界条件，这些是很可能导致技术方案调整的，因此单测评审值得一做，但不必先实现单测，这样成本过高。

技术方案评审与需求方案同理，都应该是在评审前充分沟通，评审更多地是模型评估和全面同步。

技术方案必须考虑数据迁移、灰度方案和详实可行的验证方案。

3、技术开发和联调测试

技术开发最大的风险是进度风险，往往由于方案评估不充分和，每日站会可以规避这一风险，但这只是在沟通层面而不是解决问题层面。尽量在方案制定阶段规避这一问题，但如果已经出现，及时沟通和额外成本投入是必要的。

联调可能是分阶段分模块的，因此联调时间点需要在技术方案评审时就要给出，如果有调整必须及时同步。联调需要做哪些准备工作也需要在方案评审时评定好，以节省联调成本，否则很有可能会导致联调延期。

4、发布上线和线上观察

发布上线很多时候不只会影响单个应用，多应用协调部署需要考虑发布顺序，考虑已有业务流量和新业务流量的兼容问题。在需要做数据清洗和数据迁移的情况，需要列出精细的执行方案。