1. 网站地图
  2. 设为首页
  3. 关于我们


项目管理在D公司“智慧工程”信息系统建设中的应用研究

发布时间:2023-01-15 15:16
目录
摘要 I
ABSTRACT II
        IV
第一章绪论 1
1.1选题背景及研究意义 1
1.1.1选题背景 1
1.1.2研究意义 2
1.2国内外研究现状 2
1.2.1国外研究现状 2
1.2.2国内研究现状 4
1.3研究思路与方法 6
1.3.1研究思路 6
1.3.2研究方法 6
1.3.3论文创新点 7
1.4论文主要内容及框架、研究路线   7
1.4.1论文主要内容及框架 7
1.4.2研究路线 8
第二章相关理论介绍 9
2.1项目管理 9
2.1.1项目管理的概念 9
2.1.2项目进度管理的概念 9
2.1.3项目管理的过程 10
2.2信息系统项目管理常用模型 11
2.2.1瀑布模型 11
2.2.2原型模型 12
2.2.3敏捷模型 13
2.3模型适用总结 15
2.4本章小结 16
第三章D公司信息系统项目管理问题分析 17
3.1D公司概况 17
3.2D公司“智慧工程”信息系统项目情况 17
3.2.1D公司信息系统建设项目组织架构 17
322 D公司信息系统建设项目实施流程 18
3.3 D公司“智慧工程”信息系统项目管理存在的问题 19
3.3.1D公司“智慧工程”信息系统项目管理现状 19
3.3.2D公司“智慧工程”信息系统项目管理存在的问题及分析 20
3.3.3选择敏捷模型解决D公司信息系统建设项目管理问题的思考........23
3.4本章小结 25
第四章 构建适用于D公司“智慧工程”信息系统项目管理模型 26
4.1整体优化 26
4.2具体实施说明 28
4.2.1完善管理机制——启动阶段 28
4.2.2优化流程管理 30
4.2.3深化沟通及指导 - 31
4.2.4细化计划管理 32
4.2.5强化过程管控 33
4.3辅助工具   37
4.3.1甘特图 37
4.3.2看板 38
4.3.3燃尽图 38
4.4本章小结 : 38
第五章 优化后的模型在D公司“智慧工程”信息系统项目管理中的应用 40
5.1项目背景 40
5.1.1项目简介 40
5.1.2功能范围 40
5.1.3目标价值 42
5.L4开发模式 42
5.2优化后的模型在D公司“智慧工程”信息系统项目管理中的实施 42
5.2.1 启动SCRUM 42
5.2.2阶段内控制 44
5.2.3阶段边界管理    52
5.2.4 收尾   56
5.3实施效果总结评估 56
5.3.1需求管理改进效果 56
5.3.2沟通管理改进效果 58
5.3.3进度管理改进效果 59
5.3.4整体效果的评价 59
5.3.5实施注意事项 63
5.4本章小结     66
第六章总结与展望 67
6.1总结 67
6.1.1总结 67
6.1.2不足 68
6.2展望 69
致谢 70
参考文献 71
附录 75
攻读学位期间发表的研究成果 78
第一章绪论
1.1选题背景及研究意义
1.1.1选题背景
随着信息技术不断发展,各行各业都在积极探索智慧化管理新模式。D公司基 于管理和业务的需要,对所管理的重点工程建设领域进行了相应的信息化系统建 设,但这些系统主要只针对某一方面的单一工程类型进行管理,能够提高相应领域 的管理能力和业务水平。但由于系统不断增多,数据编码规范、数据接口、数据处理 能力等方面不尽相同,给各系统间的业务流程处理、数据共享和关联等方面带来了 一定的困难,形成了数据孤岛、信息碎片、系统割裂的问题,无法为D公司提供充 的数据分析,更无法为公司管理层提供有效的决策参考依据。基于上述的现状和 问题,D公司的决策者和管理者们按照“总体设计、分步实施、稳步推进”的建设原 则,积极探索推进D公司实现“智慧管理”的“智慧企业”建设,启动了“智慧企 业”的专业数据中心和基层四大业务单元的建设。使得各业务单元能够在专业的数 据中心上,用统一的数据编码、统一的数据格式实现业务联动和数据共享,能够为 D公司领导层提供决策辅助支持和数据依据,为企业管理提供有效的支撑⑵。由于 D公司的“智慧工程”项目是按照“总体设计、分步实施”的,每一阶段的小项目 是否能够保质保量按时地完成,是整个项目成功的关键。本研究就是基于D公司 “智慧工程”信息系统建设项目而进行的。
传统的信息系统项目通常会遵循既定流程进行开发,大部分采用瀑布模型来 实施,通常要经过项目的启动、项目的规划、项目的执行、项目的监控和项目的收尾 五大过程【%需要进行系统需求调研与分析、系统设计、系统开发、系统测试和系统 集成等环节。整个流程就像瀑布一样,从上自下,相互衔接,逐级实施。因为每个 环节是相互衔接的,如果某一环节岀了问题,将会影响下一环节的实施,从而影响 到整个信息系统项目的推进。另外,由于水电工程建设与天气、水流、地质等情况 有关,水电工程在现场的建设管理中的动态性和不确定性因素较多,水电站建设管 理者们对系统的需求会随时发生变化,使得D公司的信息系统项目比其他行业的 信息系统项目会更经常地发生需求变更。因此,要求此类信息系统的研发工作必须 很好地适应需求发生的变化,并且还要有很强的工期约束,以免影响水电站实际工 程的建设。在这种情况下,进度管理控制的作用必不可少,亟需有一种好方法,来 解决D公司的信息系统建设管理的问题。
1.1.2研究意义
传统的信息系统项目管理方法强调过程管控,不喜欢在项目的推进过程中产 生过多的需求变更,因为需求变更会增强研发人员的工作量甚至会导致项目返工, 也会对项目进度、成本带来很大影响,增加项目失败的可能。敏捷开发模型因为有 着“适应变化、阶段交付”的特点,近年来成为信息系统建设项目管理的主流方法 之一⑷。这是一种被称为“轻量级”的信息系统研发方法,强调迭代,强调团队合 作和沟通,倡导用户或需求者加入研发工作。整个团队聚焦于短时间内的冲刺或迭 代开发,随时随地响应变化,推进项目实施。敏捷模型经过不断的实践,证明了对 于提高信息系统研发团队的工作效率、及时响应使用者的需求是行之有效的。
从应用的角度,本文的研究意义在于:针对D公司当前信息系统建设中存在 的问题,探索适合D公司进行信息系统建设管理的模型,使得研发人员在系统建 设过程中的需求分析更完善、开发过程更顺畅,更能适应快速的需求变化,为D公 司后续项目的实施提供一些借鉴。从理论的角度,本文将以“敏捷思想”为切入点, 探索利用敏捷模型加上原型元素优化瀑布模式下的信息系统研发方式,并验证该 方式在D公司信息系统建设过程中的实施情况,检验是否有效。因此,无论在实 际应用还是在理论研究方面,对于是否能改进当前的水电行业信息系统建设是一 个值得探索的课题。
1.2国内外研究现状
1.2.1国外研究现状
国外对项目管理的研究历史悠久。最早可以追溯到20世纪30-40年代美国的 曼哈顿工程一一原子弹研发案例「I。后来,项目管理的实施领域逐步扩展到军事、 宇航、电信、信息系统研发等领域。
上个世纪60年代,北大西洋公约组织为了应对“软件危机”,提出了要将信息 系统视为一个项目来管理。70年代,美国国防部对大部分信息系统出现的无法按时 交付等原因进行了研究,结果显示2/3以上都是因为管理不当而造成的。到了 80 年代,国际信息系统行业研究发现,项目进度是影响信息系统研发是否成功的重要 因素,用项目管理的方法可以解决信息系统建设的进度问题【%随着科学技术的不 断发展,一些用来管理信息系统项目建设的新模型不断地涌现,包括传统的瀑布模 型、顺序与迭代相结合的并强调风险管理的螺旋模型、适应需求不断变化的敏捷模 型、就系统最关键部位先打造一个原型框架的原型模型、强调质量管理的能力成熟 度模型等等,这些模型支撑着信息系统研发行业不断发展。
20世纪70年代,Royce提出了最早的信息系统研发模型一一瀑布模型,因为 早期使用信息系统的行业较少,且需求比较固定,在那样的背景下,瀑布模型在很 长的一段时期内被广泛应用。这个模型像瀑布一样,自上而下地逐步推进实施,上 一个环节结束后下一个环节才开始,每一个环节环环相扣,互不交叉、互不干扰, 但又相互衔接。原型模型是一种快速的信息系统研发模型,它先就系统最关键的部 位打造出一个框架,再在客户反馈意见的基础上不断地修改,最终实现系统的研发, 这个框架就叫做“原型”回。增量模型由Mill在20世纪70年代提出,它综合了 “瀑布” + “原型”模型的特点【7〕,推进时将信息系统分解成一系列的增量任务, 在一个周期内完成并实现一部分的系统功能,经客户反馈修改完善后再进入下一 个增量研发周期。它通过分批次实现并提交系统功能,可以避免如果到项目结束才 向客户反馈,那时才发现客户不满意、系统研发结果与客户需求出现了偏差或者是 客户需求产生了变化,就会造成返工。螺旋模型是B.Boelm于1988年提出的同。 它在瀑布模型的基础上进行了改进,通过将项目分解为若干小阶段,每一个阶段都 要进行风险评估,强调项目风险管理。能力成熟度模型CMM诞生于20世纪80 年代,它是美国联邦政府委托信息系统工程研究所SEI提出的一种质量评估形式。 经历了多次迭代、改进和优化,目前应用的是2002年问世的版本一一能力成熟度 集中模型CMMI〔9]。它将评价标准分为5个等级,即:初始级、可重复级、定义级、 量化管理级、优化管理级[1叭它强调质量管理,通过进行级别认定来改进信息系统 的最终品质。它的缺点是过度关注研发过程的文档,在实施过程中不够灵活oCMMI 认定费和运行费较贵,一般的小型公司难以接受[⑴。统一信息系统过程RUP是 Rational公司在1998年提出的,它是一个基于网络、面向对象的信息系统开发方 法论。它以架构为核心,以用户为驱动,基于迭代和增量的一种过程管理方法〔I%
敏捷开发于2001年由17位美国业界有影响力的专家和学者们提出,他们发 表了著名的“敏捷宣言”[⑸。“敏捷宣言”的基本思想是;1.强调人的个体与互动, 而不是功能的实现和测试环境的选择;2.强调完整功能的信息系统产品,而不是纷 繁复杂的文档及说明;3•强调用户的参与和协作,而不是合同文本的内容;4.强调 灵活快速地响应种变化,而不是按部就班地执行计划。目前敏捷开发模式主要有: SCRUM、极限编程(XP)、精益方法、水晶球(Crystal),自适应信息系统开发(ASD) 等方法。SCRUM源于橄榄运动,表示两支球队通过争球重新开始比赛【"J SCRUM 是Jeff Sutherland和Ken Schwaber (敏捷宣言起草人中的两位)于1995年在面 向对象编程、系统、语言及应用工作坊上共同提出的[㈢,适用于需求难以预测的复 杂产品的研发。KenSchwaber于1995年提到SCRUM将系统开发过程定义为一组 活动,这些活动可以将已知的工具和可行的技术与研发团队相结合,能够设计出最 好的构建系统的方法。Moe于2008年提出,可以利用SCRUM要素在小型团队中 提高工作效率的方法,并讨论了这些要素与一个初创SCRUM团队的关系"1。 Martin在2003年从开发原则、模式与实践三方面去设计敏捷信息系统开发,阐述 了如何实践敏捷、如何应用敏捷方法实现对整个敏捷流程的推进[国。Jeff在2005 年提出,使用SCRUM敏捷开发系统是为了快速将新产品推向市场,同一个SCRUM 团队可以使用多个重叠的Sprint来设计高级SCRUM,从而实现高频次的发布版 本,推动高效的互动等【切。SCRUM在实践中由于规则少,实施简单,使得很多实 践者在没有深入学习和实践的情况下,容易回到过去的项目管理模式。Ken于2007 年发表了富有启发性的案例总结,即:《敏捷项目管理的教训一一成功与失败》㈤]。
Mike Cohn在2010年提出,SCRUM敏捷信息系统开发对SCRUM实践过程的细 节提供了较好的实践方式,并有完整的案例,具备一定的指导性囚];并在《用户故 事与敏捷方法》中阐述了用户故事的重要价值,就如何编写好用户故事、实现真正 适合用户、满足客户需求、对客户有价值的功能需求卩习。Rubin于2012年对用户 需求和用户故事、估算与速率、团队结构等方面做了详细的阐述,并对这些方面提 出了具体的实践建议【绚。根据敏捷宣言和SCRUM原则,敏捷团队是一个能够实 现自我管理和跨职能的团队。Gutierrez和Garzas等人在2019年提出自我管理是 敏捷模型的重要原则之一。自我管理可以对员工和组织产生巨大的影响力Bl。
1.2.2国内研究现状
国内的项目管理最早可以追溯到几千年前万里长城的修筑,但那时并未将项 目管理形成一个体系来进行研究。现代项目管理理论由华罗庚先生通过“统筹法” 引入。上世纪60年代,我国在研制第一代战略导弹武器系统时就引入了项目管理 的一些方法。随着1984年项目管理在鲁布革水电站建设的成功应用,项目管理方 法在我国越来越受欢迎。
黎亮、肖庆钊等在2015年指出,项目管理要通过调整任务的工序、工期,做好 计划和管控,合理分配资源,以确保项目按时完成儿 魏永涛在2011年提出,项目 管理者应该根据实际情况综合考虑,将项目的所有任务分解成更易于管理的子任 务单元,以此来界定项目的范围【25]。宋庸在2017年介绍了如何运用项目管理的方 法,用工作分解结构和计划评审技术,确认项目的关键路径,并对工期进行优化a〕。 罗守成在2005年提出,项目延期不能只考虑个别任务的延期时间,要以整体的眼 光考虑各阶段活动对于进度管理的作用,包括紧前工作后续活动和非关键活动的 时间[27]。叶平在2011年提出了以计划评审技术和关键路径法为基础,加强甘特图 的使用,提高项目进度管理的水平〔2叭石慧在2007年运用网络计划的方法,对信 息系统研发项目进行进度规划,构建了进度管理模型。该模型着重对工作量估算、 任务结构分解等方面进行了规定等㈤]。
国内在信息系统研发模型的研究方面相对于国外来说起步较晚。负责信息系 统研发的项目经理应当利用各种行之有效的工具和方法来合理规划、安排、控制信 息系统项目。蒋晓科在2011年针对目前信息系统研发项目中的问题,论述了进度 管理的相关概念,从定义活动开始到进度计划控制等方面阐述了进度管理的过程[沏。 刘阳在2010年研究了如何评估信息系统开发项目的时间,结合信息系统开发项目 的特点和三点估算法,解决在新技术不断更新的情况下,对于项目工期估算要求越 来越高的情况,提高信息系统开发项目周期估算的效率[311。武圆圆在2019年使用 关键路径法,通过改进信息系统项目的研发过程,调配项目资源,将不是关键路径 上的活动移到非关键路径上,缩短关键线路的时间,通过关注活动的浮动时间,压 缩了项目工期,同时注意控制项目变更,防止资源浪费和进度延迟,从而保证项目 的顺利完成卩%
利用“敏捷思想”来开展信息系统的研发工作,国内的研究和应用相对于国外 起步更晚。它是2005年“敏捷宣言”的发布者之一 Martin Fowler访华时,将“敏 捷思想”带入到中国。以后,“敏捷模型”在金融、电信、互联网等行业的信息系 统项目中成功应用,成为我国信息系统建设项目管理的新技术、新工具,更有效地 响应客户的需求,更好地实施了需求变更国]。2013年,中国敏捷软件开发联盟出 版了《敏捷信息系统开发知识体系》,这是我国第一本较为权威的介绍敏捷方法的 书籍[珂。闫帅等人在2013年对“瀑布模型”和“敏捷模型”进行了研究,提出了: 在信息系统开发过程中,要将两种模型的优点进行结合,针对“敏捷模型”对客户 需求响应速度快、研发效率高的优点,将“敏捷模型”融入到“瀑布模型”的实施 过程中,建立完整的、动态灵活的、易于操作的信息系统项目研发管理体系,提出 了具体的操作方法,并通过对实际案例中的检验,证明了其可行性[列。田莉在2018 年第32届中国(天津)IT、网络、信息技术、电子、仪器仪表创新学术会议上指 出,敏捷模型因为对外界变化有强大的适应的能力,得到业界的好评,并指出在使 用过程中不能生搬硬套,要对具体的信息系统项目进行具体的分析,灵活运用,才 能达到更好的管理效果[珂。李文星于2015年在《长城开发MES-HR软件项目进度 管理研究》中,从应用的角度,对科技企业在信息系统项目建设的优化进度管理方 法进行了总结El。颜海剑等人2013年对SCRUM框架在信息系统研发过程的人力 资源调度进行了研究,提出要将合理的资源用在适当的项目里国]。陈国栋等人2019 年在《持续集成系统可视化设计研究》中提出了基于SCRUM框架的信息系统研 发方法的改进和应用,并举例证明改进和应用方法有效〔39]。文俊浩等人2011年提 出了利用SCRUM敏捷框架快速响应计算机信息系统缺陷管理的方法,并就信息 系统研发过程提出了改进措施,设计出基于改进缺陷管理的流程模型和度量方法⑷〕。 夏维力等2017年提出,SCRUM框架对于客户参与信息系统的研发与信息系统是 否能够成功有着密切的关系,其中:有效的交流、有用的感知、趣味的互动是3个 非常关键的因素,它们与系统是否能够成功研发有着正相关的关系⑷]。孙杰成等 2018年利用SCRUM框架对跨境电商平台信息系统项目进行了研发设计〔42]。在敏 捷框架下,用快速灵活的方式对需求进行响应是改进信息系统研发效率的关键环 节。
1.3研究思路与方法
1.3.1研究思路
本论文属于案例型研究。以D公司信息系统建设项目为例,查找D公司信息 系统建设项目存在的问题,通过分析问题,并结合信息系统研发模型和项目管理知 识,为D公司提供在信息系统项目管理改进过程中的解决方案,即利用SCRUM 敏捷模型对瀑布模型进行优化,并在优化过程中加入了原型模型的元素。最后验证 了改进方案在D公司信息系统建设项目中的使用,证明了改进方案的应用效果。
1.3.2研究方法
(1)文献研究法:大量地学习国内外相关文献、专著,搜集、查阅相关企业、 单位关于信息系统建设的资料,运用学习到的相关知识提出改进D公司“智慧工 程”信息系统建设的方法。
(2)问题分析法:通过充分分析D公司在“智慧工程”信息系统建设中存在 的问题,结合项目管理理论知识,提出解决办法并推进实施,最后总结经验。
(3)实证研究法:以实际案例应用分析作为研究手段,阐述了信息系统建设 和改进的过程,为论文的研究提供实证分析。
(4)归纳总结法:一是从相关资料中总结专家学者们的观点,对D公司信息 系统建设存在的问题提出改进项目管理的方法。二是通过实例,验证改进方法在项 目推进实施的应用情况,归纳总结经验和不足,以供以后的工作或其他信息系统建 设借鉴。
(5)问卷调査法:通过使用调查问卷向D公司多名专家对信息系统建设项目 管理存在的问题进行调査研究,找出关键原因,为后续模型设计改进提供依据。
1.3.3论文创新点
本论文用SCRUM敏捷模型融入原型元素对瀑布模型进行优化,并使用了 Project、看板、燃尽图等工具,对基于信息系统研发的项目管理改进方法有着较全 面、较系统的研究和探索,可供后续信息系统的成功建设借鉴。在问题分析时,从 管理的角度,对D公司机制、流程、沟通、计划、管控等方面进行探讨;在优化 流程时,从项目管理的角度阐述了信息系统建设在阶段内进行启动与筹备、阶段内 控制、阶段边界管理、产品交付管理、项目计划、收尾等阶段的优化过程,并从 SCRUM阶段流程入手进行了深入的研究分析,强调了 SCRUM模型在优化信息系 统项目管理中的需求管理、沟通管理、进度管理方面起到的改善作用。论文最后通 过对整体效果进行评价,说明该研究在促进整体项目的推进效果方面也是有效的。 研究还提出了模型使用过程中的注意事项,提醒后续实施人员“别踩坑”。
1.4论文主要内容及框架、研究路线
1.4.1论文主要内容及框架
本论文共有六个章节,其内容主要如下:
(1)绪论。本章节主要阐述了论文的研究背景和研究意义,叙述了国内外研 究机构或研究人员对信息系统项目管理的研究情况,提出了论文的研究思路和研 究方法,搭建了论文框架,拟定了论文撰写的主要内容,指明了研究路线。
(2)相关理论介绍。本章节主要介绍了项目管理、项目进度管理以及项目管 理的过程的概念,介绍了信息系统研发的常见模型,重点介绍了本论文将要使用的 敏捷模型SCRUM框架,并比较优劣势及适用范围。
(3)问题查找与分析。首先通过对D公司的信息系统项目管理现状进行阐述, 初步找到目前D公司信息系统项目管理存在的问题;再使用问卷调查对D公司的 信息系统项目管理中的问题,从机制、流程、沟通、计划、管控等方面进行更细致 的分析,为后续优化信息系统项目管理流程提供支撑。
(4)模型设计及优化。基于第3章发现并分析的问题,提出使用SCRUM框 架优化D公司信息系统项目管理的流程,分阶段进行“冲刺”“迭代”,以解决D 公司信息系统项目管理中存在的问题。
(5)案例实践。通过将第4章优化的模型在D公司使用的实际情况,检验优 化效果,并对效果进行评价。重点针对前期需求管理、进度管理存在问题进行改进 评估,并利用模糊综合评价的方法对系统的整体情况进行评价。最后还提出模型使 用要注意的事项。
 
(6)总结与展望。总结本论文的经验和不足,以及对未来的展望等。
1.4.2研究路线
 
图1-1论文研究路线
第二章相关理论介绍
本章主要针对论文将要使用到的理论进行阐述,如项目管理、项目进度管理、 项目管理过程,主要的信息系统研发模型、SCRUM敏捷模型等。
2.1项目管理
2.1.1项目管理的概念
项目管理是为了完成特定的目标而进行的一系列活动。它需要在不确定的环 境中、在一定的时间范围内、在有限的资源限制下、人员规模受到约束的前提下, 保质保量地完成某项工作的任务,达到事先确定的目标。项目化是当今社会的一种 趋势。它要克服众多不确定性因素的影响,来达到一个确定的工作目标,是一项系 统性的工作,需要有方法、有技巧地开展。
项目管理在各行各业被广泛地应用。当前项目管理主要有两套知识体系,一套 是美国项目管理协会(PMI)开发的PMBOK®项目管理知识体系;还有一套是由 英国商务办公室(OGC)开发的PRINCE2体系⑴。
PMBOK®常用于资源丰富、流程和边界清晰、可控性强的项目。它强调全面 管理、强调用户需求驱动,重要干系人和发起人是决定项目的关键,需要从一开始 就对整个项目作出详细的计划。
PRINCE2是受控环境中的项目管理体系,适用于复杂项目,对于不确定因素 多、技术相对不成熟、资源相对缺乏的项目尤其有效。它由企业价值所驱动,聚焦 于项目管理的战略层面;它以产品为目标,基于过程管理的项目管理准则;它强调 人的因素,将项目管理作为一种结构化的模式分阶段实施;它不需要从一开始就对 整个项目制定详细的计划,只需要对近期将要实施的过程制定详细的计划;它实施 重点管理,对于受控条件下或不确定性因素多的复杂项目具有很高的适用性和实 用性[氏
2.1.2项目进度管理的概念
项目进度是指项目开展的速度,实施整个项目所要花费的时间。进度管理作为 项目管理的三大核心要素之一,也是项目干系人最为关注的内容之一,更是关系到 项目成败的关键因素之一。项目进度管理需要用科学的管理手段,在给定的资源和 时间、成本有限的情况下,面向项目建设的总目标,制定出满足约束条件的项目计 划和阶段划分,制定进度保证措施和重大进度风险评估方法【%并开展阶段性检查, 实现项目的总体推进屮]。在项目实施过程中持续地开展计划、执行、检查、修正等 过程,直到项目结束。
2.1.3项目管理的过程
PMBOK规定了项目管理有5大过程,即启动、计划或设计、执行、监控和收 尾冋。
Prince2规定了项目管理有7大过程(如图2-1所示),描述了项目从准备到收 尾的各阶段,它与PMBOK不同的是,将项目执行阶段分为了 3步,即:阶段内控 制、产品交付管理、阶段边界管理,而项目指导和计划的过程则贯穿了整个项目的 始终⑴。
 
图2-1 Prince2的7大项目管理过程
 
筹备阶段主要解决“这个项目是否值得做”的问题。项目筹备组要准备项目的 概述文件、定义项目方法、制定计划等工作,通过项目管理委员会批准后启动项目。 同时要制定组织架构,成立项目团队。启动阶段主要思考“项目的交付物是什么, 怎样产出交付物,谁来产出交付物”的问题。在启动阶段,要制定一个项目的整体 计划、本阶段的计划和下一阶段的计划,经项目管理委员会同意后实施。Prince2的 计划管理原则是:针对长期只制定一个框架或大概的计划,针对近期则要制定比较 详细的计划。计划管理要不断地循环推进,贯穿于整个项目的始终,因为随着项目 的推进,近期比较详细的计划会逐步实施完毕,而远期的计划会逐步临近需要继续 根据当前状态,对临近的工作计划进行细化,持续进行。计划的关键活动包括计划 本身的制定,各种估算、风险分析、产品定义等,计划还要分析产品研发各阶段的 活动及相互间的逻辑关系等。项目指导是指项目委员会要对整个项目进行指导,对 关键问题进行决策,对项目经理进行授权,对项目实施情况进行全方位掌控。阶段 内控制是指在PRINCE2流程中,提倡分多个阶段执行项目,并且要对各个阶段进 行管控,发现问题及时处理,保证项目在允许的偏差范围内执行。阶段内控制要聚 焦于阶段性的产品交付,对项目持续进行监控,对项目的阶段性产品进行评审,防 止在执行过程中方向和执行结果的偏离,保证风险和问题得到管控,促进阶段目标 顺利实现。产品交付管理又叫交付物管理,包括阶段交付物管理和项目交付物管理。 交付物管理要检验或评审交付物是否达到标准。阶段边界管理是指通过将项目分 成多个阶段,当项目推进到阶段边界时可能继续、可能停止也可以改变⑴。因此, 项目的阶段边界管理要规定每个阶段需要完成的工作,到达阶段边界时要编制下 一个阶段计划,并根据本阶段的工作完成情况更新项目的整体计划、同时进行新的 风险评估和商业论证等工作,还要制定计划外的执行方案,以防止一些可预见的意 外情况发生而影响项目实施。项目收尾是指按照项目约定的标准对项目进行评审。 项目管理不仅要保证项目的产出物能够达到接收标准,又要保证使用者能够正常 使用产出物。收尾过程还要对本项目活动进行评估,提出后续的行动建议。
PRINCE2适用于需求变化多、不确定因素多的项目,它将项目分为了多个阶 段来进行管理,能够更好地提高资源的利用率,更好地对项目进行控制,从而促进 项目有效地执行,保证项目顺利完成。
2.2信息系统项目管理常用模型
信息系统项目管理模型规定了研发过程中执行项目活动的流程和结构框架。 自“软件危机”以来,业界专家们探索出解决信息系统研发的管理方法,固化成一 些模型,常见的有:瀑布模型、原型模型、敏捷模型等等。
2.2.1瀑布模型
温斯顿•罗伊斯于1970年提出“瀑布模型”,它是目前应用最广泛的系统开发 模型[呦。瀑布模型顾名思义,形状像瀑布一样,根据系统开发的特定顺序,自上而 下、相互衔接,各阶段原则上不交叉,这一阶段的结束就是下一阶段的开始。这个模 型下主要由文档驱动,评审工作对文档要求高。目前大部分系统研发都是使用瀑布 模型。其流程如图2-2所示。
 
 
 
2.2.2原型模型
原型模型是指在研发真实的系统之前,通过一些辅助工具就系统的关键部位 快速打造原型(如图2-3)【叫该模型的流程是:收集需求,根据掌握的信息,提 取关键部位并打造这些部位的“原型”系统,再将这个“原型”系统呈现给客户, 通过与客户不断交互,不断修改完善,直到将“原型”成为客户理想中的那个样子。 最终确认了 “原型”后,再在这个“原型”的基础上迭代、叠加,直至完成整个系 统的研发工作。这种方法能够帮助研发人员更快更准确把握客户需求。通常在客户 对系统需求不清晰、不明确的情况下使用。这种方法可以减少瀑布模型下对系统需 求不明确带来的返工风险。
修改精进
 
图2-3原型模型
 
 
2.2.3敏捷模型
“敏捷”的含义是快速。敏捷模型强调对需求变化的快速响应。它将信息系统 的整体研发阶段划分为若干个迭代小周期,在每一个小周期内都有阶段成果交付。 敏捷模型要求在实施过程中建立良好的沟通反馈机制,以便对需求变更作出及时 的处理。分阶段实施系统研发,有利于最大程度地降低项目风险,从而增强对信息 系统研发项目的控制能力[呦。“敏捷模式”有着很多不同的框架和方法。常见的有: SCRUM、精益开发、极限编程(XP)和看板方法等呦。
SCRUM框架是目前应用得最广泛的敏捷方法(如图2-4)。在该模式下将以团 队为单位推进项目的实施。SCRUM框架的核心是冲刺(迭代),它强调:项目团 队要在最短的时间内交付具有最高商业价值的产品,要求客户或需求提出者要参 与到系统研发中,与SCRUM研发人员一起确定需求优先级,按从高到低的顺序 对客户需求实施研发工作,分阶段对系统功能进行冲刺(迭代)交付。SCRUM强 调团队的自组织和跨职能,团队对整个项目的管理负责,有利于提高团队成员开展 工作的积极性和主动性[5铁
SCRUM框架适用于较复杂的系统,通过渐进的、迭代的冲刺研发,实现增量 交付。在SCRUM模式下包含了若干个迭代周期,一个迭代周期称为一个冲刺过程, 每个冲刺过程周期通常是2到4周国]。最长不超过2个月。
 
 
在SCRUM模式下没有太多的过程文档。尤其是对比瀑布模式下的需求分析 与系统设计等较繁琐的文档。它通过用户故事分析需求,并与需求方一起讨论排序 产品需求待办列表的优先级,由高到低对需求待办列表逐一进行研发。需求待办列 表由产品负责人维护,通过与客户、研发团队一起讨论、分析、分解需求而形成, 每个冲刺周期结束后更新需求待办列表,对新的需求进行再整理、再评估、再分解。 在冲刺计划会上,产品负责人将优先级最高的客户需求从需求列表中优先提取出 来,由客户、研发团队一起细化、讨论,相当于集体设计的一个过程,形成一个冲 刺待办列表,再对列表中的任务进行研发。此后的工作日,研发团队每日通过站立 会,对冲刺待办列表中的任务完成情况进行跟踪。在这个冲刺周期结束时,要召开 冲刺(任务)评审会和冲刺〔流程)回顾会。冲刺(任务)评审会对本阶段的冲刺 任务完成情况进行评审,完成任务功能要在评审会上演示,没有完成的任务或达不 到要求的功能退回到产品待办列表,等待下一轮冲刺;冲刺(流程)回顾会对冲刺 〔流程)执行情况进行回顾总结,将做得好的工作固化,改进做得不好的地方压]。
SCRUM框架包括了 3个原则、3个角色、3个工件、5个事件和5个价值 [57]o主要内容通过思维导图整理如图2-5,26
按从高到溜优先麴隧出来用户故事,在Sprint 戕会上強讨论,分析、曲 祸 形的 冲刺待办列表 冲剌待办列表
前3讪礙时扌tel交付产品壇量
产品増量 站UITI的全部蠡义在于提供"完成”増蠹
觀0人员:需求着研友人贸 舉求评审会 对删畫求佣户觴)进搭审 越出:产品畅俵
蹴牺从翻矽翫务,弼负!!人竹计工作 颤人员需求着研发人员
spring^ @ 划岀:爛待办列表
每日站会 齡Spri曲魁泪趣情况,安摒当日工作, 轨人员:(需求樹、研发人员
绷人屁胡豫槪人员
5pmt评审会 繼射榊娥燈嫌定的目碰翩况. 翰岀:产錨貝
总翳附神伽幽怖就侧馮
沏nt回雜 续工作, 额人员(耕劃'研发人员
SCRUM
 
图2-6 SCRUM框架的3个原则、3个角色、3个工件、5个事件和5个价值(2)
2.3模型适用总结
本论文论述的主要模型特点及适用范围见表2-1。
表2-1模型特点及适用范围总结
模型 优势 劣势 适用范围
瀑布模型 模型成熟,流程明确,注重每 一个环节的质量,强调各个环 节的交付物管理,有利于项目 的组织和管理。 流程管控严,过程文 档多,发生变更时需 重头再来,变更成本 高。 适用于需求明确的 项目,成本固定, 工期长的中大型项 目。
原型模型 适应需求变化; 研发成本低。 不利于创新。 适用于需求不明确 的项目,研发人员 需要对系统及系统 涉及的业务熟悉, 对原型设计的软 件、工具熟悉。
敏捷模型 按业务优先级从高到低的顺序 进行开发,核心是迭代(冲 刺),能够让用户快速看到一 版可用的关键功能。强调与用 户实时沟通,能够较早得到最 终用户的反馈,逐步完善,接 近最终目标,对需求有较好的 适应性。 注重沟通,忽略文档 质量,对开发人员素 质要求比较高。如果 人员发生流失对项目 组冲击较大。 适用于需求不明 确、变化快、变化 多的项目。
 
 
根据以上分析,从系统项目管理模型的演变情况来看,信息系统从最早的“引 导”式、“计划”式和“预测”式,由研发机构或人员作为主导的研发,发展到现 在的“反馈”式和“适应”式,由客户或需求者作为主导的研发。一个信息系统项 目的研发方式采用哪种方法,主要根据实际情况来定。对于不确定性强的信息系统, 可用敏捷法、原型法进行研发;对于确定性强的信息系统,则可以使用瀑布法进行 研发。选择开发模式的方法如图2-7测。
 
研发机构或人员引导式
研发计划式
研发预测式
图2-7选择开发模式方法[“]
2.4本章小结
本章对使用到的理论进行了阐述,对要使用的信息系统研发模型进行了介绍, 并总结了各模型的适用范围。最后对选择研发模型的方法进行了说明。
第三章D公司信息系统项目管理问题分析
3.1D公司概况
D公司是四川省一家大型的水电开发公司,主要负责D流域的梯级电站开发、 管理和运营,位列四川省工业企业规模50强和经济效益10强[斶。由于所辖的电 站众多,电站建成时间长短不一、电站形式复杂、水库大,并且大都处于大山深处、 高山峡谷之间,河流沿岸容易产生滑坡、泥石流等自然灾害,现场工作给工作人员 的生命带来威胁。在电站的运营管理过程中,还要考虑汛期多库联调保证洪峰安全 度过,也要考虑洪水过后水流调整,保证下游供水等等。该公司希望从更加科学、 更加人性的角度,优化工作方式和流程,提升管理水平囚。
该公司在业界率先提出了 “智慧企业”建设,开展了《智慧D公司战略研究 与总体规划报告》和《智慧工程建设总体规划报告》顶层设计,站在企业管理的高 度和流域水电站项目管理的角度,将信息技术、工业技术和管理技术进行融合,先 后经历了先期探索、试点建设和全面实践三个阶段,建成了较为完备的“智慧工程” 信息系统框架。该公司的“智慧企业”构想是将整个企业看作是一个"智慧人”, 决策指挥中心作为“系统的头部”,是信息系统的“决策脑”;专业数据中心作为“系 统的器官”,是该信息系统的“专业脑”;22个基层单位作为“系统的四肢”,按照 业务功能分为:“智慧电厂"、“智慧检修”、“智慧调度”和“智慧工程” 4个业务 单元,是信息系统的“单元脑”⑵。
本论文就是基于D公司“智慧企业”业务单元之一一一“智慧工程”在实施 过程中遇到的项目管理问题进行研究,探索用新的方式来解决。
3.2D公司“智慧工程”信息系统项目情况
自2016年起,D公司“智慧工程”就开始在各项目分公司、子公司试点实施, 截至目前共开展了 12个信息系统项目建设,已完成7个,5个在建,为该分公司 水电工程实现智慧管理起到了一定的作用。
3.2.1D公司信息系统建设项目组织架构
D公司成立了“智慧工程”信息系统项目推进小组,这是一个跨部门的职能型 组织架构(如图3-1)0该职能架构下,“智慧工程”牵头单位在工程建设部,但系 统研发职责在产品研发部,相关数据资料又在数据部,信息系统项目的实施需要沟 通多个部门。
 
图3-1 D公司“智慧工程”信息系统项目组织架构
 
在这样的组织架构下,每个部门都处于组织架构的同一级,负责“智慧工程” 信息系统建设的项目经理职位没有各部门领导的职位高,如果出现需要决策等情 况,项目经理不完全具备决定权,会比较被动,需要协调上级领导出面沟通,会造 成项目推进缓慢。
3.2.2D公司信息系统建设项目实施流程
D公司信息系统建设采用的是瀑布模式。当项目启动后,开始进行需求调研与 分析,形成需求分析文档;再根据需求分析文档进行系统设计,梳理业务流程图, 建立规范;随后进行开发;通过系统集成,测试完成后上线。如果出现问题,就会 倒回需要改进的环节返工。基于瀑布模型开展的研发工作,测试工作通过在主要功 能完成后进行。一旦发生了需求变更或者测试不通过等情况,将会对整个系统的推 进造成影响,尤其在进度方面较为严重。具体流程如图3-2所示。
大量的实践表明,瀑布模型对于需求工期稳定、变更少的信息系统建设可以很 好地完成。但对于需求模糊、需求变更多、工期紧的项目就较为吃力。D公司“智 慧工程”信息系统是基于流域水电站建设而建的,其需求也依附于水电工程建设。 由于水电站的工程投资大、建设周期长,水电站的信息系统处理数据和信息管理工 作量大,管理逻辑复杂。瀑布模型下模型的各个环节都是必须的,而且是瀑布式的 流程逐步推进。需求分析和需求调研阶段,如果需求者对系统功能产生了新的想法, 提出新增需求或进行了需求变更后,研发人员重新进行需求分析;设计阶段,由于 需求分析产生了变化,要进行重新设计;开发阶段,如果新的需求或者原先研发的 系统功能不能满足使用者的需要,需要重新开发新功能或者要对己有的功能进行 改造;测试阶段,一旦系统功能发生了新的变化,又要重新开展测试;部署阶段, 
系统变更就要重新发布实施。瀑布模式过多地强调过程文档,特别在需求分析和系 统设计环节,这些文档要作为后续实施的基础,如果需求变更是发生在系统设计完
 
 
所以,基于瀑布模式下的研发流程,对于新需求多或需求频繁变更的项目应对 能力较弱,返工情况较多,将会大大影响项目的研发进度。
3.3 D公司“智慧工程”信息系统项目管理存在的问题
3.3.1D公司“智慧工程”信息系统项目管理现状
D公司从以下维度来管理信息系统项目:
(1)组织方面。D公司“智慧工程”信息系统项目建设小组属于职能型组织 架构,对于跨部门的协调沟通成本相对较高。
(2)流程方面。D公司目前采用的是瀑布模式来进行信息系统研发,该流程 按照需求调研和分析、系统设计、开发、集成、测试、部署等步骤来进行,如果在 某一个环节出现进度滞后或者有返工的情况,将会影响下一个环节的实施,进而会 影响整个项目的进度。如果要进行需求变更,则由双方项目经理结合当前的项目进 展情况以及对后续系统推进情况可能造成的影响,评估后决定是否进行变更,大多 数情况下对需求变更的响应结果不好。
(3)沟通方面。项目经理每周组织一次例会,就项目进展和遇到的问题进行 沟通讨论,提出解决方案。但参加人员主要是需求方和研发单位的主要负责人或研 发人员代表。研发人员参加例会的频次和人数很少。日常沟通的主要方式还有会议、 文档、邮件、电话、微信或QQ等即时通信、面对面等,但主要限于项目经理之间 的沟通,研发人员与需求人员的直接沟通少,主要沟通方式如表3-1所示。
表3-1 D公司信息系统研发人员主要沟通方式
沟通内容 沟通方式
会议 文档 邮件 电话 即时通信 (微信或QQ) 面对面
需求管理
任务分配 V V
方案设计 7 7 7 7 V
技术交流 7 7 V 7
需求变更 V
系统测试 V V
用户体验 7 7
(4) 计划方面。中标单位进场后,双方的项目经理根据经验和之前信息系统 建设项目的时间,以及水电工程建设的项目开展情况对每个阶段的工作进行分配 安排。信息系统建设与相应的工程施工总体进度相适应并适当超前,以确保为水电 工程建设提供信息化技术支持。
(5) 进度管控方面。前期D公司围绕“智慧工程”建设的12个信息系统项 目有7个完成了建设任务,但都存在着不同程度的延期,在建的5个项目在进度 方面推进得也不理想。
因此,D公司在信息系统项目进度管理方面需要改进。
3.3.2D公司“智慧工程”信息系统项目管理存在的问题及分析
前期D公司围绕“智慧工程”建设的12个信息系统中,有7个已完成但都存 在项目延期的问题,为了保证剩余项目或者后续项目更好地实施,D公司需要改进 信息系统项目管理方法。
要改进、优化D公司在信息系统建设过程中的项目管理方法,首先要找到其 在信息系统建设过程中产生问题的根本原因。本研究基于系统化的思考,既要查找 问题的表象,又要深入分析表象背后的根源,并提出相应的解决方案,为后期的问 题防治提供对策。
3.3.2.1直观地查找问题——问卷调查
因为问卷调查比较直接,本研究前期已找到D公司“智慧工程”信息系统项 目管理中进度延期的情况较严重。因此,问卷调査直接针对D公司前期建设的信 息系统进度延期问题进行调查,调查结果显示,主要原因有(排名前3的问题,后 3个并列第3):需求变更过多、需求分析不到位、方案设计有问题、沟通不畅、人 员配置等方面存在着问题。被调研者认为对信息系统项目进度影响最大的是需求, 排名前2位的均与需求相关,需求变更和需求分析所占的比例分别为75%、68.75%。 具体见图3-3。
 
 
结合前期的研究及调研结果,需求变更、需求分析、方案设计都是与需求不明 确、需求变更多有关的,均为需求响应方面的问题,应从研发流程的角度考虑改进; 而人员配置与组织架构和组织职能有关,将它归纳到机制问题上;沟通问题又与交 流平台有关,需要有更好的交流平台,让研发人员之间、研发人员与需求人员之间 有更多的交流机会。
3.322深入分析问题原因 系统思考
系统思考的精髓在于“从整体出发、全局看问题,注重各要素的关系”〔59•叭 针对D公司在研发流程、机制方面、沟通方面存在的问题,研究从机制、流程、 沟通、计划、管控等5个方面来分析D公司信息系统建设项目的管理问题。
(1)机制方面:D公司跨部门、职能化的组织架构,项目成员如果出现意见 分歧的情况,需要协调上一级领导出面协调沟通,如果遇到领导不在等情况,会影 响项目顺利实施,需要优化组织架构。
(2)流程方面:参与水电站工程建设的单位多,不同单位不同管理层级提出 需求多;水电站工程建设受水流、天气、地质等因素的影响多,不确定性因素多, 为其建设的信息系统不确定性因素也多,并且可借鉴的水电工程信息系统较少,前 期需求方对系统功能需求不明确、不清晰;同时,由于水电站工程建设周期长,在 长周期内会出现新的技术和新的方法,也会导致变更需求频繁。瀑布模型适用于流 程清晰、需求确定的信息系统研发,而不适用于需求变更多的信息系统。因为瀑布 模型对项目实施的各个阶段有着严格的划分[5】,一个阶段的产出会影响下一个阶段 的实施,在这种模式下,对需求变更的响应速度较慢,或者响应需求变更使用的资 源较多,甚至是要重新开展一次之前进行的流程。瀑布模式下,如果能够越早纠正 研发需求偏离度、或者越早提出需求变更,后期所花的代价就会越小;如果是在项 目尾声发生了需求变更,付出的代价就会越大⑹]。在瀑布模式下,系统研发的近三 分之一的工作基本是围绕需求调研与分析进行,而系统设计是非常重要的一环,涉 及到系统框架、数据库、系统功能的详细设计,大量的工作集中在前2个环节,瀑 布模式下强调需求调研的重要性,并且对于需求分析报告的要求很高,如果发生了 需求变更,将会严重消耗资源⑸。如果要响应需求,就会过多地将时间和精力花在 项目研发前期的文档撰写上,对于系统开发阶段的实施并不能起到积极的作用,相 反会形成制约。但如果不响应需求,也会影响后期的工作,让项目推进陷入两难的 境地。因为D公司是项目的业主单位,其信息系统是为了支撑水电工程建设项目 的,自己提出的需求无法响应,就难以支撑在建的水电工程项目,对整个公司的影 响是巨大的。
(3)沟通方面:D公司信息系统研发团队建立了日常的沟通方式,但研发人 员只与项目经理或工作相近的人员进行沟通,与需求人员、其他人员的沟通较少。 同时研发团队分工较细,研发人员基于各自的分工开展工作较多,如:研发人员负 责代码、数据人员负责数据、测试人员负责测试等,聚焦于整个项目的实施与推进 主要是项目经理,研发人员关注整体情况开展得较少,在一定程度上对于整个项目 的推进有影响的。项目团队在虽然每周固定召开会议,就项目进展情况、存在的问 题等进行沟通,但沟通对问题的讨论会陷入到问题的细枝末节,既没有解决问题, 又浪费了时间。同时,由于参加会议的人员范围较小,大多数是需求方和研发团队 代表参加,系统研发人员基本与需求提出者不见面,不沟通,在某些情况下,沟通 的匮乏使得彼此之间对需求的理解会产生偏差,造成后期的系统功能不能满足使 用者的需求。而系统的最终使用者,也是在系统上线后才知道系统功能是否能满足 需求。没有一个积极的有效的沟通机制,导致团队成员间信息闭塞,沟通迟缓或滞
后,严重影响了项目进度。系统研发是一项系统工程,成员之间存在较强的耦合关 系,需要多沟通才能保证顺利实施。
(4) 计划方面:项目经理在进行计划的编制时,大部分是靠个人的经验来进 行的。通常是按阶段将项目粗略地分为几个阶段,一个阶段的时间较长,任务的颗 粒度太大,有的甚至会超过60天,研发人员容易产生疲劳感。如果按照这样的计 划进行项目实施,一旦出现问题,项目经理如果在中途对项目管控没那么尽心的话, 会造成这一个阶段的项目进度失控。
(5) 管控方面:项目启动后,项目经理分配完每个开发人员各自的开发任务 并定时进行任务追踪,了解整体项目的进展。但对于团队的人员只对自己的那一块 领域负责,对整个项目的工作进展不了解甚至不关心。这样的机制下没有发挥团队 的积极性主动性,不利于项目的整体推进。如果项目经理在项目任务的追踪上力度 较弱,会造成项目在一定程度上失控,尤其是进度方面。因为信息系统的项目质量 是可以牺牲进度来保证的,项目成本可以与研发人员开发系统的质量进行挂钩。虽 然研发人员会以周报的形式对系统研发进度进行汇报,项目经理也会以会议的形 式对研发进度进行监控,但是周报和例会的监控没有固化为相应的流程,受人员的 主观意识影响较大,如果项目经理或研发人员对周报或例会不够重视或消极对待, 很难达到监控的效果。
从以上几分面的分析可以看出,D公司信息系统项目没有得到有效的推进,需 要采用科学的管理方法来进行改进。
3.3.3选择敏捷模型解决D公司信息系统建设项目管理问题的思考
根据以上分析,本研究运用SCRUM敏捷模型来优化D公司信息系统项目管 理流程,探索解决D公司在信息系统建设项目管理中遇到的进度管理问题。
3.3.3.1从解决机制问题的角度
SCRUM敏捷模式下强调自组织和跨职能。自组织是指SCRUM团队能够不受 外部的影响自己决定完成工作的方式。团队可以和外部人员交流探讨,但最终决策 权在团队。跨职能是指研发人员拥有完成研发工作所需要的全部技能⑶〕。它强调 整体是保持敏捷的最佳条件。这种机制的组织架构下,能够在一定程度上解决信息 系统中的跨部门协调和人员配置的问题。
3.3.3.2从解决流程问题的角度
SCRUM模式下最主要的流程过程就是冲刺(如图3-4),它把整个项目分成若 干阶段进行实施,周期都很短,通常控制在2个月以内。
Sprint 未结束
 
图3-4 SCRUM模式下冲刺流程图
 
它用简单的用户故事模版来收集需求,用5种类型的会议来解决需求的问题。 用户故事用来解决“需求者想要什么”的问题,产品待办列表用来解决“我们要研 发什么”的问题,冲刺待办列表用来解决“这个〔Sprint)阶段我们要重点突破什 么”的问题,产品增量用来解决“近期研发的内容是不是达到标准”的问题。需求 评审会,是研发人员与需求者沟通的纽带,进一步深化对需求的理解;Sprint计划 会是对需求的再次确认和理解,对本阶段需求任务的实施任务进行安排;每日站会 是对前一天的工作任务进行监控,对当天任务的强调;Sprint评审会是对近期研发 任务的检验;Sprint回顾会是对本阶段的流程执行情况进行检视和固化。从流程的 角度上讲,SCRUM流程相当于是对当前冲刺流程的一个PDCA循环检验,并且在 实施过程中通过会议可以解决沟通问题;Sprint计划会相当于是对该冲刺阶段任务 的细化、安排,冲刺待办列表相应于是本冲刺阶段的一个计划表;通过用户故事的 编写、收集、分解等,可以解决需求响应的问题。
3.3.3.3从解决沟通问题的角度
SCRUM模式搭建了几个沟通平台,即需求评审会、Sprint冲刺计划会、每日 站立会、Sprint冲刺评审会和Sprint冲刺回顾会。需求评审会是对收集的需求进行 评审的环节,与需求有关的干系人、研发人员都要参加;Sprint冲刺计划会是对通 过评审的需要在近期(这一个Sprint冲刺阶段)完成的任务进行细化、分解、实施 安排,类似于集体设计的环节,与需求有关的干系人、研发人员都要参加;每日站 立会是对前一天的工作进行总结、对当天的工作进行安排的环节,SCRUM成员都 要参加;Sprint冲刺评审会是对这一个Sprint冲刺阶段实施的任务、对本阶段需求 完成情况进行检验的环节,与需求有关的干系人、研发人员都要参加;与Sprint冲 刺回顾会是对本阶段SCRUM流程执行情况进行检验的环节,SCRUM团队成员都 要参加。这些会议中,需求评审会、Sprint冲刺计划会、Sprint冲刺评审会解决了 研发人员与需求者的沟通问题、需求调研和分析的问题,确保研发人员的需求理解 近乎接近需求者的实际需求;Sprint冲製计划会通过讲解实施方案、细化分解用户 故事等环节,类似于集体设计的方式解决了设计方案的问题;Sprint冲刺评审会由 产品负责人与需求方对阶段成果进行评审,相当于交付物的阶段验收环节,解决了 交付物阶段验收的问题。从沟通的角度上讲,这些会议形式不仅仅为了解决干系人 与研发人员的沟通问题,而且通过沟通还解决了信息系统设计中需求调研和分析、 方案设计、执行、检收等环节存在的问题,强化了过程管控。
3.3.3.4从解决计划问题的角度
在SCRUM模式下,信息系统建设的整体工作的计划通过“产品待办列表”体 现;阶段计划由Sprint冲刺计划会制定,在“冲刺待办列表”体现;阶段完成的工 作任务通过评审后在“产品增量”里体现;每日计划在每日站立会上制定,每日站 立会还是前一日计划实施情况的一个检视环节。对计划执行的监控检验还有Sprint 冲刺评审会和回顾会,对这一阶段完成的工作任务和流程执行情况进行总结、检验。 从解决计划方面问题的角度,SCRUM模式对计划的实施有过程管控和结果管控, 能够在保证阶段过程和结果的情况下促进整个项目顺利的完成。
3.3.3.5从解决管控问题的角度
敏捷开发的过程实际上是快速迭代的过程,保证敏捷模式下够快速地适应需 求或环境发生变化,通过分阶段冲刺来完成顼目各环节的掌控。如前所述,SCRUM 的3个工件、5个会议都是对项目进行管控的好方法,本项目还引进了 Project、看 板、燃尽图等工具辅助管理,能够对项目进行很好的管控。
3.4本章小结
本章介绍了 D公司及其“智慧工程”信息系统项目建设概况,通过问卷调查直 观地査找D公司信息系统项目存在的问题,并深入分析问题存在的原因,指出D 公司在机制、流程、沟通、计划、管控等方面存在问题,提出了使用敏捷模型来解 决信息系统建设项目管理存在的问题的考虑。
第四章构建适用于D公司“智慧工程”信息系统项目管理模型
自敏捷宣言发表以来,敏捷模型以其灵活的需求响应方式给客户和研发单位 带来的效益,得到了业界的认可。行业研究报告显示,美国等一些发达国家的系统 研发行业的敏捷模型使用率以每年超过50%的速度递增,谷歌、IBM、微软等著名 企业通过敏捷模型改善信息系统的研发管理,既提高了生产率,又增强了企业竞争 力[73]。据Standlish Group统计报告指出,使用敏捷模型研发信息系统比瀑布模型 的成功率要高3倍以上,而进度超时、成本超支的情况要少得多[%
因此,针对D公司当前信息系统项目管理过程中面临的状况和问题,将使用 SCRUM敏捷模型对传统的瀑布模型进行改进,并融入“原型模型”元素,对D公 司信息系统建设项目的整体流程进行优化。
4.1整体优化
使用敏捷模型对D公司的信息系统建设流程进行改进,并不是对传统的瀑布 模型进行抛弃或颠覆,而是引入SCRUM敏捷管理的思想,针对D公司信息系统 研发中存在的问题,进行优化,以更好地满足实际项目和工作的需要,增强系统的 实用性。基于之前分析的D公司“智慧工程”信息系统建设项目存在的问题,对 应将要用到的SCRUM、瀑布、原型模型的优势进行分析,并论述3种模型在实践 中的作用,具体内容见表4-1。
表4-1 D公司信息系统建设流程优化分析
机制方面 的问题 流程方面 的问题 沟通方面 的问题 计划方面的问题 管控方面的问题
D公司“智慧 工程”信息系 统建设项目存 在的问题 职能型组 织,跨部 门协调沟 通成本 高。 D公司参 建单位 多,对系 统的需求 多。纯瀑 布模式 下,对需 求的响应 速度慢。 研发人员 与需求人 员直接沟 通少,对 需求的理 解存在偏 差,对需 求的响应 速度慢。 凭经验制定计划, 计划颗粒度大。由 于对水电站建设进 行管控的信息系统 可借鉴的少,需求 不明确的情况多, 多数情况需要“摸 着石头过河”。 项目成员各施其 责,对整体项目 的掌握情况少。
项目管控受项目 经理主观因素的 影响多,管控力 度弱。前期建设 的系统都存在进 度管理的问题。
 
续表4-1 D公司信息系统建设流程优化分析
机制方面 的问题 流程方面 的问题 沟通方面 的问题 计划方面的问题 管控方面的问题
各 模 型 对 应 问 题 所 起 的 作 用 SCRUM SCRUM 项目团 队,有自 组织和跨 职能的作 用。 SCRUM 冲刺流 程,分阶 段实施。
使用“用 户故事” 收集需 求,用2 种待办列 表管理需 求。 用5种会 议(每日 站会、冲 刺计划 会、冲刺 评审会、 冲刺回顾 会、需求 评审会) 来解决沟 通问题。 冲刺计划会对本冲 刺阶段进行规划, 进行“始边界”控制。 每日站会按天对 项目进行跟踪, 进行“冲刺”阶段 内控制;冲刺评 审会、回顾会对 本冲刺阶段的项 目实施情况进行 跟踪管控,进行 “末边界”控制。
瀑布模型 设计、开 发、集成、 测试的过 程不可 少。 通过“里程碑”来划 分各冲刺阶段。
原型模型 “仿真式” 需求呈 现。 与需求者 沟通更直 观、更高 效。
基于以上分析,D公司将SCRUM敏捷模型与Prince2的7大管理过程相结 合,并加入了原型开发的元素,对于一些创新性的新功能、则用“原型”模型进行 仿真式的模拟呈现,让使用者能够更好地感知系统功能,优化后的流程如图4-1所 示。该流程将整个信息系统以里程碑为分界点分为各小段,每一小段为一个 SCRUM冲刺(迭代)周期,在Splint流程里,各阶段按Prince2流程分为项目阶 段实施、项目阶段边券管理、产品交付物管理,项目计划和项目指导贯穿于整个项 目的实施环节。每一个冲刺周期按一次小的瀑布模式来实施,每一次实施都会产出 一个阶段性成果,其间可能会用到原型模型元素来对不清晰、不明确的需求进行 “仿真”设计。项目借鉴了三峡公司的TGPMS系统来向需求者展示,需求者再反 馈意见再修改再完善再精进,直到需求者认为达到了他的要求。然后再在这个原型 的基础上,对系统的其他功能进行研发、迭代、叠加,直到完成这一个阶段的功能 任务研发。最后通过阶段任务评审和回顾,对产品交付物进行初步验收和评审,实 现对这一阶段任务的闭环管理。然后又进行下一个里程碑的冲刺(迭代)。
 
优化后的流程用“用户故事”来代替需求分析,用需求评审会、Sprint计划会 进行集体的分析、评审来代替纷繁的设计文档;通过评审后的需求则整理为产品待 办列表,用产品待办列表来代替冗长的需求分析报告,将时间和精力节省到系统研 发上。每一个冲刺(迭代)结束,就会召开一次评审会和回顾会,以评审这一阶段 产出的功能是否达到要求,回顾这一阶段的经验教训,为下一阶段更好地实施打好 基础。
原型设计、反馈、精进
 
 
项目计划
项目指导
图4-1用SCRUM模型融入原型元素优化瀑布模型的流程即1]
4.2具体实施说明
4.2.1完善管理机制——启动阶段
成立敏捷团队便启动了 SCRUM,随后在工作中不断营造“敏捷”氛围。
SCRUM敏捷团队是一个跨职能的团队,团队主要有三类角色,能够实现独立 产品增量的研发及发布。通常情况下,SCRUM中的角色有产品负责人、研发人员、 SCRUM主管。在本项目中,由于D公司初次实施敏捷开发,暂时无人能胜任 SCRUM主管,所以外聘了一名SCRUM敏捷教练推进敏捷流程的实施。D公司是 需求方,所以指派了一名项目经理来负责该项目的整体工作,他相当于是一部分的 产品负责人。研发单位的项目经理对研发人员比较熟悉,在担任SCRUM实施过 程中承担着更多SCRUM推进功能的产品负责人。由于敏捷开发强调任务的反复 迭代 加上本信息系统项目建设涉及了数据中心、项目公司数据等,技术及功能较 为复杂,共有10名系统研发人员。其中1名流程管理员、2名需求收集分析人员、 1名架构设计、4名研发、2名测试。
(1) 产品负责人:是项目组与其他干系人沟通的桥梁,主要负责与需求方沟 通,协调需求方与研发团队在产品方面的理解、认知差距,以达成研发共识。他要 熟悉系统功能、流程,能够对需求和优先级的评估起到指导性的作用,能够对于每 次系统功能的发布时间和内容进行决策与拍板。在每次Sprint冲刺(迭代)会议 中,引导项目团队设定Sprint目标,完成冲刺待办列表中本次需求任务的分解、故 事点数评估、排列优先级等。在执行Sprint冲刺(迭代)时,通过每日站立会了解 项目进展情况并对团队工作进行安排、协调,以掌握整体项目的进度。一名优秀的 产品负责人特质是:一直都在、沟通专家、准确分析、正确判断、业务专家。
(2) 研发团队:本项目中的研发团队包括流程管理员、需求收集分析人员、 架构设计师、研发人员、测试人员等,组成了一个跨职能式的组织,负责在规定的 时限内完成系统的建设。
〔3) SCRUM教练:负责指导项目团队正确实施SCRUM。他要有丰富的敏捷 技术理论知识和实战经验。在本项目中是外聘专家,还担任着SCRUM主管的职 能。负责调动项目团队的积极性,指导、培训项目团队在SCRUM框架下开展研 发,及时解决发现的问题,从SCRUM流程上起到控制风险的作用。他要指导团队 进行计划Sprint、执行Sprint、总结并回顾Sprint。Sprint回顾会由SCRUM教练组 织,除了总结本阶段Sprint阶段的Sprint流程执行情况以外,还要根据这一阶段的 实施情况对下一阶段Sprint进行调整优化。
SCRUM项目团队角色的主要职责简要归纳如表4-2。
表4-2 SCRUM项目团队角色职责
角色 主要项目职责
1FJL 需求 管理 预算 管理 险理 风管 团队 激励 消除 外界 干扰 协调 解决 问题 目量 项增 S
产品负 责人 O O O O 0 0 O
研发团 队 0 0 O O O
SCRUM
教练 0 O 0 O
说明 主要职责O,次要职责0
4.2.2优化流程管理
SCRUM敏捷模型适用于需求变更多、工期要求高、沟通内容多的项目,具体 流程具体如图4-2。
 
图4-2 SCRUM实施流程讯54,55]
 
在SCRUM框架下,需求分析用“用户故事”来代替,再将收集到的“用户故 事”整理为产品待办列表,通过需求评审会对需求进行评审、分析、分解、评估、 评定优先级等,提出将优先级最高的产品待办列表中的任务提交给Sprint计划会 评审。在Sprint计划会上,研发人员对需求进行反讲,需求人员对相关内容可以提 出疑问或补充,研发人员进行补充说明,让“用户故事”更加细化,使之更容易理 解更容易实施,并为其工作量、优先级赋予评估值,并估算工作时间,指定负责人 负责研发。最终形成冲刺待办列表,作为这一阶段的Sprint任务,同时启动本次 Sprinto从次日起,项目团队通过站立会汇报工作进展,提出需要团队解决的问题, 由整体团队协助、协调解决。到本次Sprint末期,项目团队要进行Sprint评审和回 顾,评审本Sprint阶段的任务完成情况,总结存在的问题,如果存在没有完成的任 务,将退回到产品待办列表,等待进行下一轮的Sprinto Sprint回顾是对本阶段实 行SCRUM框架情况进行总结。然后又进行下一个周期的Sprinto
需要说明的是,研发过程中,由于需求者对系统需求的不明确、不清晰,导致 研发人员在系统研发中处于摸石头过河的状态,后来通过融入了“原型”模型的元 素,将系统的主体框架或主要功能通过“原型”实现需求可视化,即用一个诸如仿 真设计的原型设计工具先将框架或主要功能通过这个软件进行模拟开发(本项目 借鉴了三峡公司的TGPMS系统进行功能展示),让需求者能够感知这个需求的模 拟功能,在需求可视的基础上与需求者不断沟通,便于双方交流,并根据反馈意见 不断完善,直至使用者满意。最后再在这个可视化的功能需求上进行具体的研发。
4.2.3深化沟通及指导
强调沟通是SCRUM模式的特点之一。除了常规的沟通以外,SCRUM模式下 的主要沟通方式有:冲刺(迭代)计划会、每日站立会、冲刺(迭代)评审会和冲 刺(迭代)回顾会[罔。本项目的实施过程中还增加了需求评审会。各种会议除了有 沟通的作用,敏捷教练、项目经理甚至是外聘专家、D公司领导都会对整个项目进 行指导。
4.2.3.1 Sprint 计划会
规划本阶段的冲刺目标、任务。即确定本Sprint阶段的交付增量有哪些,怎样 完成。
Sprint规划会议通常在这一个Sprint开始的第一天由产品负责人组织项目团队 成员、与本阶段有关的需求人员召开,对本Sprint阶段要实施的需求进行讨论、分 解。
4.2.3.2每日站立会
每日站立会是SCRUM模式下对冲刺任务进行管控的方法之一。原则上工作 日上班初期由组织项目团队成员召开。团队成员围绕前一天完成的工作、今天将完 成的工作、工作中遇到的问题、困难、阻碍等进行沟通和讨论,通过看板、燃尽图 了解项目和各成员的工作开展情况。敏捷教练对团队执行SCRUM情况进行点评、 分析和指导。为提高会议效率,原则上会议时间为15分钟。有的项目团队是站着 召开这类会议,所以叫站立会,本项目也叫每日例会。
4.2.3.3 Sprint 评审会
Sprint评审会主要是对本阶段的输出内容进行评审。通常Sprint评审会是在本 Sprint阶段的最后一天举行,会议由产品负责人组织开展,由项目团队研发人员和 需求发起人参加,负责对本阶段计划完成的产品增量进行评审。首先由研发人员代 表对本阶段完成的产品增量进行演示,由产品负责人、需求人员进行评审,达到标 准后签字认可。通过后的产品增量列入已完成工作,未完成、未通过的产品增量加 入到当下的产品待办列表中。还要对未完成、未通过的产品增量进行原因分析,以 便在下一次的冲刺中改进和完善。
4.2.3A Sprint 回顾会
Sprint回顾会是对本冲刺阶段SCRUM流程的实施情况进行回顾。主要包括流 程执行情况检视、团队成员关系检视、沟通过程检视、辅助工具检视等内容。会议 由SCRUM敏捷教练组织,SCRUM团队成员一起讨论本冲刺阶段的优点和不足, 分析本次冲刺(迭代)过程中需要改进的行为,帮助和指导SCRUM团队成员找到 SCRUM敏捷方法的要义,更有效地掌握SCRUM敏捷实施的方法,以便在后续的 工作中更好地实施SCRUM框架。
4.2.3.5需求评审会
需求评审会由产品负责人或甲方项目经理组织,由系统研发团队、需求人员参 与。评审先由研发人员对该用户故事提出自己的理解,对拟采用的实现技术、拟实 现的功能等内容进行阐述,需求提出人员对研发人员理解的用户故事进行纠偏或 认可,讨论优先级,列入产品需求列表。整个研发团队对确定后的用户故事进行工 作量评估,分配责任人。
需求评审会相当于Sprint计划前的需求评审和认定。在较为成熟或较为简单 的系统研发中,不需要召开需求评审会。产品经理依靠个人经验对需求进行评审或 在Sprint计划会中同步进行需求评审即可。但在复杂的、新型的、可借鉴较少的系 统研发中,需要对需求进行评审,以更好地掌握需求方的需求并提高Sprint计划会 的效率,甚至可以改善冲刺结果。因为如果对需求理解不深不透,会导致这一个 Sprint阶段的产品增量不能通过评审而出现返工的情况。
在SCRUM模式下,用沟通代替需求文档,增加了研发人员与需求人员的沟 通,减少了需求分析文档和设计文档的撰写时间,避免了对需求理解不到位或有困 惑的地方拍脑袋研发造成返工或研发过度,最大限度地保证研发出的功能与需求 更匹配。
4.2.4细化计划管理
SCRUM框架下的计划管理贯穿于整个实施阶段,包括整个顼目的计划、冲刺 (迭代)计划和每日计划。整体项目计划通过用户故事来收集,整理为需求待办列 表,通过确定项目里程碑,按里程碑分阶段实施。冲刺(迭代)在冲刺(迭代)计 划会上制定,计划任务就是本阶段的冲刺待办列表。冲刺阶段的计划使用Project 软件来制定。每日计划由研发人员根据项目安排和自己的实际情况,自行安排,并 在每日站会上向项目团队汇报,让团队成员监督执行。每日站会还要总结问题,在 这个Sprint阶段内循环执行。冲刺阶段末期,要召开冲刺(迭代)评审会、冲刺(迭 代)回顾会对本阶段的产出物研发情况、冲刺(迭代)工作执行情况进行评审。整 个过程形成闭环。
425强化过程管控
4.2.5.1需求管理
解决D公司在信息系统建设中的需求问题是本研究需要重点改善的问题之一, 而SCRUM的需求管理模式对问题的改进指明了方向。SCRUM模式下使用用户故 事、需求待办列表、冲刺待办列表来对需求进行管理,研发人员与需求人员的沟通 平台有需求评审会、Sprint计划会。使用用户故事来收集需求,使用需求待办列表 来记录需求,使用冲刺待办列表来细化、分解需求,使用优先级的方法来管理需求, 优先级最高的需求经过与需求方和研发人员讨论细化后进入冲刺待办列表,开始 研发工作。这是SCRUM方法与其他开发模式的不一样的地方,也是能够提高研 发效率之处。下面对SCRUM需求管理工具进行阐述。
(1)用户故事
站在用户的角度,通过使用简单的框架式的“用户故事”方法来收集需求,很 容易把握住需求的重点。通常需要制定一个简单模板“用户故事”模版(如图4- 3),至少要包含“类型”“目标” “价值”3项内容。
表4-3用户故事(模版)
标题(用户故事名称)
角色或用户
需求目标(期望)
行动(采取某种行动)
价值(获得某些益处)
创建时间创建者 故事类别及代号 估算工作量
 
这个“用户故事”模版用来描述需求者“作为一个XX,期望达到XX,采取 XX行动,希望获得XX”。
使用“用户故事”的好处有四点:一是简洁明了,便于整理。通过模版收集的 用户故事对于后期整理到产品需求列表中非常方便。二是有利于重点工作重点抓。 精炼的用户故事方便研发人员写在卡片或便利贴上进行提醒,便于后续实施看板 管理,让项目实施过程更透明。三是节省时间,提高效率。精简的用户故事让研发 人员从冗长的需求分析文档编写工作中解放出来,让他们有更多的时间、更多的精 力去专注地研发系统。四是深入的沟通促进研发人员对需求的理解,最大限度地将 系统功能接近于用户的真实需求。
使用“用户故事”收集需求时要注意:首次收集的用户故事不是需求的最终版, 它只是对需求的概括描述,要更好地将用户故事与需求者的使用需求相匹配,需要 更进一步的沟通,更好地了解需求人员的需求,要在进一步的沟通中将需求分解、 细化为更容易理解和开发的需求描述。因为SCRUM模式下强调的是沟通交流而 不是过程文档。与需求者沟通的方式除了日常的沟通以外,还有需求评审会、冲刺 (迭代)计划会等。
(2) 产品需求列表
产品需求列表相当于是整个项目所有用户故事的集合。由产品经理先将初步 收集到的用户故事整理到初步的产品需求列表中,并根据个人经验给需求赋予优 先级。在一些较成熟的信息系统研发中,可以根据产品负责人的经验和能力对用户 故事优先级、故事点数进行复制,并提出优先级最高的用户故事,直接进入冲刺(迭 代)计划环节。对于复杂的需求,需要请需求提出者参加需求评审,必要时需由项 目经理邀请D公司高层管理者及其他业务部门领导参与,以提高对需求的理解与 把控。由于本项目较为复杂,涉及水电工程的实体建设的方方面面,需要召开需求 评审会,对需求进行再沟通、再确认、再细化,最终将需求分解成可实施的用户故 事。这样可避免出现设计和研发不足,或者出现过度设计和研发。需求评审会不仅 要对产品需求进行细化成适合冲刺颗粒度的用户故事,还要对细化后的产品需求 列表中的工作任务进行工作量估算,并进行优先级排序,形成这一阶段的用户需求 列表。
(3) 冲刺待办列表
产品负责人提出当前用户需求列表中的最高优先级别的用户故事,由SCRUM 项目团队一起细化为更小颗粒度的任务,评估需求待办列表中的每个需求所需要 的研发时间,指定任务负责人(有的任务根据团队成员的实际情况进行任务认领, 有的任务需要产品负责人指定),形成冲刺待办列表。
冲刺待办列表中的用户故事通常有六个标准,即:能够实现独立开发的、可能 进行协商的、有价值的(可以是业务价值也可以是商业价值或其他价值)、可以估 算工作量的、可验证可测试的、有适合颗粒度可以用于冲刺周期的⑹〕。所以,要在 冲刺(迭代)计划会议上对较粗颗粒度的需求进行再细分,使之成为更小的颗粒度。 细分只需要针对本阶段冲刺(迭代)代办列表中的任务进行。因为提前细化还没有 进入到这个阶段的需求任务,对于当前Sprint的执行并没有太大意义,随着项目的 不断推进,这个优先级别较低的需求有可能会被修改、甚至会被取消。动态地逐步 细化需求,既能够最大程度地保障当前阶段的研发任务,也能够有效地提高Sprint 计划会的效率。
4.2.S.2阶段管理——阶段内控制' 阶段边界管理
(1) 阶段内控制
阶段内控制主要包括工作进展情况跟踪,对项目在阶段内的实施过程中发现 的问题,分析原因,及时采取行动纠正偏差、解决问题,对于不能在项目团队成员 中解决的问题,向项目领导小组汇报寻求帮助。
SCRUM流程中的阶段内控制主要通过每日站会进行。会议由产品负责人组织, 项目团队成员在会上就前一日工作情况、当日工作计划和遇到的问题向团队汇报。 会议原则是讲结果、讲重点,不过多展开讨论。阶段内控制通过会用看板和燃尽图 辅助,实现项目监控的可视化管理。
每日站立会不是听取团队成员汇报已完成工作、计划完成工作、听清问题障碍 而已,而是要适时掌握当前研发工作的进度,及时了解目前影响系统研发的问题。 对于研发团队不能解决的,由SCRUM教练及产品负责人及时向甲方项目负责人 反馈,争取资源,或组织召开解决问题的讨论会、甚至是专家研讨会来解决。
(2) 阶段边界管理
Sprint的阶段边界就是前后2个项目里程碑的边界,这一个Sprint的实施时间 就是这个项目里程碑的推进时间。项目里程碑是项目阶段性工作完成的标志,它的 完成进展情况能够影响整个项目的实施。通常通过在项目里程碑的时间节点对项 目的执行情况进行监控,以加强对整体项目的控制。
SCRUM框架中的阶段边界管理通过Sprint计划、Sprint评审和回顾来进行, 它们分别是这一个阶段的“始末”边界。
阶段的“始”边界是Sprint计划。Sprint计划是本阶段的重点工作。主要有以 下步骤:
第一个步骤是整理用户故事,形成产品需求列表。由产品负责人将前期收集的 用户故事或系统需求整理汇总为产品需求列表,并给每个需求赋予相应的优先级。 对于一些较为复杂的用户或系统需求,要组织召开需求评审会,最好需求方、研发 成员都参加,相当于需求再沟通的过程,以充分了解需求。
第二个步骤是召开Sprint计划会,形成冲刺待办列表。Sprint计划会从产品待 办列表中选择优先级最高的用户故事作为本次Sprint要完成的任务,一般由产品 负责人组织。参会人员尽量召集与本次任务有关的提出需求的人员以及研发团队 的所有成员参加。先由产品负责人或研发人员代表对需求理解的陈述,对拟研发内 容、流程、功能等进行讲解,与需求人员进行沟通,尽量将研发思路与需求相匹配, 以便后期开展工作。沟通好的需求要经研发团队讨论进行拆分,细化为更容易实现 的颗粒度,评估工作量、赋值优先级、指定责任人。
项目中的工作量用故事点来估算。通常以一个小的、常见的、简单的功能作为 一个基础故事点,以此作为基准,其他功能则在此基础上对工作量、复杂程度、持 续时间进行比照估算。故事点的数值通常用斐波那契数列来估算,这个数列从第3 项开始,每一项都等于前两项数列的和。这种评估方法是为了对Sprint周期时长以 及拟在周期内研发的任务工作量进行估算而定的。Sprint周期时长以及拟研发的任 务数由团队中经验丰富的人员来估算。估算工作原则有2条:一是只对当前任务 进行精确估算,对时间过长或优先靠后的任务暂时不估算;二是要将用户故事分解 成研发人员认为最小颗粒度的任务再进行估算,这样的估算才会更精确。估算的准 确程度取决于需求待办列表的细化程度和研发人员的经验。在估算工作量的时候 要注意,不要对估算结果过于乐观,因为不是每次估算都能够十分准确,在项目的 实施过程中,会有很多不确定性的情况发生;如果不准确,下一个周期适当进行调 整,让估算达到尽可能的准确。
另外,在冲刺过程中要注意的是,冲刺是为了分阶段实施项目,让团队有计划 地开展研发工作,而不是将不可能完成的工作通过加班加点冲刺完成,所以,冲刺 计划会要经过团队讨论而进行,而不产品负责人进行拍脑袋操作,将很多工作任务 安排在一个冲刺周期内完成。
阶段的“末”边界是Sprint评审和回顾。需要对这个阶段的产出物进行评审, 对这个阶段的冲刺流程执行情况进行回顾。Sprint评审和回顾也是这个Sprint阶段 的收尾过程。Sprint评审会要产出产品增量。
4.2.S.3交付管理——收尾
SCRUM模式下,冲刺(迭代)阶段的可交付物有3种(见表4-4),即:产品 待办列表、冲刺待办列表、产品增量。
各阶段的产品增量集成在一起,就成了最终的产品。当然,最后一步的集成, 也是一个用户故事,它的实现也要按照SCRUM流程来执行。
 
表4-4 SCRUM模式的3种交付物
可交付物
(工件) 产生环节 主要内容
产品待办列 表 在项目前期收集的用 户故事,或在Sprint 完成、发布等环节, 形成的新用户故事。 它是一个动态的需求列表,是整个项目所有需求或 任务的集合,根据需求者提出的需求适时更新。它 根据用户故事整理得出,是项目实施幵发的基础。 它需要与需求人员进行全面的沟通再形成最终版, 以尽可能地接近需求人员所需。
冲刺待办列 表 从高优先级别的产品 需求列表中提取,经 Sprint计划会讨论确 定、细化后形成。 它是冲刺(迭代)阶段的任务目标,是该阶段系统 研发团队需要完成任务的集合。由SCRUM团队在 Sprint计划会上根据用户故事的优先级来确定。它 要求描述准确、没有歧义、能够直接开发。如果有 对本阶段的任务目标有帮助的变化,产品负责人可 以直接修改冲刺待办任务;如果与本阶段任务目标 无关,则要列入产品待办列表中,等待下一个Sprint 环节。
产品增量 Sprint结束 它是每个Sprint阶段的产出物,经过Sprint评审后 确定产品增量是否符合标准。它要具有潜在可发布 的特质,既要保证自己本身可发布,也要保证与其 他增量集成后可发布。
 
4.3辅助工具
在SCRUM框架下,透明性、可检验性、适应性是其三大原则。本项目除了用 甘特图来对项目进行管理以外,还使用看板和燃尽图来实现可视化管控,看板方式 和燃尽图就可以让任务进度更明了、更直观、更透明。在制定进度计划时,用Project 来辅助;每日站立会上按日检验项目的实施情况,看板和燃尽图对实施情况进行监 控;产品待办列表、冲刺待办列表代替了大量的长篇文档;产品增量是对项目阶段 成果的检验,体现了 SCRUM的可检验性。站立会的问题提出能够对系统研发过 程中发现的问题及时处理和调整,体现了 SCRUM的适应性。
4.3.1甘特图
甘特图是用来显示项目进度随时间的推移项目实施情况的一个工具。它可以 直观地明了地展示任务计划在什么时候开始进行,在什么时候计划结束,实际进度 与计划要求情况可以通过甘特图进行对比。通常使用Project软件来安排任务计划、 优化执行路径、进行资源管理等。
4.3.2看板
看板管理源自于丰田公司的精益管理原理,它是为了达到准时生产而使用的 对生产现场进行管控的一种工具(看板示例见4-5)。项目用较简易的看板对系统 研发项目进行管控,即利用白板、便签贴或Story卡片对项目状态进行展示,展示 内容包括任务、时间和责任人等信息,项目状态包括未开始、进行中、已暂停、已 完成、已取消,研发人员每天下班前将看板进行更新。看板内容对项目成员公开, 让团队成员都清楚当前项目的状态。根据看板内容在每日站会期间进行说明和沟 通,以解决当前存在的问题。
表4-5任务看板(示例)
用户故事 未开始■ 进行中・ 已暂停・ 已完成・ 已取消
USERST0RY1
USERSTORY2 李四
USERSTORY3 王五
 
4.3.3燃尽图
燃尽图(示例图见4-3)顾名思义,用来表示实施这个项目还剩下多少时间的 一种图表。它能够表示项目进度的偏差情况[52]。如果实际进度小于计划进度,则项 目可能滞后,在表中体现为蓝色在红色线之下。
燃尽图
 
-•-计划工作一•一实际工作
 
图4-3燃尽图(示例)
4.4本章小结
本章在第3章查找出D公司信息系统建设项目管理中存在问题的基础上,引 用了一些行业分析研究报告,指出当前一些发达国家、国际知名系统研发企业都在 使用敏捷模型来改善信息系统的管理,有着良好的效果。提出用敏捷模型来对D 公司信息系统建设管理过程进行优化,这种优化不是对传统的瀑布模型进行颠覆, 而是引入敏捷管理的思想,融入原型元素,针对存在的问题进行逐一对照分析,提 出改进方案。方案还结合Prince2的项目管理流程和D公司存在的问题进行了具体 实施说明,如:完善管理机制即SCRUM的启动阶段;项目指导在沟通环节实施, 通过Sprint计划会、每日站立会、Sprint评审会、Sprint回顾会、需求评审会5个 会议深化沟通交流及指导;计划管理贯穿于整体项目的过程,只不过近期要实施的 计划细,较后实施的计划粗,以需求待办列表作为整体项目的粗略计划、以冲刺待 办列表作为近阶段的细项计划、在每日站会制定个人当日计划进行计划管理;阶段 内控制和阶段边界管理通过过程管控来加强;收尾过程即交付的过程。最后还对项 目管理要使用的辅助工具如甘特图、看板、燃尽图进行了介绍。
第五章优化后的模型在D公司“智慧工程”信息系统项目管理
中的应用
5.1项目背景
5.1.1项目简介
,D公司开展“智慧工程”信息系统建设己经有很长的时间,并且在不断地优化 迭代中。这些系统主要在只针对某一方面或单一工程类型进行建设管理,对水电工 程建设的全阶段、各部位、多专业的协同管理和全生命周期管理的信息系统研发较 少。D公司需要从整体层面进行数据分析,作为决策工作参考依据,需要管理人员 进行更多的汇总和数据分析工作,给D公司的管理人员造成了更多的负担,并且 分析质量不佳,对管理造成一定影响。随着水电站开工越来越多,影响层面将会越 来越多地存在,所以,D公司的“智慧工程”信息系统实际上是对D公司的所有 信息系统进行的一次整合、再造和优化。
“智慧工程”信息系统与传统的信息系统相比,凸显的就是“智慧”,其终级 目标是实现“自动预判、自主决策、自我演进”的自动管理能力。D公司对“智慧 工程”信息系统的规划是:它不仅仅是业务层面的流程化、数字化、系统化、信息 化,而是在现有成果的基础上,汇聚工程建设中各项业务数据,侧重于解决工程项 目管理过程中面临的管理问题,对工程项目管理各个业务环节的运作方式、方法进 行研究、优化和整合,通过使用合理、有效、科学的管理方法,确定适合水电工程 信息化建设的方案,整体优化、组织、控制、调整项目的各项资源,从而达到项目 管理各种信息流的有机整合。
5.1.2功能范围
D公司“智慧工程”信息系统面向D公司宏观、整体的管控需求,与项目公 司系统的全面、微观管控相结合,针对流域水电工程建设的重点业务,从工程建设 数据中心的海量数据中,监控各项目工程建设的重要指标和流域工程建设的重点 对标项、控制指标项,及时进行预警并提供决策支撑,实现D公司水电工程建设 的“智慧管控”。它向下集成项目公司信息系统(智能工程管理系统、智能大坝、 智能地厂等)、横向对接公司工程建设相关业务系统(造价管理系统、安全管控系 统等)、向上支撑大渡河企业IT规划(统一企业门户、用户认证、大数据中心、移 动平台)谀〕。它将采用现代化的项目管理理念、管理方法和管理手段,从具体的项
目作业层的业务数据、实时监测等海量工程建设过程中的数据,进行智能感知、计 算、分析等方面开展研究,通过数据挖掘、整合分析,建立进度管控、质量管理、 安全管控、投资管控、环水保管控等工程管控模型,建立合理的分级预警指标体系 和科学的风险管控算法模型,实现对已有的“单元脑”数据的有效利用,为业务管 理、工程管控提供管理和决策依据,实现高效优质地完成水电工程建设管理。
D公司“智慧工程”信息系统包括流域电站综合展示、工程建设管理、风险预 警管控、建设保障管控等子系统(其功能概况见图5-1)。移动APP功能基本与信 息系统相同,可在手机、平板电脑上使用。
 
 
 
 
 
 
图5-1用思维导图整理的"智慧工程”信息系统功能概况
5.1.3目标价值
该平台的总体建设目标是:以D公司流域工程的进度、质量、安全、投资等 问题和关键部位为管理重点,对水电工程项目管理要素的趋势性、系统性问题进行 分析、预判、预警、决策和综合管理,实现“数据集成、高效管控、智能预警、辅 助决策”的目标国〕。
5.1.4开发模式
根据前期的分析,本论文将用敏捷模型融入原型元素,优化瀑布模式下的研发 流程,并在D公司信息系统建设项目中实施。本章节将重点对具体实施过程进行 阐述。
5.2优化后的模型在D公司“智慧工程”信息系统项目管理中的实施
由于水电站建设受水流、地质、季节等影响多、不确定因素多;进行水电站工 程的参建单位多,不同的单位、不同的管理层级对信息系统的需求不一致;水电站 建设周期长,在长周期内会出现新的技术、新的方法促进信息系统不断更新迭代, 在不确定因素过多、需求过多、变更过多等多重因素的影响下,D公司的对“智慧 工程”信息系统需求是不断变化的。我国基于水电站管控进行信息系统建设的时间 较短、经验较少,近年来才有较少的一些水电工程管理者从传统的经验管理转向流 程化、系统化管理,对系统框架不清晰,对系统功能不明确。并且水电行业的信息 系统因地域、环境、规模、坝型等方面的不同,可借鉴的信息系统少。同时,由于 信息系统是为了建水电站工程而建的,其建设情况会影响水电站实体工程的管理, 间接地影响实体工程的进度,对系统建设的时限要求高。因此,D公司信息系统项 目有着需求变更多、需求不明晰、对信息系统的功能交付时限要求高等特点。
5.2.1启动 SCRUM
本阶段主要任务有两个,即创建敏捷团队、构建敏捷氛围(培训等),具体实 施过程如下:
5.2.1.1项目团队
本项目团队共计13人,其中,甲方项目经理1人,外聘SCRUM敏捷教练(技 术支持)1人,乙方产品负责人(产品主管)1人,研发团队10人【流程管理员 (研发主管)1人,需求分析(市场)2人、架构设计(产品经理)1人、研发人 员(研发)4人、测试人员(测试)2人】。
项目启动时,由甲方项目经理在启动会上对本项目的背景进行宣贯,介绍系统 的功能范围、最终的目标价值,确保项目团队有着一致的研发目标。由于D公司 是第一次实施敏捷项目,特别聘请了一位外部专家对敏捷项目全程进行指导。项目 经理将人员情况输入“禅道”系统。
ID 4 真实姓名e 用户名= 职位二
001 系统管理员 admin 其他
002 李王程师 Ii1 项目经理
003 刘老师 Iiu1 技术支持
004 尹工程师 yin1 产品主管
005 冯工程师 fengl 硏发主管
006 wen1 市场
007 冯经理 feng2 市场
008 弓CE程师 zhangl 产品经理
009 孙工程师 sun1 硏发
010 彭工程师 pengl 硏发
011 葛工程师 gel 研发
012 王工程师 wangl 硏发
013 器工程师 Iei1 测试
014 远程师 zhaol 测试
图5-2用“禅道”软件管理项目研发人员
 
5.2.1.2营造敏捷氛围
外部专家作为SCRUM敏捷教练,首先对团队成员进行SCRUM方法培训。 首次培训内容包括以下内容:
(1) 敏捷开发模式所产生的背景;
(2) 敏捷开发模式的本质和主要思想;
(3) 敏捷开发模式的主要方法体系;
(4) 敏捷开发模式的主要实践;
(5) 敏捷开发常见的误区;
.(6)敏捷团队的角色转换;
(7)常见的敏捷开发支持辅助信息系统。
5.2.1.3使用辅助工具
“禅道”是国产的一个项目管理信息系统。它是基于SCRUM敏捷项目管理方 法而研发的,基本的敏捷管理需求“禅道”都能实现。对于使用SCRUM方法优化 D公司信息系统项目管理,能够起着很好的效果。
Project是微软公司研发的一个项目管理软件。可以通过甘特图很直观地实现 项目的时间管理、资源管理等计划安排。
5.2.1.4制定里程碑
D公司“智慧工程”信息系统项目中的工程建设子系统分为7个里程碑,具体 内容见表5-1。
表5-1 D公司“智慧工程”信息系统中的工程建设子系统项目里程碑
序号 里程碑
1 项目启动、团队组建、SCRUM培训
2 枢纽业务之安全管控
3 枢纽业务之进度管控
4 枢纽业务之投资管控
5 枢纽业务之质量管控
6 系统调试
7 验收交付
通过里程碑制定,将系统分为7个阶段来实施,每一个阶段都需要实施一次 “冲刺”。D公司“智慧工程”信息系统基于水电站枢纽建设,涉及水电站枢纽业 务的安全、进度、投资、质量等方面进行管控,各模块都是基于水电工程主体设施 的项目管理而进行的,不可谓不复杂。业界对水电枢纽工程需求的理解并进行研发 还处于探索阶段,系统使用者对系统需求只有一个大致的概念,具体落到实处还需 一步一步地引导和试探。以下将以D公司“智慧工程”信息系统中的工程建设子 系统进度管控模块为例,对优化后的模型在D公司信息系统建设中的应用进行分 析。
5.2.2阶段内控制
阶段内的控制包括阶段执行和监控2方面的内容。
5.2.2.1 执行
冲刺(迭代)是SCRUM的核心步骤,它是研发团队在一个冲刺周期要对本阶 段的产品冲刺(迭代)列表中的工作任务进行研发的过程。这个过程是否能够有效 地执行,关系到这一阶段的任务是否能够得以有效地实施。
通常,一个信息系统项目的建设工作,有三分之一都在进行需求调研和分析。 而在SCRUM模式下,需求调研和分析不按照传统的需求说明书进行撰写,而是 从用户或使用者的角度,将需求写成了 “用户故事”。
(1)用户故事
本项目的“用户故事”主要内容包含:标题“需求的类型或名称”,这个“角 色”期望达到“某个目标”,将“采取某种行动”,以期获得“某些价值”。描述为 作为一个XX,期望达到XX,采取XX行动,希望获得XX (具体见表5-2)。
表5-2用户故事(示例)
标题(用户故事名称) 进度管控
角色或用户 公司领导级、部门级、分公司、子公司级
需求目标(期望) 能够统计查询与工程进度相关的数据,实现工程项目的进 度管控。
行动(采取某种行动) 1•基础工作:建立统一的数据结构标准与交换接口,集成子 公司分公司系统(智能大坝、智能地厂、智能工程信息系 统)数据以及手动录入的工程执行过程中的进度数据与文 档。
2.进度数据的统计查询。对于项目公司具有三维可视化的模 块,接入项目系统的三维可视化功能。
价值(获得某些益处) 通过移动端或PC端访问,了解与工程进度预警相关信息和 数据,掌握流域工程建设进度的控制情况。
创建时间创建者 故事类别及代号 估算工作量
 
“用户故事”是一种笼统的、粗略的需求。产品负责人将需求整理为初步的产 品待办列表,组织讨论现有需求并提出拟采用的技术、评估实现的风险,按照产品 特性价值的大小评估需求的优先级,分解成适合团队工作量的颗粒度任务。“用户 故事”需要经过评审才能进行最终的产品待办列表。有的信息系统项目较小,需求 颗粒度较小,用户故事较为直观,能够很好理解或直接实现,对需求评审的要求较 小,由产品负责人或项目团队进行评审即可。而本项目涉及水电站建设的全过程管 理,水电工程本身是一项大工程,与水电工程相关的信息系统可借鉴的又太少,很 多信息系统需求发起者对自己的需求描述不够清晰,项目团队对需求理解不够深, 会造成执行偏差。因此,需要组织召开需求评审会,以尽可能地了解需求、描述需 求、细化功能颗粒度,才能在后期的研发过程中更好地设计和实施。
在最早收集的进度管理“用户故事”中,需求人员只提出了要“能够统计査询 与工程进度相关的数据,实现工程项目的进度管控,了解与工程进度预警相关信息 和数据,掌握流域工程建设进度的控制情况”的需求,但在随后进行的需求评审会 及沟通中,了解到水电站工程进度管理是一个复杂的需求。在指标管理方面,需要 根据施工部位、施工类型的不同,如土石方开挖、土石方填筑工程、混凝土工程、 灌浆工程、支护工程、金结工程等等,每类施工的进度表结构均不同,需要从不同 的系统提取数据并整理成统一的数据表结构。同时要结合水电站进度对标管理指 标,完成进度节点目标完成率、实际发电工期与可研批复发电工期的差值、大坝填 筑工期、厂房开挖工期、首台机组安装工期、蓄水前库区移民搬迁完成的提前时间、 库区代建项目工期、首台机组启动前送出工程完成的提前时间等KPI指标的统计, 按照分部位、分层级、分单位、分时段等不同维度多因素进行分类,进行进度KPI 管理。在进度预警方面,需要根据管控预警模型,针对每一项指标设置预警阈值, 建立对标预警模型与进度KPI指标的对应关系。对超出对标预警阈值的指标项, 根据超出阈值的程度,划分预警等级:白、黄、橙、红四级预警。白色预警:周期 实际进度滞后周期计划进度,或非关键线路标段过程管控节点或关键节点实际进 度滞后,出现偏差,但偏差值小于自由时差(指不致影响后续工程或相关工程进度 的最大允许进度延误值)。黄色预警:非关键线路标段过程管控节点或关键节点实 际进度滞后,出现偏差,但偏差值超过自由时差但小于总时差(指不致影响总工期 的最大允许进度延误值);或关键线路标段的关键节点实际进度滞后,出现偏差, 且偏差值超过黄色预警标准。橙色预警:实际进度滞后,各进度控制节点出现偏差, 且偏差值超过橙色预警标准。红色预警:实际进度滞后,各进度控制节点出现偏差, 且偏差值超过红色预警标准。还要对各管控指标预警信息进行分级管控,发送预警 信息,即白色预警信息和黄色预警信息只发送至项目公司,由项目公司决定是否启 动决策响应、是否报送D公司等;橙色预警信息和红色预警信息同时发送至项目 公司和D公司。对于橙色以上级别的预警,将接入決策指挥系统,综合展示施工 三维面貌、进度明细数据、KPI统计、预警信息,并关联企业知识库中的技术文档、 类似工程经验数据等,供各专家进行决策会商或远程决策会商[网。进度分级管控 预警模型如图5-3。
 
 
图5-3进度分级管控预警模型图网
通过沟通及需求评审会评审后确定的需求,整理出需求待办列表。
整体来说,整个系统较为复杂,前期的用户故事只是对需求有一个概括的说明, 后期还要经过不断地沟通,才能真正地了解需求,达到了最后效果。这样做的好处 是避免了设计人员凭空地想象设计出不适用的系统或者造成过度设计。
C2)需求待办列表
本阶段的需求待办列表通过需求评审会评审后产生(研发进度管理模块时的 冲刺阶段需求待办列表见表5-3),需求评审会负责对目前收集到的需求(用户故 事)进行评审。需求评审会的原则是:让尽可能多的项目干系人参加,尽可能地将 前期搜集到的需求(用户故事)形成可以初步交互的示意图、流程图等,让信息系 统需求者能够感受到关键信息,尽可能多地与系统需求者进行互动,取得最真实的 反馈。实施过程中,在每次Sprint计划会议(迭代启动会)召开前都要进行多次的 需求沟通或召开需求评审会,通过反复修改最大限度的逼近系统需求者的最终需 求。每次里程碑结束,也要对下一次的冲刺进行需求沟通或需求评审,将功能敲定, 再按照SCRUM流程进行开发【网。
 
表5-3研发进度管理模块冲刺阶段的需求待办列表
序号 用户故事 故事名称 数据来源 优先级
1 工程进度数据 土石方开挖工程进度 智能大坝、智能地厂、工程 信息管理等系统数据提供。 3
2 土石方填筑工程进度
3 混凝土工程进度
4 灌浆工程进度
5 支护工程进度
6 金结工程进度
7 机组安装工程进度
8 锚杆支护工程进度
9 锚索支护工程进度
10 房屋建筑工程进度
11 道路工程进度
12 其他进度
13 进度KPI 对标预警模型 D公司水电站全过程对标管 理指标体系表。 4
14 进度节点目标完成率 智能大坝、智能地厂、工程 信息管理等系统数据(含机 电安装工程)。 2
15 实际发电工期与可研 批复发电工期的差值 智能大坝、智能地厂、工程 信息管理等系统数据。 2
16 大坝填筑工期 2
17 厂房开挖工期 2
18 首台机组安装工期 2
19 蓄水前库区移民搬迁 完成的提前时间 3
20 库区代建项目工期 2
21 首台机组启动前送出 工程完成的提前时间 2
22 进度预警 进度管控模型 进度管控对标数据库(参考 管控模型设计建立)。 4
23 进度决策会商 进度信息展示 数据积累;用户总结。 1
 
(3)冲刺待办列表
冲刺待办列表是Sprint冲刺会议的产物,Sprint冲刺会议要对优先级高的、需 要在本阶段进行研发的需求进行评审,形成这一阶段的冲刺任务待办列表(表5- 4),并启动本阶段的冲刺(迭代)工作。会议要对当前优先级最高的拟在这个一阶 段实施的用户故事进行任务分解,分解任务的标准是完成该用户故事所需的最小 工序,每个任务都要确认负责人,规定相应工作完成的时间。在会议上,优先项目
团队人员认领任务及承诺完成时间。在没有人认领的情况由产品负责人指定,并由 团队成员共同估算该任务的完成时间。
表5-4研发进度管理模块冲刺阶段的冲刺待办列表
编号 所属模块 用户故事 故事名称 优先级 责任人 预计工作量 (天)
1 进度管理 工程进度数据 土石方开挖工程进度 3 张工程师 2
2 进度管理 工程进度数据 土石方填筑工程进度 3 张工程师 2
3 进度管理 工程进度数据 混凝土工程进度 3 张工程师 2
4 进度管理 工程进度数据 灌浆工程进度 3 张工程师 2
5 进度管理 工程进度数据 支护工程进度 3 张工程师 2
6 进度管理 工程进度数据 金结工程进度 3 张工程师 2
7 进度管理 工程进度数据 机组安装工程进度 3 张工程师 2
8 进度管理 工程进度数据 锚杆支护工程进度 3 张工程师 2
9 进度管理 工程进度数据 锚索支护工程进度 3 张工程师 2
10 进度管理 工程进度数据 房屋建筑工程进度 3 张工程师 2
11 进度管理 工程进度数据 道路工程进度 3 张工程师 2
12 进度管理 工程进度数据 其他进度 3 张工程师 3
13 进度管理 项目进度信息 查询 工程进度信息集成 3 张工程师 5
14 进度管理 项目进度信息 查询 工程进度信息查询 2 张工程师 2
15 进度管理 进度KPI 对标预警模型 4 葛工程师 20
16 进度管理 进度KPI 进度节点目标完成率 3 孙工程师 1
17 进度管理 进度KPI 实际发电工期与可研批 复发电工期的差值 3 孙工程师 1
18 进度管理 进度KPI 大坝填筑工期 3 孙工程师 1
19 进度管理 进度KPI 厂房开挖工期 3 孙工程师 1
20 进度管理 进度KPI 首台机组安装工期 3 孙工程师 1
21 进度管理 进度KPI 蓄水前库区移民搬迁完 成的提前时间 3 孙工程师 1
22 进度管理 进度KPI 库区代建项目工期 3 孙工程师 1
23 进度管理 进度KPI 首台机组启动前送出工 程完成的提前时间 3 孙工程师 1
24 进度管理 进度KPI据统 计查询 项目进度KPI统计查 询 2 孙工程师 3
25 进度管理 进度预警 进度预警模型 4 尹工程师 20
26 进度管理 进度预警 进度管控预警 3 彭工程师 4
27 进度管理 进度预警 预警分级推送 2 彭工程师 2
28 进度管理 进度预警决策 会商综合信息展示 2 王工程师 4
29 进度管理 进度预警决策 会商决策管理 1 王工程师 2
 
 
项目团队在Sprint计划会上将列入本阶段执行的产品需求待办列表中的任务 进行细化及工作量等进行评估,通过Projcet进行计划安排(见图5-4)。如:进度 管理模块研发阶段的时间计划为40个工作日,则本阶段的冲刺时间为40个工作 日。经过分析,对标预警模型、进度预警模型、各项工程进度数据收集可以同步, 再通过集成的手段进行集成,再进行下一步工作。
 
图5-4研发进度管理模块冲刺阶段的进度计划
会议结束后,要在“禅道”系统里录入对应的资料,进行线上线下的数据匹配。
5.2.2.2 监控
项目团队通过每日站立会(每日例会)对冲刺阶段的执行情况进行过程监控。 研发团队每个工作日都要召开站立会,由产品负责人组织,由SCRUM教练控制 会议节奏,项目各成员逐一汇报前一个工作日的工作完成情况、本工作日需完成的 工作,需团队共同商讨或解决的问题等。
每次站立(每日例会)会原则上控制在15分钟左右,但项目前期站立会召开 时间超过了 40分钟。因为项目初期,项目成员要沟通的事项很多,而且每个人都 想要一次性地将自己所负责的事项描述清楚,遇到疑难的问题,会陷入具体的细节 讨论,这种方式虽然达到了沟通效果,但效率并不高,从敏捷的意义上讲,并未达 到SCRUM模式下的站立会效果,同时影响了当日的工作进程。为了开好每日站 立会,SCRUM教练对项目成员进行了指导,要求团队成员做好以下准备:一是前 一天工作结束在“禅道”系统中录入工作情况,使得系统能够生成“燃尽图”和“看 板气如图)。二是制定发言框架,发言内容仅包括昨天完成任务、今天待完成任务、 需要解决的问题三项,每项内容不超过100字,三分钟内描述清楚。最后由产品负 责人对会议进行总结或答复团队成员的问题,并对当天工作进行安排。这样,会议 时间控制在20分钟以内。产品负责人在项目团队遇到难以解决的问题,会在会后 请甲方项目经理协调专家参与分析,提供解决思路及办法。
不能小看这20分钟,每天这样简单的沟通过将使团队成员能够了解整个冲刺 任务的开展情况,以及了解自己的工作任务在整体系统开发的作用。同时,每日站 立会(每日例会)类似于一个开启工作的仪式,会议的召开形成了一种仪式感,让 团队成员在会后很快进入工作状态。每日站立会还有一个很大的好处,就是能够及 时发现问题、解决问题,保证冲刺任务顺利实施,保证项目的最终完成。
例如:尹工程师在进行进度预警模型设计时就遇到一个问题,进度KPI数据 将从D公司的相关系统中提取数据,数据多而且杂,项目成员无法确定相关的标 准和关键数据。在每日例会上反映后,得到了 D公司项目经理的支持,组织研发 人员与需求人员进行沟通,并及时请示相关领导,得岀结论:根据D公司水电站 施工的关键环节和关键项目,参考水电站全过程对标管理指标体系,建立进度管控 模型,对超出预警阀值的指标,根据超出范围的大小分为白、黄、橙、红四级预警。 预警信息按不同的级别分层发送。白色预警信息和黄色预警信息只发送至项目公 司,由项目公司决定是否启动决策响应、是否报送D公司等。橙色预警信息和红 色预警信息同时发送至项目公司和D公司。同时确定了进度管控指标预警标准体 系(见表5-5)
表5・5进度管控指标预警标准体系[湘
类别 预警级别 预警标准
里程碑节点 0<TZ < X]
Xi<TZ < X2
TZ> X2
关键线路标段工程 0<TZ/T^j<X3/12
X3/12<TZ/T^<X4/12
TZ/T 剰〉X/12
非关键线路标段工程 0< TZ <FF
FF < TZ <TF
TF<TZ 且 X3/12vTZ/T«ivX4/12
TF<TZ 且 TZ/Tw>X4/12
“燃尽图”和“看板”是项目管理工具之一,使用“燃尽图”〔示例见图5-5) 和“看板”(示例见图5-6)来显示冲刺任务列表随着冲刺日期的推进整体项目的进 展状态。让团队成员较直观地、可以在线了解本阶段的进度情况和工作开展情况。 如果整个项目燃尽所用时间与之前的计划相符,则记录下一次迭代能完成的任务 数以供后续参考,如果与计划有偏差将在下次迭代时进行调整。如果没有使用“禅 道”系统,普通的EXCEL表格也可以实现。
BKiua珥 己延is o ■ 曰毋 «« 口时be st尽be w«bb 廿- 画由4*也・(
 
 
图5-5 “禅道”系统中的燃尽图
任隽 密板 嵌氈 1* 故事 濟试•文档 諏 日志储 产品瞬
osksi ©IM®
未刑S 进时 BSf* so
图5-6 “禅道”系统中的看板
在执行过程中,如果实在有无法完成的任务,将裁剪到产品待办列表中,按优 先级排序等待下一轮的冲刺计划安排。当需求取消时,要提前结束冲刺周期,以免 造成工时浪费。当冲刺被提前结束时,未完成的用户故事要放回产品待办列表中, 经过重新评审后进行新一轮的产品冲刺(迭代)列表处理。对于已完工可交付的系 统特性,通过系统特性发布评审后试运行。
5.2.3阶段边界管理
在SCRUM模型下,将信息系统建设的整体周期划分为若干个小阶段的进行 冲刺(迭代),每一个阶段类似于一个小型或者微型的项目。每个冲刺将针对当下 需求库里优先级最高的需求进行研发,每一次冲刺都有一组“产品增量”要进行评 軋 实现预交付。这样一个周期称为一次迭代。冲刺是SCRUM框架下,项目团队 完成项目的最小周期Q
阶段边界管理就是对这个周期的边界做好管控,以保证这一阶段的项目任务 顺序进行。一个Sprint阶段的"始末"边界分别是Spimt计划/启动会和Spring评 审/回顾会。在具体的实施过程中,Spimt计划会召开后同时也是这一个冲刺阶段的 启动会,即Sprint阶段的"始"边界» Sprint计划会用来确定本次迭代目标,制定 任务计划。在冲刺执行阶段,项目团队集中力量完成冲刺任务待办列表,通过每日 站会对任务完成情况及时进行跟踪监控。而Spring评审会和回顾会是Sprint阶段 的“末”边界,它们通常在同一天召开,要对这一阶段的交付物进行评审,并对这 一阶段的工作进行回顾、复盘总结,以便下一个迭代阶段改进。
523.1 Sprint计划(启动)会
冲刺(迭代)计划会的输入是产品待办列表,输出是冲刺待办列表,Sprint计 划会就是要对这两个表进行管控,而这两个表的基础是用户需求。产品待办列表是 所有用户需求的集合,冲刺待办列表是本阶段要实施的用户需求集合。
Sprint计划会是阶段边界管理的控制要点,每个Sprint阶段的第一天上午,由 产品负责人组织,原则上需要项目团队全体人员及与本次冲刺阶段的需求人员参 加,会议主要有以下议题:
(1) 明确本次冲刺(迭代)的目标;
(2) 讨论现有需求并提出拟采用的技术、评估实现的风险;
(3) 拆解“用户故事",评估任务工作量和优先级。
以下是进度管理模块冲刺阶段Sprint计划会议的情况(见表5-6):当前的产 品待办列表中的项目优先级系数最高的是4,目前有2项待办都是4的系数,即: 对标预警模型和进度管控模型。将这两个模型列为优先级最高的情况原因是:系统 “模型”是系统建设的基础,是系统功能实现的逻辑梳理。通过示意图、流程图可 以在短时间内将系统功能进行演示,便于与需求者进行交流,让这个示意图、流程 图先形成一个最基础、最简单的“原型”,通过此原型与客户或使用者进行演示、 交流,让他们能对该系统能有更加清晰的认识,对需求也能够有更好更精细的补充。 通常确定了示意图、流程图后,用三峡公司的TGPMS来进行“仿真展示”,让需 求人员更清楚自己的需求。后期再根据他们的意见进行修改,直到他们满意后,再 在这个原型的基础上开发系统、叠加子系统。再通过反复的交流和反馈,逐步获得 完整、合理、达成一致并切实可行的产品信息,列入待办列表中。这样既能够简化 文档编制、吸引用户参与,又可以较早地得到关于设计的优点、缺点的反馈。最后, 经过研发人员自测没有大的bug以后,移交给测试人员测试。测试人员经过几轮 测试确认功能已经实现,则实施发布。这样,将研发风险降到最低。
 
表5-6进度管理模块冲刺阶段的冲刺待办列表优先级情况
序号 所属模块 用户故事 故事名称 优先级
1 进度管理 进度KPI 对标预警模型 4
2 进度管理 进度预警 进度预警模型 4
3 进度管理 工程进度数据 土石方开挖工程进度 3
4 进度管理 工程进度数据 土石方填筑工程进度 3
5 进度管理 工程进度数据 混凝土工程进度 3
6 进度管理 工程进度数据 灌浆工程进度 3
7 进度管理 工程进度数据 支护工程进度 3
8 进度管理 工程进度数据 金结工程进度 3
9 进度管理 工程进度数据 机组安装工程进度 3
10 进度管理 工程进度数据 锚杆支护工程进度 3
11 进度管理 工程进度数据 锚索支护工程进度 3
12 进度管理 工程进度数据 房屋建筑工程进度 3
13 进度管理 工程进度数据 道路工程进度 3
14 进度管理 工程进度数据 其他进度 3
15 进度管理 项目进度信息查询 工程进度信息集成 3
16 进度管理 进度KPI 进度节点目标完成率 3
17 进度管理 进度KPI 实际发电工期与可研批复 发电工期的差值 3
18 进度管理 进度KPI 大坝填筑工期 3
19 进度管理 进度KPI 厂房开挖工期 3
20 进度管理 进度KPI 首台机组安装工期 3
21 进度管理 进度KPI 蓄水前库区移民搬迁完成 的提前时间 3
22 进度管理 进度KPI 库区代建项目工期 3
23 进度管理 进度KPI 首台机组启动前送出工程 完成的提前时间 3
24 进度管理 进度预警 进度管控预警 3
25 进度管理 项目进度信息查询 工程进度信息查询 2
26 进度管理 进度KPI据统计查询 项目进度KPI统计查询 2
27 进度管理 进度预警 预警分级推送 2
28 进度管理 进度预警决策 会商综合展示 2
29 进度管理 进度预警决策 会商决策管理 1
 
Sprint计划会议也是本冲刺阶段的启动会,会议结束后相当于启动了本阶段 的冲刺。次日即通过每日站立会(例会)对本阶段的工作开展情况进行工作安排 部署、执行监控。
5.2.3.2 Sprint评审、回顾会
Sprint评审、回顾会是冲刺(迭代)阶段的末边界。主要是针对本阶段实施的 工作结果进行评审,对SCRUM的流程执行情况进行回顾。具体如下:
(1) Sprint评审会
Sprint评审会通常会在本Sprint冲刺阶段的最后一天召开。会议议程是主要检 验本期Sprint输出的产品是否达到要求。Sprint评审会由产品负责人组织,协调项 目关键干系人到会,提出本阶段需求的需求者必须到会,因为他要检验需求是不是 达到了他的预期。
Sprint评审会一般有3个议题:
一是介绍本冲刺阶段的任务完成情况,包括:已完成的产品增量,未完成的需 求任务,任务未能完成的原因,并开展讨论。
二是演示本冲刺阶段完成的系统功能。
三是收集使用者的反馈建议以及新增需求,整理加入需求待办列表作为下一 个冲刺计划会的输入。
产品增量是Sprint阶段产出物。通常由产品负责人和需求方评审该阶段的产 品增量是否符合标准。由研发人对产品增量的特性进行演示,产品负责人和需求人 员对其进行评审,其评审标准不同,产品负责人是从技术的角度进行评审,需求人 员是从功能使用的角度进行评审,达到标准后签字确认,类似于阶段验收。本项目 中,系统功能实现分阶段交付。
图5-7是进度管控模块的Sprint阶段评审会时对会商指挥中心进行评审的照 片。
 
图5-7某Sprint阶段评审会对决策会商指挥中心进行评审
(2) Sprint回顾会
Sprint回顾会主要是回顾已经完成的Sprint阶段在执行SCRUM流程中的经验 教训,并讨论确定怎样才能改善后续的Sprint,使得工作更高效。Sprint回顾会通 常会与Sprint评审会一起召开,在评审结束会以后举行。回顾会一般由SCRUM教 练主持,对SCRUM流程执行情况回顾,改进不合适的流程、固化实施效果较好的 流程,形成持续改进的闭环管理。回顾会议一般也有3个议题:
一是评估上一次Sprint回顾会明确改进之处的整改措施落实情况。
二是回顾本阶段的Sprint实施较好的环节,讨论评估这些环节是否能够固化 成为本项目团队的常规动作。
三是回顾本阶段的Sprint实施较差的地方,讨论如何改进,并制定实施计划。
Sprint回顾会是SCRUM项目团队的内部会议,外部人员可以不参加,或者可 以参加但不参与讨论。Sprint回顾会功能是提升和促进,而不是问责。通过对本阶 段Sprint的回顾和复盘,可以对Sprint在项目中的实施实现PDCA的闭环管理。 当然,每次回顾会议要形成经验文档,以供后续工作借鉴。
要注意的是:作为冲刺阶段的末边界,产品负责人会在冲刺评审会上收集新的 需求,更新后续的产品待办列表,实现对后续的需求的滚动分析、拆解等工作,又 启动另一个冲刺阶段的工作。
5.2.4收尾
收尾阶段是指全部Sprint结束后,对项目实现验收交付的阶段。
本项目于2020年9月1日开始启动,共经历了 7个冲刺阶段,于2021年6 月28日进行初验,比计划提前5天完成,现己进入试运行期(运行维护阶段)。通 过敏捷开发流程优化了建设方法,实现“小步快跑”的节奏,项目计划进度偏差为 2.33%,各项措施得到有效地贯彻执行,项目得以顺利完成,通过验收。
5.3实施效果总结评估
总体来说,SCRUM的实施对于D公司信息系统建设顺利实施起到了一定的 效果,尤其是在对需求管理、沟通管理、进度管理等方面,通过用模糊综合评价法 对系统的整体效果进行评价,系统的整体效果评价为良好。说明实施效果良好。
5.3.1需求管理改进效果
5.3.1.1需求描述更明确
项目初始,如果不是经过深入细致的研究,需求方对信息系统的框架和功能不 会很明确。所以,本次项目采用了“用户故事”进行信息收集,用原型设计与需求 方进行沟通,并在交互过程中不断进行迭代的方式,完善需求待办列表,增加研发 人员对需求的理解、需求人员对系统的感知。在需求评审会和Sprint计划会上,需 求方全程参与了需求分析和功能细化,参与了类似于集体设计的环节,让需求者对 系统的认识更加明确,对需求的描述会更准确,研发人员也能够更好地将产品功能 需求更好地呈现出来。
5.3.1.2需求响应更高效
SCRUM信息系统研发方式通过“用户故事”收集大量的系统需求,强调与需 求方的交互与沟通,减少了需求分析文档、设计文档等冗长文档的编写,让研发人 员更清楚需求方的需求更有时间和精力投入到系统研发工作中,更有利于提高工 作效率。
使用产品待办列表来管理需求,能够更加方便快捷地管理和响应需求变更。当 需求者有新的需求或者进行需要变更,都可以随时提出,加入待办列表,经过评审、 估算该需求的工作量和优先级后,在产品待办列表中进行调整。如果需求方没有提 出“用户故事”,即产品待办列表中没有这项需求,则研发人员不用想当然地对这 项功能进行开发,可以避免开发人员过度设计。
5.3.1.3需求价值更能得到体现
“用户故事”其中一项内容是“期望获得'某些价值这项内容体现了用户 诉求。因此,以“用户故事”为基准,实现“用户故事”的精准拆分,并将“用户 故事”的目标贯穿于整体研发工作的始终,以“用户故事”作为分析需求、评估工 作量的依据,是研发任务的关键。通过Sprint计划会,让研发人员能够充分地理解 “用户故事”、分析“用户故事”、拆解出便于实施的细颗粒的研发任务。在拆解“用 户故事”时要注意,要将其拆分为让研发人员尽可能一次性完成的任务的颗粒度。 这需要发挥SCRUM敏捷教练、产品负责人的个人经验,在充分了解研发人员的 能力特点、经验、学识等基础上,开展充分讨论,通过自行认领任务与任务分配相 结合来开展。“用户故事”验收是系统将用户对业务价值认识进行固化的体现。要 将“用户故事”的价值贯穿于研发工作的始终,不管是在Sprint阶段结束,还是系 统特性发布,还是最终验收,都要评估该系统是否完全实现了用户的需求,即:是 否完全体现了 “用户故事”的业务价值。
在该项目实践过程中,总共完成用户故事58个,其中原始用户故事16个,新 增用户故事20个,修改的用户故事22个。这种方法无需在项目前期就掌握所有 需求,可以随着项目的进行不断地调整需求。在传统的系统开发模式中,大部分的 需求在项目初期就要确认;而在敏捷模式下,大部分需求是在后期产生的,这种方 法可以有效地解决需求变更的问题。
5.3.2沟通管理改进效果
5.3.2.1需求沟通更有效
传统的信息系统研发项目主要问题之一是缺乏沟通。在瀑布模式下,一般是由 乙方的项目经理与甲方的需求人员进行沟通(大多数情况下是甲方的项目经理), 需整理出冗长的需求分析报告。需求报告太冗长,不管是需求方还是研发人员,对 太多的资料理解会存在差异,这样就会造成研发人员对整体项目的情况不完全了 解的情况下,研发出的系统功能可能会与需求方的真正需求有偏差。同时,瀑布模 式下,很多系统功能要到最终才与需求方见面,导致重复、返工的现象。但在 SCRUM模式下,项目团队成员与项目干系人都参与进来。尤其在规划Sprint环节, 大量的需求沟通让研发人员能够很清楚地了解需求,以便进行研发。实施敏捷模式 后,因需求沟通不及时导致后期系统修改的数量仅为8次。
S.3.2.2技术沟通更频繁
在大量的沟通中还促进了团队成员间的技术交流,积极的讨论使得团队成员 间的交流更加频繁,促进成员之间对彼此的工作更加了解,增加工作的默契,为项 目的顺利实施打下良好的基础。虽然敏捷模式下没有要求过多的文档,但是要提供 对工作有帮助的文档,必要的文档给后续项目的实施或敏捷模型的推进将提供宝 贵的经验。
5.3.2.3团队成员之间更和谐
敏捷模型提倡的是“以人为本”,倡导交流。每日站立会(例会)进行让团队 成员的交流更顺畅,通过“看板”和“燃尽图”,以数据说话,暴露出的问题对事 不对人。对于团队不能解决的问题,能够在会下及时向甲方项目经理求助,并获得 相应专家支撑,使问题能够及时解决,促进各环节有序进行。敏捷教练的指导让团 队成员对敏捷流程更加理解,对工作更加高效。通过各种沟通让团队成员成长,团 队成员工作压力得到舒缓,团队成员的自我价值得到体现,让整个团队更加和谐。 计划会议让团队成员提升了计划工作的能力。每日站立会让团队成员形成“今日事 今日毕”、形成3分钟陈述问题、计划工作、倒排工期等习惯,并利用辅助工具协 助研发。Sprint评审会、回顾会让团队成员学会了总结、分析,通过对近一阶段工 作的复盘,让团队的管理工作实现螺旋式上升。系统功能演示让团队成员展示自我。
5.3.3进度管理改进效果
进度管理是项目管理的三大要素之一,也是本研究利用SCRUM模型重点改 进的研究内容。在SCRUM模型下,对进度管理起到了一定的效果,项目提前通过 初验,进入试运行阶段。项目进度偏差情况如表5-7。
表5-7 D公司信息系统建设项目进度偏差情况
里程碑
1 里程碑
2 里程碑
3 里程碑
4 里程碑
5 里程碑
6 里程碑
7 总时 间
实际进度 5 29 44 59 44 29 5 215
计划进度 5 30 45 60 45 30 5 220
进度偏差 0.00% 3.45% 2.27% 1.69% 227% 3.45% 0.00% 2.33%
其中:项目进度偏差=(实际进度-计划进度)/计划进度x 100%【65]
本项目计划周期为220天,实际完成天数为215天,提前完成项目,进度偏差 为2.33%。该项目缩短了完成时间,克服了延期的问题,进度偏差也控制得较好。 在项目的执行过程中,以里程碑作为Sprint的阶段分界点进行冲刺,在及时地响应 需求的同时,保证按时完成项目进度。
在传统的系统建设过程中,对于需求变更、增减管理较为呆板,并且与需求方 的沟通少,属于卖方导向型,基于项目初期制定的系统功能进行开发,但随着系统 的实施,使用者的需求会不断发生变化,如果到系统建设的后期再沟通时才发现有 新的需求、或需求达不到要求等情况,再进行更新会给整个项目的实施造成很大的 影响,甚至要面临重新设计的情况o SCRUM模式下保持与需求方进行频繁的沟通, 能及时获得需求方的反馈情况。而且使用原型设计和“用户故事”的方法使需求方 对于系统的需求更加清晰,对需求的描述和对系统功能的要求会更加完整。.另外, 文档的减少和沟通效率的提高也使得系统的研发效率利于提升,促进了项目时间 的缩短。还有,频繁的沟通也让团队成员间的配合越来越顺畅,合作越来越紧密, 有效地促进对项目的实施。因此,SCRUM模式在本项目的进度管理方面取得了理 想的效果。
5.3.4整体效果的评价
D公司“智慧工程”信息系统建设在严格的项目管理控制之下,按进度顺利上 线。现采用模糊综合评价法对系统的整体效果进行评价【I】。
5.3.4.1确定主要评价因素集和评语集
(1)确定主要评价因素集U= (Ui,U2,UQ =(数据融合度,工程管控能力, 风险管控能力)。从以上3个因素集中细分出系统的主要功能,确定影响指标的数 个,形成三个层次的“智慧工程”效果评价指标,如图5-8所示。
鵲工程”信息啟效果
评价删系
 
 
(2)评语集是综合评判中评语的集合。表示评价事物特性区间。设评价集 为¥= CV1, V2,……V 4 , V5)=(差,较差,中,较好,好)。
5.3.4.2综合进行评判
本项目采用专家打分法,邀请D公司“智慧工程”信息系统项目管理团队中 的10名管理人员根据评价指标对系统的整体情况进行评价。得分整理为表5-8所 zK。
 
表5-8 D公司“智慧工程”信息系统评价情况
评仔 「内容 评, 介指标 模糊评价
因素 符号 权重 因素 符号 权重 较差 较好
数据融合度 (系统集成 情况) U1 0.2 多系统整 合数据的 一致性 U11 0.6 0 0.1 0.2 0.6 0.1
方便调用 程度 U12 0.2 0 0 0.1 0.1 0.8
0.8
统一存储 情况 U13 0.2 0 0 0.1 0.1
工程管控 能力 U2 0.4 流域综合 展示内容 U21 0.05 0 0.1 04 0.1 0.7
安全管控 能力 U22 0.15 0.1 0.1 0.1 0.6 0.1
质量管控 能力 U23 0.2 0 0 0.1 0.2 0,7
进度管控 能力 U24 0.15 0.1 0.1 0.2 0.2 0.4
投资管控 能力 U25 045 0.1 0.1 0.2 0,5 0.1
环水保管 控能力 U26 04 0.1 0J 0.2 0.5 0.1
建设保障 能力 U27 0.05 0.1 0.1 0.1 0.6 0.1
前期管理 能力 U28 0.1 0.1 0.1 0,1 0,6 0A
APP使用 情况 U29 0.05 0.1 0.1 0.2 0.5 0.1
风险管控 能力 U3 0.4 风险自动 识别能力 U31 0J 0 0.1 0.2 0.6 0.1
风险告警 能力 U32 0.1 0 0.1 0.1 0.4 0.4
风险措施 推荐能力 U33 0.4 0.2 0.1 0.5 0.1 0」
风险决策 辅助能力 U34 0.2 0.2 0.5 0.3 0 0
 
5.3.4.3具体的计算过程
将评价指标中各因素的权重A与模糊关系矩阵R进行合成计算:
 
0.38)
 
0.33, 0.26, 0.11)
以Ri为i行整理出评价矩阵R:
'0 0.06 0.16 0.4 0.38 >
R= 0.075 0.08 0.145 0.405 0.295
、0.12 0.18 0.33 0.26 0.11)
 
这是从因素集U到评语集V的一个模糊关系矩阵。
由评价模型中取岀3个评价因素的权重集A= (0.2, 0.4,
程”主要功能实现效果综合评价向量:
'0 0.06 0.16 0.4 0.38、
B= A o R= (0.2, 0.4, 0.4) X 0.075 0.08 0.145 0.405 0.295 =(0.078,
、0.12 0.18 0.33 0.26 0.11;
 
0.116, 0.222, 0.346, 0.238)
综合计算得出评判结果,D公司“智慧工程”主要实现功能的综合评价结果差、 较差、中、较好、好的比重分别为0.078, 0.116, 0.222, 0.346, 0.238,按照最大 隶属度原则,评价结果为较好。
整体来说,D公司“智慧工程”主要实现功能的综合评价较好,但在风险管控 能力方面的综合评价为中,还有着较大的改进空间。
535实施注意事项
在项目实施过程中,项目团队总结了本项目实施SCRUM框架过程中的几个 要点:
5.3.5.1重视需求评审会
需求评审会是项目研发团队与信息系统需求方进行充分沟通的一个平台,它 将展现项目研发团队对需求的理解,并与需求方达成共识,是避免日后返工的重要 环节。展示方法通常有流程图、框架、思维脑图、原型模型等。由于本项目采用了 原型设计对主要业务流程和关键交互方式对系统原型进行搭建,提高了视觉效果, 让需求方更直观地看到未来系统的样子,减少后期的改动,这是保证项目进度的较 好办法。普通的信息系统项目可以用“墨刀”等软件来搭建原型。
5.3.5.2重视三个工件
产品待办列表、冲刺待办列表、产品增量是SCRUM框架下体现“透明、检 验、适应”三项内容的三个输入、输出工件。
(D产品待办列表简洁地体现了项目需求、任务清单和优先级,能够很好地 体现用户需求,要将对产品待办列表的管理放在第一位。
(2)产品冲刺列表对于每一次冲刺计划的完成至关重要。在规划Sprint时要 注意:
一是强调尽可能多的干系人参加Spint计划会议,需求方可以更好地对“用户 故事”需求进行阐述,系统研发人员可以对需求提出自己的见解,对目前技术手段 或其他原因暂时不能实现的需求,引导需求者可以暂时放弃或者使用其它替代方 案,有效地进行双向沟通。最大程度地保证需要开发的需求能够更好地满足使用者 的需求,尽可能低地降低系统开发风险。
二是要能够拆解足够细的任务。产品冲刺〔迭代)列表中的任务是将优先级高 的用户故事或需求并且在计划会议中确定要实施的,需要细化为有一定颗粒度的 任务,以便研发人员理解实施。因为SCRUM模式下不需要复杂的设计文档,而是 通过对需求的讨论和对用户故事的拆解近似于一个快速的集体设计,形成产品冲 刺(迭代)列表的一项任务作为研发人员的需求任务。
三是要对工作量进行合理的估算。通常按故事点进行估算。首先确定基准故事 点,即:将一个常见的、容易理解的功能任务作为一个基准故事点,再通过对比工 作量的形式,在这个工作量上叠加故事点。如:将一个简单的“查询页面”的功能 任务作为一个基准的故事点,另一个功能任务如“查看个人信息”的工作量与“查 询页面”的工作量差不多,则“查看个人信息”的故事点也是1。如果“个人信息 管理”的用户故事要复杂一些,工作量大约是“查询页面”功能实现的3倍,那么 这个故事点就是3。产品冲刺(迭代)列表中的用户故事所需的故事点数,就是该 阶段项目团队需开发的任务量。其次是要估算团队的速度。在实际工作中,团队成 员的每一个人并不是都能够将100%的时间和精力投入到系统建设中,他们可能还 会有会议或其他临时的事项需要处理。每次估算研发人员都要估计自己研发任务 所需的时间,再累加所有团队成员的研发任务所需的总时长,最终判断是否能够完 成本次冲刺的所有任务。如果做完估算后,发现本次迭代的累计工时超过了团队的 开发速率,需要做更详细的评估,看哪位团队成员工时过多,其他团队成员是否能 协助开发,是否能够将某些任务或者部分用户故事推到下一个阶段。本项目团队在 实施了 2次以上的迭代之后,便可以大致确定团队的开发速率,后期的工期估算 就会更准确。
四是要对用户故事进行优先级排列。编排优先级有以下原则有以下三点:首先 是最有价值的用户故事优先。因为要保证系统的研发顺序与使用者的业务需要进 行匹配,不能由研发人员自己拍脑袋定优先级,避免出现耽误最有价值或最具需要 的系统功能研发。其次是最基础的、能够支持其他系统功能的用户故事优先。因为 这是下一项任务的紧前任务,必须优先开发,并能够保证系统的最终研发时间。最 后是根据研发人员的工作先后顺序来排列用户故事优先级。如果同一个研发人员 被分配了多个用户故事的开发工作,则需要根据这位研发人员的工作顺序来排列 优先级。这样通过业务价值、功能基础性、支持性评估以及用户故事之间逻辑性评 估和人员完工优先顺序评估,达到对用户故事优先级的合理编排。
(3)产品增量是一个Sprint周期内完成的所有产品待办列表中的项目总和。 它是SCRUM模式下通过“小步快跑”实现价值交付的重要一环。因为敏捷开发倾 向于让需求方尽快看到交付成果,产品增量就是最终交付并集成发布的特性。它必 须达到以下要求:满足高质量符合规划前的定义标准才可以发布;必须满足产品负 责人、客户或使用者的使用功能。
535.3重视冲刺过程中的进度管控
进度管理是项目管理的重要目标之一,也是本研究的重点研究对象oPrince2的 流程管理方式对于优化项目管理流程和进度管理是有效的,但也不能忽视传统的 项目管理工具,如甘特图,它是进度管理的基础工具之一,通过Project制定项目 进度计划,能够更好地进行分阶段实施冲刺。分阶段对进度、质量做好管控,也是 本研究能够有效实施的一大举措。所以,使用SCRUM模型融入原型元素对瀑布 模型进行优化,在经典项目管理工具Project、看板、燃尽图等辅助下,促进了 D公 司信息系统项目管理得到改善。
S.3.5.4重视冲刺过程中的特殊情况
SCRUM模式下,项目的执行过程主要是冲刺的过程。Sprint执行过程中可能 会遇到以下情况:
(1) 冲刺失败的情况
SCRUM模式下强调敏捷,沟通较多、周期较短,一个Sprint周期内的任务较 少,因此,一次Sprint任务完全失败的可能性较小,多数情况下只有部分失败或者 需要终止Sprint的情况。部分失败的原因是可能没完全实现本阶段的全部计划任 务,或者系统功能测试失败。处理方式是:不要增加Sprint的时间,而是要按时进 行Sprint评审和回顾,作为问题和经验教训进行记录。未完成的工作任务或未通过 测试的功能放回产品待办列表,按照Sprint规划进行下一个周期的评审、规划。如 果出现某个Sprint被提前终止的情况,则在终止这个Sprint时启动下一个Sprint。 没有完成的用户故事放回产品待办列表重新评审,已完成的工作任务按特性增量 任务进行评审。避免造成需求缺失或资源浪费。
(2) 需求变更的情况
在Sprint执行期间发生需求变更,由产品负责人评估变更的需求是否能够对 完成本Sprint周期中的项目任务起到促进作用,如果是,则在不改变Sprint周期的 情况下,将此需求加入冲刺待办列表;如果需求影响本冲刺的实施,则将这个需求 列入产品待办列表,在以后的需求评审会或Sprint计划会中进行评审;如果是本冲 刺阶段的需求任务变更,则要停下来重新修改产品冲刺列表,在剩余的时间内完成 修改后或剩下的工作;如果修改后或剩下的工作不能按期完成,则按部分冲刺失败 的情况处理。
(3) 需求不确定的情况
D公司基于水电站建设的信息系统与实际工程相结合,存在着很多不确定因 素,导致了信息系统的很多需求不确定。解决需求不确定的方式主要有3种3】: 一是对于试探性质的需求。某些需求只是需求人员的一个想法,想试探一下当前技 术是否能实现,可以通过解释或用原型模式先来响应者需求者,确定是不是这样的 需求再往后推进。二是对于研究性质的需求。是指就目前研发团队所掌握的技术而 言,暂时无法实现需求方的需求,可以通过提出一种指导性的、宽泛性的、展望式 的方式来解决,或者通过研讨,设立新的课题,尝试用新的技术、新的手段来研究 或解决这个课题,以获取的新的知识或新的解决办法,尝试探索有哪些可选技术或 可选方法,以供未来的系统建设借鉴使用。三是对于追踪性质的需求。一些需求太 过于理想,暂时无法细化,经评估也无法通过研究的形式进行课题研讨,则通过沟 通放弃需求或简化弱化需求的方式来达成任务炉】。
5.4本章小结
本章在第3章査找问题、第4章提出解决措施的基础上,对优化后的方案在 D公司信息系统建设项目管理中的应用进行研究。
本研究的思想是用SCRUM敏捷模型融入原型元素,优化瀑布模型,利用 Prince2的执行流程(启动、阶段内控制、阶段边界管理、收尾等环节)进行系统 开发。在启动阶段利用SCRUM思想成立了项目团队,并进行氛围营造,在机制上 对D公司项目管理团队进行了改变;在流程上用SCRUM敏捷模型融入原型元素, 优化瀑布模型;阶段内控制从抓好用户故事收集、整理需求待办列表、完善冲刺待 办列表入手,通过强化沟通、交流、意见反馈等做好需求收集和分析,体现执行的 效果,通过每日站立会进行过程监控;整个需求待办列表体现了整体的项目计划, 使用Project对确定了的阶段冲刺待办列表进行阶段计划安排,每日站立会对当天 的工作进行安排;阶段边界抓好Sprint计划会/启动会的始边界管理和Sprint评审 会/回顾会的末边界管理;最后做好收尾。
在这个过程中,用户故事、需求待办列表、冲刺待办列表体现了对系统建设的 需求收集和分析环节,加快了对需求的响应速度;每日站立会、Sprint计划(启动) 会、Sprint评审会、回顾会、需求评审会促进了人员的交流;分阶段实施、按天对 工作情况进行监控,强化了项目执行,有效地把控了项目进度。
论文最后对实施效果进行了评估,无论是在影响D公司信息系统建设中的需 求管理问题、沟通管理问题、进度管理问题还是在项目的整体效果方面都得到了改 善。通过验证,用SCRUM敏捷模型融入原型元素,优化瀑布模型是有效的。
第六章总结与展望
6.1总结
6.1.1总结
论文从改进D公司“智慧工程”信息系统建设项目管理出发,利用SCRUM敏 捷方法融入原型元素,优化了瀑布模型在D公司“智慧工程”信息系统建设项目 的实施方法,解决了D公司在信息系统项目管理中存在的一些问题,推进D公司 在团队、需求、沟通和进度等方面的管理,促进项目保质保量甚至提前完成。研究 得出以下结论:
(1)结合实际情况选择合适的研发模型,使之更好地推进项目的开展。本论 文针对D公司“智慧工程”信息系统建设中存在的需求管理、沟通管理、团队管 理等方面存在的问题,进一步分析造成D公司信息系统项目进度延期的情况,用 SCRUM敏捷流程融优化了 D公司“智慧工程”信息系统项目的实施方法,解决了 相应的问题,推进项目顺利实施,并改进了相应的管理模式。
(2)收集需求时要简单快捷,后续的沟通与跟踪反馈要跟上。为了能够快速 地满足需求,加快研发速度,SCRUM模式下的“用户故事”能够简化需求方对需 求的文档描述,通过产品待办列表、冲刺任务列表对需求进行管理;用需求评审、 迭代评审等方式进行沟通,能够更好地理解需求、响应需求。同时,对需求研发进 行优先级排序、开展原型开发和迭代,推行阶段性交付,确保能够在最快的时间内 完成研发。通过Sprint计划、每日计划对项目进度进行管控;通过项目里程碑和分 阶段冲刺实施对项目进行推进;用“禅道”这个辅助工具和燃尽图、看板等辅助手 段让项目进度管理更直观。这些措施保证了项目能够有效地实施,保证进度能够可 管可视可控,降低项目延期的风险。
(3)有效的沟通方式让工作效率更高。SCRUM模式下搭建了需求评审会、 Sprint计划会、Sprint评审会、Sprint回顾会、每日站会等形式,加强了团队成员之 间、需求方与研发人员之前的沟通,并增加了沟通频次和沟通内容,同时对每日站 会要沟通的内容进行了模版化的规定,提高了沟通效率。
(4)辅助工具让过程监控更有效。本研究利用Project制定项目进度计划,包 括整体项目和冲刺任务,在优化关键任务之后,首先保证了进度计划在可控范围。 再通过看板、燃尽图在每日站会上的使用,有效地监控着项目的实施,在保证项目 进度方面起到了很好的支撑作用。
本论文提出的利用SCRUM敏捷方法融入原型元素优化的瀑布模型,保留了 传统的项目管理的里程碑管理、阶段内的进度管理,优化后的方法按里程碑进行了 阶段分解,在每一个冲刺阶段使用“用户故事”、需求待办列表、冲刺待办列表对 需求进行了收集、分析和设计,“开发、集成、测试”等环节遵循了瀑布开发模式, 实现每一个阶段都有成效交付,通过“敏捷”思想和相应的项目管理工具提高了研 发效率。经过验证,本研究的模型更适用于初始需求不明确、后续需求变更多的信 息系统研发中。并总结了研究模型在团队、沟通、需求、进度、研发成果等管理要 素中的特点、注意事项及适用范围如表6-1所示。
表6-1论文研究模型的特点及适用范围
管理要素 特点 注意事项 适用范围
团队 (人员) 自组织、跨职能,面对面沟通。 对人员素质要求 高,强调学习和成 长,突出重点和高 效。 需求不明确、变化 多,对文档要求 少,尤其适合有强 烈要求产生阶段 成果的项目。
沟通 沟通多,问题导向,突出重点,不需 要过多的文档资料。
需求 初始需求不明确,可借鉴的模型、流 程、经验少,后续需求变更多。
进度 按里程碑分阶段管理,按重要性和 优先级进行开发,过程管控力度大。
研发成果 基本上每一个冲刺阶段都能产生可 交付的成果,提高研发效益
 
6.1.2不足
由于个人研究水平有限,论文还有很多不足之处:
(1) 传统的系统开发模型与敏捷模型在项目进度管理方面还有着更深的领域, 敏捷方法中也还有很多框架,论文只将要使用的SCRUM框架与其中的一些进行 了简单的对比,并不一定全面,需要在今后的实践中深入学习、探讨和研究,将更 多的项目管理方法和敏捷思想运用到实际的工作中。
(2) 论文立足于D公司实际,提出了优化信息系统建设的模型,只是一次对 于敏捷模型使用的探索和尝试,研究不够深入,研究结论也许只适用于D公司, 由于行业和单位的实际情况不同,对其他行业、其他公司的信息系统建设项目不一 定能适用。
(3) 论文中的故事点数评估法在当下有规划扑克甚至是电子规划扑克,这在 研究中没有应用到,需要在以后的实践中探索应用。
6.2展望
信息系统项目管理过程伴随着信息系统建设项目的始终,随着系统研发行业 的不断发展,对信息系统项目管理方式的改进研究将是一个长期持续的过程,论文 提出的利用SCRUM敏捷方法融入原型元素,优化了瀑布模型在这个项目的子系 统中取得了成功,但“敏捷”思想在D公司的应用还有很长的路要走,且该项目 只对“敏捷”思想为解决进度问题进行了探讨,“敏捷”思想在项目管理的范围、 质量、风险等其他方面的研究还需要加强。另外,大型复杂项目是多个小项目的组 合,SCRUM框架下团队规模不宜太大,因此,项目团队会拆分成多个SCRUM团 队来完成国]。这需要有很强SCRUM理论和经验的敏捷教练来指导,待敏捷思路 应用熟练后于大范围推行。
致谢
首先,我要感谢我的母校电子科技大学!感谢您的“求实求真、大气大为”的 教育理念!感谢所有老师的谆谆教诲!从备考研究生开始就是一个项目管理的过程, 这个经历是我永远的财富!今后的路不管有多远有多难走,我都会一直前行!所学 的知识将伴随我左右!
其次,我要感谢我的导师黎亮先生!本论文从选题、框架搭建到写作和成文后 的修改,都是在黎老师的精心指导下进行的,老师对论文的标题、观点、结构、内 容等方面提出了很多宝贵的意见,并帮助我进一步学习相关理论,尤其是PRINCE2 项目管理的理论知识及其运用。他用明朝-清朝的发展史来讲解PRINCE2项目管 理理论,即生动、又使人难忘。老师有趣有料、别开生面的课程,让我们把上课当 成了一种享受,犹如在知识的海洋里畅游。黎老师对学术要求严谨,对学术道德要 求规范,让我终身受用。老师不仅在论文撰写上指导我顺利完成,更是在人生的路 上为我指明了方向。老师对我的教导终身难忘!再次对黎老师的指导表示衷心感谢!
再次,我要感谢我的家人!你们的理解,让我能够花更多的时间在学习上;你 们的大力支持,使我顺利“上岸”;你们的相伴,让我在成长的道路上没有孤单! 在我论文即将完成之际,给你们一个大大的拥抱!感谢理解、支持与相伴!
最后,感谢我的校外指导老师提供的帮助!感谢同师、同班、同组的同学们给 我无私的关怀!感谢各位审阅、评审论文的老师的辛勤评阅!
参考文献
[1]黎亮,肖庆钊,宋瑾.《项目管理——PRINCE2+PMB0K》[M].清华大学出版社,2015
[2]涂扬举.《智慧企业一一框架与实践》(第二版)[M].经济日报出版社,2018
[3]Royce W.W.,Managing the Development of Large Software Systems:Concepts and
TechniquesfC], NY, USA, IEEE Computer Society Press, 1970, 329-330
[4]袁夏•敏捷项目管理在人力资源开发系统中的应用研究[D].上海:上海交通大学电子信息 与电气工程学院,2017
15]武红兰•敏捷开发在A公司信息系统项目进度管理中的应用研究[D].北京:北京交通大 学,2019
[6]张友生,李雄.信息系统开发模型研究综述[J].计算机研究与应用,2006(3),109-115
[7]林正奎,杨德礼•信息系统开发模型研究:发展、问题与挑战[JJ.计算机应用研 究,2005(3),6-9
[8]Boehm B.W., A Spiral Model for Software Development and Enhancement [J]. IEEE Computer, ]9 込 11(5):14-24
[9]Chrissis B., Konrad M., Shrum S., CMMI: Guidelines for Process Integration and Product Improvaiient[M]. MA, USA? Addison-Wesley? 2003, 58-60
[10]邓景毅,叶世绮,郑欣•信息系统成熟度模型(CMM)发展综述[几计算机应用研
究,2002(07),69 .
[11]唐俐威•信息系统开发的敏捷管理方法应用研究[D].哈尔滨:哈尔滨工业大学,2006
[12]Booch G.? Jacobson I.? and Rumbaugh I, Unified Modeling Language 1.3, White paper[M]. NJ, USA, Rational Software Corp, 1998,28-30
[13]Martin R.C.f Agile Software Development: Principles, Patterns, and Practices[M].NJ? USA, Prentice Hall, 2003, 33-34
[14]Koch A.S.j Agile Software Development: Evaluating the Methods for Your Organizations[M]. MA, USA: Artech House, 2005, 360-373
[15]许秀影.敏捷项目管理:基础知识与应用实务[M]冲国电力出版社.2016:27-28,31-35,49-53
[16]Schwaber K. SCRUM development process: Acm Conference on Object Oriented Programming Systems, 1995[C].1995: 117-134
[17]Moe N B, Dingsoyr T. SCRUM and Team Effectiveness Theory and Practice[J]. Lecture
Notes in Business Infonnation Processing, 2008,9(9): 11-20
[18]Martin R. Agile Software Development: Principles, Patterns, and Practices[M]. 2003: 173-222
[19]Sutherland J, Future of Scrum: Parallel Pipelining of Sprints in Complex Projects: Agile ConferencefC] .2005: 1-10
[20]Schwaber K. Agile project management with SCRUM[M]. Shanghai World Publishing Corporation, 2007: 35-47
[21]MikeCohn. SCRUM敏捷信息系统开发[M]•清华大学出版社,2010: 97-115
[22]MikeCohn.用户故事与敏捷方法[M].清华大学出版2010: 15-25
[23]Rubin K S. Essential SCRUM: A Practical Guide to the Most Popular Agile Process[M]. Addison-Wesley Professional, 2012: 324-346
[24]Gutierrez G, Garzas J, de Lena M T G, et al. Self-Managing: An Empirical Study of the Practice in Agile Teams[J]. IEEE Software, 2019,36(1):23-27
[25]魏永涛.工作分解结构WBS技术[J].中国高新技术企业,2011(25):50-52
[26]宋庸.电子消费公司新产品开发进度管理[J].企业技术开发,2017,36(01):130-132
[27]罗守成.计划评审技术中的延误惩罚问题[J].上海第二工业大学学报,2005
[28]叶平.基于PERT/CPM的甘特图应用研究[J].浙江建筑,2011,28(3):72-74
[29]石慧.信息系统开发项目的进度计划与控制研究[D].武汉:武汉理工大学,2007
[30]蒋晓科•时间管理在信息系统项目中的应用[J].电脑知识与技术,2011,07⑸:1063-1064
[31]刘阳• IT项目工期估算方法的研究[J].西安建筑科技大学学报(社会科学版),2010
[32]武圆圆.L公司信息系统开发项目进度管理研究[D].北京:中国人民大学,2019
[33]沈成莉.敏捷项目管理在信息系统开发中的实践应用[D].上海:复旦大学信息科学与工程 学院,2009
[34]中国敏捷信息系统开发联盟ADBOK编写组.敏捷幵发知识体系[M].清华大学出版 社,2013
[35]闫帅,许鹏翔.基于瀑布模型与敏捷开发相结合的项目管理方法探讨[JJ.电子技术与信息 系统工程,2013(18):67
[36]田莉•论如何借鉴敏捷信息系统开发方法来改进信息系统项目管理[C]//第三十二届中国 (天津)2018!IT,网络、信息技术、电子、仪器仪表创新学术会议
[37]李文星.长城开发MES_HR信息系统项目进度管理研究[D].济南:山东大学,2015
[38]颜海剑,肖俊超,李怀璋•基于挣值的SCRUM信息系统过程人力资源调度方法[J].计算机 工程与设计,2009,030(002):460-464.2013:1 -24
[39]陈国栋,罗省贤.SCRUM敏捷信息系统开发方法实践中的改进和应用[J].计算机技术与发 展,2011,21(12):97-99
[40]文俊浩,田清,李朋.SCRUM中软件缺陷管理方法的研究与应用[J].计算机工程, 2011,037(19):35-37
[41]夏维力,多彦彦,姜继娇.客户参与对SCRUM团队信息系统开发成功率的影响[J].科技管 理研究,2017,037(017):187-192
[42]孙杰成,颜锦奎.SCRUM敏捷开发方法在跨境电商平台的实践[JJ.计算机技术与发展, 2018,28(01):159-163
[43]郝品山.M医院智能建筑项目的进度管理研究[D].南京:东南大学,2019
[44]周彬祥.怎样进行IT项目进度管理[几现代企业教育,2014(8):493-494
[45]李志东.基于PRINCE2的S银行“智慧银行”建设项目群管理研究[D].济南:山东大 学,2019
[46]Brooks F. P,, The Mythical Man-Month: Essays on Software Engineering[M]. MA? USA, Addison-Wesley, 1995? 18-19
[47]董寒松.基于结构化方法和螺旋模型实施Web工程的探究[几微型机与应用,2005,53-59
[48]唐俐威「信息系统开发的敏捷管理方法应用研%[D],哈尔滨:哈尔滨工业大学,2006
[49]孙丽萍,王云光,诸敏.敏捷软件过程的研发与实践[J].计算机工程,2007,33
[50]项目管理协会.敏捷实践指南[M].北京:电子工业出版社,2010(10):35-37
[51]彭家旺.敏捷项目管理在F公司软件开发项目中的应用研究[叨.济南:山东大学,2019
[52]丁平进.SCRUM敏捷方法在电子商务研发项目中的应用研究[D].哈尔滨:哈尔滨工业大 学,2017
[53]陈华恩.SCRUM敏捷方法在湖南翼方信息系统开发项目管理中的应用研究[D].长沙:湖 南大学,2014
[54]李国彪.SCRUM敏捷项目管理实战[M].清华大学出版社,2009:8-9
[55]Sims C. The elements of SCRUM [M].人民邮电出版社,2013: 16-28
[56]Babar M A, Paik H. Using SCRUM in Global Software Development: A Systematic Literature Review [J]. IEEE Computer Society, 2009: 90-93
[57]SCRUM 中文网.什么是 SCRUM[EB/OL]. http://www.SCRUMcn.com/agile/SCRUM-kno wledge-library/什么是 SCRUM.html, 2020
[58]国电大渡河流域水电开发有限公司,三峡高科信息技术有限责任公司•四川大渡河双江口 水电站工程管理信息系统建设方案•成都:国电大渡河流域水电开发有限公司,三峡高科 信息技术有限责任公司,2016
[59]王慧娟•基于云计算的会计大数据分析平台构建研究[D].太原:山西财经大学,2015
[60]苗东升.系统科学精要[M].北京:中国人民大学出版社,1998,238-269
[61]王厚量.SCRUM方法在T公司软件项目管理中的应用研究[D].成都:电子科技大学,2017
[62]Salah D, Maturity Models in the Context of Integrating Agile Development Processes and User Center Design[DJ. University of York Compute Science PhD, 2013(6): 19-28
[63]余泽斌.基于敏捷方法的研发团队管理研究[D].北京:北京邮电大学,2014
[64]国电大渡河流域水电开发有限公司•国电大渡河智慧企业建设之智慧工程建设管控平台 建设方案.成都:国电大渡河流域水电开发有限公司,2016
[65]Pham A., Pham P.V.,崔康(译),SCRUM实践——敏捷信息系统项目管理与开发[M].北京: 清华大学出版社,2013,124-126
[66]Khamooshi H, Golafshani H. EDM: Earned Duration Management, a New Approach to
Schedule Performance Management and Measuranent [J]. International Journal of Project
Management^ 2013 (32): 1019-1040
[67]刘凌.A公司C3项目进度管理分析与应用效果研究[D].北京:北京邮电大学,2019
[68]颜烈川.D公司基于SCRUM管理信息系统研发流程优化[叨.广东:暨南大学,2019
[69]马国丰,屠梅曾.制约因素在项目进度管理的应用[J].管理工程学报,2002,16(4): 72-75
[70]肖华琴.北京市燃气工程项目进度管理的研究[D].北京:北京建筑大学,2014
[71]施策•基于敏捷开发的软件项目管理与研究[D].昆明:昆明理工大学,2020
[72]罗志坚.敏捷项目管理在S公司开发项目中应用的研究[D]•贵阳:贵州大学,2017
[73]邱强•敏捷开发在软件开发中的应用[J].科技咨询,2009(20):5
[74]国电大渡河流域水电开发有限公司,四川大学.大渡河公司工程建设项目管控模型.成都: 国电大渡河流域水电开发有限公司,四川大学,2016
【本文地址:https://www.xueshulunwenwang.com//guanlilei/xiangmuguanli/6364.html

上一篇:Y软件公司基于PMO的多项目管理组织硏究

下一篇:精装修工程项目管理研究一以北京万豪酒店 装饰工程为例

相关标签: