软件项目管理的内容有那些？

Posted 2023-05-08

《软件项目管理的内容》
　软件项目管理的内容主要包括如下几个方面：人员的组织与管理，软件度量，软件项目计划，风险管理，软件质量保证，软件过程能力评估，软件配置管理等。
　　这几个方面都是贯穿、交织于整个软件开发过程中的，其中人员的组织与管理把注意力集中在项目组人员的构成、优化；软件度量把关注用量化的方法评测软件开发中的费用、生产率、进度和产品质量等要素是否符合期望值，包括过程度量和产品度量两个方面；软件项目计划主要包括工作量、成本、开发时间的估计，并根据估计值制定和调整项目组的工作；风险管理预测未来可能出现的各种危害到软件产品质量的潜在因素并由此采取措施进行预防；质量保证是保证产品和服务充分满足消费者要求的质量而进行的有计划，有组织的活动；软件过程能力评估是对软件开发能力的高低进行衡量；软件配置管理针对开发过程中人员、工具的配置、使用提出管理策略。因为大家对人力资源管理和软件过程能力比较有兴趣，下面就详细的对这两方面展开讨论。
　　从软件工程的角度讲，软件开发主要分为六个阶段：需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段。不论是作坊式开发，还是团队协作开发，这六个阶段都是不可缺少的。根据公司实际情况，公司在进行软件项目管理时，重点将软件配置管理、项目跟踪和控制管理、软件风险管理及项目策划活动管理四方面内容导入软件开发的整个阶段。在20世纪80年代初，著名软件工程专家B.W.Boehm总结出了软件开发时需遵循的七条基本原则，同样，在进行软件项目管理时，也应该遵循这七条原则。它们是：
1、用分阶段的生命周期计划严格管理；
2、坚持进行阶段评审；
3、实行严格的产品控制；
4、采用现代程序设计技术；
5、 结果应能够清楚地审查；
6、开发小组地人员应该少而精；
7、承认不断改进软件工程实践的必要性。 参考技术A 《软件项目管理的内容》
　软件项目管理的内容主要包括如下几个方面：人员的组织与管理，软件度量，软件项目计划，风险管理，软件质量保证，软件过程能力评估，软件配置管理等。
　　这几个方面都是贯穿、交织于整个软件开发过程中的，其中人员的组织与管理把注意力集中在项目组人员的构成、优化；软件度量把关注用量化的方法评测软件开发中的费用、生产率、进度和产品质量等要素是否符合期望值，包括过程度量和产品度量两个方面；软件项目计划主要包括工作量、成本、开发时间的估计，并根据估计值制定和调整项目组的工作；风险管理预测未来可能出现的各种危害到软件产品质量的潜在因素并由此采取措施进行预防；质量保证是保证产品和服务充分满足消费者要求的质量而进行的有计划，有组织的活动；软件过程能力评估是对软件开发能力的高低进行衡量；软件配置管理针对开发过程中人员、工具的配置、使用提出管理策略。因为大家对人力资源管理和软件过程能力比较有兴趣，下面就详细的对这两方面展开讨论。
　　从软件工程的角度讲，软件开发主要分为六个阶段：需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段。不论是作坊式开发，还是团队协作开发，这六个阶段都是不可缺少的。根据公司实际情况，公司在进行软件项目管理时，重点将软件配置管理、项目跟踪和控制管理、软件风险管理及项目策划活动管理四方面内容导入软件开发的整个阶段。在20世纪80年代初，著名软件工程专家B.W.Boehm总结出了软件开发时需遵循的七条基本原则，同样，在进行软件项目管理时，也应该遵循这七条原则。它们是：
1、用分阶段的生命周期计划严格管理；
2、坚持进行阶段评审；
3、实行严格的产品控制；
4、采用现代程序设计技术；
5、 结果应能够清楚地审查；
6、开发小组地人员应该少而精；
7、承认不断改进软件工程实践的必要性。 参考技术B 有8种方法可以优化和简化软件项目管理流程：

—移除团队中的非开发性工作，让团队专注于开发
—通过分享他人的成功故事来激励团队，比如科技巨头的成功故事，这会激励你的团队
—分配任务后避免更改任务
—坚持计划（除非计划需要变更）
—通过提高效率来鼓励条理性
—通过有效授权来提高生产力
—了解你的团队，建立融洽的关系
—分解计划，给团队成员具体的日常任务

软件开发的那些坑－目标的重要性

项目上线有一段时间了，上线后大家忙着改bug，忙着汇报，忙着二期的规划，一直没有坐下来一起聊聊。

上周，我还是决定花费大家半天的时间，组织开了迭代回顾会。

迭代回顾会对于敏捷来讲，是一个很重要的实践，但其实不提敏捷的时候，我们也在做，只是有个更普通的名字，叫项目总结会。(迭代回顾会的实践方法见文章最后)

会上，当我们回顾了项目过程时，发现一个重要问题，这个问题就是：经常性的，我们忽略了或忘了目标，这里的目标应该有但不限于以下内容。

一、 业务目标

说出来，大家可能都觉得不可思议，没有目标，那项目组最终要交付什么样的系统？项目组又在为了什么而忙？

可事实就是如此，很多时候，我们盲目的就开始了一个项目，然后盲目的就做出一堆功能。

真实情况是这样的，我们的研发团队不是一个真正的互联网产品团队，虽然有产品经理的角色，也基本是技术主管或经理担当的，结果就是我们更关注的是要做哪些功能。

例如，我们规划要做一个公有云系统，产品经理就会看世面上的公有云产品：华为云，阿里云，亚马逊等，然后去参考他们的界面，去试用他们的功能，恨不得copy一个类似的产品出来。

实际上，我们并没有想清楚，华为云，阿里云已经做起来了，我们为什么还要做这个系统？我们是比他们有更强大的技术能力，能快速的仿造出一个公有云系统，跟他们抗衡或分一杯羹？还是我们的资源比人家便宜？还是我们的安全性或服务可以做的比他们好，让客户觉得更有保障？

可是，至少从目前看，我们的技术实力并不比人家强；据我了解，亚马逊本来就是因为那些资源闲着也是闲着，才做了个公有云来处理闲置的资源，其他的市面上单独卖I层资源的，都是在做赔本生意；还有，公司内部的环境还存在各种单点，无容灾系统等问题；

那我们为什么要做这个系统？我们的客户是谁？客户的使用场景是什么？我们能为他们解决什么问题？这点就决定了我们的业务目标是什么、产品和服务是如何定义的，也决定了我们的产品跟其他的竞争对手的差异性。

所以，做一个产品，我们核心要明确业务目标，确定目标用户、梳理业务场景并进行产品定义。

开发都启动了，才有人点拨我们，我们差不多花了整整一个月才从想到想明白，造成了部分返工。

二、进度目标

需求清楚了后，技术负责人将需求转化成开发计划，接下来就可以开发了。

开发计划的坑同样很多，完全依赖于技术负责人对需求的理解，以及将需求转化为开发的设计能力。对需求的不理解或理解偏差，以及较差的设计能力导致系统扩展能力不足，都会导致不必要的返工，并且可能会低估工作难度，导致计划评估不准。

于是，在开发阶段，又有一个很容易迷失的目标：进度目标。因为以上主要原因，就算计划做的再详尽，人员再稳定，计划和实际执行也是很难一致。

加上公司内部的系统，没有客户抽着鞭子催你，项目经理也很容易做着做着被现实屈服，做到哪，算到哪，不停的变更发布计划。

首先，要解决的是需求到设计的转化，形成双向评审机制。产品经理除了输出业务流程和原型外，还要输出需求文档，并且需求文档要能细化到功能点，包括界面的字段说明，长度等，技术负责人评审确认；而当技术负责人完成设计后，产品经理要反向的参与进来评审。

然后，要严肃计划，计划是每个人的承诺，不是完全不可变，但是一旦定下来，大家就要严格执行，无法完成的就自己想办法，要不加班，要不优化提高个人生产率。

三 、测试目标

很多系统测试，最注重的还是功能测试，而且偏向于功能点的测试，忽略了贯穿测试。

所以，一开始就要确认测试的目标，要包括功能测试，安全测试，静态代码扫描等，还要有兼容性测试，一开始在ue开始做静态页面的时候就要明确好要支持的浏览器版本，省的理解不同，还要做改造才能向下兼容。

性能测试指标也要一开始就跟测试人员确定好，多少用户量，满足多少tps，响应时间最长多少等必须明确。

四、 个人目标

做每个项目，除了达成项目的目标外，我们也要给自己设定一个目标。比如，我想通过这个项目让老板对我刮目相看，想在公司中扬名立业，让大家都知道，这么牛的系统是我带队开发的。

或者我想通过这个项目达到坚持每日过进度，有效管理项目计划的目的。

或者，我想通过这个项目实践我刚刚学习到的沟通技巧，在面对冲突时，或关键对话时。

或者，我想按照敏捷的方法试一下项目管理过程，更或者特别微小的，就是想试试敏捷的生产率评估或持续集成。

作为开发人员，你可以定的目标是了解整个项目的业务，而不是只关心自己开发的那部分功能，或者是要学会使用一种前台框架，或者熟悉redis，或者学会部署监控系统，日志系统。

附： 迭代回顾

每个迭代完成后，项目经理要组织产品经理以及技术经理在内的项目团队一起进行迭代回顾。

项目经理可以回顾下整个迭代过程，大家轮流发言，每个人都回顾一下他认为哪些是做的好的，哪些可以做的更好， 哪些需要在下个迭代中改变，具体有什么建议。

要注意的是，通过回顾，你会发现需要改进的点很多，都改过来变得很困难，所以，结束前，还是要跟大家一起商量出下个迭代优先要解决的TOP5。

迭代回顾特别重要，否则，你就会发现在下一个迭代中，团队还是在不断重犯同样的错误。尤其提醒的是，氛围也很重要，不要把迭代回顾变成批斗大会，因为我们的目标是为了在下一个迭代能够做的更好，而不是让大家自我否定，退缩，失望。