《Create Your Successful Agile Project》书评与作者访谈

电玩女神 2022-02-22 10:37 132阅读 0赞

> \\
> 
> ## 本文要点 ##
> 
> \\\\
> 
>  *  你可以把敏捷和精益方法组合成某种适合你上下文环境的敏捷方法；\\\\t
>  *  弄清楚你的团队需要什么人，确保团队拥有所需的所有能力和技能；\\\\t
>  *  如果你的团队不知道或者无法完工，那就通过回顾会议审查团队的流程，转向“多么少”思维，或者看一下团队关于完工的约定；\\\\t
>  *  避免仅仅使用估计的方法评估工作的价值，因为不同的特性可能需要通过学习以及中间可交付成果才能了解其真正的价值所在；\\\\t
>  *  不管你处于什么位置，都可以引导敏捷方法的采用——你不需要有个头衔才能这样做。\\

\\\\

《Create Your Successful Agile Project》一书帮助人们理解敏捷方法，并选择适合他们的方法。通常，团队采用一种框架，但并不了解该框架适用的上下文环境。本书展示了如何利用团队独一无二的产品、上下文和人员为项目定义一种可持续的敏捷方法。

\\\\

InfoQ读者可以下载《Create Your Successful Agile Project》一书的摘录。

\\\\

InfoQ采访了Johanna Rothman，内容涉及如何将敏捷和精益组合在一起、团队如何组织、可以用于对特性进行排序的标准以及它们的用法、为什么她不喜欢“强化迭代（hardening）”、为什么学习机会如此重要以及如何创造学习机会。

\\\\

**InfoQ：您为什么要写这本书？**

\\\\

> \\
> 
> **Johanna Rothman**：许多人——团队和项目经理——都希望使用敏捷方法。那很棒。不过，他们可能不是一个跨职能团队。或者，他们可能不得不同时参与多个“项目（工作流）”。或者，他们可能被不断地打断，项目工作排到了最后，而不是最开始。
> 
> \\\\
> 
> 这些人还是希望使用敏捷方法。他们可以。不过，“开箱即用”的方法并不适合他们。他们需要设计/创造/研究改进自己工作的可能性。
> 
> \\\\
> 
> 多年来，我用过许多不同的敏捷方法。我帮助我的客户针对各种项目创造了有成效的敏捷方法。我希望分享我的学习和思维方式，并和他人一起试验。
> 
> \\

\\\\

**InfoQ：哪些人是这本书的目标读者？**

\\\\

> \\
> 
> **Rothman**：简单来说是技术负责人，但是，我不认为你需要有一个类似“负责人”或“项目经理”或“教练”这样的头衔才能阅读这本书。如果你希望改进自己的敏捷方法或者你所在的团队的敏捷方法，那么你就可以阅读这本书。
> 
> \\

\\\\

**InfoQ：如何将敏捷和精益组合在一起？**

\\\\

> \\
> 
> **Rothman**：事实上，敏捷是精益的一个子集。不过，有太多人认为精益是针对生产，而敏捷是针对创新。不是这样的！精益说，“把尊重人放在首位”。敏捷方法说，“把协作、频繁交付和透明度放在首位”。不是随意选择一种方法，而是根据你的上下文对敏捷和精益方法进行仔细地比较然后做出选择。
> 
> \\\\
> 
> 举个例子。Susan把自己称作敏捷管理员，她设法在一个14人的团队里使用迭代。所有那些人都需要设法完成他们希望在特定迭代中完成的工作。然而，他们需要现场提供产品支持，服务请求的提出也没有规律。团队承受着加班之苦，而测试人员“也无法跟上”。
> 
> \\\\
> 
> Susan和她的团队听说了基于迭代的敏捷方法，如Scrum。他们想办法让这种方法为他们所用。当她听说了精益的支柱是尊重人和持续改进，她意识到，自己缺少了一些东西。学识和技术实践帮助她实现了选择。
> 
> \\\\
> 
> 有个大问题是，她的上级认为敏捷方法只是另一种生命周期（最初Susan也是这么认为的）。没有人意识到，敏捷方法是团队和组织文化的变革。
> 
> \\\\
> 
> Susan和她的团队就问自己，如何才能看到他们的工作，如何限制在制品数量，如何实现频繁交付，而且是以与业务合作伙伴协作的方式？一旦他们提出了这个问题，他们改变了他们的记事板，改变了制定工作计划的方式，改变了响应方式——一切都变了。在这个过程中，他们遇到了一些小问题，因为在学习的过程中很难不犯错。不过，他们需要使用敏捷和精益原则创建一个创新、交付环境。
> 
> \\

\\\\

**InfoQ：团队如何组织？**

\\\\

> \\
> 
> **Rothman**：在许多组织里，管理人员向团队分派团队成员。那是成为自我管理型团队，然后成为自组织团队的开始。
> 
> \\\\
> 
> 当团队成员掌控了流程，他们就会认识到谁具有交付完善特性的技能和能力。如果团队开始可视化他们的流程，他们就知道何时需要一个UI人员，或者更多的测试人员，或者是数据库人员。团队可以提出这样的问题，“我们该如何相互学习，从而充分发挥每个人的能力，以便我们可以协作交付价值？作为一个团队，我们如何完成有价值的工作，并展示给我们的客户？”
> 
> \\\\
> 
> 当团队回答了那些问题，他们就学会了观察流程，就可以改进流程。然后，随着他们实现了这些答案，他们就建立起了跨职能协作团队。
> 
> \\

\\\\

**InfoQ：您在书里提到，在团队没有必要的技能时，您不喜欢将向团队增加“访问者”作为解决方案。您能详细说下为什么吗？**

\\\\

> \\
> 
> **Rothman**：软件就是学习和创新。当然，我们可能知道部分甚或许多需求。而且，我们知道如何处理其中部分或许多特性。但是，更多的时候，我们在做一些未知的事情。可能不是完全未知，但是未知的。
> 
> \\\\
> 
> 我见过一些关于访问者的问题。首先，虽然他们应该在一段时间内成为团队的一员，但他们没有。他们不和团队在一起办公。他们还有其他的任务。一名访问者说，他要在几个周的时间里访问其他五个团队。人们说的“访问者”不是这个意思（在一个特定的时间段内分派给一个团队），但是，他的上级认为访问就是这个意思。那不是很有效，这是上级特别关心的。
> 
> \\\\
> 
> 此外，访问者的名义通常会强化那个人的专业知识。“访问者”背后的意思是团队并不是长期需要那种专业知识。根据我的经验，那种想法是错误的。在绝大多数情况下，团队不只是现在需要访问者的专业知识，将来也需要。
> 
> \\\\
> 
> 由于访问者不是全程和团队在一起，所以访问者需要学习如何与现有的团队协作，而该团队已经学会了如何共事。这会导致延误。
> 
> \\\\
> 
> 这名访问者可能缺少分享其专业知识的动力。甚至更糟糕，我看到过一些工作环境，鼓励访问者不要与团队深入合作。
> 
> \\\\
> 
> 即使访问者愿意与团队合作，他们也会妨碍团队的协作。团队不得不向每一位新的访问者解释他们的团队是如何运作的。团队也需要作出改变，因为它得学习如何与其他人合作。如果你需要访问者，我建议你们结对或成群地学习访问者所知道的东西。
> 
> \\

\\\\

**InfoQ：有什么标准可以用来对特性进行排序？**

\\\\

> \\
> 
> **Rothman**：我喜欢的方法有三个，尤其是对特性而言：最短工作优先、价值趋势和学习。
> 
> \\\\
> 
> 当使用最短工作优先方法时，可以取得立竿见影的效果。你甚至能够构建出一个最小的端到端系统。
> 
> \\\\
> 
> 如果使用价值趋势方法，就可以帮助所有人看清楚不同的特性随着时间推移体现出的不同价值。有时候，现在还没有价值。有时候，只有现在有价值。
> 
> \\\\
> 
> 我还喜欢根据我们能学到什么来认定特性价值。这种方法鼓励MVP和MVE（最小可行试验）。
> 
> \\

\\\\

**InfoQ：在特定的情况下，如何确定使用哪一种方法？**

\\\\

> \\
> 
> **Rothman**：我喜欢首先使用学习或者最短工作优先方法帮助团队创建一个最小的端到端系统——最小的特性集，那样我们就可以看到产品如何工作。
> 
> \\\\
> 
> 通常，PO（或其他利益干系人）会有大的蓝图，整个产品的愿景。他们会说：“我全都需要，或者那没有价值。”他们可能也是这么想的。如果我们把这个大的蓝图分解成小的特性，那么我们就可以看到，什么现在就可以提供价值，什么将来可以提供价值。
> 
> \\\\
> 
> 在推进小特性相关工作的过程中，我喜欢考虑我们需要学习什么（有时候，甚至在我们开始实现一个最小的端到端系统之前就需要学习。）在考虑学习时，我们通常会考虑谁需要在什么时间学习什么，以及用户什么时候需要学习什么。
> 
> \\\\
> 
> 所有这三种方法都鼓励每个人创建和使用小故事。那是我们的“独家秘方”。
> 
> \\\\
> 
> 如果项目不复杂，那么我会首先使用最短工作优先方法。如果项目很复杂，那么我会使用学习。如果我们有很大的特性集，那么我会使用价值趋势，看看先做什么能获得最大的价值。
> 
> \\

\\\\

**InfoQ：对于“强化迭代”，您有什么看法？**

\\\\

> \\
> 
> **Rothman**：我讨厌强化化迭代的思想。当我们定义并使用故事的验收标准及团队的完工定义时，我们能够知道我们完成了这个故事。真得完成了。就是——请原谅——done-done或done-done-done。
> 
> \\\\
> 
> 如果团队无法完工，而且知道他们完成了工作，但他们最终不得不回到工作中去。出现那种情况没人会觉得好受。
> 
> \\\\
> 
> 如果团队无法知道或者无法达成故事完工，则可以考虑以下选项：
> 
> \\\\
> 
> 1.  进行回顾，了解人们那时有什么数据可以用来决策。现在，作为任务项生成的一部分，考虑通过试验来了解如何向团队提供其他数据。\\\\t
> 2.  弄清楚是否正是你的工作量评估创建了这种无法完工模式。有时候，团队会觉得似乎需要推动更多的工作。我们从更为连续的方法中遗传了“多么多”思维。转向“多么少”思维对每个人而言都是挑战。\\\\t
> 3.  看一下，对于团队的工作规范、故事、迭代、发布，完工都意味着什么。有没有可能为团队创造出更多的完工机会，有没有可能知道他们真得完成了一个特性？（我喜欢把场景作为故事和发布标准的一部分。）\\

\\\\

**InfoQ：为什么学习机会很重要？我们如何创造学习机会？**

\\\\

> \\
> 
> **Rothman**：借助敏捷方法，我们每天都可以收到关于产品、团队流程及团队交互方面的反馈。为什么不利用好这一点呢？
> 
> \\\\
> 
> 敏捷团队可以利用回顾的机会较为正式地学习产品和流程，就像喜欢小故事一样，我喜欢简短的学习。
> 
> \\\\
> 
> 在知识工作中，我们在开展工作的过程中发现并了解需求。我们每天学习如何协同工作。我们每天学习产品如何工作（或不工作）。
> 
> \\\\
> 
> 我们越是使用小故事，越是彼此合作，就有越多的改进机会。对我而言，目标不仅仅是改进——不是，我的目标是一款出色的产品，帮助我自己及团队改进，以及创建可以帮助客户解决问题的产品。
> 
> \\

\\\\

**关于作者**

\\\\

**![5e1cb7084ed09617be69aa333b9538d7.jpg][]Johanna Rothman**, 是一名“务实的管理者”，可以针对复杂的问题提出坦诚的建议。她帮助领导者和团队看到问题，消除风险，管理产品开发。Rothman的著作超过10部，其中包括：《Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver, Agile》、《Agile and Lean Program Management: Scaling Collaboration Across the Organization》、《Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects》。感兴趣的读者可以访问jrothman.com查看更有关于Rothman的著作的信息。

\\\\

**查看英文原文：**Q\\u0026amp;A on the Book \\"Create Your Successful Agile Project\\"

[5e1cb7084ed09617be69aa333b9538d7.jpg]: /images/20220222/6d88fc35e50c47c2937a394296a3419b.png