作为项目经理，我们经历过不同的项目，却总是被相似的困境所局限。例如以下三个典型问题：团队目标不一致团队成员不熟悉信息发布不顺畅如果任由问题存在而不对每个项目进行总结和提炼，我们将反复在充实的理想和骨感的现实之间徘徊。敏捷思维和实践可以为我们提供一种可能，帮助我们解决项目交付过程中遇到的具体困难。敏捷项目管理——追求最大价值的成功提到敏捷项目管理，首先要说说瀑布式开发和迭代式开发的区别。（图片来自：http://t.cn/R9IjtIs）大家都知道瀑布式开发的特点是批量大，流程慢，每个阶段都追求完成工作，但是因为缺乏并行迭代的概念，对变化的反应必然缓慢。迭代开发正好弥补了这个弱点。在迭代开发过程中，整个开发工作被组织成一系列短小的、固定长度（在ThoughtWorks中通常为2周）的小项目，我们称之为一系列“迭代”。每次迭代包括需求定义、需求分析、设计、代码实现和测试。使用这种方法，可以在需求完全确定之前就开始开发工作，在每次迭代中完成系统的一部分功能开发工作，然后通过客户反馈细化需求，进行新一轮的迭代开始。ThoughtWorks的敏捷开发通过逐步细化、迭代推进的方式，分阶段实现需求。比如我们先从整体的功能规划中，定位一小部分核心功能，打造一个基本可以运营，对用户有价值的最小可行产品（MinimumViableProduct，MVP），然后快速迭代开发，听用户反馈，及时调整功能规划。曾经在一次培训中听同事讲到敏捷团队和大话西游团队的相似之处。他认为，唐僧和他的徒弟们在Agile中可以算是一个功能齐全的团队：团队有一个共同的目标——求得真理；九十九八十一难度，就像九九八十一的迭代，每成功打败一个怪物，一次交付就完成了；在不断迭代的过程中，团队不断收集反馈，持续改进，一步步完成最终目标。拿到经文，意味着项目的交付已经完成，同时，团队的能力也得到了质的提升。这是一个美妙的结果。项目成果的交付和团队能力的提升是项目经理在项目管理中最希望达到的目标。传统项目管理的定义是：“在资源有限的条件下，达到或超过设定的要求和期望”。一句话概括了传统项目管理的铁三角：需求就是范围，资源包括时间和成本。那么这个定义正确吗？大家都看过电影《泰坦尼克号》。如果套用上述“范围、时间和成本”定义的框架，《泰坦尼克号》将被判定为失败的项目。为什么？这部电影在拍摄过程中多次被推迟，并且大大超出了预算，无论是在成本还是时间上，它都是一个失败的项目。但我们都知道，《泰坦尼克号》依然是一个无法超越的票房神话。由此可见，左图中“传统项目管理铁三角”的概念忽略了“价值”这一重要因素。右边的“敏捷项目管理铁三角”，强调的是团队要从市场得到真实的反馈，帮助敏捷团队持续、尽早地交付有价值的软件。在追求价值交付的过程中，我们越来越发现敏捷项目管理中有一个至关重要的部分——人，也就是我们的团队。价值由人创造，为人服务。许多敏捷实践都围绕着人展开。我们试图找到一种通用的方法来最大化人类的能量。未来社会最有价值的人的特征是创造力、洞察力和客户感知。我们相信这样的团队才能创造最大的价值。下面将以我在ThoughtWorks的项目经历为例，讲述ThoughtWorks主要运用在日常交付项目中的敏捷实践如何帮助团队实现价值最大化。用户故事用户故事（UserStory）是敏捷开发的基础，它从用户的角度描述需求。软件开发是为了实现产品的商业价值，满足用户的需求。只要需求足够清晰，每个人都了解它的具体内容，团队就可以简单有效地将需求转化为可实现、可测试、可发布的代码。为了实现这个目标，就需要找到一种描述需求的方式，让大家对任务的范围有一个共同的认识。这样，团队就会对任务完成有一个共同的定义，不会出现“你做的不是我要求的”、“我忘了告诉你这个需求”等问题。用户故事体现了用户需求和产品的商业价值，定义了一系列的AcceptanceCriteria（AC）。只有团队完成的工作符合这一系列的AC，用户故事才能真正完成。一个用户故事通常包括三个元素：角色：谁会使用这个功能；activity：需要完成什么样的功能；商业价值：为什么需要这个功能，这个功能带来什么价值。用户故事可以以不同的形式呈现，以下是其中一种：作为，我想，只有这样我才能获得。因此，用户故事一旦确定，所要实现的功能、需求的范围、所需的工作量也就随之确定。之后开发者需要做的就是根据这个用户故事的内容进行开发。只有当所有的AC都被覆盖，测试人员完成测试，发现所有的功能都可测试可操作时，用户故事才算完成。估算和迭代计划估算（Estimation）：团队在开始开发用户故事功能之前，应该清楚地了解实现这个用户故事所需的工作量。正如MartinFowler所说，“估算在帮助您做出重大决策时很有价值”。只有当团队清楚地了解实现目标所需的努力以及实现目标的“好处”时，他们才能做出明智的决定。当团队确定工作优先级和规划迭代时，业务分析师需要知道每个用户故事的成本，团队成员需要知道每个用户故事的价值。估算一个用户故事的工作量有很多种方法，其中一种方法是将完成用户故事所需的点数（根据用户故事的复杂程度估算）写在相应的故事卡片上。估算可以帮助团队以不同方式更好地了解即将到来的用户故事的实现、未来的架构方向和代码库的设计。可以估计一次迭代可以完成多少个点。也可以使用一些工具统计过去每次迭代完成的点数，比如燃尽图。如果整个团队齐心协力，估算本身也可以成为一项有益的活动。它有助于团队增进理解，并确保团队中的每个人都同意要交付的需求的范围和价值。使评估更有趣的是，它通常不是简单的数字序列，如1、2、3、4、5等-而是近似斐波那契数列的形式，如1、2、3、5、8、13等（如《达芬奇密码》中所见），因此随着数字变大，相邻数字之间的空间变大，使团队更容易分辨哪个故事较小，哪个故事更大。在做迭代规划（IterationPlanning）时，团队需要从客户价值维度和技术风险的角度进行优先排序。下图是常用工具之一——需求优先级矩阵。迭代会议和功能演示敏捷宣言之一：客户协作优于合同谈判。在敏捷团队中，有一个角色叫做业务分析师（BA），其核心职责是保证业务需求的清晰透明，确保开发团队对业务有足够的了解，并优先考虑这些用户故事完成后，以任务卡的形式带动团队的发展。迭代会议(IPM)通常在每次迭代的第一天举行，团队成员会聚在一起制定迭代计划。这次会议由BA主持，大家同步了几个方面：下一次迭代的用户故事；对下一次迭代的期望和计划；风险评估和总结。不同的人对需求有不同的理解，所有团队成员必须就用户故事的所有相??关内容、要实现的功能以及用户故事完成前必须满足的条件达成一致。迭代会议的主要产出就是下一次迭代需要完成的用户故事，而这些用户故事就是下一次迭代要完成的主要目标。功能演示（Showcase）是敏捷开发过程中的另一种实践，通常发生在每次迭代的最后一天，目的是演示可工作的软件。团队向相关人员演示一个迭代开发的特性，并收集反馈，以便在下一个迭代中快速响应变化。站立会议和用户故事开场卡简单来说，站立会议（Standup）就是团队一起快速开会（通常在实体墙前），成员们一一更新自己的状态。更新包括以下几个方面：昨天完成的工作；今天计划完成的工作；面临哪些障碍，需要哪些帮助；手头的用户故事进展，是否存在技术风险。由于是快会，站立时间不宜过长，最好在10分钟左右。建议团队成员站着开会，因为研究表明，当人们坐着时，会议会延长。这里有一些实用的原则：团队成员必须参加站会，轮流主持，迟到没人等——仪式感很重要。在站会期间，每个团队成员都会围绕故事卡进行更新。介绍一个有趣的做法——使用Token（即用一个实物作为“令牌”，要发言的人先获得“令牌”，发言后将“令牌”传递给下一个人。令牌应该引人注目，可以是毛绒玩具或帽子）。用户故事启动：在开发每个用户故事之前，确保BA、DEV和QA对用户故事有一致的理解。这种交流活动通常表现为DEV解释这个用户故事中要完成的功能和AC。一旦发现遗漏，BA会及时补上。如果DEV有疑问，需要及时提出，并当场确认，才能正确实现这些功能。如果在后续开发中遇到什么疑惑，也应该及时向BA了解一下。QA会严格按照AC对用户故事进行验收。CodeReview和Review代码审查（CodeReview）开发团队完成每日代码后，会聚在一起审查当天的代码。这样做有几个好处：经过一天的密集思考和编码，团队适当停下来看看别人写的代码，同时解释自己的代码，往往能得到一些意想不到的启发，可能会解决你面临的障碍;了解彼此的设计思路，得到更好的建议和重构思路，提高代码质量；及早发现潜在缺陷，降低事故成本：如果此时发现代码有不好的味道和需要改进的地方，可以在codereview之后花少量时间进行修改；促进团队内部的知识共享。回顾：回顾会议的目的是通过新的沟通形式，唤起大家对团队的集体意识，指出一段时间内团队或个人的不足，并列出相应的行动。持续有效的回顾和反馈可以确保团队关心生产力和效率，了解自身的不足，这将成为团队持续改进的起点。审查的重点也多种多样。除了“项目开发”，还可以关注“敏捷成熟度”、“团队角色与职责”、“人员技能提升”等。在坚持评审的同时，需要做的是保证项目的有效性评价。根据团队建设目标的发展变化，不断调整回顾的重点和形式，确保回顾能够有针对性地发现团队的缺陷，并转化为实践。长期有效的评审和正确的评审输出也能不断提升团队内部的安全感和信任感。复习的形式和方法很多，最常见的是“Well&LessWell”。最大的可视化看板来自于精益生产的实践。Nimble借鉴了其背后的可视化管理理念，形成了具有自己独特风格的可视化管理工具。在敏捷项目中，常见的做法是在墙上挂一张“每个人都能看到的大图”，用于共享和可视化项目状态。例如，代表项目状态的实体墙。这样的物理墙通常包括三个要素：时间、任务和团队。除了代表项目的状态之外，项目团队还可视化其他元素，例如团队应遵守的规则、在项目上分享的经验以及项目的里程碑。一般来说，通过相关团队和个人之间的相互协商，可以确定各自未来的活动和相应的成功措施，然后将其可视化，然后每个时间段进行一次回顾和调整。通过这种可视化，团队更容易调整目标并不断培养和加深责任感。可视化的好处是：日常工作透明化，迭代过程中的所有故事卡都可视化，团队成员可以随时知道需要做什么和将要做什么。由于人类对视觉的反应更灵敏，视觉故事墙可以立即吸引团队的注意力。把迭代过程中遇到的问题暴露出来，可以促进团队成员在工作中一起积极讨论解决方案。团队也可以根据当前的进度和遇到的问题，了解到需要什么样的帮助，更好地分配资源，降低开发进度被延误的风险。敏捷沟通计划中的自组织团队实际上是敏捷的结果，而不是先决条件。实施敏捷的过程也是建立自组织团队的过程。当每个团队成员面临“做什么、怎么做”的问题时，他也会以自组织的方式去解决。每天，团队中的每个人都要求其他成员进行协调。为了保持同步，我们会根据敏捷实践创造交流机会，这也是实施敏捷的过程之一。ThoughtWorks中有一个非常著名的事件叫做Inception。Inception是一种启动软件设计和交付项目的方法。通过集中式、交互式的设计工作坊，帮助客户在最短的时间内就项目范围达成一致，并快速进入项目交付。Inception的成果之一是沟通计划。比如在这个沟通计划中，会讨论：用什么频率和形式来更新项目，比如每周五以周报的形式更新一些主要信息；比如业务负责人、技术负责人等。以下内容将在沟通计划中明确定义：写在文章的最后，回到文章的开头，我认为敏捷实践和解决方案可以映射如下：团队目标不一致使用电子墙和物理墙来展示用户故事、需求全景图、项目进度燃尽图；通过迭代会议和功能演示会议调整迭代计划、项目进度并识别项目风险。团队成员不熟悉基于敏捷的实践，创造了更多的交流机会，例如回顾、代码审查和站立会议。通过不断创造这样的交流机会，团队成员可以更加默契。信息发布不畅分享信息，制定沟通计划；最大化可视化。文章中提到了许多类型的敏捷实践，这些实践需要融入到团队的日常活动中，以便持续实施和改进。行为心理学研究认为，重复21天以上就会形成习惯。任何一个动作，重复21天，就会成为习惯动作；任何一个想法，重复21天，或者重复验证21次，就会成为一种习惯性的思维方式；任何信念或有益的做法，经过团队的不断验证，一定会成为团队的信念和实践。剑道中有这么一个心诀：守、破、离。服从性：初级阶段一定要听从老师的教导，认真练习基础，达到熟练的程度。突破：掌握基础后，尝试突破原有的规范，获得更高层次的进化。李：在更高的层次上得到新的认识和结论，创造新的花样，开辟新的境界。大部分项目经理处于“守”阶段：学习吸收前辈的项目管理经验，带领团队有条不紊地进行项目交付；但他们经常被管理上某些方面的问题反复出现，苦于没有有效的解决办法，不得不在新的项目中重复以前的困惑；一些项目经理已经到了“破”的地步：可以从全局优化的角度总结自己的项目管理经验，并通过学习、分享和各种交流平台来开阔眼界、拓宽思路，借鉴或改进方法和方法项目管理，使他们更适用于团队；而所有项目经理的最高目标就是“离”：随着项目经验的不断积累和管理思想的深入，我对项目管理有了新的、更高层次的、独特的理解，并运用到实践中去创造一种独特的方式使整个项目管理思维焕然一新。希望越来越多的项目经理能够达到更高的阶段。这是我们在项目管理中始终不变的追求。【本文为专栏作家《ThoughtWorks》原稿，微信公众号：Thinkworker，转载请联系原作者】点此阅读更多该作者好文
