论文部分内容阅读
摘 要：敏捷开发不需要详尽的文档，项目管理和运维又需要一些信息被文档化以支持项目的顺利进行和运营维护。本论文以金融数据运维团队为例，描述了敏捷项目管理中需要被记录下来的信息或文档包括：项目目标、实施方案和约束条件、交付物列表、任务列表、燃尽图、项目报告和支持文档（仅针对软件产品），以及每项文档的产生过程或注意事项。为运维团队的敏捷项目管理提供了指导。
关键词：敏捷项目管理;文档;运维
一、引言
金融数据公司主要通过软件、电子文件等形式向客户（即各类投资者）交付数据以用于投资决策。所以对于金融数据公司而言，所销售数据的准确性、及时性至关重要。运维团队在金融数据公司除了要确保所有软件每天都能准确、及时交付数据之外，还需要不断地监控和优化整个系统以满足业务不断增长所带来的变更。所以，金融数据运维团队日常会开发和维护各种软件工具，以减少计划外工作及其影响。
敏捷开发方法由于其高效和灵活的优点，被越来越多软件开发工作者所使用。在敏捷团队中进行项目管理，要使用敏捷项目管理的方法。敏捷软件开发宣言提出了一条价值观：工作的软件高于详尽的文档。许多敏捷团队成员依此提出敏捷开发不需要文档的设想，然而在实际开发过程中，信息的传递仅依靠人脑记忆和口口相传会造成信息的流失和失真，对软件进入运维阶段的工作也会造成不小的麻烦。所以，虽然敏捷开发不需要详尽的文档，但是站在项目管理的角度，有些信息是需要被文档化以保证项目的顺利进行和验收的。那么哪些信息要写文档，哪些信息不需要？需要的信息要写到什么样的详尽程度才合适？这些问题，在现有的研究中还没有标准答案。
二、哪些信息必须文档化
根据在金融数据运维团队中多个大大小小项目的管理经验，总结出以下信息必须要用文档方式记录下来，或者这些文档必须要有，才能够保证项目最终能顺利地实现目标，并使得相关干系人满意。
（一）项目目标
在金融数据运维团队中，项目目标通常是减少计划外工作，或者减少某项成本，或者支持某个业务目标等。通常我们在描述项目目标时会陷入一个误区：就是将手段或交付物描述为目标。比如，项目发起人说他需要一个事件处理系统，然而实际上不是，他需要的是保证产品上所有事件能够得到及时、有效地解决，以提高客户满意度。事件处理系统可能会帮助提高客户满意度，也有可能会因为步骤繁琐、响应不及时而降低满意度。那么当我们有了一个完美的系统但客户满意度并没有提高的时候，相关干系人会觉得项目成功交付了但是项目目标并没有达成，所以找准项目目标是关键。
那么项目的目标应该如何收集，以确保我们找到了正确的目标呢？通常，我们会问项目发起人以下三个问题：
1）为什么要发起这个项目？2）最终是想解决什么问题？3）期望能解决到什么程度？
并且重点关注项目发起人想要的东西和他想解决的问题之间的因果逻辑。有的人描述的想要的东西和想解決的问题，可能其因果关系是存在问题的。比如，有人说：“我要一个面包，想解决小孩饿了的问题”，如果小孩不满半岁，那么他需要的可能是一瓶牛奶而非面包。再比如，在运维团队中，项目发起人提出要优化事件处理系统，深挖其目标时发现他想解决的问题是某些事件因为没有得到及时响应而遭到了客户投诉，那么针对这个待解决的问题，项目需要做的事情并不是优化事件处理系统，而是制定一套服务水平协议并与客户达成共识。所以项目目标与想解决的问题之间的关系是非常密切的。同样还要了解相关干系人对于问题解决到什么程度的期望。比如提高系统性能，将系统响应时间从30秒提高到15秒，还是3秒，所需的成本肯定是不一样的。了解期望问题解决的程度有助于正确地预估项目成本。将这些信息作为项目目标的一部分记录下来，一方面可以确保项目团队做的是正确的事;另一方面也可以有效避免需求蔓延，以及正确评估项目满意度。
（二）实施方案和项目约束
在明确了项目目标之后，我们需要规划如何才能达到该目标——即实施方案。在规划的过程中需要进行一系列的概念验证，以确保方案是可行的。比如“将大象放进冰箱”项目，没有经过概念验证的实施方案可能就是：第一步，将冰箱门打开;第二步，将大象放进去;第三步，关上冰箱门。在进行概念验证的时候就会发现问题，这个实施方案取决于大象体积有多大，以及冰箱的容量有多大。所以，在确定实施方案之前，一定要进行概念验证。
此外，在多个实施方案之中，项目团队一般会选择投入产出比最经济的方案，但是最终项目实施方案的选择还取决于项目约束。什么是项目约束呢？有些情况下，项目发起人对于项目目标的达成过程是存在一些要求的。比如，项目应该三个月之内完成，或者实现这个目标的花费不应该超过20人日等。甚至有些要求或约束，在发起项目的时候自己并没有意识到，在沟通实施方案的时候才一步步被挖掘出来。比如某个项目需要一个数据分析平台以预测系统改进方向，在沟通实施方案时发现，尽管选择现有技术自主开发平台最经济有效，项目发起人却更青睐使用第三方工具或者新的技术来实现目标，以获得较高的可扩展性，以及提高团队的技术能力水平。这些约束条件如果没有被满足，将会影响相关干系人对于项目的满意度。而且当项目过程中出现冲突需要进行决策时，这些约束条件能够为冲突决策提供有效依据。
（三）交付物列表
在决定了实施方案之后，可以根据方案的大致步骤列出每一步的产出物——即交付物。交付物根据步骤的详细程度可分为不同的层次或颗粒度，其划分方法取决于该项目的实施方案。比如，开发一个事件处理平台，我们可以根据事件处理流程将系统划分为收集、处理、汇报三个模块。但是最终交付时可能会发现问题从而影响进度，并且客户需要等待比较长的时间才能看到产品，所以敏捷团队一般不采用这种实施方案。敏捷团队可以选择按照事件等级划分，将系统划分为：高优先级事件处理流、中优先级事件处理流和低优先级事件处理流，使得客户在第一个交付物交付使用时就能够开始使用产品了。或者也可以按照事件来源划分，先开发数据库事件处理过程，再扩展至接口事件、邮件事件等。所以，敏捷团队的交付物划分，都是基于用户可用原则的。 针对每一个交付物，需要列出其验收方法和验收标准，以及预估任务大小等级，从而可以根据资源可用情况来制定里程碑计划。验收方法和验收标准的制定，是为了验证交付物是否合理。不可衡量的目标不是好目标，所以每一个交付物都必须是可衡量可验收的。预估任务大小等级，可以依据概念验证时的经验来预估要交付该交付物大致所需的资源等级。当然，这种预估在项目进行的过程中是可以调整的。这些信息，和团队的资源可用情况，共同决定了里程碑计划的合理性。
（四）下一迭代周期的任务列表
当交付物列表和里程碑计划确定之后，项目就可以进入实施阶段了。首先，项目团队需要对交付物进行分解，列出为了交付该交付物所需完成的任务有哪些，从而形成任务列表。和传统的瀑布式软件开发项目管理不同，敏捷项目管理不要求在任务开始前定义好完整的任务列表，可以仅定义下一个迭代周期的任务列表，就开始任务实施，并同时定义下一个迭代周期所需完成的任务列表。在此过程中，任务列表、交付物列表和里程碑计划，都可根据项目最新进展和反馈进行调整，这样就确保了项目的灵活性和及时性。
在金融数据运维团队中，任务不仅包括写代码开发或修改某程序，还包含其他支持性的工作，比如研究某项新技术用于实施某功能、查找某问题的根本原因、更新维护文档等。不管是何种类型的任务，都应该包括验收标准以判断任务完成情况。针对写代码的任务，还需要列出修改范围和步骤，以确保不管是团队中何人领了该任务，具体代码的实现方式没有太大差异，这样有利于知识共享和团队承诺。当然，金融数据运维团队日常还需要完成一些计划外工作，又称救火工作，比如重大问题、异常事件等。由于这类工作在范围、时间、成本等方面存在不可预估性，通常我们不将这部分工作包含在任务列表中，敏捷项目管理仅针对计划内工作。
（五）燃尽图
敏捷开发团队通过在一个固定的时间周期内，完成一次冲刺以交付用户价值，即完成一个迭代。在这个过程当中，团队的进度可以通过燃尽图来控制。燃尽图是一个二维坐标曲线图：横坐标表示迭代周期内每次监控的时间节点，纵坐标表示任务大小，中间一条基准直线连接纵坐标上的团队承诺总大小和横坐标上的迭代结束时间，还有一条实际燃尽曲线表达每次监控时间节点上团队剩余任务的大小。
一般情况下，敏捷团队的监控周期是每日一次，所以团队通过每日站会来更新燃尽图。每日站会是每天在一个固定的时间点，所有人站在一起来分享各自三个信息：1）我昨天完成了什么;2）我今天准备或正在做什么;3）我发现了什么问题。分享完成后大家更新燃尽图上的实际燃尽曲线，通过实际燃尽曲线和基准直线之间的距离，讨论当前迭代的进度风险，以及风险应对措施。
在当前迭代结束后的迭代回顾会议中，团队还可以根据燃尽图来讨论改进措施，以达到团队自我管理和不断改进的目标。
（六）项目报告
在项目进行的过程当中，需要将项目的进度及问题汇报给相关干系人，特别是那些并不参与到项目之中但又对项目有重大影响力的关键干系人，于是就需要有项目报告。一般针对读者的不同，项目报告里的内容可以分为不同的层次。比如高层管理者仅关心项目是否健康、能否如期交付，并不关心项目实施的具体细节;而中层管理者会关注一些进度和风险方面的大致情况，以安排资源;项目团队就会关注更具体一点的信息，以准确把握项目的实施细节来做好相互配合。所以，项目报告中一般包含三个层次的内容：
1）项目目标和状态。用一句话描述项目目标，然后用不同颜色标注范围、时间和成本方面是健康（绿色）、有风险（黄色）还是失控（红色）。这样读者并不需要看其他细节，就可以对项目状态一目了然。
2）里程碑进展和正在进行时的风险列表。用图或表的形式展现里程碑信息，例如计划时间和实际时间对比，让读者可以对项目的进度一目了然。并且列出已发生尚未解决的风险和进展情况，以便相关干系人配合协调资源清理项目阻碍。
3）前一个周期完成的任务和下一个周期准备开始的任务。这些属于项目的细节信息，项目团队可以通过这些细节对整个项目的阶段和未来一段时间所需要做的事情有一个前瞻性的了解。
同时，对于某些关键交付物的完成或者重大风险，可以在项目报告的最上方突出显示以重点强调这部分内容。重点突出关键交付物的完成，是汇报一个阶段性成果完成的喜讯，可以提振大家的信心和士气。突出重大风险，可以引起所有人的重视，以集思廣益、尽早解决问题。
（七）支持文档（仅针对软件产品）
对于软件产品，在第一个交付物交付使用的同时，就需要有一个支持文档，用于记录日常维护的过程中可能会遇到的问题，以及解决问题或问题升级的步骤。随着项目的持续交付，甚至项目结束后一段时间内，支持文档都需要根据实际情况来更新信息。
一般来说，支持文档需要包含以下内容：
1）背景信息。描述维护该产品所需要了解的所有背景信息，包括产品的业务背景、整体架构、部署信息和运维工具等。
2）已知问题和措施。描述所有已知的可能会发生的问题，和当问题发生时需要执行的步骤。一般这里的步骤是指短期解决方案，或者收集用来解决问题的信息的步骤。如果某个问题从长远来看已经被彻底解决了，那么该问题可以从支持文档中移除。
3）经常被问到的问题。这里的问题一般是指运维团队在救火过程中经常会被问到的问题及其解决方案。
4）维护注意事项。比如在类似系统升级这种维护的过程当中，需要关注哪些注意事项。
5）问题升级名单。表示当有重大问题出现时，应该找谁来处理或解决。
三、总结
在敏捷项目管理中，项目目标、实施方案和约束条件确保了项目团队能够做正确的事，交付物列表、任务列表、燃尽图和项目报告确保了项目团队能够正确地做事，支持文档保证了软件投入使用之后运维团队能够正确地做正确的事，这些文档是缺一不可的。本论文从文档的角度分析了敏捷项目管理的流程和注意事项，对金融数据运维团队的项目管理工作有重要指导意义。
参考文献：
[1] Gene Kim， Kevin Behr， George Spafford.凤凰项目[M].北京：人民邮电出版社， 2015：9-1.
[2] Ward Cunningham. Manifesto for Agile Software Development [EB/OL]. http：//agilemanifesto.org/ 2001.
[3] 项目管理协会.项目管理知识体系指南[M].北京：电子工业出版社，2012：8-19.
[4] 叶俊文.融合Scrum敏捷开发的标准研制项目管理模式探索[J].学术研讨，2019（3）：38-53.
关键词：敏捷项目管理;文档;运维
一、引言
金融数据公司主要通过软件、电子文件等形式向客户（即各类投资者）交付数据以用于投资决策。所以对于金融数据公司而言，所销售数据的准确性、及时性至关重要。运维团队在金融数据公司除了要确保所有软件每天都能准确、及时交付数据之外，还需要不断地监控和优化整个系统以满足业务不断增长所带来的变更。所以，金融数据运维团队日常会开发和维护各种软件工具，以减少计划外工作及其影响。
敏捷开发方法由于其高效和灵活的优点，被越来越多软件开发工作者所使用。在敏捷团队中进行项目管理，要使用敏捷项目管理的方法。敏捷软件开发宣言提出了一条价值观：工作的软件高于详尽的文档。许多敏捷团队成员依此提出敏捷开发不需要文档的设想，然而在实际开发过程中，信息的传递仅依靠人脑记忆和口口相传会造成信息的流失和失真，对软件进入运维阶段的工作也会造成不小的麻烦。所以，虽然敏捷开发不需要详尽的文档，但是站在项目管理的角度，有些信息是需要被文档化以保证项目的顺利进行和验收的。那么哪些信息要写文档，哪些信息不需要？需要的信息要写到什么样的详尽程度才合适？这些问题，在现有的研究中还没有标准答案。
二、哪些信息必须文档化
根据在金融数据运维团队中多个大大小小项目的管理经验，总结出以下信息必须要用文档方式记录下来，或者这些文档必须要有，才能够保证项目最终能顺利地实现目标，并使得相关干系人满意。
（一）项目目标
在金融数据运维团队中，项目目标通常是减少计划外工作，或者减少某项成本，或者支持某个业务目标等。通常我们在描述项目目标时会陷入一个误区：就是将手段或交付物描述为目标。比如，项目发起人说他需要一个事件处理系统，然而实际上不是，他需要的是保证产品上所有事件能够得到及时、有效地解决，以提高客户满意度。事件处理系统可能会帮助提高客户满意度，也有可能会因为步骤繁琐、响应不及时而降低满意度。那么当我们有了一个完美的系统但客户满意度并没有提高的时候，相关干系人会觉得项目成功交付了但是项目目标并没有达成，所以找准项目目标是关键。
那么项目的目标应该如何收集，以确保我们找到了正确的目标呢？通常，我们会问项目发起人以下三个问题：
1）为什么要发起这个项目？2）最终是想解决什么问题？3）期望能解决到什么程度？
并且重点关注项目发起人想要的东西和他想解决的问题之间的因果逻辑。有的人描述的想要的东西和想解決的问题，可能其因果关系是存在问题的。比如，有人说：“我要一个面包，想解决小孩饿了的问题”，如果小孩不满半岁，那么他需要的可能是一瓶牛奶而非面包。再比如，在运维团队中，项目发起人提出要优化事件处理系统，深挖其目标时发现他想解决的问题是某些事件因为没有得到及时响应而遭到了客户投诉，那么针对这个待解决的问题，项目需要做的事情并不是优化事件处理系统，而是制定一套服务水平协议并与客户达成共识。所以项目目标与想解决的问题之间的关系是非常密切的。同样还要了解相关干系人对于问题解决到什么程度的期望。比如提高系统性能，将系统响应时间从30秒提高到15秒，还是3秒，所需的成本肯定是不一样的。了解期望问题解决的程度有助于正确地预估项目成本。将这些信息作为项目目标的一部分记录下来，一方面可以确保项目团队做的是正确的事;另一方面也可以有效避免需求蔓延，以及正确评估项目满意度。
（二）实施方案和项目约束
在明确了项目目标之后，我们需要规划如何才能达到该目标——即实施方案。在规划的过程中需要进行一系列的概念验证，以确保方案是可行的。比如“将大象放进冰箱”项目，没有经过概念验证的实施方案可能就是：第一步，将冰箱门打开;第二步，将大象放进去;第三步，关上冰箱门。在进行概念验证的时候就会发现问题，这个实施方案取决于大象体积有多大，以及冰箱的容量有多大。所以，在确定实施方案之前，一定要进行概念验证。
此外，在多个实施方案之中，项目团队一般会选择投入产出比最经济的方案，但是最终项目实施方案的选择还取决于项目约束。什么是项目约束呢？有些情况下，项目发起人对于项目目标的达成过程是存在一些要求的。比如，项目应该三个月之内完成，或者实现这个目标的花费不应该超过20人日等。甚至有些要求或约束，在发起项目的时候自己并没有意识到，在沟通实施方案的时候才一步步被挖掘出来。比如某个项目需要一个数据分析平台以预测系统改进方向，在沟通实施方案时发现，尽管选择现有技术自主开发平台最经济有效，项目发起人却更青睐使用第三方工具或者新的技术来实现目标，以获得较高的可扩展性，以及提高团队的技术能力水平。这些约束条件如果没有被满足，将会影响相关干系人对于项目的满意度。而且当项目过程中出现冲突需要进行决策时，这些约束条件能够为冲突决策提供有效依据。
（三）交付物列表
在决定了实施方案之后，可以根据方案的大致步骤列出每一步的产出物——即交付物。交付物根据步骤的详细程度可分为不同的层次或颗粒度，其划分方法取决于该项目的实施方案。比如，开发一个事件处理平台，我们可以根据事件处理流程将系统划分为收集、处理、汇报三个模块。但是最终交付时可能会发现问题从而影响进度，并且客户需要等待比较长的时间才能看到产品，所以敏捷团队一般不采用这种实施方案。敏捷团队可以选择按照事件等级划分，将系统划分为：高优先级事件处理流、中优先级事件处理流和低优先级事件处理流，使得客户在第一个交付物交付使用时就能够开始使用产品了。或者也可以按照事件来源划分，先开发数据库事件处理过程，再扩展至接口事件、邮件事件等。所以，敏捷团队的交付物划分，都是基于用户可用原则的。 针对每一个交付物，需要列出其验收方法和验收标准，以及预估任务大小等级，从而可以根据资源可用情况来制定里程碑计划。验收方法和验收标准的制定，是为了验证交付物是否合理。不可衡量的目标不是好目标，所以每一个交付物都必须是可衡量可验收的。预估任务大小等级，可以依据概念验证时的经验来预估要交付该交付物大致所需的资源等级。当然，这种预估在项目进行的过程中是可以调整的。这些信息，和团队的资源可用情况，共同决定了里程碑计划的合理性。
（四）下一迭代周期的任务列表
当交付物列表和里程碑计划确定之后，项目就可以进入实施阶段了。首先，项目团队需要对交付物进行分解，列出为了交付该交付物所需完成的任务有哪些，从而形成任务列表。和传统的瀑布式软件开发项目管理不同，敏捷项目管理不要求在任务开始前定义好完整的任务列表，可以仅定义下一个迭代周期的任务列表，就开始任务实施，并同时定义下一个迭代周期所需完成的任务列表。在此过程中，任务列表、交付物列表和里程碑计划，都可根据项目最新进展和反馈进行调整，这样就确保了项目的灵活性和及时性。
在金融数据运维团队中，任务不仅包括写代码开发或修改某程序，还包含其他支持性的工作，比如研究某项新技术用于实施某功能、查找某问题的根本原因、更新维护文档等。不管是何种类型的任务，都应该包括验收标准以判断任务完成情况。针对写代码的任务，还需要列出修改范围和步骤，以确保不管是团队中何人领了该任务，具体代码的实现方式没有太大差异，这样有利于知识共享和团队承诺。当然，金融数据运维团队日常还需要完成一些计划外工作，又称救火工作，比如重大问题、异常事件等。由于这类工作在范围、时间、成本等方面存在不可预估性，通常我们不将这部分工作包含在任务列表中，敏捷项目管理仅针对计划内工作。
（五）燃尽图
敏捷开发团队通过在一个固定的时间周期内，完成一次冲刺以交付用户价值，即完成一个迭代。在这个过程当中，团队的进度可以通过燃尽图来控制。燃尽图是一个二维坐标曲线图：横坐标表示迭代周期内每次监控的时间节点，纵坐标表示任务大小，中间一条基准直线连接纵坐标上的团队承诺总大小和横坐标上的迭代结束时间，还有一条实际燃尽曲线表达每次监控时间节点上团队剩余任务的大小。
一般情况下，敏捷团队的监控周期是每日一次，所以团队通过每日站会来更新燃尽图。每日站会是每天在一个固定的时间点，所有人站在一起来分享各自三个信息：1）我昨天完成了什么;2）我今天准备或正在做什么;3）我发现了什么问题。分享完成后大家更新燃尽图上的实际燃尽曲线，通过实际燃尽曲线和基准直线之间的距离，讨论当前迭代的进度风险，以及风险应对措施。
在当前迭代结束后的迭代回顾会议中，团队还可以根据燃尽图来讨论改进措施，以达到团队自我管理和不断改进的目标。
（六）项目报告
在项目进行的过程当中，需要将项目的进度及问题汇报给相关干系人，特别是那些并不参与到项目之中但又对项目有重大影响力的关键干系人，于是就需要有项目报告。一般针对读者的不同，项目报告里的内容可以分为不同的层次。比如高层管理者仅关心项目是否健康、能否如期交付，并不关心项目实施的具体细节;而中层管理者会关注一些进度和风险方面的大致情况，以安排资源;项目团队就会关注更具体一点的信息，以准确把握项目的实施细节来做好相互配合。所以，项目报告中一般包含三个层次的内容：
1）项目目标和状态。用一句话描述项目目标，然后用不同颜色标注范围、时间和成本方面是健康（绿色）、有风险（黄色）还是失控（红色）。这样读者并不需要看其他细节，就可以对项目状态一目了然。
2）里程碑进展和正在进行时的风险列表。用图或表的形式展现里程碑信息，例如计划时间和实际时间对比，让读者可以对项目的进度一目了然。并且列出已发生尚未解决的风险和进展情况，以便相关干系人配合协调资源清理项目阻碍。
3）前一个周期完成的任务和下一个周期准备开始的任务。这些属于项目的细节信息，项目团队可以通过这些细节对整个项目的阶段和未来一段时间所需要做的事情有一个前瞻性的了解。
同时，对于某些关键交付物的完成或者重大风险，可以在项目报告的最上方突出显示以重点强调这部分内容。重点突出关键交付物的完成，是汇报一个阶段性成果完成的喜讯，可以提振大家的信心和士气。突出重大风险，可以引起所有人的重视，以集思廣益、尽早解决问题。
（七）支持文档（仅针对软件产品）
对于软件产品，在第一个交付物交付使用的同时，就需要有一个支持文档，用于记录日常维护的过程中可能会遇到的问题，以及解决问题或问题升级的步骤。随着项目的持续交付，甚至项目结束后一段时间内，支持文档都需要根据实际情况来更新信息。
一般来说，支持文档需要包含以下内容：
1）背景信息。描述维护该产品所需要了解的所有背景信息，包括产品的业务背景、整体架构、部署信息和运维工具等。
2）已知问题和措施。描述所有已知的可能会发生的问题，和当问题发生时需要执行的步骤。一般这里的步骤是指短期解决方案，或者收集用来解决问题的信息的步骤。如果某个问题从长远来看已经被彻底解决了，那么该问题可以从支持文档中移除。
3）经常被问到的问题。这里的问题一般是指运维团队在救火过程中经常会被问到的问题及其解决方案。
4）维护注意事项。比如在类似系统升级这种维护的过程当中，需要关注哪些注意事项。
5）问题升级名单。表示当有重大问题出现时，应该找谁来处理或解决。
三、总结
在敏捷项目管理中，项目目标、实施方案和约束条件确保了项目团队能够做正确的事，交付物列表、任务列表、燃尽图和项目报告确保了项目团队能够正确地做事，支持文档保证了软件投入使用之后运维团队能够正确地做正确的事，这些文档是缺一不可的。本论文从文档的角度分析了敏捷项目管理的流程和注意事项，对金融数据运维团队的项目管理工作有重要指导意义。
参考文献：
[1] Gene Kim， Kevin Behr， George Spafford.凤凰项目[M].北京：人民邮电出版社， 2015：9-1.
[2] Ward Cunningham. Manifesto for Agile Software Development [EB/OL]. http：//agilemanifesto.org/ 2001.
[3] 项目管理协会.项目管理知识体系指南[M].北京：电子工业出版社，2012：8-19.
[4] 叶俊文.融合Scrum敏捷开发的标准研制项目管理模式探索[J].学术研讨，2019（3）：38-53.