我们在本网站上使用 Cookie 和类似技术(“Cookie”)。为了允许 Cookie 分析网站使用情况并提升功能性,请点击“接受”。如需选择授权我们使用哪些特定的 Cookie、更改您的设置或获取更多的详细信息,请点击“详情”。

详情

拒绝

接受

您可以在下面激活/停用本网站上使用的个别技术。
全部同意
需要

这些 Cookie 通过提供基本功能(如:页面导航、语言设置,以及对网站受保护区域的访问权限),以便您能使用网站。由于本网站在无此类 Cookie 的情况下将无法正常运行,故您无法退订此类 Cookie。

功能

这些 Cookie 通过保存诸如您的设置、选择和过滤器等,用以在后续的访问中识别您的设备,从而帮助我们改善网站的功能性和吸引力,并提高您的用户体验。

分析

这些 Cookie 允许我们和服务提供商(如:Google 通过 Google Analytics 服务)收集和分析有关您与我们网站互动的信息和统计数据,以便通过获取的信息优化我们的网站。

发展项目的管理。弥合两个世界的差距

开发项目经理(DPM)每天都会遇到各种各样的挑战,从与客户密切合作安排发布和时间线,定期向指导委员会报告,到与开发团队的日常工作和与解决方案架构师的技术讨论--同时也不要忘记与总项目经理的全面协调。

敏捷地按计划工作

如今,Scrum已经深入人心,大多数人至少都熟悉敏捷团队和工作方法。这在软件开发中尤其如此。年轻的开发者很少接受诸如时间线、截止日期和瀑布模型等概念。开发很少是一个线性过程:意外的绊脚石和不断的重新安排被认为是正常的。正是这个世界催生了敏捷工作方法,也正是这个领域如今使用最多的方法。

当敏捷工作的世界与历史悠久的汽车发动机制造商的需求结合在一起时,事情就变得非常激动人心了,他们仍然重视仔细规划和遵守最后期限等品质。为汽车制造商工作的IT项目经理们很清楚,管理层需要一个精心设计的时间表。大多数决策者都不喜欢听天由命,这就是为什么这个时间表必须涵盖从开始到结束的一切,从接收需求和监督生产到交付软件。因此,制造商希望被委托开发软件的公司也能表现出这些品质,这并不令人惊讶。

发展项目管理者:弥合差距

敏捷工作和传统的项目管理都有其优势。长期的软件开发项目没有其中之一就无法运作。这就是为什么拥有在两个世界中都游刃有余的同事,在两者之间架起桥梁是至关重要的。这就是DPM的关键技能之一。他们在客户对结构和仔细规划的渴望与开发过程的现实及其往往不可预测的性质之间取得平衡。

设定场景:物流控制发展项目

本案例研究了一个项目,在这个项目中,我们的一个客户被委托用一个更现代的物流控制系统来取代现有的物流控制系统。由于现有的软件包含了许多针对终端客户的不同解决方案,未经调整的标准软件只能满足一些必要的要求。调整现有软件以满足最终客户的具体需求的过程将是非常复杂和耗时的。由于项目启动的延迟,以及一些开发人员同时在从事其他项目,使情况变得更加具有挑战性。由于我们的客户当时没有足够的能力来管理他们几年来最大的开发项目,他们委托杜尔咨询公司接管开发项目的管理。

对您的好处

  • 我们在敏捷工作和传统项目管理之间架起了一座桥梁--并能在两种系统中同样有效地工作。
  • 久经考验的项目管理办公室服务:我们始终密切关注时间、质量和成本。
  • 在汽车工程和一般制造业方面有长期的项目经验

组织和沟通超过编程

我们已经探讨了DPM是如何在敏捷和传统项目管理之间起到促进作用的。现在我们来看看DPM到底是做什么的。他们的主要职责是组织和沟通;虽然目标是生产出能正常运行的软件作为最终产品,但DPM一般不参与编程方面的工作。他们的工作重点是收集和组织大量的信息,根据目标受众的需要进行调整,并与相关的利益相关者分享和讨论。在一个典型的星期里,这个开发项目的DPM将组织和领导与不同利益相关者的以下会议(如下图所示)。

每天与开发部门的核心员工开会(称为样片)。15分钟的日会的目的是检查每个人所取得的进展和面临的障碍,并处理开发团队内部无法解决的任何障碍。

每周的内部管理会议。除了提供当前开发工作的最新情况外,这些会议的目的是商定措施,帮助克服开发团队内部无法解决的障碍。

与客户的Jours fixes。与最终客户的定期沟通是任何成功开发项目的重要基础。这就是为什么参与项目的人组织了一次固定的会议。该会议由DPM、一般项目经理和终端客户方面的项目经理参加。他们将讨论与按计划实施项目有关的一切问题。这包括发布时间表和时间线,以及当前的技术挑战。

每两周还有一次SteerCo项目会议,由项目经理和两家公司的高级管理层代表参加。会议的主要目的是提供当前项目状态的更新,但它也是一个升级和决策委员会。

虽然结构化程度较低,但DPM和开发团队负责人之间的关系也很关键:他们必须紧密合作,坦诚相待。开发负责人对他的团队了如指掌,如果需要的话,可以在短时间内提供必要的资源。

复杂软件项目的时间表

正如西塞罗曾经说过的,"在开始之前,要仔细计划"。德怀特-D-艾森豪威尔也持同样的观点。"计划是没有价值的,但计划是一切"。传统的项目管理和敏捷工作之间的对比,最明显的莫过于项目调度。前者依赖于具有明显阶段性的长期计划,而后者则更倾向于对数据做出实时反应的短期计划。至于完成一个 "史诗"(敏捷术语,指一个目标下的较大工作单位)需要多少时间,软件开发人员的估计可能相差三倍。根据定义,开发任务涉及到创造新的东西,而这往往意味着你不能从过去的经验中吸取教训。因此,对时间的估计仅仅是估计而已。这种高度的不确定性是由技术风险和组织风险造成的,比如关键员工的缺席。另一个常见的风险是,软件开发人员对目标的理解往往与客户的理解不同。任何参与软件开发的人可能都听过这样一个有趣的比喻:这种情况就像一个在对立位置上来回移动的秋千,从客户的描述到项目经理对其描述的理解,再到程序员的工作,最后到客户的实际需要。这往往会导致一个花费了大量时间和精力制作的软件产品,但却不能实现最终客户所需要的附加值。处理这些一般不确定因素的一个屡试不爽的方法是将应急因素纳入进度计划,以备出现意外的延误。然而,在这个特定的案例研究中,在杜尔咨询公司接管DPM角色之前,时间线已经确定。

动态的、基于数据的规划

DPM和客户软件开发团队的负责人就一种动态的、基于数据的规划方法达成一致。这在现实中是什么样子的呢?我们的客户正在使用 "Jira "软件进行内部运作。这允许你在故事和/或史诗级别上估计开发工作的持续时间,然后将每个故事分配到计划的发布中。它还可以让你更新开发团队的能力。

Jira使用这些信息在甘特图中创建一个动态计划,根据最新的工期估计,清楚地显示哪些阶段将在哪个版本完成。每个故事的实际持续时间是根据开发人员记录的时间自动记录的。如果个别阶段需要的时间比最初计划的多,时间表会自动调整,关键路径也会重新定义。如果由于特别长的延迟,向客户传达的发布日期可能无法实现,就很容易提前看到。这就给了DPM更多的时间来应对滞后的情况。

调度的成功始于需求工程师

系统的需求管理是确保创建的软件功能与最终客户的实际需求相一致的关键。在第一次委托Dürr咨询公司时,在与所有利益相关者举行的全面的经验教训会议上,很明显,产品所有者(POs)在过去承担了许多角色。需求工程师的新角色是根据会议的要求而设立的,目的是释放出更多的POs的能力,使他们专注于自己的核心职责,并引入专业的需求管理系统。然后,需求工程师开发了一种方法,以确保将需求无缝集成到Jira开发环境中。由于他的角色是专门负责需求管理的,他能够与最终客户的项目经理更紧密、更深入地合作。这意味着绝大部分的开发工作实际上是直接针对客户的需求。由于减少了为解决对最终目标的误解而进行的bug修复,准时性和生产力都得到了提高。

软件开发也需要清晰的结构

导致汇款的交叉。交叉往往会导致沟通问题和定义责任的困难。这就是为什么Dürr咨询公司与开发团队一起开发了一个特殊的流程,如图2所示。该图描述了软件开发过程的不同阶段(第1行),相关的要求(2),谁在内部负责实现这些要求(3),以及为实现阶段目标需要与客户进行哪些互动(4)。流程概述的最后是一张列出相关文件的流程图(5)和 "准备就绪的定义"(DoR,6)。

这使我们能够确保更大的透明度,并在早期发现交叉问题。在这个过程中,DPM负责管理交叉问题。这意味着确保上游阶段进行的初步工作的要求在每个后续阶段之前得到明确的沟通。一旦引入该流程,样片就会根据概述进行结构化设计,并集中于某个交叉话题。

不断改进需要时间,但会有回报

围绕这个项目的条件非常具有挑战性。与其他项目相比,其范围、复杂性和时间压力都要大得多。面对这些新的挑战,我们客户的组织能够不断发展。发展的起点是第一次委托杜尔咨询时的经验教训会议。对薄弱环节进行公开分析的结果导致引入了需求工程师的新角色,一个具有明确交叉点的定义明确的软件开发过程和一个使用现代工具的基于数据的时间表。虽然将新的流程落实到位需要时间,但它很快带来了明显的改进。内部角色的明确分配使团队能够有效地完成流程。客户也清楚地看到了速度提高和质量提高(而不是妥协)的好处,他们在反馈中说:"最后一个版本在功能方面取得了巨大的进步","很明显,开发团队了解我们想要实现的目标"。对我们来说,这证明了我们不断改进的努力得到了回报。

摘要

DPM对于大型开发项目来说是至关重要的,因为他们监控着许多内部和外部的交叉问题,但他们不能解决所有的问题。在每个参与者之间进行激烈的讨论并不能保证软件会按计划发布,但当问题和延误发生时,它对于尽快找到建设性的前进道路是至关重要的。能否实现这一点最终取决于外部项目管理与客户内部流程的整合程度。在一个理想的情况下,项目经理只是在有限的时间内参与,这一事实不应该在项目的日常运行中显现出来。