项目经理的职责、软件生命周期、软件的开发的模式的一些总结

Myth丶恋晨 2023-03-06 05:52 48阅读 0赞

在软件项目开发过程中，项目经理的权利在弱化，更重要的是在承担责任，尤其是在小团队中，对项目经理的技术和管理能力都有着很高的要求，而且小团队更强调稳定性，在开发中一旦出现因管理不善而造成人员流失，对团队将造成很大的影响。  
在实际开发中，项目经理的职责如下：

1.  **需求管理，负责带领团队完成需求分析、概要设计与详细设计**
2.  **协调、组织、解决团队问题**
3.  **制定项目开发计划、召集会议。**
4.  **控制进度、获取并调配资源分配任务**
5.  **作出决策**
6.  **风险控制、解决危机**
7.  **考核团队成员**

## 制定开发计划 ##

在做项目管理时，要记住任何的管理者都要关注三个要素：事物、时间和资源。其中资源包括人、财、物。只要把三个要素搞明白了，那么我们的计划就顺理成章了。  
管理学上有一个有名的公式，管理 = 计划 + 追踪 + 调控  
计划是管理活动开展的前提，这个公式离我们并不远，无论我们做什么事情，它都可以帮我们完成。  
第一阶段：需求分析  
第二阶段：概要设计、详细设计  
第三阶段：开发  
第四阶段：测试  
第五阶段：实施计划、进行实施  
第六阶段：后期维护

### 划分任务点 ###

一个项目可以看作是一个大任务，将大任务进行分解，一直到我们可以估计的程度，再一步步慢慢实现出来。  
列如：我们开发项目的时候可以分解为以下几点

> 需求分析

*  需求调研
 *  分析
 *  需求评审
 *  编写需求规格说明书

> 概要设计

*  系统架构设计
 *  软件结构设计
 *  公共数据结构设计
 *  系统环境结构设计
 *  编写概要设计文档

> 详细设计

*  各功能业务逻辑与实现设计
 *  编写详细设计说明书

> 开发

*  登录、注册功能
 *  权限管理功能
 *  …

> 测试

*  功能测试
 *  集成测试
 *  …

> 实施

*  系统部署
 *  用户培训

> 维护  
> 制定项目计划，我们可以将任务细分，分解成一个个小任务，通过这些小任务，估计项目需要什么样的资源，需要多少时间，存在什么样的风险，应采取什么样的方式应对。

### 分配资源 ###

划分好任务之后，我们就需要把每个任务指派人手和所需的设备、物资。  
项目的计划中需要明确“什么任务” “谁完成”和“完成任务的起止时间”  
我们能够知道这个项目需要多少人，多少时间来完成，项目计划开始实施后，我们需要逐项追踪，看看是否按计划执行了，如果有出入要及时调整。

### 获得开发人员的承诺 ###

项目经理制定计划的时候更多的是依靠自己的经验，他可能安排一个开发工程师用一个工作日完成“合同变更”的详细文档，这基本是合理的，但开发工程师可能有自己的特殊情况，如刚入职，对技术框架不太熟悉，需要先阅读相关文档，或者还没有从另一个项目中完全撤出来，只能将50%的时间投入到这个项目中等等问题。  
如果项目经理只凭自己主观的判断制定计划，那这样的计划在实施的时候阻力会很大，这就要求开发工程师本人要对项目经理或开发经理分配给自己的任务表示同意，也就是“做出承诺”。  
一般的情况下，一个长期合作的团队，彼此了解的时候，不会逐项确认计划是否合理，但项目经理制定出开发计划后都会在正式发布前留一个反馈的时间。以便提前发现计划中不合理的部分，并进行调整。  
一旦开发计划发布并开始实施后，就要严格遵守，开发工程师要对自己的承诺负责。

### 定制开发的原则 ###

1、充分了解原则  
在定制软件项目开发计划时，要对所做的项目，团队成员做充分了解，只有了解充分才能知道这个项目有哪些功能，需要多少人来开发完成，谁合适来做什么。  
2、有效追踪原则  
任务点是进行有效追踪的基本单元，有效追踪原则是对任务点的划分而言的，指的是在划分任务点时，粒度要适中，粒度太大，追踪的效果就差，粒度太小，效率就太低，一般软件开发任务点用工时控制在1~3个工作日是比较适中的。  
3、共同参与原则  
任务安排和计划是项目经理的事，团队成员只管执行，但在软件开发中采取更合理的做法，制定计划时相关人员也参与进来，在制定计划的“获得参与人员承诺”，步骤中可以体现出来。  
在这里我们要明白，制定计划的目的是根据我们的经验做提前规划，但所有的事情都是变化的，没有一成不变的计划，如开发过程中发生人员变动，遇到技术难题、客户需求发生重大变化、公司战略发生变化等都需要对项目开发计划做适当的调整。  
在实际开发过程中，在制定计划项目开发时要做到前紧后松，要给后续发生的不可预料的事情留出足够的反应时间，否则一旦发生变化，整个团队将会很被动。

### 软件生命周期 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ0NzM5NzA2_size_16_color_FFFFFF_t_70]  
1、可行性研究与计划  
可行性研究与计划最主要的任务就是讨论和确定一个项目的可行性，我们首先了解软件项目的目的和客户的期望，也就是大体需要实现什么，然后估计软件的规模，并从技术可行性，经济可行性、操作可行性、社会可行性等几个方面分析项目的可行性。如果问题没有可行性的解决方案，分析人员应该建议停止开发这项工程，以避免时间、资源、人力和金钱的浪费。如果问题可行，分析人员应该推荐一个较好地解决方案，并为工程制定一个初步的计划。  
2、需求分析  
需求分析阶段的主要目的是获取用户对软件功能的具体要求并加以分析，获取用户需求的方法主要有如下几个：

> 1、与用户交谈，向用户提问题，向用户群体发调查问卷  
> 2、参观用户的工作流程，观察用户的操作。  
> 3、与同行、专家交谈，听取他们的意见  
> 4、分析已经存在的同类软件产品，提取需求  
> 5、分析已经存在的同类软件产品，提取需求  
> 6、从行业标准，规则中提取需求  
> 7、从网上找到相关资料进行分析  
> 当得到用户的需求之后，再加以分析，主要是分析得到的需求是否有不清晰的地方，是否都可以用软件来实现，是否存在矛盾和二义性等。  
> 需求分析完毕时形成需求说明说，并准备进入软件的设计阶段。

3、设计  
设计阶段的主要目的是设计如何把已经确定的需求转换成实际的软件。软件设计一般分为概要设计和详细设计两阶段。  
概要设计也称为总体设计，其基本目标是能够对软件需求分析中提出的一系列软件问题，概要的回答问题如何解决，例如，软件系统将采用什么样的体系架构，需要创建哪些功能模块，模块之间的关系如何，数据结构如何，软件系统需要提供什么样的网络环境提供者支持，需要采用什么类型的后台数据库等。  
经过概要设计阶段的工作，已经确定了软件的模块结构和接口描述，但每个模块如何实现仍不清晰，详细设计阶段的根本目标是确定如何具体的实现所要求的系统，也就是说，经过这个阶段的设计工作，应该得出对目标系统的精确描述，因此，详细设计的结果基本上决定了最终程序代码的质量。  
4、开发  
开发阶段包括以下内容

> 1、对在原型创建阶段构建的用户界面进行最后的修改  
> 2、用数据库工具软件构件数据库  
> 3、编写代码

5、测试  
在测试阶段，项目经理根据客户需求规范来审核以开发的系统，从而确保该系统能够彻底解决问题定义问题，此阶段的活动如下：

> 1、单元测试、集成测试和验收测试  
> 2、安全性测试，尝试验证系统的内置保护机制能否实际的保护系统不被误用和擅自访问，它确保软件根据相关权限遵循命令使用。数据访问和访问要求的限制  
> 3、强度测试：要求以不正常的数量，次数或容量提供资源的方式来运行系统

6、维护  
维护阶段是对已经完成的开发系统的维护，这个阶段通常比较漫长，包括对用户的培训、对软件缺陷的跟踪和升级准备等。  
软件开发的生命周期只是一般软件开发过程中都需要经历的一些阶段和步骤，但到了实际软件开发中，这些步骤如何具体实现，针对不同类型的软件，其实现也会有所不同，开发具体软件时，软件开发生命周期中这些开发步骤的具体实施方法称为软件开发过程模型。  
软件开发过程模型有很多种，典型和常见的开发模型有瀑布模型、快速原型模型、迭代模型、敏捷模型等。

### 瀑布模型 ###

瀑布模型也称"线性顺序模型"，该模型是最早的，也是最简单的一种软件过程模型，适用于一些较小的项目或需求非常明确的项目，如果在开发项目时发现曾经做过某个类似的项目，则特别适合使用瀑布模型来开发该软件。  
瀑布模型其实就是软件开发过程中的每个阶段逐步完成，在完成时对每个阶段的开始点和结束点都做了跟明确的规定，并产生明确的交付成果传递给下一个阶段，并且只有完成了一个阶段后才可以开始进入下一个阶段，每个阶段还都会产生一定数量的文档，以提交给后面的各项活动和过程：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ0NzM5NzA2_size_16_color_FFFFFF_t_70_pic_center]  
瀑布模型为项目提供了按阶段划分的检查点，当前一阶段完成后，再去关注后续阶段，瀑布模型软件工程初期为解决大型系统开发提出的软件开发模型，是后续出现的各种模型基础。  
瀑布模型存在以下一些缺点。

> 1、各个阶段的划分固定，阶段之间产生大量的文档，极大的增加了工作量  
> 2、开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险  
> 3、不能适应用户需求的变化

### 快速原型模型 ###

在软件开发过程中，用户的需求是软件成败的关键因素，但在开发初期用户的需求并不一定很明确，这就导致开发出的软件可能不能解决用户的问题，基于这个情况，人们设计了快速原型模型，快速原型模型是迭代模型的产生基础。  
快速原型模型的执行过程分为以下两步。  
第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户对原型经行评价，进一步细化待开发软件的需求，通过逐步调整原型使其满足用户的要求，开发人员可以确定用户的真正需求是什么。  
第二步则是在第一步的基础上开发用户满意的软件产品，快速原型模型可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，其关键点是尽可能快速的建造出软件原型，随之迅速修改原型以反应用户的需求。  
快速原型模型克服了瀑布模型的缺点，减少了由于软件需求不明确带来的开发风险，其缺点是快速建立起来的系统结构加上连续的修改可能会导致产品质量降低，并且给项目维护增加了难度。

### 迭代模型 ###

瀑布模型强调文档的作用，并要求每个阶段都要仔细验证，但是这种模型的线性过程太理想化，不再合适现代的软件开发模式，几乎被业界抛弃。  
其实，在软件开发的早期阶段就想完全、准确捕获用户的需求几乎是不可能的，而实际工作中，我们经常碰到的结果是需求在整个软件开发中经常会改动，由于这个原因，常常导致软件项目的失败，因而，软件开发中，推出了迭代模式，它允许在每次迭代过程中需求发生变化，并经过不断的精化来加深对用户需求的了解。  
早在20世纪50年代末期，软件领域就出现了迭代模型，最早的迭代过程被描述为"分段模型"，在美军空军项目开发中使用。  
迭代模型是RUP（统一软件开发过程）推荐的周期。在RUP中，迭代是这样被定义的，迭代过程包括产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必须的所有其他外围元素，在某种程度上，开发迭代是一次完整的经过所有工作流程的过程；至少包括需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。  
实质上，迭代模型类似于小型的瀑布式项目，RUP认为，所有的阶段都可以细分为迭代，每一次的迭代都会产生一个可以发布的产品，这个产品时最终产品的一个子集。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ0NzM5NzA2_size_16_color_FFFFFF_t_70_pic_center 1]  
在现代过程方法XP（极限编程），RUP无一列外地都推荐、主张采用能显著减少风险的迭代模型，美国国防部原本提倡瀑布过程和观点，在发现多个采用了瀑布模型的失败项目后，不但放弃了对他的要求，而且从1994年的报告开始，积极的鼓励采用更加现代化的迭代模型来取代瀑布模型做法，  
迭代模型的选择使用条件包括以下几点

> 在项目开发早期需求可能有所变化  
> 分析设计人员对应用领域很熟悉  
> 高风险项目  
> 用户可不同程度的参与整个项目的开发过程  
> 使用面向对象的语言或统一建模语言  
> 使用CASE（计算机辅助软件工程）工具  
> 具有高素质的项目管理者和软件研发团队

与传统的瀑布模型相比，迭代过程具有以下优点

> 降低了在一个增量上的开发风险，如果开发人员重复某个迭代，那么损失只是这个开发有误的迭代的花费  
> 降低了产品无法按照既定进度进入市场的风险，通过在开发早期就确定风险，可以尽早解决而不至于在开发后期匆忙补救。  
> 加快了整个开发工作的进度，因为开发人员清楚问题的焦点所在，他们的工作会更有效率。

由于用户的需求并不能在项目刚一开始就做出完全的界定，它们常常是在后续阶段中不断细化，因此，迭代过程能更容易适应需求的变化。

### 敏捷开发 ###

敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力，敏捷开发可以应对客户快速变更的需求，它强调以人为核心，采用迭代，循环渐进的开发软件，敏捷软件开发的宣言如下：

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

在敏捷开发过程中，软件项目被分成多个相互联系但又能独立运行的子项目，这就使每个子项目在开发、测试直至完成的过程中一直保持可使用的状态，这个过程实际上就是要形成开发过程中团队成员之间更加有效的合作关系，使其灵活性更高，以适应不断变化的需求，敏捷开发过程与传统开发过程最大的不同之处在于，在敏捷开发过程中，团队是有激情、有活力的，能够适应更大的变化，产生出更高质量的软件。  
1、Scrum敏捷模型  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ0NzM5NzA2_size_16_color_FFFFFF_t_70_pic_center 2]  
关于几个关键词解释如下：

> Backlog：可以预知的所有任务，包括功能的和非功能性的所有任务。  
> Sprint：一次迭代开发的时间周期，一般最多以30天为一个周期（2~4周），在这段时间内，开发团队需要完成一个制定的Backlog，并且最终成果是一个增量的、可以交付的产品。  
> Sprint Backlog：一个Sprint周期内所需要完成的任务  
> Scrum Master：负责监督整个Scrum进程，修改计划的一个团队成员。  
> Time-box：一个用于开会的时间段，每日例会的Time-box为15分钟  
> Sprint Planning Meeting：在启动每个Sprint前召开，一般为一天时间（8小时），该会议需要指定的任务是产品经理和团队成员将Backlog分解成小的功能模块，决定在即将进行的Sprint里需要完成多少个功能模块，确定好这个Product Backlog的任务优先级，另外，该会议还需要详细的讨论如何能够按照需求完成这些小功能模块，制定的这些功能模块的工作量以小时计算。  
> Daily Meetings：由开发团队成员召开，一般为15分钟，每个成员需要向Scrum Master汇报3个项：1、已经完成了什么？2、是否遇到障碍？即将要做什么？通过该会议，团队成员可以相互了解项目进度。  
> Sprint Review Meeting：在每个Sprint结束后，团队将这个Sprint的工作成果演示给产品负责人和其他相关人员，一般Time-box为4小时  
> Sprint Retrospective Meeting：对刚结束的Spring进行总结，会议的参与人员为团队开发的内部人员，一般Time-box为3小时。

2、Scrium的实施过程

1.  将整个产品的Backlog分解成Sprint Backlog,这个Sprint Backlog是按照目前的人力、物力条件可以完成的
2.  召开Sprint Planning Meeting，划分、确定这个Sprint内需要完成的任务，确定任务的优先级分配给每个成员，注意，这里的任务是以小时计算的，并不是按人、天计算的。
3.  进入Sprint开发周期，在这个周期内，每天需要召开Daily Scrum Meeting。
4.  整个Sprint周期结束，召开Sprint Review Meeting，将成果演示给产品负责人。
5.  团队成员最后召开Sprint Retrospective Meeting，总结问题和经验。
6.  这样周而复始，按照同样的步骤进行下一次Sprint。

3、Scrum敏捷开发的原则和方法

1.  迭代式开发：整个开发过程被分为几个迭代周期，每个迭代周期是较短的时间块。
2.  增量交付：每次交付的都是可以被部署到用户应用环境中被用户使用的，能个用户带来即时效益和价值的产品
3.  开发团队和用户反馈推动产品开发，需求变化和用户反馈能被及时集成到产品中，同时，团队对于用户的需求也能及时提供反馈意见。
4.  持续集成：新的功能或需求变化总是尽可能频繁的被整合到产品中。
5.  开发团队自我管理：构建积极的、自我管理的、具备自由交流风格的开发团队；人是敏捷的核心。

在实际开发中，不论是迭代开发还是敏捷开发对团队成员也就是人的要求在不断提升。有些团队在使用迭代开发或敏捷开发时失败了，很重要的一个因素是人不行，这不仅仅是技术的问题，人的职业素质、团队协作、自我管理能力也是关键，所以我们必须重视自己的职业素养，团队合作能力和自我管理能力的提升。

### 需求分析 ###

1、静态原型  
在实际的需求分析中，当完成需求调研后，要进行需求分析，然后编写需求文档给用户确认。但如果此时的需求都停留在文字上，会让用户很难理解，另外，由于文字描述的局限性，有些需求不能准确描述，难免会出现理解上的偏差，为了避免出现这个偏差，我们一般使用“静态原型”作为需求规格说明书的补充附件。

**原型的定义：**  
原型即把系统的主要功能和功能执行流程通过快速开发制作为“软件样机”，以可视化的形式展现给用户，及时征求用户意见，从而明确无误的确定用户需求。同时，圆形也可用于征求部门意见，作为分析和设计的接口之一，可方便通过。

**原型的主要价值：**  
原型的主要价值是可视化，强化沟通，降低沟通，降低风险，节省后期变更成本，提高项目成功率，一般来说，采用原型后可以改进需求质量，虽然前期投入了较多的时间，但可以显著减少后期变更的时间，原型投入的人力成本代价并不大，但可以节省后期成本，对于较大型的软件来说，原型系统可以称为开发团队的蓝图，另外，原型通过充分和客户交流，还可以提高客户的满意度。

**基本要求**  
对原型的基本要求包括以下三点：

> 体现主要的功能  
> 提供基本的界面风格  
> 明确展示需求中的模糊部分，便于与客户进行确认或进一步明确，防患于未然。原型最好是可运行的，至少在个主要功能模块之间能够建立相互连接。

**表达工具**  
原型的表达工具可以有很多，可以应用各种快速显示的工具，如HTML、PowerPoint、Axure等，只要能够充分而形象地表达就可以了。  
另外值得注意的是界面设计的引入。我们认为将界面风格在原型阶段进行基本确定是一种优化的做法，因为开发前期对界面的确定可以避免后期开发时对界面进行统一调整所带来的不必要的成本浪费，良好的界面也可以使客户增加对系统的好感。  
最终我们开发出的系统应该和原型系统基本一致（包括外观和操作方式）

2、需求变更怎么办？  
做过软件项目的人都会有这样的类似的经历，用户不断的修改需求，项目就像一个“无底洞”，感觉总也做不完。1997年12月，Computer Industry Daily 报道了Sequent Computer Systems公司的一项研究，该公司对美国和英国500名IT经理进行调查后发现，76%的受访者在他们的事业中经历过完全的项目失败，其中提到最多的导致项目失败的原因就是变更用户需求。  
因此，必须接受软件项目中的需求变更这个事实。一方面，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，那些是易变的需求，以便在进行系统统计时，将软件的核心建筑在稳定的需求上，同时留出变更空间，另一方面，在软件开发过程中要对需求的变更进行管理，避免由于需求的频繁变更最后导致项目失败。当遇到需求变更时，我们需要对变更带来的影响及可能造成的花费进行评估，并根据评估结果来与相关的人员进行协商，已确定哪些需求可以变更，无论处于开发的那个阶段，我们都应该跟踪每项需求的状态。  
这些都是需求变更管理的主要内容。  
另外，我们认为前期深入细致的需求调研和分析可以有效减少后期需求变更的频率，在项目进入开发阶段，要对需求变更进行严格的管理，需求变更申请要经过讨论，确认，项目管理者不能随意的对用户的需求变更进行承诺。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ0NzM5NzA2_size_16_color_FFFFFF_t_70]: /images/20230208/8f969dc1f156456a9c14582095d2a5f7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ0NzM5NzA2_size_16_color_FFFFFF_t_70_pic_center]: /images/20230208/e60cc95f49664da489e59a0459e7005b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ0NzM5NzA2_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20230208/ce73c7acaa54420a925359f45c0c1efe.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ0NzM5NzA2_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20230208/e293d6642d1c45ba993790a971bf7ffa.png