项目开发在汽车行业中的变化——敏捷方法（一）

前言：本文延续前文，继续与诸君分享敏捷型项目开发的相关知识内容。在汽车行业中，传统的项目开发形式是以预测型项目生命周期为主的由瀑布模型演化而来的V模型进行开发的。在这个行业中，对于正在或已经接触到敏捷方法的大多数小伙伴来说，想来都是从传统的项目管理知识领域逐渐向着敏捷方法论转型的，或有的是以接触实际项目为契机从而开始接触到敏捷。

在这个过程中，无论大家是以何种方式接触到敏捷，对于传统的项目管理知识体系都应有所了解，毕竟敏捷不是凭空出现的，它是在传统的项目管理知识中演化而来的，用以补充快节奏的项目开发形式。

项目管理是一种知识体系，因此若以碎片化的方式向诸君传达相关内容，恐对诸君造成实际的困扰，同时对于想在这个领域有所发展的小伙伴而言是不利的，出于此种考虑，便打算从整体的知识体系出发，系统性的将敏捷内容以章节形式与诸君进行分享，并结合实际工作，尽可能做到浅显易懂，以便新晋小伙伴的理解。

文本主要分几大部分内容：敏捷概述、生命周期选择、创建敏捷环境以及在敏捷环境中交付。

1.敏捷概述

诸君可回想一下，在我们的日常工作之中，当我们接到一项任务时，我们是如何判断这份任务自己能不能完成的？想必大家首先都会在心里评估一下要完成这份工作所需的技能、知识、辅助等诸多方面都在自己的掌控之中，如此便对这份任务胸有成竹。但如果这其中的某一项超出了自己的预期，可能就会产生犹豫了吧。

其实这正是任务（项目）的特性所造成的，在日常工作中，项目开发工作可分为两类：可确定的工作与高度不确定的工作。

图1 项目类型

可确定的工作：车企启动项目之后，将需求释放给到供应商，在这份需求中已经明确了所需产品的硬件、软件、结构、功能等等，供应商按照技术要求组织团队进行相关开发工作，由于供应商在该领域的经验积累，在工作开展期间基本上不会出现频繁的变更，很顺利的便可按照计划将任务完成。业内小伙伴对于这个流程应该已经非常熟悉了。

高度不确定的工作：车企在启动项目之后，由于需要在一个新的领域进行产品的开发，对于该产品的实际功能、用户意向等等皆不是特别清楚，同时由于行业尚处于探索阶段，供应商在这方面同样没有经验积累，因此双方需要共同探索，甚至经常需要参考团队之外的用户的经验，以此来逐渐完成产品的最终状态。在这个过程中，许多的工作是不确定的，这类工作具有变化速度快、复杂、风险高等特点。

针对可确定的工作，我们通常是清楚在本阶段项目完成之后的下一阶段的工作内容，如此整个团队只需按部就班的按照流程进行便可，这便是我们通常所说的预测法。但是对于那些具有高度不确定的项目，我们以传统的预测法便难以下手（因为不清楚接下来会发生什么），但是对于这类工作又不可能避免，怎么办？只能通过一点一点的去尝试，然后一旦发现问题，便及时调整方向再次尝试，如此敏捷方法便出现了。

图2 《敏捷宣言》四大价值观

注：敏捷是一切以实际行动为主，‘更重视左栏’不代表可以不关注右栏。在汽车行业中应该认为右栏的优先级可以滞后，但不是可以缺失。

图2 《敏捷宣言》十二大原则

所有的原则总结成一句话便是：通过有效的行动，尽可能快速的将可用的产品交付到客户手中，有不合适的我们就改，直到解决客户问题为止。

图3 敏捷思维

敏捷方法是一个囊括了各种框架和方法的涵盖性术语，它的使用不是唯一的，而是适时的、变动的，根据实际情况可以做出不同的改变。

图4 敏捷是许多方法的统称

我们在进行项目时，我们的目标绝不是为了敏捷而敏捷，而是‘为了向客户持续交付价值流，并达到更好的商业成果’，因此选择哪种方式进行项目并非是固定的，只要能将项目成果有效的交付给到客户那就是最好的。

不知道小伙伴们有没有遇到过这么一种情况：客户自己也不清楚自己最终想要一个具有什么功能的产品，只是很模糊的告诉你‘我感觉应该是这样’。面对这种情况，这个项目做不做？该如何做？

对于高度不确定的项目，返工的风险会大大增加，为了减轻这些风险的影响，团队需要选择一种合适的生命周期，以较少的工作增量去解决项目中大量的不确定性。换句话就是说，既然公司接了这个项目，但是甲方又不清楚自己想要什么，那就先给你做出一个简易版的产品，然后以此来试探甲方的真正意图。

有时甲方并非不将真正的需求明确下来，而是他们也不是清楚。既然如此，项目团队通过少量多次的交付成果，以此来刺探客户的潜在需求，最终引导出客户真实的需求。这里便涉及到了项目生命周期的选择。

图5 不确定性与复杂性模型

要注意，随着项目不确定性的增加，变更、无效工作、返工的可能性也将随之增加，这付出的不仅仅是高昂的代价，还有不可逆的时间。因此客户可以混乱，但团队必须要能通过明确稳定的管理要求规划和管理项目，这种方式也是可以随项目而变化的。

这就如在智能座舱的开发过程中，其基本功能、结构等是明确的，我们可以采用预测型项目周期进行，而在交互、适应性功能等方面，则可以采用迭代、增量或者预测+迭代等不同的生命周期进行。

项目开发在汽车行业中的变化——敏捷方法（二）

2.生命周期选择

2.1项目生命周期的特征

在日常工作中，我们常会听到‘项目周期’这个名词，这里需要明确一下该名词的含义：“项目生命周期指项目从启动到完成所经历的一系列阶段。它为项目管理提供了一个基本框架。不论项目涉及的具体工作是什么，这个基本框架都适用。这些阶段之间的关系可以顺序、迭代或交叠进行。”

无论是何种行业的何种项目，它都有一个通用的生命周期，其整体过程如下图所示：

图6 项目生命周期

项目生命周期可以是预测型或适应型。项目生命周期内通常有一个或多个阶段与产品、服务或成果的开发相关，这些阶段称为开发生命周期。开发生命周期可以是预测型、迭代型、增量型、适应型或混合型的模式，我们所说的敏捷便是适应型，它包含了迭代与增量。不同的生命周期具有的特征简要总结如下：

图7 不同生命周期特征

注：上表中的交付是指具有‘商业效用’的交付，即交付后可完成双方商务合同/技术协议等功能的交付，临时的中间版本并不算在内。比如在迭代型中，我们开发了一个ECU，但是常会遇到功能达不到预期的情况，因此就有中间版本的交付，而最终完成合同的交付只会有一次。通过上表的‘交付次数’，诸君可以判断自己所开发的产品是属于什么周期。

不同生命周期的项目我们可对照实际产品的开发，大体如下例子：

预测型：整车、传统控制器总成、结构件等的开发，这些产品的开发有着明确的需求，就如房子一样，知道要做什么，同时也知道每一步、每一阶段的工作，而且不太可能出现推倒重来的情况。预测型项目强调根据部门划分的、有效的、顺序的工作，并且通常不会在项目结束之前交付‘商业价值’（即具有商务要求的成果）。如果遇到需要频繁变更、技术实施难度不明确等情况，那么将会导致额外的成本支出。

图8 预测型生命周期

迭代型：知道要做什么，同时开发成果以非正式的方式交付，再根据反馈进行迭代，将错误/异常进行修正，最终交付一版具有商业效用的成果。比如开发一款VCU软件产品，先进行A版本交付，客户端进行验证之后，反馈某某功能未达到预期，于是开始了软件迭代。然后开始B、C版本的交付（如果未单独签订合同，那么这些交付都是非正式的），直到修正完成之后，交付一版冻结的版本以进行项目的验收工作。

对于项目复杂性高、变更频繁、范围不明确时，采用迭代型生命周期便更具优势，不过过程耗时可能会更长。

图9 迭代型生命周期

增量型：小范围内知道要做什么，由于时间关系，产品无法进行完整功能交付，因此只能先交付一部分。在新能源汽车高速发展期间，主机厂们为了尽快占领市场，都在想办法缩短产品的上市时间，于是便有了‘功能未开放’的产品，比如智能座舱/智驾等方面的软件开发，常有许多功能无法使用的情况。待产品推上市之后，再通过OTA技术对那些未完成的功能进行升级或添加。

图10 增量型生命周期

敏捷型：对于最终产品是模糊的，在这种模糊的状态之下，团队预料需求会发生变更。只能先通过迭代与增量的方式为项目提取到反馈信息，以便于项目进行下一部分的计划。通过增量的交付，可以发现客户隐藏或者错误的需求，便于将项目与客户需求保持一致，并根据需求进行适时的调整。

这是说随着项目的继续，初始计划的交付物与实际的工作可能会发生偏差，直到项目结束后回头一对比，发现最终的产品与最初计划的根本不是一个东西。但这已经不再重要了，重要的是客户需要的是最终的交付成果。

图11 基于迭代和基于流程的敏捷生命周期

在基于迭代的敏捷中，团队通过分析需求，提取出最重要的功能，接着进行实际开发，由于这个过程中的时间是一致的，所以有可能出现功能完成不了的情况，遇到这种情况的话，不要延长时间（做到哪算哪），然后将未完成的工作再次插入全部需求中，再次评估，重新得到最重要的任务。

注意：由于需求的不明确，因此详尽分析是不可取的（很有可能是无用功），而是通过完成小任务去拨云见日。

基于流程的敏捷，同样的通过分析需求，抓取出需求中的若干任务，然后按照团队的实际能力去完成其中的某个，这个功能不一定是最重要的，但一定是可完成的，待完成了任务之后，再去处理其他任务。任务的复杂度不同，因此完成任务的时间也是不定的，不过，要尽可能的让任务规模缩小化，以防止需求不明确带来的返工。

在上述所说的四种类型之中，所有的项目都具有这些特征，只是主导型是哪一种而已。项目是一个连续的过程，在不同情况下采用合适的方式灵活的对项目进行管控是项目经理人需要掌握的手段。

一个项目是否采用敏捷、预测还是混合，在之后的文章中也会介绍到敏捷筛选器，诸君可通过筛选器进行评估。

图12 项目连续生命周期

敏捷（三）——敏捷适用性筛选

如何判断一个项目适用于何种生命周期？除了项目管理人员自身所具备的资深经验得以判断之外，还有一种公式化的方法——使用敏捷适用性筛选工具，诸君在进行项目时可用其作为辅助工具使用，该工具旨在通过文化、团队和项目这三种适用性属性分别在三个维度的评估，可以帮助组织评估和讨论采用预测、混合还是敏捷方法来实施项目。

其做法是通过问卷调查的形式回答相关问题，回答者对问题进行1-10分范围进行打分（如果你是项目负责，那么就问自己），然后将结果在雷达图中进行绘制，该方式具有主观性，但问题不大：

文化支持方面：即是否有合适的环境。

对于组织内部，发起人是否了解并支持在该项目中使用敏捷方法？

图12-0 支持方法评估

对于组织外部，相关方确信凭借支持和双方反馈，开发团队可以将其需求实现？

图12-1 对团队信任度评估

对于开发团队自身，是否可以自主的进行如何实施工作的决策？

图12-2 团队决策能力评估

团队方面：

对团队规模进行打分。1-9人得1分，10-20人得2分，21-30人得3分，31-45人得4分，46-60人得5分，61-80人得6分，81-110人得7分，111-150人得8分，151-200人得9分，201以上得10分。

图12-3 团队规模评估

对团队经验水平进行打分。在团队中担任每种角色的人员的水平是参差不齐的，这并不影响敏捷的开展。为了更加顺利的开展敏捷项目，角色人员至少存在一名有经验的人员，如软件开发人员多名，但至少有一名是具有经验的。

图12-4 经验水平评估

团队与业务之间的联系评估。开发团队更多的注意力是在具体的开发工作上，团队是否每天都可以联系上客户代表/业务以获取相关的反馈？

图12-5 业务联系评估

项目本身方面：

对变更的可能性进行评估。每个月需求变更或发现新需求的可能性是多少？

图12-6 变更可能性评估

对项目的成果进行评估。如果项目交付的成果出现故障，将会失去或产生何种结果？

图12-7 产品关键性评估

增量交付评估。产品或服务是否可以按照比例构建？客户代表或业务是否可以及时的对所交付的增量进行反馈？

图12-8 增量交付评估

在进行了评估之后，可将结果在如下雷达图中进行绘制，可对组织采用何种生命周期做参考。

图12-9 敏捷方法适应性模型

注：若结果横跨多个区域，那么请对项目进行分解。

由于敏捷的特殊性，在行业中有一种声音始终存在着“敏捷不需要文档”，这就导致了在汽车产品开发过程出现与26262/ASPICE的要求相互对立的情况，在此需要提醒诸君，其实这两者之间并不矛盾。因为无论哪一种生命周期，计划都是必要的，不同生命周期与计划之间的关系是：不在于完成多少，而是何时完成并根据不同生命周期对完成的计划进行更新或再计划。

在软件定义汽车的时代背景之下，需求的模糊使得敏捷方法得以被重视，但单纯的敏捷并不足以在整个项目周期中发挥重要作用，就如上面提到的文档问题，因此多方法混合而成进行相互补充的混合型生命周期的应用或更加符合行业的‘适应性’。

在敏捷宣言中说“我们更注重客户合作而不是合同谈判”，在实际的工作中，诸君遇到过多少情况是先不签合同而直接开始项目开发的？我曾经就做了几个这类项目，但风险是有的项目完成了，可主机厂将项目关停了，导致项目款收不回来。所以，在这个行业中，单纯的敏捷似乎不太能被接受。

混合型生命周期有多种形式，当我们的项目存在不确定性、复杂性和高风险时，可以通过功能分解，然后再以明确的、重复的方式进行更新。对于整车而言，便是先发布一版基础的功能，然后在后期进行反复的OTA升级，对于这个反复的过程是可预见的，而前面开发则是不明确的，而这不明确的部分并不会对最终用户造成实际的困扰，这类混合方式便是敏捷之后接可预测型发布。

图13 先敏捷后接可预测型发布

在有些项目之中，项目团队会为了某些功能开发对产品进行短迭代，同时团队会结合敏捷相关工具，如回顾、每日站会的方式进行，同时在产品的评估、工作任务分配、工作跟踪等方面依然遵循着预测型，这类方式便是敏捷与预测相结合的形式，在如今汽车软件开发中这类方式也是是很常见的（将其称之为敏捷是不正确的）。

图14 敏捷与预测结合

我们在之前的文章中聊过，对于整车的开发而言，其整体工作是可预见的，只是对于如今的智驾等新技术的应用还处于探索阶段，因此这类开发的不确定性和高风险性主要集中在部分软件的开发上，针对于这类项目便是预测为主敏捷为辅的混合类型。若将不确定的软件开发单独拎出来，那么它所处的位置便是下图小框中的‘敏捷型’了。

图15 预测为主、敏捷为辅

在电子硬件的开发过程中有时我们也会见到这类生命周期的身影，比如对零部件进行降本时，需要采用成本更低的芯片或组件对现有零件进行替换，为了尽可能的较小风险，一般会先分析对比规格书，然后对新零件进行验证，接着才是替换后的验证，若发现不合适便会及时做出调整。软件也是一样的，单模块验证、集成验证，这便是增量的方式，但是对于总成件而言，其整体还是可预测的。

我们知道主机厂有许多的供应商，而这些供应商所交付的产品、功能、时间不尽相同，同时由于技术水平不齐，对于所交付的产品进行最终集成时的结果是不可预料的，在这个过程中，便需要及时的对结果做出调整，这过程采用的方法便是敏捷为主、预测为辅的混合生命周期。下图‘小框’中的预测型此时是针对主机厂而言的，对于主机厂来说，他对于供应商的交付内容是明确可知的。

图16 敏捷为主、预测为辅

诸君需要注意，项目管理的目标是在现有环境之下，以最好的方式创造商业价值。所以，无论是哪一种方式进行都无关紧要，重要的是如何才能将项目做好。

在我们拿到项目之后，可通过交付物（创造价值）、管理方法等方面对项目进行评估，若需要频繁的为客户创造价值（反复交付新成果），那么增量型则是合适的。若需要在项目过程中重点管理风险，那迭代或敏捷的方式会更好些。

每个项目都有其特殊性，若我们使用了敏捷方法，对于敏捷团队而言也不会局限于某一种敏捷，团队会根据实际情况对方法进行裁剪并组合使用，这便是我们所说的灵活性。对于项目的属性进行裁剪可参考下表：

图17 改进配合的裁剪方案

敏捷（四）——创建敏捷环境及Scrum介绍

若一个项目打算采取敏捷方法管理，那在诸君制定相关策略之前首先需要搞清楚几个问题：

1）项目团队如何以敏捷方式行动？（即要怎么做？）

2）团队需要快速交付哪些成果并获得反馈？

3）团队如何透明地行动？（相对于传统的项目开发，团队中的相关人员各有负责任务，每个人的任务对于不同组员而言不一定是透明的。说白了就是，虽然大家共同为同一个项目服务，但是每个人都在做什么组员之间并不一定清楚。）

4）为了那些高优先级的任务，可以避免哪些工作？

5）仆人式领导（下文换个说法：服务型领导）对团队达成目标有何益处？

注：如果对于一个项目来说，上述几个问题并没有答案，那么建议不采用敏捷方式。

诸君在日常工作中必然有参与过某些项目，所以大家都有过项目组成员的经验。对于传统项目开发方式：在项目开始前，由项目发起人指定项目经理，然后再由项目经理完成项目团队的组建，这个团队成员分布于不同部门有着各自的任务，这种方式大家应该都接触过了。

采用敏捷方法就不同了，虽然组建团队也是一个必经的过程，但与传统不同的是，这个团队并非由项目经理组建，而是自发组织而成。就好比项目发起人问‘这个活谁来干啊？’然后大家一商量，有的举手表示加入，有的则因为手头工作太多而放弃，就这样，一个自发地为该项目服务的团队形成了。该团队具有如下特点：

1）注重快速地开发产品，以便获得反馈进而完善需求；

2）由3-9人组成；

3）组员同在一个场景中工作（如大家聚集在同一个办公室）；

4）100%专职（即只为该项目服务）；

5）自我管理团队；

6）每一阶段的不同工作任务由项目团队成员自己决定由谁完成；

7）单任务时间短，通常是一个月之内的几天、数周不等；

8）团队成员与团队促进者（服务型领导/‘项目经理’）共同进步；

9）企业领导必须支持/认可团队方式（老板都不同意，那就别搞了）。

团队的形成是为项目服务的、是需要解决客户需求的，因此这个团队就需要有人与客户对接。老话说‘国无君乱，家无主散’，同样的道理，队伍不可无领头的，因此当在这个自发而成的团队中并未发现有人能担此重任之时，便需要指定有能力之人‘任职’或者延后团队的组建。组建而成的敏捷团队具有如下属性：

图18 成功的敏捷团队属性

通常在敏捷团队中不可或缺的三类角色是：跨职能团队（完成实际开发任务）、产品负责人（开发导向）以及团队促进者（为团队服务）。具体总结见下表：

图19 敏捷团队角色描述

注：在本章节开始时我们有5个问题，通过上述的团队属性、成员分工皆可得到回答，正也是因为团队为了高优先级的任务，暂时避免了一些工作（主要是文档类），因此敏捷与传统方式在文档上的矛盾被触发了。

另外，在传统的开发方式中，项目经理对于组员注重的是他的个人技能，如何让组员在项目中发挥其能是项目经理常常考虑的事情。但在敏捷团队中，‘项目经理’在这方面的权利小了，他注重的是交付而不是怎样‘用人’。这对于反感整天被‘安排’的组员来说，敏捷的方式会更加自由些，只不过有利便有弊，敏捷节奏更快。

对于100%专职成员主要是出于对效率的考虑。有研究表明，当一个人在两项目之间切换时（各占50%的时间的项目），其投入到实际工作中的精力并非各50%，而是降低到20-40%，同时还会带来项目记忆混乱等情况。

敏捷的方法有许多种，在汽车行业中基于频繁交付的增量以及基于迭代的敏捷都有可能被使用，而敏捷方法有许多种，常需要穿插着结合使用，常见的有Scrum、看板、XP（极限编程）等。

图20 敏捷方法

敏捷方法介绍：

Scrum：用于管理产品开发的单个团队过程框架，该框架包含Scrum角色、事件、工件和规则，采用的是迭代方式来交付产品，且它是运行在小于1个月的时间盒上。

图21 Scrum事件与工件

三个角色：产品负责人、团队成员、Scrum主管（团队促进者），详见上述团队介绍；

三个工件：产品待办事项列表、冲刺代办事项列表、增量。

注：产品待办事项列表与冲刺代办事项列表。

产品待办事项列表：我们在第二节时提到过基于迭代的敏捷型生命周期，任务以重要性（优先级）进行自上而下排列，由此形成的列表便是待办事项列表。该列表由产品负责人根据客户初始需求与团队成员共同制定，并同时完成产品交付预测。会根据团队实际完成情况与交付客户后的反馈情况，以每周（实际有可能更短）一次，一次一小时的形式对列表、计划进行更新。

图22 产品待办事项列表

冲刺代办事项列表：在产品待办列表中由团队选出的用于某个周期进行迭代的任务列表。如开发智能座舱功能，经过初步评估，团队罗列了20项的功能，然后再根据当前阶段的优先级从这20项中选出5项任务形成冲刺代办事项。而形成的冲刺代办事项列表是通过细化之后，可直接用于开发的，这里之所以叫做‘冲刺’，是因为紧迫性，要赶时间，也可以叫实际开发/任务，名称而已。

图23 冲刺代办事项列表

而要完成这5项任务，需要有计划、有目标的完成，这个连续的过程便称是Sprint，在迭代的过程中，每一项任务的开发便是一个小的‘项目’但它们的时间是一样的，若有需要，可在Sprint中再分解更小的任务以便更好的完成项目。

增量（increment）：完成的每一次迭代称为增量，所有的增量必须进行集成（无论是否交付给客户），以确保整体的可靠性，这在极限编程（XP）中也称为‘持续集成’。

图24 增量

五个事件（会议）：冲刺计划会议、每日例会、冲刺评审、冲刺回顾。鉴于篇幅，下一章时再介绍。

极限编程（XP）：

Scrum框架是基于迭代的敏捷方法，而极限编程是基于频繁交付周期的软件开发方法，即基于流程的增量型敏捷方法。

图25 极限编程实践

其特点可参考后续文章的内容。

汽车项目管理之敏捷方法（五）——过程及交付

一、章程

有过项目管理经验的小伙伴们应该清楚，对于传统项目，为了让团队成员了解项目的重要性、项目目标和前进方向，在项目开始前项目经理都会先完成项目章程，以此来约束项目团队的相关活动。

而在敏捷团队中，由于该团队的组建是自发的，虽具有很强的凝聚力，但相较而言其规范性方面则会差一些，为了尽可能大的调动团队成员并发挥成员的能力，除了项目章程外，还需制定协调团队成员的团队章程。

敏捷项目章程需要包含如下内容：

1）项目愿景。为何而做？2）受益方及受益方式？3）项目发布标准？4）预期工作流？

团队章程包含：

1）团队价值观。如何可持续的开发速度和核心工作时间？2）工作协议。定义诸如‘就绪’‘完成’等事项；3）基本规则。如会议发言时间等；4）团队规范。

二、敏捷实践

2.1回顾

定期反省如何做到更有效，并相应的调整团队行为。对于何时回顾较好呢？可以选择如下时间点：

1）完成一个发布时；2）上次回顾之后的几周；3）团队出现问题时；4）达到某个里程碑时。

从上面的回顾时刻我们知道回顾并非只有在项目结束时才进行，可以在项目进行中。但无论是何时回顾，我们都需要从定性及定量两方面出发。先讲定性的感觉，再从定量的数据分析近期的项目情况，然后制定相关对策与行动计划（‘先礼后兵’）。

注意：回顾不是责备。当我们项目完成度不如预期时，回顾的目的是怎么去解决它，而并非责备团队成员，敏捷主管需要做的是鼓励。

2.2待办事项列表的编制

该列表是所有工作的序列表，以故事的形式呈现。比如开发某个产品有数项工作需要完成，我们便通过优先级将其罗列出来（开始时无需完整的进行罗列，只需确需要交付的第一项的正确性即可）。产品负责人可能还会制定相关的产品路线图，用于观测交付的成功的预期性。

2.3待办事项列表的细化

在基于迭代的敏捷中，由于前期需求的不够明确，在早期制定的待办事项列表中的用户故事与实际有可能会有偏差或范围过大的情况，而随着项目的进行，产品负责人会对迭代中的故事（功能）进行细化，因此便需要与团队成员一同细化待办事项列表，细化会议一般每周不超过一小时。

如下图便是一个基于迭代的敏捷发布计划，开始时会有预测的版本，然后针对首次要交付的产品完成待办事项列表，随着项目的进行可能需要对迭代中的故事进行细化。

图1 敏捷发布规划

2.4每日站会

首先每日站会的主持可以是团队中的任何人，其次每日站会的时间不超过15分钟，最后每日站会不分析具体问题或解决具体问题。在基于迭代的敏捷中，可以通过任务板每个人轮流回答：

1）上次站会以来（其实就是昨天）我完成了什么？

2）从这次到下次站会（就是今天）我计划完成什么？

3）我的风险或可能的阻碍是什么？

如果是基于流程的敏捷，那么我们将注意力集中在团队上：

1）我们还需要做什么来推进一下这个工作？

2）有人在做任务板上没有的工作吗？

3）我们需要完成什么？

4）工作流程是否存在瓶颈？

注：每日站会的目的是通过简单的交流发现问题。针对具体问题可以在站会之后理解召开新的会议以解决问题。

2.5展示/评审

当我们团队完成一项特定的功能时，需要通过评审来决定该成果是否可被接受。这个频次至少是每周一次。

2.6规划基于迭代的敏捷

不同的项目，不同的团队，其需要完成的工作量是不同的。产品负责人与项目团队在划分工作内容时需要考虑自身情况，避免任务过大而无法完成的情况。同时对于团队成员不可用时（比如请假等），对于任务的大小需及时做出调整。

2.7交付执行

产品的质量非常重要，若只在乎交付时间而不重视质量，在我们执行项目过程中会发现，不出几个交付节点，便无法再进行按时交付，因为需要解决的问题会越来越多。

为了避免不重视质量所带来的风险，我们需要：

1）持续集成。在完成一项任务后，将其集成到整体中，然后重新测试，以确定产品的功能正确性；

2）不同层面的测试。通过自动化测试完成模块测试、集成测试、单元测试、系统测试、整车测试等；

3）验收测试驱动开发（ATDD）。针对验收标准，编写测试代码，通过自动化方式完成测试。对于非软件项目，我们需要考虑当团队完成大量工作时对其进行测试。

4）测试驱动开发（TDD）和行为驱动开发（BDD）。这是一个反向驱动的方法，通过先编写自动化测试的过程可以帮助开发人员深入认识到所需开发产品的相关标准，防止不确定的错误。对于硬件或机械结构类的非软件项目，我们也常通过先模拟再设计的方法，便是测试驱动开发。

5）刺探。在评估、验收标准的制定和通过产品了解用户行为中使用，可以刺探出深层的需求。

三、敏捷项目中的困难

通过敏捷方法中的各种技术及工具，以解决预测法中的相关若干问题，可参考下表：

图2 敏捷项目的衡量指标

四、衡量指标

诸君应该都见过项目的状态报告，对于传统的预测型项目，我们常会遇到项目在临近交付前发生与预期不同的状况，比如各模块单独工作时一切正常，但在最后集成到一起时却效果不如预期，此时项目的状态便会从绿变为红，这种无预警的‘西瓜项目’正是由于项目数据是直到最后时间才被集中到一起。

但敏捷是对于每一次的成果进行衡量，将客户的价值直接进行展示，通过这种微量的交付对已完成工作进行反馈，同时可及时调整即将到来的工作，因此对于团队去掌握项目的基准、估值、投资回报等会更加有把握。

这过程中会使用燃尽图或燃起图查看项目的进展情况。

图3 剩余故事的燃尽图

如上图‘剩余故事点’折线出现‘水平’，说明交付遇到了问题。

图4 燃起图

燃起图与燃尽图正好相反，是从已完成故事点出发的。

基于流程的敏捷团队通过使用交付周期、周期时间、响应时间来衡量，并通过看板方式展示，团队可通过衡量周期时间发现瓶颈和延迟问题。

图5 看板

通过将已完成工作、剩余工作以及待办事项工作整合到一起，团队可以更好的评估和估算自己的工作，如此便可以得到如下功能图：

图6 功能图

在敏捷中的挣值是基于已完成的功能，对于有许多故事点的大功能来说，可以用待办事项列表燃起图来显示已完成的工作与预期工作总量的对比。

图7 产品待办事项燃起图

对于挣值的衡量可以使用燃起图

图8 敏捷下的挣值（左：故事点，右：项目支出）

基于流程的敏捷团队可结合累积流图对看板上的工作进行显示，可对各部分工作内容进行管控，更直观的对整个开发工作进行评估。

图9 已完成功能的累积流图。

看图方法：纵坐标为已完成功能点数，横坐标为时间，图中内容解释：

1）队列，任务进入看板形成的排列模式。

2）分析、开发、测试，任务开始并进行中。

3）部署，任务完成。

4）周期时间：任务开始到完成的时间。如功能点2，开始时间是1月中旬，完成时间是10月中旬，就是说该任务花费了9个月时间。

5）交付周期：任务进入看板时间到完成时间；

6）响应时间：任务进入看板到开始工作的时间（有些任务进入看板，但由于优先级问题，并未第一时间开始，在看板上的等待时间便是此处的响应时间）。

分析方式：如果某项工作点任务数量变多（如图中的分析）那么该图就会向上‘拱’（阴影面积变大），那么剩余的任务自然会变‘高’，在同等资源下，横轴便会被‘拉长’，则项目恐会延期。

要使得项目按照正常时间完成，那么同样时间内需要完成的任务数便会增加，如此一来，团队成员的压力便会增大。因此如何合理的安排任务，是敏捷团队成员需要思考的问题。

通过该图，将任务在看板上进行调整，可以直观项目的变化，并作出合理的调整。

汽车项目管理之敏捷方法（六）——合同及变更

一、组织文化

你的公司首先要了解敏捷并支持敏捷方法的实施，否则上述所说的一切都只是空谈。

二、合同

在实施敏捷方法时，团队一直强调的是价值驱动，并通过频繁交付不断去刺探用户的实际需求。诸君试想一下：在需求不明确、范围可能随时发生变动之时，对于项目的工作量、资源该怎么评估？这便会产生了一个很棘手的问题：合同该怎签定？

诸君应该都有接触过合同的定立过程：根据项目需求评估工作量、投入资源、各种成本核算、利润核算、然后输出总价价格。。。这是我们传统的方式。但在敏捷中认为“客户协作高于合同协商”，这‘协作’必须建立在双方共赢的前提之下，即主机厂、供应商提倡共担项目风险和共享项目奖励，很明显，在现阶段的汽车行业要达成这一目标并不太容易。所以，在汽车行业中建议扮演供应商角色的小伙伴可以考虑如下做法：

1）分层/分文件签署。 将基本的条款以商务合同的形式签订，然后项目尽量不要以总价合同方式签署，而是转化为技术服务明细（即开口合同）。虽然敏捷项目变化快，但是对于企业而言要完成这些工作的技术内容肯定是在自己的范围之内的（超过技术范围的就别接了），如此便将不确定转变为了确定内容。以服务为合同附件，在每一次的迭代/增量开始前，对服务内容进行双方确认即可，如此便不用太过担心项目范围变化导致的频繁变更而产生额外的成本了。对于突发的资源，如突然产生的第三方试验等费用，可以再以应急资金方式纳入（事实上，对于这些内容主机厂也是有预算的）。

2、分项目签署。这做法就是麻烦点。在每一次交付完成之后，下一次迭代/增量开始前，双方重新签订商务合同，说白了就是将大项目分解为已知的小项目，每次以小项目洽谈，以少量多次的方式完成整个项目开发过程。

注意：对于敏捷项目，供应商尽量不要签总价合同，除非自己非常有自信不会范围蔓延。其他类似总价+激励/奖励等合同方式，在汽车行业中就没见过。

三、变更

当在混合或敏捷方法中项目开发遇到变更时，常用的方式是将变更过程视作一个敏捷项目，团队可以引入变更待办事项列表。每一个变更可视为一个实验，其将进行短时间测试以确定变更的适应性以及进一步细化需求。

注：敏捷对于文件的要求落后于实际工作，但变更在项目开发中特别重要，尤其是在软件的追溯性方面，因此建议将变更记录及时完善。

变更进行时，可以使用看板对变更进行跟踪，如下：

图1 变更初始待办事项到过程进行

通过上述可视化的方式对实施的方法进行跟踪，将提高项目成功的可能性。