项目管理论文哪里有？本研究发现，存在这些问题的原因主要是项目需求管理流程繁琐低效且失控、项目经理无力把控项目进度、项目成员缺乏高效沟通机制渠道。在借鉴相关项目管理知识理论并比较瀑布模式和敏捷模式各自适用的项目管理场景的基础上，结合A公司目前项目管理中客观实际情况，给出A公司由瀑布开发模式转型到敏捷开发模式，并基于敏捷开发模式进行软件项目管理优化的策略建议。
第一章绪论
第二节国内外文献研究综述
一、国外文献研究综述
Holtzhausen[1]通过探讨使用敏捷方法Scrum与团队工作效率的关系，研究得出敏捷方法Scrum能有效提高团队工作效率的结论。Ardakani[2]认为敏捷方法Scrum通过自组织建立起来的团队可以更好发挥成员的主观能动性，团队成员相互之间更乐于合作和沟通，非常有助于团队工作效率的提高。Anand[3]指出传统的瀑布模型的软件开发模式属于线性顺序执行的开发模式，不太适合业务需求迅速变化的新情况，现在已经转向敏捷方法，并提出软件企业从瀑布模型转向敏捷模型将成为一种趋势。Aryanto[4]关注敏捷方法Scrum中系列工具的作用，认为敏捷方法中燃尽图等工具是很好的进度管理工具，可以帮助开发人员可视化的跟踪管理项目进度。
Zayat和Senvar[5]对比了Scrum和Kanban这两种敏捷方法的异同，经过比较显示Scrum非常强调与客户间的合作和交互沟通，而Kanban适合于需要客户定期按时参与的项目。两种方法都非常有助于提升项目干系人的沟通意愿，促进形成良好的合作沟通氛围。Jiles[6]指出为了满足迅速变化的商业环境，很多商业领袖正在培育一种敏捷文化，传统瀑布模型的软件开发已经无法跟上业务发展的速度，需要使用敏捷开发模式快速响应业务变化，赢得商机。Zender[7]认为敏捷理论不仅适合于软件开发领域，而且适合于类似建筑等领域，并认为敏捷理论具有普适性。Agh和Halimeh[8]认为Scrum是目前使用最为广泛的敏捷方法，但对于可用资源没有明确定义变量，作者通过识别Scrum中的变量，来解决Scrum配置的问题。
第三章常见软件开发模式及比较选择
第一节瀑布开发模式
一、瀑布开发模式的内涵
以“瀑布模型”为代表的“软件工程模型”在处理“软件危机”的过程中发挥了一定的积极作用。“瀑布模型”是最早，也是流行最广的软件工程模型。它将软件生命周期按时间顺序划分为如下图[33]所示的3个大阶段、8个子阶段。
在瀑布模型中，由于软件的整个生命周期被划分为3个主要大阶段、8个明细的小阶段多个阶段，由此将软件项目管理这个复杂问题化整为零，化简成对各个阶段依次进行管理，另外，需求分析、概要/详细设计、编码开发、测试、维护等几个不同的过程交由不同角色的人员负责，这样更细化对软件开发中参与人员的分工，每个角色对应的人员只需要专注于本角色相关的工作就可以了，方便了对软件项目中人员的管理和成长。
上述这些子阶段都有明确的工作内容，每个子阶段的结果必须以文档的形式反映，并且上一个子阶段的工作结果是下一个子阶段工作的基础和输入。每一子阶段工作结果都必须进行验证确认，发现错误则需反馈至上一子阶段，直至确认后再进入下一子阶段。如果没有上一子阶段工作成果作为基础和输入，下一子阶段的工作不能启动开展。
第五章A公司软件项目管理优化策略
第一节实施敏捷流程和方法优化需求管理
旧有的瀑布模式下，需求管理有一整套从需求获取、方案制定、需求分析及后续评审等冗长固定的流程，这些流程在保证需求的完整性和一致性上确实可能起到了一定的作用，但是随着业务的高速发展，越来越多的需求或者需求变更不断涌来，如果还按照旧有瀑布模式下的全套流程按步就班的执行，会耗费业务人员、开发人员大量的时间和精力，而且还不一定能跟上业务需求或需求变更不断提出的节奏，而且一般需要完成所有需求并确认之后才能进入开发阶段，这样严重阻滞项目开发的进度，该模式下管理方式逐渐成为制约业务发展的瓶颈。
基于Scrum敏捷方法在需求管理上遵循循序渐进、逐步明细、多轮迭代、稳步推进的原则，为解决上述瀑布模式下低效需求管理的问题提供了比较好的解决方案。下文将Scrum的基本框架和A公司软件项目需求管理实际情况结合起来，提出了具体的需求管理改进方案。
一、拥抱变化、简化流程赋能需求管理
需求管理优化流程的首要工作是明确需求双方牵头责任人。需求管理流程效率的提升首先要把负责需求的开发方和客户方的需求牵头责任人明确，然后再基于敏捷精简高效能及时响应变化、拥抱变化的流程对需求管理进行优化，这样才能有的放矢高效开展需求管理工作。
一般而言，项目的开发方和需求提出的客户方参与项目的成员名单需要在项目立项初期就确认明确。敏捷开发模式下开发方一般由Product Owner(产品经理或称产品负责人)、Scrum Master(敏捷教练)、Development Team(开发小组)等组成，而客户方既包括主产品业务联系人和所涉及其它产品业务部门的联系人外，还需要包含唯一的、专业的需求对口人员，可称之为需求专员。产品经理PO主要对接需求专员，需求专员对着业务方各涉及产品业务部门的联系人。
第二节遵循敏捷尽快交付原则创新方法升级进度管理
一、运用敏捷迭代渐进明细尽早交付加快项目进度
A公司虽然根据各项目上报的时间点进行归纳汇总，形成粗粒度组织级别的批次进度计划，但对每个项目而言没有更细粒度的详尽的项目进度管理计划，这样不便于项目进度的日常跟踪和管理，项目管理人员往往只是凭着以往的项目经验管控项目进度，存在着较大的不确定性和进度失控风险。
软件项目进度管理首要工作是根据项目所包含的工作内容来估计项目工作量，另外项目的工期是通过团队的开发速度和项目工作量计算得出的，敏捷开发方式的项目时间预估中，一般是以具有普遍通用意义的功能点/故事点作为项目工作量的估算基准单位,将有代表性的功能点/故事点当一个基准，所有其他功能点/故事点可以以这个点为参照，其他功能点/故事点所花时间就是这个参照物的若干倍[36]。如表5.2所示是某个产品第一个迭代轮次要完成的具体的故事点和相应的时间安排，此为迭代开发计划的一个示例。
第六章结论与展望
第二节研究展望
论文根据本人在A公司的工作经历，对公司的软件项目管理现状作出了分析，提出了在工作中发现的问题并且给出了相应的优化策略，希望本文能给类似的软件研发公司带来有价值的贡献。
此外，提升敏捷开发模式下团队自我组织能力、关注人与组织的转型，是团队走向成熟的关键之一。后者虽然比落地具体实践方法更加不容易，但高效的自组织团队更能使团队凝聚目标，使项目增加成功几率，因此，打造自组织团队也将是敏捷开发模式下项目管理的重要篇章。
参考文献（略）
