软件项目管理 3.5.敏捷生存期模型

软件项目管理 3.5.敏捷生存期模型

【公众号 “项目管理研究所” 将会第一时间更新文章】
归档于软件项目管理初级学习路线
第三章 生存期模型
《初级学习路线合集 》

---

前言

大家好，这节我们学习敏捷模型，前面介绍的几种生存期模型在实际应用过程中遇到的一些挑战，有时不能很好地适应需求的快速变化，为此软件界比较流行敏捷生命期模型。

一、敏捷模型

《敏捷宣言》价值观，原则，和通用实践之间的关系：
敏捷模型符合敏捷宣言，并通过满足12个原则和实践体现出来的，敏捷模型结合了迭代和增量方法可以适应更频繁的变更和更频繁的交付。

敏捷与传统模型的区别：

1.传统软件开发更倾向于不考虑项目后期需求的变化，在项目开始时预测用户的需求然后分析需求，制定相应的开发计划，再按照计划执行。而计划与实际间会存在一定的差距。

2.与之形成鲜明对比的的是敏捷软件开发过程，他是不断地进行反馈，动态调整需求，最终达成目标，这种自适应性的特征使得敏捷开发的产品更符合实际的需求。

敏捷的工作模型：

项目需求来自于待开发的功能列表，初始需求可以很粗，但是要有优先级，每个迭代是按照优先级来进行，从中选择部分内容进行迭代。

每个迭代1-4周左右，迭代完成就提交一个可交付的运行成果，然后进行评审，反馈进行下一个迭代。

二、敏捷方法

敏捷模型也在不断地发展过程中，从经典的Scrum模型到XP极限编程发展到持续的交付，以至于到全程敏捷的Devops模型，下面对这几个模型，方法进行说明：

三、Scrum模型

Scrum模型是敏捷模型的代表，1990年代初，肯·施瓦伯在其公司使用了一种方法
Advanced Development Methods（先进开发方法），这种方法后来发展为Scrum。

这个图是展示Scrum模型，可以分三个部分分来说明：

1.两层的项目规划：
体现为远期的计划和近期的计划，基于远粗近细的原则，远期计划和近期计划通过产品订单和冲刺订单来体现，产品订单是所有需求的唯一来源，所有的工作都来自于他，开始阶段是比较模糊的，随着时间的推移越来越明确。

最高的优先级需求就是冲刺订单，是当前迭代要完成的任务清单。

2.迭代式的软件开发过程：通过将整个软件交付的过程分为多个迭代周期，一个周期就是一个Sprint。

每个迭代的周期2-4周，迭代内任务有详细的分解估算，可以分解到小时。迭代结束时提交一个运行版本。

3.四个管理会议：包括迭代规划会议，每日站立会议，迭代评审会议，迭代回顾会议。

迭代回顾会议是在每个迭代开始前进行的，要确定任务的目标，理清迭代的需求版本。

每日站立会议是每个迭代的过程当中，每天站着开会，说明昨天做了什么，今天准备做什么，有什么风险。

迭代评审会议是每个迭代结束的时候，团队都会召开迭代复审会议，展示本迭代的运行版本，既得到反馈信息，同时决定下一次迭代的内容。

迭代回顾会议是每个迭代完成后，要进行迭代回顾会议，为了持续的过程改进。

四、XP极限编程模型

XP(eXtreme Programming)极限编程是由Kent Beck提出的一套针对业务需求和软件开发实践的规则。

XP由价值观、原则、实践和行为四个部分组成，它们彼此相互依赖、关联， 并通过行为贯穿于整个生命期。

四大价值观：沟通（Communication）、简单（Simplicity）、反馈（Feedback）、勇气（Courage）

五大原则：快速反馈、简单性假设、逐步修改、提倡更改、优质工作。

极限编程13个最佳实践是通过整体实践，开发团队实践，开发者实践三个层面来体现。

四个整体实践：

1.完整团队（Whole Team）：团队当中包括客户，程序员，测试员，分析员还有一个上层的经理等等，那么每个角色是平等的。

2.计划博弈 ( Planning Game )：体现主要两个主要计划，发布计划和迭代计划。

3.小型发布 ( Small Release )：如果有可能，每天都要发布一个小版本。

4.现场客户( Customer Tests)：客户对每一个需求都定义了一些验收测试，通过运行验收测试，开发人员和客户可以知道开发出来的软件是否符合需求。

五个开发团队实践：

1.集体所有（Collective Ownership）：团队中的每个成员都拥有对代码进行改进的权利，每个人都拥有全部代码，也都需要对全部代码负责。同时，XP强调代码是谁破坏的，就应该由谁来修复。

2.代码规范 ( Code Standards )：开发团队应该拥有一个编码标准。

3.平稳工作 ( Sustainable Pace )：加班最终会扼杀团队的积极性，最终导致项目失败，每周工作40小时是一种顺势行为，是一种规律。

4.系统隐喻 ( System Metaphor )：寻求共识，发明共享词汇，描述体系结构。隐喻是设计和沟通的辅助手段，使项目成员对于系统的实现方式达成共识。

5.持续集成 ( Continuous Integration )：开发人员坚持随时进行提交，系统每天一次集成。

四个开发者实践：

1.简单设计 ( Simple Design )：用最简单的方法来实现小的需求，那么这些设计只要能满足当下的需求就可以了，而且所有的这些设计都将在后续的开发中被不断地重整和优化。

2.结对编程 ( Pair Programming )：系统的任何一个部分都肯定至少有2个人以上熟悉，好处是代码会被100%review，有效地降低代码缺陷率。

3.测试驱动开发 ( Test-driven Development)：极限编程将测试结合到开发过程中，每次结合代码都应该运行一遍所有的测试。

4.代码重构 ( Refactoring ) ：时刻对代码进行重构，一直保持其良好的结构与可扩展性。集体检查也是很重要的。

精益（Lean）模型

精益最初是来自于丰田公司的制造工业，其主要的思想是分析所有的流程，删除没有必要的流程，不断提高效率。精益模式提倡持续不断地改进，减少流程中的浪费。

对于软件开发而言从开发者和最终用户的视角来检查软件开发过程，消除不利于快速交付的行为，形成精益的软件开发，这就是精益模型的思路。

持续交付

持续交付是经典的敏捷软件开发方法的自然延续，能够以较短的周期完成需求的小颗粒度的频繁交付。

频繁的交付周期带来更迅速的对软件的反馈，并且在这个过程中，需求分析，设计，测试，开发，运维等角色可以密切的协作。

那么持续交付包括持续集成，持续部署，持续交付。

持续集成是将个人代码向整体进行交付，以便更早发现开人开发出现的问题。

持续部署是集成的代码尽快向可运行的环境来交付，以便尽早的测试。

持续交付是尽快向客户交付，以便尽早发现生产环境中存在的问题。

DevOps

那么由持续交付演变成的DevOps既Development and Operations，他是开发端和运维端一个全程敏捷思维。

开发和运维原本有着不同的目标，那么开发人员希望尽快提交产品，运维端希望产品的更合理化，高性能高可靠性，减少运维成本。

开发人员与运维人员目标上的差异就叫混乱之想。DevOps融合开发和维护形成了一个统一的敏捷过程，意在帮助那些人员向着一个共同的目标努力。

DevOps是一种方法论，是一组过程，方法与系统的统称，用于促进开发，技术运营和质量保障（QA）部门之间的沟通，协作与整合。

DevOps的工具是多种多样的，甚至可以由多种工具组成一个DevOps的工具链。

总结

总之 无论是最经典的Scrum还是XP模型，还是精益，持续交付，以至于devops等敏捷模型，可以通过一些敏捷实践灵活应对变更，快速的交付产品。

到这里，第三章 生存期模型就讲解完毕！希望大家对生存期模型有一个全面的认识~

如果您觉得这篇文章有帮助到您的的话不妨点赞支持一下哟~~😉

后续将持续更新【软件项目管理初级学习路线】的全知识点，大家感兴趣的多多关注博主哟~
————————————————