【《AI软件项目需求管理的Pm-Scrum模型构建探析案例》8600字】

目录 11.1AI软件项目需求管理的过程分析 11.1.1传统瀑布方式的需求管理过程分析 11.1.2敏捷方法的需求管理过程分析 21.2AI软件项目需求管理的关键因素分析 21.3AI软件项目需求管理的Pm-Scrum模型构建 31.1.1Pm-Scrum的整体框架搭建 31.1.2Pm-Scrum的人员组织形式 61.1.3Pm-Scrum下的需求管理模型 61.1.4Pm-Scrum下的需求变更管理模型 121.4Pm-Scrum的评价方法 151.1AI软件项目需求管理的过程分析AI软件项目需求的管理过程，根据不同企业不同行业采用不同的管理模型有关，传统的大型软件企业，偏重于传统的瀑布式的管理模式，流程上安排顺序方式执行，每一步都输出相应的文档资料。快速响应型的软件公司，如互联网公司，则更倾向于敏捷方法下的需求管理模式，这种模式可以快速响应，拥抱变化，提高发布效率，同时快速响应客户或市场的变化，进行迭代增量交付。1.1.1传统瀑布方式的需求管理过程分析传统项目管理理论PMBOK的核心是过程规范化和标准化管理，侧重过程管理和文档，更适合一些规模比较大、意义重大和需要尽量规避风险的项目，是一个重量方法。传统瀑布式的需求管理过程，通常是按照既定的顺序，先从市场或合同导入客户的需求。根据需求内容做进一步的分析，形成需求说明书，然后转给开发团队，在需求说明书的基础上，进行理解和计划，形成产品规格书。产品规格书，作为团队开发的重要指导资料，指导团队进行开发和测试。如图3-1所示：图3-1传统瀑布方式的需求管理过程该模式下的需求管理过程，遵循循序渐进，对导入的需求要求是必须是明确的，准备的，否则在后续需求的实现环节，会出现因需求变更而导致的返工，延误等情况。为避免出现这种情况，企业会比较重视需求导入的评审，和需求文档的完备性，这从另外个角度将，又增加了项目的时间，同时会导致开发和测试人员无法尽可能早的进行开发和测试工作。1.1.2敏捷方法的需求管理过程分析敏捷方法的核心是软件开发的敏捷，侧重技术方法和实践而非管理和计划，更适合团队规模比较小的中小型项目和需求变化快的项目，是一个轻量方法，其需求管理过程，如图3-2所示。图3-2敏捷方法的需求管理过程简单是敏捷的第一个特点，从需求管理过程中就可以看出。敏捷设置了一个需求池，所有需求导入后首先汇集在需求池中，然后由产品经理根据情况，从需求池筛选优先级较高的需求一部分需求出来，形成第一次迭代。第一次迭代从筛选需求、需求理解、需求开发测试和需求发布，形成一个闭环。第一迭代发布后，再从需求池筛选第二个迭代需要的需求，重复上一个闭环的步骤。以此实现循环迭代，增量交付的目的。如果说简单、持续迭代、拥抱变化和增量交付是敏捷的优点，那它也同时存在一些不足，那就是这种模式针对轻量小型的软件开发，效果较好。但是对复杂AI软件开发就稍显不足。AI软件的一些需求过大，可能无法放入任何一个迭代中进行，例如算法模型，就需要单独的组建算法团队来进行模型设计和训练。1.2AI软件项目需求管理的关键因素分析根据上一节的过程分析，结合实际项目，可以分析出影响需求管理的几个关键因素，分别是合适的需求管理模型，需求分类分层级设置，人员组织结构和闭环的需求管理。（1）合适的需求管理模型。在不同企业，不同的项目采用不同的管理模型，所带来的需求管理水平和能力是截然不同的。轻量型快速交付的企业，选择瀑布模式，则会因为瀑布模式的循序渐进，而导致项目延期交付，无法快速响应客户需求变更。同理，复杂软件的项目管理如果选择敏捷模型，则会出现需求理解肤浅、提交的交付物的稳定性较差。所以，合适的软件项目选用合适的管理模型就比较重要。（2）需求分类分层级设置。在需求管理中，尤其是复杂AI软件的需求管理中，需求的形态各种各样，有功能性需求，业务性需求，性能性需求，也有算法性需求。不同的需求，如果放在一个需求文档或需求池中，必须要根据需求的属性和特点，进行分类和分层，做结构化的分析，才有助于需求的理解和实现。（3）人员组织结构。人员组织结构，对需求管理的影响也较为重要。不同岗位的人员对需求的认知也是不一样的，相同工作内容不同经验的人员对需求的理解也同样存在偏差。采用传统瀑布模式的项目，如果团队人员组织架构是传统职能型架构，则会阻碍模型中部分流程的有效进行。采用敏捷方式的项目管理，如果人员是矩阵式架构，同样也会造成模型无法有效运转的情况。所以不同模型下对应有不同的人员组织架构是保证不同管理模型有效运转的基础。（4）闭环的需求管理。闭环的需求管理在敏捷开发过程中，得到比较好的体现，因为敏捷单个迭代时间较短，需求最终的实现和初期的需求可以很好的匹配对应。传统复杂的软件，因开发周期较长，需求繁多，经常会在需求实现过程中，出现需求挂起或需求丢失的现象。所以，闭环的需求管理，也是较为重要的关键因素。1.3AI软件项目需求管理的Pm-Scrum模型构建1.1.1Pm-Scrum的整体框架搭建瀑布型的软件开发流程如图3-3所示，由需求分析，合计，实现，测试和运行几个部分组成。图3-3瀑布软件开发流程目前常用的敏捷模型有极限编程、Scrum、水晶等，这些敏捷方法基本都基于如图3-4中所示的敏捷开发模型流程。图3-4敏捷软件开发流程敏捷过程强调的是迭代增量交付，迭代周期内包括需求分析、设计、编码与交付，且周期较短，充分反映了敏捷的特性。对于基本的敏捷过程来说，起迭代交付，可以很好的快速响应客户，但过于强调快速满足市场要求，会造成系统的不稳定。因为在短时间内交付，所以在顶层设计的时候，没有过多的考虑系统的可扩展性，从而导致扩展性较差。作者在G公司担任项目经理，在做AI软件项目时候，经常为用传统瀑布式开发模式还是敏捷开发模式而产生疑虑，因为两种模式都不能单一高效的解决AI类项目的遇到的问题，提升管理水平。AI软件是面向客户研发的平台类项目，复杂度高、实现难度大、周期长、投入成本较高，通过传统的项目管理方法PMBOK缺乏灵活性，难以适应需求快速变更、快速迭代交付的要求。又因为软件复杂度高、难度大周期长，很难对整个项目实施全部敏捷。两种方式不管敏捷还是传统的PMBOK都为提高软件项目成功率、降低风险提供了一些方法和手段，项目中不应该局限于某一种形式进行，而是更应该选择或改进为更适合当下项目所使用的方法。针对上述两种流程的不足，结合前两节的过程分析和关键因素，本文做进一步改进结合，得到Pm-Scrum流程框架，如图3-5。图3-5Pm-Scrum流程该流程重点部分在于需求分析阶段，通过对需求范围进行分析划分为两大类，一类需求为通用需求，这类需求是属于基础性、通用性、平台性质等重量级需求；另外一类是非通用需求，例如定制需求、应用类需求、轻量需求。对上述流程图进行变形得到下图3-6，Pm-Scrum的需求管理模型。图3-6Pm-Scrum的需求管理模型在该模型中，需求池可处于动态过程，通过需求分析是筛选，提取出来通用需求，进入瀑布开发模式，其他为非通用需求，进入Scrum迭代开发模式。具体说明如下：需求池：前期和客户沟通，尽可能收集更多的需求，形成需求池。通用需求：基础性、通用性、平台性质等重量级需求，通常在短期内无法完成的需求。由项目经理及需求分析人员，和客户沟通后，从需求池中筛选，并通过评审后形成。非通用需求：定制需求、应用类需求、轻量需求，实现简单，后期变更可能性大。由项目经理及需求分析人员，和客户沟通后，从需求池中筛选，并通过评审后形成。开发管理：瀑布模式下的开发管理，严格遵守线性开发节奏，并严格每一环节评审，充分思考设计方案，通过多轮评审，在导入开发编码并最终进行测试发布。同时，处于Scrum下的这部分需求的开发管理，则通过迭代增量的开发加快新特征、新功能、新产品的开发速度来适应业务复杂性和市场的快速变化。以Sprint为开发节奏进行增量交付。每个Sprint的时间是一个月，每个Sprint分成四个迭代，每个迭代的时间一周。开发团队每周一上午确定当前迭代的基于用户故事的需求范围和开发任务的安排。经过详细设计、编码和测试后完成用户故事的开发。开发人员完成用户故事后向测试人员和业务分析人员(产品负责人)演示完成的用户故事、听取他们的反馈并做相应的调整。当每个迭代所有用户故事完成并完成演示后，周五下午开发团队向测试团队提交可测试的用户故事列表。如图3-7所示，基于Sprint的迭代开发过程。 图3-7基于Sprint的迭代开发过程 测试管理：和开发过程一样。在瀑布模式下的部分，采用正常的测试流程；Scrum模式下的部分采用迭代增量方式。在需求规格确定后，测试经理根据需求规格书来设计项目中相应的测试所用的方案和用例，并通过上会评审的方式进行审查。在每个迭代中，则是有开发人员针对需求开发为对应的用户故事，测试人员根据开发人员的用户故事编写测试用例。在迭代的最后一周，进行自动化回归测试。部署和发布管理：为了向产品负责人和测试人员能够及时提交可使用的软件，引入敏捷的技术方法如持续集成、每日构建、自动化部署。当开发人员向源代码库中提交新的代码时，就会触发持续集成工具进行系统的集成和自动化的单元测试、集成测试，当失败时持续集成工具就会通过邮件通知相关的开发人员，从而保证每次提交代码之后软件的可用性和质量。1.1.2Pm-Scrum的人员组织形式在公司原有矩阵架构下的人员组建成的项目团队成员，包含多种角色。传统瀑布式的项目人力架构通常是扁平式的架构，设置一名项目经理，每个项目成员向项目经理汇报。人数较多的项目，采用树形人力架构，在项目内部会划分功能小组，设置组长，组员向组长汇报，组长向项目经理汇报。这种传统的人力架构通常用来适用于传统瀑布式的项目管理。Scrum团队，通常规模较小，5~7人。犹豫规模较小，通常对团队如何组织不做过多的约定，每个Scum团队有一个ScrumMaster负责推动项目进展或解决争端，有一个ProductOwner负责对产品的待实现功能进行解释，并最终确认。这样简单的组织结构普遍被认为可以用来实现高灵活性的小软件开发项目，但是对于稍大或稍复杂的项目，就难免会有些不太适合。在Pm-Scrum框架下，项目成员中的一部分人员，例如软件成员需要按不同功能模块划分纳入不同的Scrum成员，不同功能模块划分为不同Scrum小组，在项目内部组建成ScrumofScums小团队，每个Scrum成员人数不超过5人，根据所负责模块，命名为xx小组。未纳入Scrum的成员还在项目团队中按原定的角色和岗位进行。1.1.3Pm-Scrum下的需求管理模型软件需求是软件的特征、功能和产品的基本，软件需求的管理贯穿整个AI软件项目生命周期。可靠、高效和灵活的需求管理流程对项目的成功提供保证。AI软件项目通过结合项目范围管理和敏捷方法Scrum相关知识，使用工具对需求管理流程进行改进，实现需求管理流程的可靠、高效和灵活。在Pm-Scrum需求管理中，引入Scrum中的PO(ProductOwner)一产品负责人的角色，负责需求管理相关的工作。Pm-Scrum要求任何导入项目的需求必须在前期经过项目评审，评审通过后，才能在合同里约定。针对客户提出的合同外需求，如果不重新拟定附加合同则可能会导致范围蔓延，导致项目成本增加，进度延长。这部分额外的需求则应该正式和客户确认后，转达到项目团队，由项目团队启动额外需求的评审，并评估需求工作量和完成时间，以及可以放在哪个版本中进行迭代，形成评审报告由商务经理整理成报价方案，提供给客户，客户签署后作为附加合同纳入项目需求池进行管理。Pm-Scrum在项目立项后的一个重要工作是把立项时定义的产品规格细化为需求，形成需求池，并为各个需求排定优先级，根据优先级划分不同的Sprint进行迭代，用来指导后续工作。在标准Scrum方法中，对需求的分配管理很简略，只包含Sprint计划会议一项工作内容。Sprint会议全员参加，用来定义在接下来的迭代周期内需要包含哪些内容，以及要如何完成这些内容。但是在AI类项目中，面对复杂的项目，这种简单的处理方法会对后面的工作造成麻烦。所以，Pm-Scrum对这部分工作也做了一些优化。首先，Pm-Scrum要求在立项后所有定义的规格细化为需求，形成需求池。针对一些标准化、平台类、基本功能类等较为清晰的规格，必须映射到需求，这部分需求需要形成详尽的需求文档，在迭代发版前交给外部测试团队时，必须提交该文档。针对不清晰或者不确定的部分，允许在下轮迭代过程启动时进行修正。此类清晰的规格所形成的需求，可以理解为整个产品的基础，在开发前予以重点阐述。整个需求管理流程，如图3-8所示，包括：需求范围阶段、需求分析和定义筛选阶段、需求理解和计划阶段、需求开发阶段、需求测试阶段。图3-8需求管理流程（1）需求范围阶段。不管是在通用需求模式下还是非通用需求模式下，需求范围阶段主要工作都是确定当下版本的主要目标，规定在迭代结束时提交给客户或用户那些新特征、功能或产品。采用需求跟踪矩阵来对需求进行统一集中的管理和控制。图3-9需求范围阶段流程（2）需求分析和筛选阶段。需求分析时，PO和客户进行需求沟通讨论，对初始需求范围进行业务和商业价值的评估，根据其业务和商业价值对每项需求设定唯一的优先级。设定优先级后，产品负责人和系统分析人员通过需求分析会议对每个需求项进行业务和系统的分析，把每个需求项的需求划分成基于用户需求故事的更小的需求，并根据需求故事在需求项中的重要程度设定第二层的优先级，最后形成基于用户故事的需求文档。开发人员和测试人员对每个用户故事开发和测试的工作量的进行大概的估计并更新到用户故事的需求文档中。所有的用户故事需求文档需放入版本控制工具中进行版本控制。同时根据需求属性，划分通用需求和非通用需求。图3-10需求分析和筛选阶段流程（3）需求理解和计划。为了便于需求计划，在项目团队成员对所有用户故事进行理解的基础上，所有的用户故事需要通过筛选，把通用需求部分放入瀑布计划，非通用需求部分用户故事将添加到待办事项(Backlog)中，产品的待办事项就相当于用户故事需求池。整个开发过程中，如果发现新的用户故事可以随时增加进来。每个Sprint开始时举行Sprint计划会议，产品负责人和项目经理根据整个团队人力资源和交付能力的情况，从产品的待办事项(Backlog)中根据优先级别选取适当的用户故事作为Sprint的待办事项(Backlog)，并制定相应的Sprint开发初步计划和任务安排。需求分析和计划阶段是一个迭代持续的过程。通常情况我们在新版本开发的前期对该版本做一个初步的整体需求分析和计划，时间限定在一周以内。由于在每个Sprint甚至每个迭代都可能加入新的需求或者需求变更，需求分析和计划也需要进行相应的调整，所以不会在前期花费大量的时间和人力对所有的需求进行分析和计划，这样保证需求管理的灵活、高效。图3-11需求理解和计划阶段流程（4）需求开发阶段。在瀑布模式下，通用需求需要进一步的分析和拆解，形成详尽的需求说明文档，在文档的指导下形成详细的设计方案，由瀑布小组成员对详细方案在划分为分系统方案，并通过会议讨论方式，由项目开发人员完成开发工作。在Scrum模式下的部分，需求分析和计划阶段制定的Sprint初步计划在需求开发阶段会进一步的细化，开发团队根据用户故事需求的优先级别细化分为三个迭代，每个迭代时间为一周，原则上用户故事需求的优先级越高迭代开发的时问越早，目的是为了确保最早交付最有商业价值和业务价值的特征、功能和产品。每个迭代周一的站立会议(StandupMeeting)后，产品负责人会向开发人员和测试人员详细讲解这个迭代计划要完成的用户故事需求，并回答开发人员和测试人员的问题，确保大家对用户故事需求的理解一致。需求开发过程中，如果有新的需求项要增加到这个Sprint中，产品负责人和系统分析人员对新的需求项进行需求分析，并把相应的用户故事放入Sprint的待办事项(Backlog)中。产品负责人和项目经理检查当前的需求开发状态，把没有开始开发的用户故事和新加入到Sprint的待办事项(Backlog)中用户故事根据优先级别从新排列，并根据团队的交付能力和人力资源情况，重新调整Sprint的待办事项(Backlog)中用户故事列表，确保团队在不增加额外资源和不改变交付日期的情况下开发商业和业务价值高的需求。需求开发过程中，如果Sprint的待办事项(Backlog)中用户故事需求发生变化，这个变化影响到用户故事对应的需求项的相关特征、功能或产品整体设计和最终的交付日期，这类需求变更需要经过变更控制流程。反之，只是用户故事的实现细节上的变化，产品负责人可以和开发团队和测试团队协商更改相关的需求，而不需要经过变更控制流程。需求开发完成后，开发人员可以邀请产品负责人和测试人员一起对完成的用户故事需求进行Mini．ShowCase，并听取他们的反馈。图3-12需求开发阶段流程（5）需求测试阶段。测试人员根据用户故事需求设计这个迭代将要完成用户故事测试用例。在测试用例评审会议上，如果发现需求中存在争论的地方，产品负责人需要澄清和对需求进行补充完善并更新到相应的需求文档中。测试人员在QA测试环境根据测试用例对开发人员完成的特征、功能或产品进行测试，并在每个Sprint的最后一次迭代在PP环境对这个Sprint完成的所有需求进行自动化的回归测试。为了确保开发人员实现的特征、功能或产品和需求的提出者是一致的，产品Owner、客户将进行用户接受测试(UAT)，对测试中发现的问题及时的反馈，开发团队根据影响的程度、优先级别和工作量决定问题的修复时问并做相应的安排。图3-13需求测试阶段流程1.1.4Pm-Scrum下的需求变更管理模型Pm-Scrum对需求变更也是持开发拥抱态度，Pm-Scrum认为变更是再算难免的事情，变化总比计划快。要保持一颗平常心去看待，积极主动的应对，采取合适的管理模型，对需求变更进行有效管理才是重要。根据对历史项目总结，发现导致项目需求变更，通常有以下几个原因[34]：（1）不同成员因为经验阅历和认知不同在需求理解上存在偏差。（2）一开始客户无法准确的描述需求。（3）随着项目的推进，客户的改变了原始需求或者提出了新看法。（4）客户方基于客观的原因，如硬件、业务环境变化而提出的变更。（5）技术瓶颈导致的变更。（6）新方法的出现，或者公司管理变革导致的变更。需求的变化会对项目整个过程都造成影响[35]，因此包括客户等所有干系人在内的人员都会受到需求变更的影响[36]。需求变更会带来很多不稳定情况，加大项目管理的难度。变更控制过程并不是为限制或抵制变更，也并不是无用的工作，是通过统一的流程标准对其进行过滤，采用合适的变更，降低需求变更的负面影响和风险。PMBOK变更控制流程如图3-14，一般要经过变更申请、影响评估、变更委员会决策、反馈等，同时变更可能拒绝也可能接受，接受后就执行需求变更，在变更完成后进行测试或验证。图3-14传统变更控制流程其具体实施过程中遵循以下原则：1)成立项目的变更控制委员会(CCB)，负责对需求变更进行评估和决定是否执行需求变更。CCB由项目相关的多方组成，应该包括干系人和项目相关团队的负责人。2)建立需求基准版本，为需求变更的提供参照。每次变更并通过评审后，需求基准版本做相应的更新3)制定变更控制流程，形成文档并发给项目相关团队和干系人。4)需求变更申请评审通过后，就要随即更新相关信息，包括计划、成本、活动等。它强调流程，注重管理和过程，而对效率方面考虑的比较少。归纳起来就是传统的PMBOK对软件开发项目过程提供可靠性，敏捷开发提供敏捷性。对AI类大型软件系统项目即需要可靠性又要不缺少灵活性。根据具体情况和实践，结合敏捷和传统项目变更控制流程，设计和提出了基于Pm-Scrum的变更控制管理，具体包含以下几个方面：（1）成立变更控制委员会（CCB）。该委员会通过定期选举方式进行，通常由项目经理、开发团队负责人、测试团队负责人、业务团队负责人及项目顾问、技术专家等组成。CCB主要是针对变更申请，通过分析评审进行把关决定是否允许变更。（2）根据需求的划分，通用性需求和非通用性需求的变更控制流程分别如下：通用性需求的变更，主要涉及系统的底层和平台层的设计，这