项目管理中的敏捷实践

写在前面

6月27日,我在ThoughtWorks PM社区上做了一个直播分享——项目管理标准化。

在这次分享中,我从项目团队的视角出发,归纳了在项目管理中我们通常遇到的三类问题:

团队目标不一致

团队成员不熟悉

信息发布不顺畅

作为项目经理的我们,不断地经历一个又一个的项目,一次次地面对相同的问题。如果我们不从中总结和提炼,我们就会反复地徘徊在丰满的理想和骨感的现实中。

敏捷思想和敏捷实践,为我们提供了一种解决方法,帮助我们解决在项目交付过程中遇到的具体问题。下面我将详细介绍我在本次分享中所谈到的敏捷实践,作为我直播分享的一个补充。

正文:

敏捷的项目管理——追求最大价值的成功

当我们提到敏捷的项目管理,我们就不能不先说说瀑布式开发和迭代式开发的区别。

项目管理中的敏捷实践_第1张图片

大家都知道瀑布式开发的特点是大批次、缓慢流动,每一阶段追求工作完整,但因其缺乏并行迭代的概念,面对变化的响应必然很慢。而迭代式开发则恰恰弥补了这个弱点。在迭代式开发过程中,整个开发工作被组织为一系列短小的、固定长度(在ThoughtWorks通常是2周)的小项目,我们将其称为一系列的“迭代”。每一次迭代都包括了需求定义、需求分析、设计、代码实现与测试。

采用这种方法,开发工作可以在需求被完整地确定前启动,并在每次迭代中都可以完成系统的一部分功能的开发工作,再通过客户的反馈来细化需求,并开始新一轮的迭代。

ThoughtWorks的敏捷开发通过逐步细化、迭代前进的方式,分阶段地将需求予以实现。比如说,我们先从整体功能规划中定位出一小部分核心功能,打造能基本运转、对用户有价值的最小可用产品(Minimum Viable Product,MVP),然后迅速迭代开发,听取用户反馈,及时调整功能规划。

上周日我参加了一个培训,其中一位同事谈到了西游记团队和敏捷团队的联系,他认为唐僧师徒是敏捷中的全功能团队:团队有共同的目标——取到真经;他们历经了九九八十一难,好比九九八十一个迭代,每个迭代的打怪都是一次交付;在不断迭代的过程中,这个团队不断地收集反馈、持续改进,一步步地完成了最后的目标。取到了真经,意味着完成了项目的交付,同时在这个过程中,团队能力得到了提升。这是一个美妙的结果。

项目成果的交付&团队能力的提升,这是在项目管理中,项目经理最希望达成的目标。

传统项目管理的定义是:“在有限资源限定的条件下,实现或超过设定的需求和期望”。一句话概括了传统项目管理的铁三角:需求是范围,资源包括时间和成本。

项目管理中的敏捷实践_第2张图片

那么这个定义是正确的吗?

大家都看过电影《泰坦尼克号》,如果我们套用上面这个“范围、时间和成本”定义的框架,《泰坦尼克号》会被判断是一个失败的项目。为什么呢?这部电影拍摄过程多次延期,预算也超出很多,无论从成本和时间来看,这都是一个失败的项目。可是我们都知道,《泰坦尼克号》直到现在仍然是一个难以超越的票房神话。

由此可知,左图的“传统项目管理铁三角”概念忽略了“价值”这一重要因素。右图的“敏捷项目管理铁三角”强调,团队应得到来自市场的真实反馈,以此来帮助敏捷团队持续不断地、尽早地交付有价值的软件。

在追求价值交付过程中,我们越来越多的发现敏捷项目管理中至关重要的一环——人,也就是我们的团队。价值是人创造的,是为人服务的,很多敏捷实践都围绕人展开。我们试图找到一种通用的方法来最大限度地发挥人的能量。未来社会最有价值的人,是以创造力、洞察力、对客户的感知力为核心特征的,我们相信这样的团队能创造最大的价值。

用户故事

用户故事(User Story)是敏捷开发的基础,它从用户的角度来描述用户希望得到的功能。软件开发是为了实现产品的商业价值,满足用户需求。只要需求足够明确,所有人都了解需求的具体内容是什么,团队就能简单有效地把需求转化成可实现、可测试、能够发布的代码。为了实现这个目标, 需要找到一种方法描述需求,让所有的人都能对任务的范围有一个共同的认知。这样团队对任务完成会有一个共同的定义,不会出现“你做的不是我所要求的”、 “我忘了告诉你这个需求”等类似的问题。

因此就出现了用户故事, 它描述了产品需求及商业价值,同时定义了一系列Acceptance Criteria(AC)。只有团队完成的工作符合这一系列的AC时, 才真正完成了这个用户故事。一个用户故事通常包括三个要素:

角色:谁要使用这个功能。

活动:需要完成什么样的功能。

商业价值:为什么需要这个功能,这个功能带来什么样的价值。

每个用户故事可以有不同的展现形式,以下是其中一种:

作为一个<某种类型的用户角色>

我要<达成某些目的>

只有这样我才能够获取<商业价值>

项目管理中的敏捷实践_第3张图片

所以只要将用户故事确认下来,那么这个用户故事所要实现的功能、需求范围、完成这个用户故事所需要的工作量也就随之确认了。之后开发人员所要做的就是根据这个用户故事的内容进行开发,只有当所有AC被覆盖到,测试人员完成测试,发现所有功能是可测试的、可运行的,这个用户故事就算完成了。

估算和迭代计划

估算(Estimation):团队在动手开发一个用户故事功能之前,应当对实现这个用户故事所需要的工作量有清晰的认识。如Martin Fowler所说,"Estimation is valuable when helps you make a significant decision"。只有当团队对达成一个目标的工作量以及完成它之后的“收益”有了一个明确的认知, 才能做出明智的决定。当团队在为工作排定优先级、制定迭代计划时,业务分析师需要知道每个用户故事的成本,团队成员需要知道每个用户故事的价值。有很多种估算用户故事工作量的方法,其中一种就是把完成这个用户故事所需要的点数(根据用户故事的复杂度估算)写到这个故事卡上。估算可以帮助团队以不同的方式,对实现即将开始的用户故事、未来的架构方向和代码库的设计,有更好的理解。一个迭代所能完成多少个点数是能估算出来的。也可以使用一些工具统计出过去每个迭代所完成的点数,比如燃尽图。

只要整个团队都一起参与进来共同协作,估算本身也可以变成一种很有意义的活动。它有助于团队增进理解,并保证团队每个人都对要交付的需求范围和价值达成共识。让评估变得更有趣的是,通常不采用简单连续的数列,比如1,2,3,4,5等——而是采用一种近似菲波拉契数列的形式,像1,2,3,5,8,13等(就如《达芬奇密码》里面看到的),这样当数字越大、相邻数之间的间隔也越大,使得团队更容易区分哪个故事更小、哪个更大。

在做迭代计划(Iteration Planning)时,团队需要从客户价值维度和技术风险的角度来排定优先级。下图中是常用的工具之一——需求优先级矩阵。

项目管理中的敏捷实践_第4张图片

迭代会议和功能演示

敏捷宣言里面有一条:客户协作优于合同谈判。在敏捷团队中有一个角色叫做业务分析师,业务分析师(BA)的核心职责是确保业务需求的清晰和透明,保证开发团队对业务有足够的理解,并将这些待完成的用户故事按照优先级排列出来,以任务卡的方式来驱动团队的开发。

迭代会议(IPM)通常发生在每个迭代的第一天,团队成员一起制定迭代计划。这个会议由BA主持,大家一起同步几个方面的内容:

下一个迭代的用户故事;

对下一个迭代的期望和计划;

风险的评估和总结。

不同的人对需求的理解是不同的,所有团队成员都要明确用户故事所有相关内容、所要实现的功能、满足哪些条件用户故事才算完成。迭代会议的主要产出是下一个迭代中需要完成的用户故事,这些用户故事即为下一个迭代所要完成的主要目标。

功能演示(Showcase)是敏捷开发流程中的又一个实践,通常发生在每个迭代的最后一天,目的是演示可工作的软件。团队把一个迭代中开发好的功能给相关人员演示,并收集反馈,以便在下一个迭代中可以对变化作出快速响应。

站会和用户故事开卡

简单地说,站会(Standup)是团队在一起快速地开一个会(通常在物理墙前),成员逐个更新自己的状态。更新包含以下几个方面:

昨天完成的工作;

今天计划做的工作;

面临什么阻碍,需要什么帮助;

自己手头用户故事的进展,是否存在技术风险。

既然是快速的会议,站会的时间就不宜过长,10分钟左右为佳。建议团队成员站着开会,因为研究表明,当人们坐着开会的时候,会议的时间会被无形中拉长——会议的重要目的是让每个人在自己以及同事面前作出承诺,这个承诺是团队之间的承诺。

这里有一些实践原则:

团队成员都要参加站会,轮流主持,谁迟到了都不等——仪式感很重要。

站会的时候,每位团队成员的更新都是围绕故事卡来进行。介绍一种有意思的实践——使用Token(也就是使用一个实物作为”令牌”,准备发言的人首先取得”令牌”,发言完成后将”令牌”传给下一个人。令牌要醒目,可以是毛绒玩具,也可以是一顶帽子)。

用户故事开卡(Story kick-off):在每个用户故事开发之前,要确保BA、DEV和QA对用户故事理解一致。这个沟通活动通常由DEV讲解这个用户故事要完成的功能及AC,一旦发现任何疏漏,BA会及时补充。DEV有任何疑惑也需及时提出来,当场确认,使这些功能得以正确实现。在后续开发中如果碰到任何疑惑,也应及时找BA了解清楚。QA会严格按照AC来验收用户故事。

代码审查和回顾

代码审查(Code Review) 开发团队在完成每天代码之后,会聚在一起评审当天的代码,这样做有几个好处:团队经过一天的高强度的思考与编码,适当地停下来,看看其他人写的代码,同时将自己的代码讲解出来,往往能意外地获得一些灵感,或许能解决自己面临的阻碍。

互相了解设计思路,更好的建议和思路重构,提高代码质量;

及早发现潜在缺陷,降低事故成本:如果这个时候发现代码的坏味道,和一些需要改进的地方,代码审查结束后可以花少量时间作出更改;

促进团队内部知识共享。

回顾(Retrospective):回顾会议的目的是通过新的沟通形式唤起大家对团队的集体意识,指出团队或个人在一段时间内的不足并列出对应的行动。持续而有效的回顾和反馈,可以保证团队关心生产力和效率,了解团队自身的不足和问题,这将成为团队持续改进的起点。

回顾的关注点也多种多样,除了“项目开发”之外,还可以关注“敏捷成熟度”、“团队角色和职责”、“人员技能提升”等。在坚持回顾的同时,需要做的还有保证回顾的有效性。应根据团队建设目标的发展变化,不断调整回顾的关注点和形式,确保回顾能够有针对性地发现团队的缺陷并转化为实践。长期有效的回顾和正确的回顾产出,还能够不断提升团队内部的安全感和信任度。

回顾的形式和方法非常多,最常见的是“Well & Less Well”。

项目管理中的敏捷实践_第5张图片

最大程度的可视化

看板源于精益生产实践,敏捷将其背后的可视化管理理念借鉴过来,形成了具有自己独特风格的可视化管理工具。

在敏捷项目里,挂在墙上的“人人可见的大图表”是一种普遍的实践,它被用来共享项目的状态并将之可视化。比如表示项目状态的物理墙,这样的物理墙通常包括三个元素:时间、任务和团队。

除了表示项目状态,项目团队还会可视化其他的元素,比如团队应坚持的规则、项目上的经验分享以及项目的里程碑。

在ThoughtWorks这样的扁平组织里面,存在着虚拟团队和项目团队。一般来说,通过有关联的团队和个人之间相互协商,可以识别出未来一段时间里各自的活动,以及相应的、对成功的衡量方式,然后将其可视化出来,每段时间再回顾和调整一次。有了这样的可视化,团队会更加容易对齐目标,并不断培养和加深责任感。

可视化带来的好处是:

日常工作透明,将迭代过程中所有的故事卡可视化出来,团队成员可以随时知道当前需要完成的工作以及将要完成的工作。由于人对视觉反映很灵敏,可视化的故事墙能立刻聚焦团队的注意力。

将迭代过程中遇到的问题暴露出来,可以帮助团队成员在工作中一起积极讨论解决方案。

团队也可以根据现在的进度以及遇到的问题,了解需要哪些帮助,更好的分配资源,减少开发进度被滞后的风险。

沟通计划

敏捷里面的自组织团队其实是敏捷的结果,而不是先决条件。实施敏捷的过程也是打造自组织团队的过程。每个团队成员在面对做什么、怎么做的问题时,也会以自组织的方式去解决。在每一天,团队中的每一个人都要与团队中的其他人保持协调。为了保持同步,我们会创造基于敏捷实践的沟通机会,这个也是实施敏捷的过程之一。

在ThoughtWorks有一个非常有名的活动叫Inception。Inception是启动软件设计和交付项目的方法,通过集中式、互动式的设计工作坊,帮助客户在最短时间内达成对项目范围的一致,快速进入项目交付。而Inception的一个产出就是沟通计划(Communication Plan)。比如在这个沟通计划中会讨论:

以什么频率、什么形式作项目的更新,比如说每周五以周报的形式作一些关键信息的更新。

站会和迭代会议什么时候召开,需要邀请那些人,比如说业务负责人,技术负责人等等。

以下内容都会在沟通计划中定义清楚:

项目管理中的敏捷实践_第6张图片

写在最后

回到文章开头所提出的三个问题,在这次的直播分享中,我是这样将敏捷实践和解决方案对应起来的:

团队目标不一致

用电子墙和物理墙展示用户故事、需求全景图、项目进度燃尽图;

通过迭代会议和功能演示会议对齐迭代计划,项目进度、识别项目风险。

团队成员不熟悉

基于敏捷实践,创造更多的沟通机会,比如回顾会议、代码审查和站立会议。通过不断地创造这样的沟通机会让团队成员更加默契。

信息发布不顺畅

共享信息,制定沟通计划;

最大程度的可视化。

文中提到了很多类型的敏捷实践,这些实践需要贯穿到团队的日常活动中去,持续的实施和改进。行为心理学研究认为:21天以上的重复就会形成习惯。任何一个动作,重复21天就会变成习惯性的动作;任何一种想法,重复21天、或者重复验证21次,就会变成习惯性的思维方式;任何一种信念或者一种有益的实践,经过团队持续验证,它一定会成为团队的信念和实践。

剑道中有这样一个心诀:守、破、离。

守:最初阶段须遵从老师教诲,认真练习基础,达到熟练的境界

破:基础熟练后,试着突破原有规范让自己得到更高层次的进化

离:在更高层次得到新的认识并总结,自创新招数、另辟新境界

项目管理者中的大多数人都处于“守”的阶段:他们学习、吸收了前人的项目管理经验,带领自己的团队有序地开展项目交付工作;但是他们经常困惑于某些在管理中反复出现的问题,苦于找不到有效的解决方法,不得不在新的项目中重复之前的困惑;

有的项目管理者已经达到了“破”的层次:他们能够以全局优化的角度去总结自身项目管理的经验,并通过学习、分享及各种交流平台去开阔眼界、拓宽思路,借鉴或改良项目管理的方式方法,使之更适用于团队;

而所有项目管理者的最高目标则是“离”:随着项目经验的不断积累,他们对管理的思考日渐加深,对项目管理有了新的、更高层次的、属于自己的独特认知,并将其应用在实践中,独辟蹊径,使整个项目管理思路焕然一新。

希望越来越多的项目管理者能够达到更高的阶段。这是我们在项目管理中不变的追求。

阅读:项目管理中的敏捷实践

本文作者万学凡,ThoughtWorks首席咨询师,武汉。作者保留本文一切权利,未经许可请勿转载

你可能感兴趣的:(项目管理中的敏捷实践)