项目基础
1 生命周期
1.1 传统项目生命周期
- 调研阶段：产品经理主导，相关人员参与
- 设计阶段：产品团队主导，开发、测试、运维参与
- 开发阶段：开发团队为主，运维参与
- 测试阶段：测试团队为主，开发、运维参与
- 运营阶段：运营团队为主，开发、产品参与
1.2 新型项目生命周期
团队沟通协作占到主导作用
- 软件架构：将项目拆分成多个独立子功能
- 团队组织：每个子功能独立组建研发团队
1.3 项目演变
1.3.1 基本架构
一般来说，任何一个项目至少由最核心的三个部分组成：访问层、数据层、存储层
1.3.2 开发框架演变
1.3.3 项目架构演变
初级阶段
- 单体阶段（MVC）：项目初期，所有应用服务都在一台主机
- 应用数据分离阶段（MVC）：项目初期，用户访问数据库有压力，应用和数据库单独部署
- 页面动静分离阶段（MVC）：项目初期，用户访问页面有压力，剥离用户读请求和写请求操作
- 页面数据缓存阶段（MVC）：项目初期，用户访问有压力，代理和数据库前面增加缓存组件
中期阶段
- 应用服务集群阶段（RPC）：项目初期，用户访问有压力，应用服务器所在主机做集群负载均衡
- 数据库读写分离化（RPC+MVC）：项目初期，用户访问数据有压力，对数据库集群做读写分离，静态文件做共享存储
- 存储分布式（RPC+MVC）：项目中期，数据存储有压力，对数据库分库、分表扩展，数据文件使用分布式存储
- 业务应用拆分（RPC+MVC+SOA）：项目中期，业务访问、团队管理有压力，项目应用进行拆分
中后期阶段
- 业务拆分：项目中后期，业务处理有压力，所有功能以服务的形式单独部署，引入配置管理中心、消息中间件、搜索引擎等功能
- 微服务阶段：项目后期，精益求精，所有服务都可以自由部署
2 版本控制
2.1 版本控制种类
2.1.1 集中式版本控制系统
- 集中式版本控制系统：
产品项目的标准代码集中放在中央代码服务器的，工作时必须连接中央代码服务器并获取最新版本代码，进行编写或者更改代码并检查完毕后，推送到中央代码服务器。该版本控制系统受网络限制比较大。 - 常见的工具：
- CVS(Concurrent Versions Control System)
- SVN(Subversion)
- VSs(Visual Source Safe)
2.1.2 分布式版本控制系统
- 分布式版本控制系统：
分布式版本控制系统没有中央代码服务器的。团队中每个人的电脑就是一个完整的代码版本库，可以在自己的电脑上进行工作，即使没有网，工作也不受影响，团队成员的所有代码最终会合并在一起因为每个人都可以在本地对同一个文件进行修改，所以在代码合并的时候，会受到一定的影响。 - 常见的工具:
- Git
- Mercurial
- Monotone
- Bitkeeper
3 分支管理
3.1 分支概念
3.1.1 常用分支
- 主分支（master）
每个代码库有且仅有一个主分支。它是版本库初始化以后自动建立的，默认就是在主分支在进行开发。 - 开发分支（develop）
项目代码的日常开发所在的分支。
3.1.2 临时分支
- 功能分支（feature）
为了开发某种特定功能，从Develop分支上分出来的。临时开发完成后，要再并入develop。 - 预发布分支（release）
预发布分支是指发布正式版本之前(合并到Master分支之前)，进行版本代码测试的临时性分支，测试通过后，就正式发布代码。代码发布完毕后，需要合并到develop和master分支上。 - 修补bug分支（fixbug）
软件项目正式发布以后，难免会出现bug，就临时创建一个bug分支来进行功能修补，功能修补完毕后在将最终代码合并到master和相应的develop。
3.2 代码开发流程
推荐开发模式：主干开发，分支发布
以下开发实践可以显著帮助软件交付变得更加高效：
- 每天向主干合并一次代码
- 让分支生命周期尽量短（小于一天）
- 同一时间少于三条活跃分支
4 软件开发模型
4.1 传统软件开发模型
4.1.1 边做边改模型
走一步，看一步
- 优势：
- 快速产出效益，回笼资金快
- 劣势：
- 无计划的发展，随着软件结构的无规律修改，产品会越来越糟，最终导致无法继续修改
- 质量无保证，开发过程未考虑测试和可维护性，也没有任何文档，软件的维护十分困难
- 场景：
- 项目初期使用最频繁
- 逻辑不需要太严谨的小项目
4.1.2 瀑布模型
按照计划执行：调研 -> 设计 -> 开发 -> 测试 -> 运营
- 优势：
- 理想化的开发模型，非常适合过程管理。
- 每个阶段的边界划分清楚，以线性的顺序依次完成。
- 有明确的需求分析，层次性的开发思路，按部就班地完成各阶段工作内容。
- 劣势：
- 直接影响产品的交付日期。 瀑布模型的优势也是劣势。按计划完成任务很好，但是真正的工作中有非常多的不确定性。
- 用户需求和开发过程存在不确定性。 用户在真正接触到产品前，需求会发生变化，而且开发过程中存在很多不确定因素，导致不能完全按照理想化的过程执行计划。
- 反馈时间长，缺乏并行性，效率低下。 按照线性的计划顺序开发产品，无法并行。
- 场景：
- 大部分项目 初期阶段
- 某些核心、大型、稳定性要求高的项目
4.1.3 迭代模型
拆分产品功能，减少交付周期
选代模型是为了实现快速的产品交付，在设计产品的时候，不像瀑布模型那样设计的非常大而完美，而是一个阶段一个阶段的实现部分功能，最终交付一个完善的产品。其中每一个阶段的功能都使用瀑布模型开发，并且有一个可交付的产品成果。
- 优势：
- 反馈周期短。 每个阶段的工作成果可以快速交付，用户使用的效果可以快速反馈给产品人员。
- 降低产品风险。 开发工作按照既定的计划推进，推进的过程中可以结合上一阶段的用户反馈来细化需求，或合理的变动部分功能和业务逻辑，并开始新一轮的迭代。
- 提高效率。 阶段性的功能拆分及快速的质量反馈，使得开发人员清楚产品的功能定位和问题焦点，提高工作效率，加快整个项目工作进度。
- 劣势：
- 团队水平。 项目研发过程中，功能需求变动频繁导致风险增多，这对领导和组织者的水平要求较高，软件研发团队的综合应变水平也有一定的要求。
- 场景：
- 大部分项目 中后期的通用做法
- 高风险项目
4.1.4 增量模型
结合瀑布模型与迭代模型
增量模型是一种分步开发的模型。集成了瀑布模型的顺序特征和选代模型的选代特性。一般情况下，先针对大型产品进行精细化设计，将复杂项目进行合理的阶段性功能拆分，然后每一阶段的功能产品都使用瀑布模型开发，并且交付子功能产品成果。每个阶段都在前一个阶段实现的功能基础上进行选代开发，多个功能阶段选代完毕后，就可以交付最终完善的产品。
- 优势：
- 在保证项目目标的方向上，产品交付时间比瀑布模型短
- 在保证交付时间的标准上，产品功能目标比迭代模型好
- 劣势：
- 精细设计程度。在产品功能设计的时候，要把控好阶段性子功能的边界，不太适合需求经常大变动的项目。
- 阶段性依赖。当前阶段是在前一阶段功能产品的基础上进行的，而且当前阶段功能开发的过程中，不能破坏前一个阶段的功能。
- 团队水平。项目研发过程中，功能需求变动频繁导致风险增多，这对领导和组织者的水平要求较高，软件研发团队的综合应变水平也有一定的要求。
- 场景：
- 大部分项目早期使用增量模型，可以规避技术风险
- 交付时间紧张、人员不足的项目场景
4.1.5 快速原型模型
一般使用于需求复杂、动态变化的软件系统
允许在调研阶段只对部分核心功能进行分析，用最少的时间做一个基本功能完备(可以运行)的产品原型，然后快速推上线，结合用户使用过程中具体的反馈信息以丰富细化产品功能需求，在当前的产品原型基础上进行功能选代更新,最终开发出客户满意的软件产品。快速原型模型，又称原型模型，有点像“边做边改”与“选代模型”的一个特殊的增量模型。以进化的开发方式为中心，迭代合理的新功能。
- 优势：
- 快速原型的目的在需求复杂不明的时候，通过快速的软件原型，理解和澄清问题，以便研发团队与用户达成共识，减少由于软件需求不明确带来的开发风险。
- 迭代新功能的时候会结合用户的反馈需求进行丰富细化，开发人员能确定客户的真正需求，所以该模型生产的产品一般比较能满足用户的需求。
- 劣势：
- 用户是善变的，开发会受到需求变更的影响，所以需要开发人员有快速重构项目的能力，应对各种未知风险的能力。
- 场景：
- 特殊的、需求不明确的、复杂的项目，或者项目中的某些紧急bug
4.1.6 螺旋模型
软件风险是任何软件开发项目中都存在的实际问题，而且项目越大，软件越复杂，风险就越大，这些风险在不同程度上损害项目产品的质量。所以，在项目研发过程中需要及时识别并分析风险，并采取适当措施以消除或减少风险的危害。
螺旋模型是在快速原型模型和瀑布模型的基础上，增加风险分析策略，结合多种方法尽量降低风险，保证项目的产品质量。 当产品交付后，在定制新需求前，评估之前的工作成果，然后进行新需求的风险分析，接着瀑布模型方式开发，直到交付产品。
螺旋模型沿着螺线进行若干次迭代：
- 功能计划：确定软件功能，理清限制条件，制定研发方案
- 风险分析：评估研发方案，考虑如何识别和消除风险
- 项目生产：软件开发、测试和部署
- 客户反馈：工作复盘，提出修正建议，制定下一步计划
- 优势：
- 结合瀑布模型与快速原型模型的所有优势。
- 强调了其他模型所忽视的风险分析。
- 劣势：
- 强调风险分析，但客户不一定能接受并相信这种分析。
- 场景：
- 特别适合于大型复杂的系统
4.2 新型软件开发模型
4.2.1 敏捷开发模型
敏捷开发是一种应对快速变化的用户需求的一种开发软件的管理新模式，它是XP、Scrum等数十种软件开发项目管理方法的集合，主要特点是：响应更快、关注产品价值、注重个人的能力。
项目开发：在敏捷开发中，最大的特点就是软件架构的解耦。 软件项目在初期被切分成多个相互联系，但也可独立运行的小项目，并分别完成，在整个软件开发过程中产品一直处于可使用状态。
功能迭代：强调较短的开发周期提交软件产品，相较于迭代模型更短（2-4周）。
核心特征：相较于个人(单团队)完成项目的传统软件开发模式(以文档方式推动项目前进)，敏捷开发更强调团队之间的紧密协作、团队小而精干，基于面对面的沟通，制定迭代功能的优先级，能够很好地适应需求变化。
- 优势：
- 团队沟通效率高
- 功能迭代快
- 劣势：
- 对团队的综合能力要求高
- 场景：
- 项目复杂、交付周期短、功能迭代快的项目
4.2.2 精益模型
精益软件开发是精益制造原则和实践在软件开发领域的变体。它基于丰田生产方式(TPS)，由敏捷社区引入并发展。
精益原则：
精益原则和精益制造原则的概念相近，精益开发也可以总结为如下七条原则：消除浪费、增强学习、下放权力全局优化、延迟决策、内嵌质量、尽快发布。
消除浪费：
精益原则的中心思想就是为了消除浪费，首先必须能够识别、认识到浪费。接照精益思维，任何不能为客户增加价值的行为即是浪费。主要包括：不必要特性/需求/返工/延迟、需求不明、沟通低效等以消除浪费和减少变异为目的。 让资源能够投入到正确的地方提高质量，达到资源的高效率利用。
通过价值流的方法来消除浪费。
团队措施：
增强学习。 精益生产非常重视员工的培训，培训方式主要是通过做中学习进行的，而软件开发本身就是个持续学习的过程，通过多种实际的代码开发过程，可以培养并增强员工的技能。透过轮岗的方式使得员工取得多种技能。在培养和提高员工技能的同时，也实现了人力资源的高效率利用。
下放权力。 传统的团队里都是由团队的领导者来决定和分配每个人所要完成的任务。但是精益开发主张将这种权利下放到团队的每个人手里，通过频繁的沟通，让员工知道所有相关工作的全貌，而团队领导者提供团队成员应有的支持和帮助，克服困难，维持团队的合作默契。
全局优化。 大多数的管理理论，强调工作拆解后，被分析出来各个子功能的最佳化。但从局部思考，常常会让整合的时候出现相依性的问题。精益生产鼓励人与人、团队之间的沟通，通过消除沟通过程中的隔阂和浪费，促进团队从不同面向去探讨整体产生最好的产品和服务呈献给客户。
项目措施：
延迟决策。 软件开发的不确定因素很多，项目初期很难预测未来的变化，通过多种方法调研比较，尽可能的延迟决定应该根据事实而非根据假设来做决策，才能应变不可避免的需求变更和修正错误。系统越复杂，那么这个系统容纳变化的能力就应该越强，使其能够具备推迟重要以及关键的决定的能力。
内嵌质量。 质量的管理在精益软件开发中尤其重要。质量应该贯穿在开发过程中的每一个阶段，当发生质量问题可以快速解决，从而提高客户良好的整体经验。
尽快发布。 在一个技术发展非常迅速的时代，尽早的发布产品有助于更快的获得用户的反馈来改善当前产品的质量，从而更快的完成下一次功能迭代。越短的开发周期，能越快让开发团队从市场获得实时信息，应变市场的变化。
662
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
