敏捷开发自2001年提出敏捷软件开发宣言后有20年，但在中文里很少有一篇文章详细介绍敏捷开发。因此本文从敏捷开发，敏捷开发的历史，敏捷开发的分类，敏捷宣言（价值观），以及敏捷精髓等方面详细阐述了敏捷开发。本文的最后还列举了敏捷在除了软件行业以外的应用，比如硬件、人力资源、市场、等等。

Scrum之类的框架非常适合解决业务问题，并且公司不断过渡到敏捷以实现目标。但是，如果他们忘记了敏捷只是一种方法论（一种实现目标的手段）而不是目标本身，就会出现问题。

斯科特-邓恩（Scott Dunn）写了一篇很棒的文章，讲述了与管理层突然"变得敏捷"的决策有关的陷阱（和恐惧）。它反映出它是一个简单的实现方式（如更换供应商），而不是一个需要在观念上进行重大改变的框架，这是一种错觉。

“亚马逊正在这样做。”

这些都是很好的指标，表明企业尚未明确定义为什么要使用敏捷，以及"为什么？" 与公司合作过渡到敏捷或教学认证的Scrum课程时，这是我首先要提出的问题之一。

我经常得到诸如以下的答案：

• 我们想迅速适应变化
• 我们要不断改进
• 我们想更定期地交付

从表面上看，这些听起来像是伟大的目标，并且与我们从敏捷方法学中期望的结果一致。

但是，即使你没有明确定义目标，但即使听起来不错的目标也会引起问题和挫败感。

你怎么知道你选择了正确的目标？

假设我的朋友告诉我他想在未来12个月内再赚10万美元。我可能会鼓励他对这个目标进行压力测试，看看这是否是他真正想要的。

“五个为什么”是一种发现问题的根本原因的公知方法，它也可以很好地发现追求目标的根本动机。

如果我问我的朋友为什么他要这10万美元，他可能会回答说这是为了改善自己的地位，或者他说他想彻底改造自己的房屋。

如果我们再加上一个"为什么"，我们可能会发现更深层次的关于这些事情对他而言重要的内容。然后他可能会说地位对他很重要，以向他的父母证明他的成功。或者，他想进行改造，以便能在一天工作结束时回家会很高兴。

当你继续研究为什么某些重要内容时，你可以开始回顾最初的目标并提出以下疑问：这是正确的目标，并且定义明确吗？

例如，也许我的朋友不需要10万美元就可以向父母证明自己成功了，也许他只需要一些生活指导就可以意识到自己足够好。也许他一天结束以后想要回家所需要的所有东西都是问候他最好的朋友。

一个好的目标也需要好的指导方针

经过一番讨论，我的朋友决定他绝对想要的就是现金。

他应该如何实现呢？

他可以抢银行。或通过庞氏风格的加密货币骗局获得资金。

他应该考虑那些选择吗？

好吧，由于我的朋友不是犯罪策划者，所以他很有可能会被抓住并失去自由。他也是一个非常体面的人，所以犯罪的想法可能会让他不高兴。

大概不是。

显然，我们认识到，除了选择正确的目标之外，他还需要想一下如何实现该目标（例如不违反法律）以及不损害对他来说很重要的事情（例如他的自由和价值观）的指南。

当你有正确的目标，但执行错误

我认识一位高级副总裁，他想利用Scrum改善协作。

对于这种敏捷框架而言，这是一个完美的目标。但是，他还认为，只有团队实际合作才能实现协作。结果，他把每个人都搬进了一个狭窄的小房间，并坚持所有的工作和讨论都在那儿进行，整个团队都参与其中。

这不仅不舒服；这也意味着以前在家里工作了几天的一名会员现在每天要往返三小时。

士气和工作质量开始受到影响。当我进来看看为什么敏捷对他们不起作用时，我首先问他为什么要改善协作。

他告诉我，他希望团队成员：

• 了解其他人在做什么，找出差距，或查看成员在哪里过度工作，以便他们可以互相帮助
• 自信而迅速地讨论问题的解决方案
• 以简单明了的方式相互交流

而且我们意识到，这些东西实际上都不需要任何人坐在别人旁边。

副总裁再次审视局势，意识到"协作"并不意味着必须坐一起，而且我们能够重新审视他们为实现实际目标而可能采取的不同方式。

当你忘记原因时，很容易被分裂

我与一个刚加入团队的Scrum Master一起工作。当她发现他们修改了一些规则时，在她眼中，他们没有正确地执行Scrum。作为Scrum Master，她觉得纠正团队，确保每个人都以正确的方式做Scrum是她的职责。

为此，她仔细研究了规则，强调了团队的错误并建议他们应该怎么做。但是她推得越多，推倒的人就越多，这变成了无休止分歧的有害环境。

我问她为什么强制采用这些工作方式如此重要。她回答：

“因为那是我以前与以前的团队一起工作的方式，所以我们真的很成功。”

我请她描述该团队的情况，并分享她为什么认为他们在一起表现很好。

“我们做到了。即使我们犯了错误，我们也是彼此的啦啦队。我们知道彼此的长处，我们从不担心踩脚，我们真的很乐意进去并尽自己最大的努力。”

当我们退后一步时，我们发现她对规则的严格性造成了紧张、不信任和生产力下降。她的总体目标是成为一支高效能的敏捷团队，但她的短期行动与之直接冲突。

如果你想避免类似的敏捷问题，请参考以下建议：

压力测试目标并确保目标明确

如果你的组织正在向敏捷过渡，请鼓励经理在可能的情况下对这些目标进行压力测试。保持好奇：找出真正重要的内容。消除歧义性与团队协作所要实现的模糊性，这样你就可以通过自己的方法来发挥创造力，而不是被任意的规则所束缚。

考虑一下你愿意支付的费用，以及你不会受到损害的地方。团队士气重要吗？吸引更少的客户以实现承诺，提供更可靠的服务并建立更多的重复业务是否更好？ 

在团队层面追求目标

我最喜欢的非敏捷书籍之一是Daniel Coyle撰写的《文化守则》。在其中，他研究了使某些团体成功的因素，并向领导者展示了如何建立凝聚力、积极进取的文化。在运动队中，他发现成功通常与团队成员做出的许多无私的传球有关，与个人如何将团队的成功置于个人荣耀之上。

我认为成功的敏捷团队也会发生同样的事情。与我一起工作的一个团队按时交付，但显然设计师天天加班。成员在计划和挑选任务时没有考虑自己的个人能力，而是开始考虑团队能力。他们认为，如果一个人在挣扎，他们会都很难受。开发人员放弃了自己的一些积压项目，花一些时间学习设计并尝试提供帮助。团队在短期内降低了速度，但从长远来看，由于他们拥有更加广泛的技能，他们开始提供更多的东西。如果他们只是专注于在每次迭代中提供尽可能多的功能，那么这种长期的进展可能永远不会发生。

敏捷是否在帮助你实现目标？

我希望知道你的经历。目标是否明确定义和理解？还是你曾经觉得自己正在遵循以流行语为基础的商业计划？使用Scrum和敏捷解决业务问题或实现目标时，你发现什么效果很好？

所有你的敏捷是怎么样的呢？ 是否有关注到最终目标呢？ 敏捷转型过程中你还有哪些困惑呢？

欢迎留言讨论……

成功实现敏捷的三个关键领导作用

---

两组领导

不久之前，我正在与潜在客户交谈，我们称他为对"变得敏捷"感兴趣的史蒂夫。史蒂夫告诉我他已经非常了解敏捷。他希望自己的组织"敏捷"，以更快地交付产品，更好的可预测性和更好的指标。

…所有这些都是组织"敏捷"发展的重要原因。但是，当我问他如何使用更好的指标时，他给了我停下来的理由。

史蒂夫（Steve）的回答：“我们想看看团队的表现如何，我们是否摆脱了我们付钱给他们做的事情。我们买不起懒散的人。如今的步伐令人难以置信……”

不用说，他的回应激起了我的好奇心。我继续提出更多问题。我想了解一下他对敏捷的真正了解以及他认为"走敏捷"的含义。

事实证明，这位特殊的高管深深植根于可追溯到工业时代的过时领导思想。他的目标是使用敏捷指标来改进"命令和控制"方法，并使用"数据"加强对团队的控制。所有这一切，都期望他的团队在自上而下的控制下能够更快，更好，更快乐。

不幸的是，史蒂夫也不例外。仍然有一些高管想要采用敏捷，但是将其用作自上而下的规则的手段。他们期望看到敏捷产生显着的组织成果，但将继续使用与敏捷价值相悖的"工业时代思想和手册"。

在创建和维持敏捷组织方面，我见过两种类型的领导者。有些领导者希望"敏捷"，并理解这样做会带来全系统的组织变革。他们采用敏捷并调整领导风格以反映敏捷价值观。我们称它们为"第1组"。

然后，还有像Steve这样的领导者想要"走敏捷"，因为他们希望获得敏捷的好处，例如更快的产品上市时间，更好的产品质量和更高的NPS分数，而无需对其领导方式进行任何调整。他们想采用敏捷，但不愿意自己适应敏捷。我们将这些领导者称为"第2组"。

与第一小组相反，这些第二小组的负责人将敏捷视为产品交付框架，其中实施由专家（敏捷顾问或教练）领导，并在本地受限级别实施。他们认为敏捷实施会影响执行级别的团队，使执行领导和中层管理人员能够照常进行工作。

根据2019年第一版发布的第13份年度敏捷状态报告，采用和扩展敏捷的三大挑战是：

• “一种与敏捷价值观背道而驰的组织文化，”
• “管理支持和赞助不足”，以及
• “……对变革的普遍抵抗。” （ColabNet VersionOne）

本文是针对第二组领导人的。这是为了帮助他们以及与他们一起工作的人们首先认识到自己属于第二小组，然后学习开始转移到第一小组领导人所需要的条件，该小组认识到领导者在各个层次上的要求。一个"敏捷"的组织。

在我们讨论可行的举措之前，将把领导者从第2组转移到第1组的三个关键方面，重要的是要了解第二组的领导风格，他们的信念体系以及他们认为敏捷实施在多大程度上引入了内部变革一个组织。

---

过时的领导：管理与工人分裂

第2组领导人的领导风格在工业时代的管理方法中具有深厚的渊源，可追溯到Frederick Winslow Taylor。泰勒（Taylor）在1911年出版的《科学管理原理》一书中，革新了科学管理理论的工作方式。在这里，他对负责计划工作方式的管理小组（“思想者”）与必须遵循经理的命令并按要求进行工作的工人（“行动者”）之间进行了非常清楚的划分。（维基百科）

令当时工会和熟练的贸易工人感到沮丧的是，泰勒的建议越来越受欢迎。结果，工作的控制不再掌握在熟练工人手中，而是掌握在管理人员手中。劳动者沦为纯粹的订单追随者，他们的价值是根据其利用和绩效产出来衡量的。任何不将自己推向极限，并且一直不忙于手工工作的人都不会被视为"士兵"，而只是在花钱。

领导就是力量：告别分裂，你好管理和工人团结……

为了使敏捷方法论有效，领导层需要与执行团队一起改变其管理流程。尽管效率仍然很重要，但管理方法应基于与从客户眼中创造的价值相关的有效性。它需要从上到下转变为更集体/服务的领导，我称之为"能力领导"。

用伟大的克劳斯-施瓦布（Klaus Schwab）的话说，世界经济论坛创始人：

“我们需要具有情感智慧，能够为合作工作建模和倡导的领导者。他们将指导而不是指挥；他们会被同情而不是自我驱动。数字革命需要一种不同的，更人性化的领导方式。”

（如Artley所引用）

领导者是组织系统设计的负责人，因此当务之急是领导力方法以及他们作为领导者展现和培养的特征必须与敏捷价值观保持一致。

一切始于领导者认识到敏捷有潜力在整个系统级别优化组织。仅将敏捷作为产品开发方法实施在位于一部分内部的组织的某个部分中，让领导和组织的其他部分改变其方法，充其量只能是对敏捷的次优化，并将其设置为失败。最坏的情况

实施敏捷可以水平和垂直地改变组织。它影响领导者和团队。它影响流程，人员，技术，更重要的是，它影响组织中每个人的语言，文化，行为和思维方式。

敏捷作为一个系统类似于活有机体。它就像一棵树，依靠有利的条件来繁衍生息。

领导者的职责是根据天气趋势/市场条件，从战略上创造必要的条件，以充分利用敏捷。

因此，如果泰勒主义的飞跃太大，领导者可以以问自己的温和方法开始过渡，而不是如何根据时间和产出最大化工人的利用率，而是如何充分利用敏捷的潜力：

• 准备"植入"敏捷需要哪些条件？
• 敏捷将在其中蓬勃发展的沃土的定义是什么？

条件的实现：3个关键因素，可以使您的组织成功

向"赋予"必要的背景和文化的转变，从而为敏捷发展壮大的沃土，要求第二组领导人的思维，信念和行动发生三个重大转变。这三个转变是：

1. 专注于集体智慧
2. 创造创新的心理和职业安全
3. KPI和奖励基于价值创造而不是利用价值

从过时的领导风格转变，而将组织的条件转变为拥抱和培养敏捷，这不是一件小事。同时更改个人级别和组织级别上的各种变量的工作需要有意识和持续的努力。这三个步骤是领导者需要采取的少量措施，但对于将其定位为从第2组过渡到第1组以及使敏捷转型成功，至关重要。

剧1：关注集体智慧

术语"集体智慧"是由托马斯-马龙（Thomas Malone），麻省理工学院的管理学教授帕特里克-J-麦戈文（Matrick P. McGovern）以及麻省理工学院集体智能中心的创始主任创造的。集体智慧的基本前提是这样一个想法，即一群在一起工作的个体创造的智慧在个体层面上是不可能的。（什么是集体智慧？）

因此，第2组领导人为成功建立敏捷而需要做的第一步是消除泰勒在管理层和团队之间的鸿沟，并挖掘集体智慧所提供的潜力。

管理层和员工必须团结一致，朝着敏捷实施所推动的共同组织目标努力。

领导者必须承认，团队不仅仅是执行被告知内容的"行动者"。他们也是思想家，解决问题者和领导者。通过承认这一点，领导者将增强组织的集体智慧，并处于创新和应对快速变化的复杂市场挑战的更好位置。

剧2：创造创新的心理和职业安全

为了能够利用组织的"集体智慧"并使之最大化，领导者需要为团队创造一个环境，以允许开放式沟通，创造力，有计划的冒险精神和失败。

通过邀请团队成员共享想法，相互挑战和领导才能来创建这种环境。领导者通过举例说明团队与管理层之间的开放式沟通，来奖励寻求挑战者和解决问题的人，以此来肯定这一点。

研究表明，“聪明的团队”（具有很高的集体智慧的团队）并不一定是一群智商高的人，而是一群"沟通能力强，平等参与，拥有良好的情感阅读能力的人"。（Wolley，Malone和Chabris）

领导者必须鼓励和奖励这些可取的行为。

剧3：基本KPI和奖励 不创造价值

在将组织转变为敏捷组织的过程中，必须改变一些旧的领导行为，但对于遵循度量标准和可测量数据的渴望，既是遵循泰勒原则的老式管理人员，也是成功的敏捷人士所共有的。

关键区别在于我们要在敏捷组织中使用哪种类型的指标以及用于什么目的。

尽管科学管理要求制定度量标准以确保遵守管理部门设定的规定性方法，但在敏捷环境中，度量标准用于诊断团队在何处需要管理部门的帮助。在运作良好的敏捷环境中，领导者可以帮助团队解决挑战-他们不使用指标作为证明低绩效者受到惩罚的数据。

与敏捷的思维方式和价值观相一致，KPI和奖励不应基于最大限度地利用资源。不应根据输出量按时管理工人。如果组织的目标是创造客户定义的价值，则KPI和奖励应与该目标保持一致。

与往常一样，KPI特定于组织，并且针对目标以及组织敏捷性成熟度。赋予团队权力的一种方法是为他们提供试验和奖励解决问题的能力，以及积极主动地优化和创造价值。无论是通过确保团队保持创新的速度还是组织定期的创新活动，领导者都需要为团队分配时间和空间来进行创新并为此奖励。

如此处所述，管理层和执行领导层不仅在敏捷组织中发挥作用，而且它们的作用也非常重要。

它是系统级别的启用，授权和组织优化之一。

通过尊重个人贡献者的知识和创造力来挖掘集体智慧的潜力。

它将创造一种环境和奖励系统，以加强受控的冒险，创新和解决问题的能力。

因此，如果史蒂夫（Steve）和像史蒂夫（Steve）这样的领导者希望获得更高的收入并希望进行创新，那么基于过时的《工业时代手册》进行的微观管理知识工作者将不会使他们成为未来的行业领导者。

写在前面

非常感谢 ETH123.org 的启发，在以太坊资源大全网站上线的时候，给我提供了灵感。尤其他们的网站是开源的，我可以直接 fork 下来进行改造即可。真心感谢ETH123.org，尤其还是感谢以太坊爱好者的曾汨和开发小伙伴。（帮我解决了一个技术问题）

还有哪些需要优化

目前还有几个地方有待进一步优化：

1. 收集更多的敏捷相关学习资源
2. 制作 Agile123.net logo
3. 每个资源（网站）的logo收集
4. 对于资源分类的建议

任何想法和建议，都欢迎在 github 上面提交issue。

目前有哪些资源

敏捷学习资源分类

当前的分类如下：

热门推荐、社区、敏捷框架、Scrum专区、大规模敏捷、产品设计、DevOps、敏捷度量、意见领袖、工具、资讯、博客、咨询公司、敏捷图书、敏捷实践等

收集的敏捷学习资源网站

这里就不一一列举了，如果你的博客，网站也想收录进来

欢迎在 github 上面提交issue。

最后，如果你认为这个站点对你有帮助，欢迎分享给更多的伙伴。

谢谢你的分享。

CSM培训总结

为期4天的CSM培训结束，自己对敏捷有了更深的认识，scrum是一种轻量级的框架，但却有着功能强大的价值观，原则和实践，主要体现在团队能在短期内能够尽快地响应变化，交付产品，快速反馈，适应变化，连续提升，相比较使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素（内部和外部因素）的复杂度增加，项目成功的可能性就会降低。

在scrum 三个角色当中，我觉得SM相对来说比其他两个角色重要，SM作为team leader和PO紧密地工作在一起，可以及时地为团队成员提供帮助。他的职责在于以下五点：

1. 保证团队资源完全可被利用并且全部是高产出的。
2. 保证各个角色及职责的良好协作。
3. 解决团队开发中的障碍。
4. 做为团队和外部的接口，屏蔽外界对团队成员的干扰。
5. 保证开发过程按计划进行，组织 Daily Scrum, Sprint Review 和Sprite Retrospective。

SM除了主持Daily Scrum之外，还有三个主要职责：

• SM需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估计可能已经发生变化。
• SM需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的条目。
• SM还必须仔细考虑进展中的任务数，进展中的工作需要得到最小化，以实现精益生产率的收益。

SM需要找出阻碍 Scrum的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决，有些则要团队之间的协调，还有的要管理层的介入来解决，甚至有些是公司的问题阻碍了团队达到他们的生产力。

现在的工作模式基本是按scrum来运作的，在迭代开始前，会有需求清单(Product Backlog)，PO会把Product Backlog排出优先级，识别出更有价值的需求排在靠前，团队从需求清单中选择迭代中要完成的US(Sprint Backlog)，由SM给每个成员做任务划分，然后成员根据开发的周期输出自己计划，将US拆分成每天要完成的Task，每天上班先进行Daily scrum，反馈前一天完成了哪些任务，今天要完成的内容，其中遇到的一些问题，SM通过沟通，协调资源等多种途径解决在Daily scrum中反馈的问题，Sprint Backlog完成形成Increment，由PO和用户验收，之后团队进行Sprite Retrospective，总结出急需改进的Top问题以及继续保持的点。

不过还是有些差异，比如Scrum角色中的PO，只能定位作为一个决策者，团队在迭代过程中遇到解决不了的问题以及与其他团队协作问题等，才由PO来沟通，解决；而需求条目的澄清则由团队中专门负责需求整理输出的同事来承担，这可能是由于商业合作产生的这种模式。再比如迭代的周期都比较长，一个迭代至少3周甚至更长才能完结，迭代的交付时间中固定的，团队只能通过施压的形式，来要求团队成员按照交付时间点来完成产品Increment。

– CSM学员 宋

Scrum敏捷管理学习心得

敏捷开发是一种能应对快速变化需求的软件开发能力，包含Scrum、极限编程（XP）、晶体、特征驱动开发等多种方法。其中Scrum是最被广泛使用的一种方法，旨在指导团队进行产品的快速迭代和增量交付。

敏捷软件开发宣言：

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人，由此我们建立了如下价值观：个体的互动高于流程和工具、工作的软件高于详尽的文档、客户合作高于合同谈判、响应变化高于遵循计划。

敏捷宣言遵循的原则：

1、我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。 2、欣然面对需求变化，即使在开发后期也一样，为了客户的竞争优势，敏捷过程掌控变化。 3、经常的交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。 4、业务人员和开发人员必须相互合作，项目中的每一天都不例外。 5、激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。 6、不论团队内外，传递信息效果最好、效率也最高的方式是面对面的交谈。 7、可工作的软件是进度的首要度量标准。 8、敏捷过程倡导可持续开发。责任人、开发人员和用户能够共同维持其步调稳定延续。 9、坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。 10、以简洁为本，它是极力减少不必要工作量的艺术。 11、最好的架构、需求和设计涌现于自组织团队。 12、团队定期地反思如何提高成效，并依此调整自身的举止表现。

敏捷的五个核心价值观：专注、公开、承诺、勇气、尊重。

Scrum的三个核心角色：Product Owner（PO）、Scrum Master（SM）、Scrum Term（团队）。

其中 PO的核心工作为：对团队对外交付的价值负责，定义需求、定义需求的优先级和验收标准、定义产品发布内容与日期。

SM的核心工作为：帮助团队遵循Scrum框架，持续改进，促进团队工作，帮助团队排除影响生产力的障碍、保护团队不受干扰。

Scrum Team则对交付结果负责，敏捷团队是自组织的团队、小而美，一般团队成员定义为5-9个人。

Scrum的3个工件：Product Backlog（产品待办列表）、Sprint Backlog（Sprint待办列表）和Increment（可交付产品增量）。

Product Backlog即产品视角的需求清单，由PO负责维护，并根据优先级进行排序，优先级高的颗粒度更细，优先级低的对应颗粒度粗。用户故事是其中一种最佳实践，每项需求都应该描述其外部价值。

Sprint Backlog即冲刺周期内规划要完成内容，来源于Product Backlog，由团队评估和选择Product Backlog中哪些放入Sprint Backlog，同时团队需要一起定义完成的标准。

Increment即冲刺结束后可对外发布的产品功能增量部分。

Scrum的5个事件：Product Backlog梳理会议、迭代计划会议、每日站会、迭代评审会、迭代回顾会：

Product Backlog梳理会议贯穿整个Scrum项目的始终，主要保持产品待办列表有序、凸显价值。

迭代计划会议作为Sprint的开始，决定在迭代中完成哪些待办列表，明确任务和战前鼓舞。会议时长对应Sprint周期每周2小时。

每日站会，会议时长建议为15分钟，检视上一个工作日做了什么，当天的工作计划和存在的问题，阐述最好是可视可量化的，问题不发散，做好时间管理。

迭代评审会议：会议时长一般每周对应1小时，在sprint结束时团队和相关干系人一起评审sprint的产出、完成工作是否符合需求预期，并展示当前产品增量情况。

迭代回顾会议：会议时长一般每周对应45分钟，在sprint结束后，scrum团队开会反省和检讨，对迭代周期内做的好的进行表扬和鼓励，不好的，提出改善方案和完成计划。

Scrum敏捷开发的优势：拥有快速反应的能力，精确要求，精准结果，更大的灵活性和稳定性、提高团队绩效，降低成本，失败的代价降低。劣势：敏捷注重人员的沟通，文档维护难度增加，在新员工较多未形成战斗力时，老员工较累。

结合当前项目实际情况的分析：

• 1）团队人员数量超出了Scrum的最优定义，站会易超时；
• 2）PO是新人，没有明确的职责定义，对产品认识度不够。
• 3）验收标准有时候没有很明确的定义，在长期不上线使用的情况下，拉通联调的支持周期过长，容易“带病”到后面的迭代。
• 4）新人较多，效能提升，共同价值目标磨合需要时间沉淀。
• 5）对于迭代评审会议，目前做的不够，没有很好的展示迭代输出成果。
• 6）奖惩制度不合理，在不断的高压冲刺中，难以长期的保持团队成员的斗志和凝聚力。

相信每个SM在Scrum交付过程中，总会遇到由内到外、由外到内等各种问题，需要不断地反思、学习、总结，所有的管理问题，最终都是人的问题，唯有持之以恒的学习反省，才能走的更远。 限于时间精力和篇幅，先写这么多吧，望谅解！

• CSM考试学员：徐某
• 2020-12-23

敏捷交付

对于敏捷交付培训与实际运用中，我理解为我们需要持续不断的及早交付满足客户有价值的的软件，在交付过程中不断通过变化，通过及时沟通，标准的流程，统一化的工具，进行可持续，高效的交付。

在软件开发中，领导阶层的指挥控制方式（经理创建详细的工作细分结构、向团队分配任务，并告诉他们每项任务要花多长时间完成的方式）存在问题。敏捷方法从业者认识到，实际执行工作的人才是制定这些决策的最佳人选。开发人员确定他们的任务，他们执行自己的评估，他们自愿挑选任务，他们自行分担工作量。在本质上，他们就像一个高效运转、自行组建的团队，没有明确定义项目经理职位。相反，该团队指派某个人作为团队领导，帮助推进整个流程，让团队成长，让团队在缺少SM这个角色后，还能依然运转。

我从如下几点详细描述我了解的敏捷交付:

• 产品路线图，
• 项目目标与里程碑，
• 团队成员责任划分，
• 团队流程与工具管理，
• 项目风险管理，
• 团队反思。

第一，产品路线图。

在产品路线定下来以后，根据产品的背景、前景和价值，让团队意识到该项目的重要性，了解产品的主要交付路线，产品主要需求的优先级，以及大致上线时间点。

第二，项目目标与里程碑。

主要是对产品路线的补充，对交付功能模块的细化，项目完结交付的所有功能点，SM基于产品路线和需求进行模块拆解，澄清所有功能点，对总目标功能点的里程碑设定，以及每个里程碑各个职能组完成的主要任务；

第三，团队成员责任划分。

主要是基于项目功能，明确团队成员和职责，让团队对每个人所负责有概念认识，基于功能和流程，明确团队成员和职责，对项目开展的相关环节的必要说明，大家共同遵守的团队规则章程，明确团队共识的协作方式。

第四，团队流程与工具管理。

为了确保共识计划得到落地执行，团队保持高效交付，那么就需要借助一些研发管理工具，辅助我们进行项目开展实施，同时在项目交付的过程中不断优化交付流程，代码管理，需求管理，人员管理，交付件的管理，将产品需求、项目任务、测试Bug以及其他事项都及时录入到项目管理工具，持续跟进、督促、检查，争取将所有事务录入项目管理工具，包括未被考虑的事情，让团队自己给自己建任务。

第五，项目风险管理。

主要是向团队成员告知个人任务进度和安排，以及需要支持的相关事项，及时暴露风险和问题；同时交付过程中存在需求理解，表达不清晰的地方，人员理解不一样的地方，要及早暴露出来这些风险，通过与客户沟通及视补救，沟通过程流程与工具能够尽早把风险扑灭。

第六，团队反思。

团队定期的反思如何提高效率，并以此调整自己的能力，让团队没个人都能够成长，同时淘汰不符合团队的人，让团队人员更加稳定延续，人员稳定才能保证项目的稳定，让团队成员执行力强，凝聚力强，没有旁观者、推诿者，共担解决；能力强，独挡一面，人人都是神枪手。 通过这6点，我们能够提醒、督促、辅助我们落地美好计划，让团队管理更加透明，让项目实施更加具体、让项目风险更加可预期，同时也可以加速交付节奏，做到极限编程，有着稳定的工具，流程，人员，并以即时的方式来让项目投资获得最高回报。

– CSM 学员陈某

内容来源：敏捷+社区线上直播009期，《在敏捷实践中加速成长》分享实录

分享者：平安壹钱包杨大鹏

关注本公众号回复"平安"即可获取本次分享的视频回放、下载PPT

平安集团是国内少有的，具备成体系的敏捷教练队伍的企业，从上到下拥有很好的敏捷土壤。再介绍一下我自己，我有十几年的工作经验，最初几年是做程序员，后来转向了项目管理和技术团队的管理，长期服务于外资银行和金融互联网的企业，我曾经在日本生活过很多年，非常熟悉传统的软件研发流程，也算是比较成功的 it项目管理者。我可以非常准确的挖掘客户需求，管控项目成本，管理团队，把成果物非常高品质的交付给客户。

但是后来我发现了一个问题，我不知道我交付的成果物能否为客户带来价值，项目结束结项以后，团队可能就会解散重组，我也没有办法持续地去帮助团队的成长。针对这两点我曾经非常的苦恼，后来就开始逐步学习敏捷的理论，毫不回头的走向了敏捷实践。

今天我和大家分享两部分内容，第一部分是在敏捷实践里，个人应该树立怎样的目标。第二部分我会用我自己的一个比较接地气的案例，来分享针对团队级别的敏捷实践，我怎样去具体解决一些常见的难点问题。用这个案例来分享我的思路和认知，希望能给大家带来一些参考。也希望能够帮大家少走一些弯路。

第一部分，我们现在是身处复杂的互联网时代，非常复杂，也被称为乌卡时代，典型的案例小黄车ofo，几年的时间里跌宕起伏，让人叹为观止。

查看原文获取更多材料和音频

内容来源：敏捷+社区线上直播008期，《敏捷的潘多拉魔盒》分享实录

分享者：李聃

关注本公众号回复"潘多拉"即可获取本次分享的视频回放、下载PPT

今天我给大家带来了一些关于敏捷方面的分享，也希望大家能有所收获。由于疫情我被困在了家中，所以在此我插播一个广告，非常感谢敏捷家及网易杭研组织这次课程，同时也感谢Bob老师以及在场的各位小伙伴。

今天我要分享的Topic是敏捷的潘多拉魔盒，当然了在讲课之前先做一个自我介绍，我叫李聃，我的聃和老子同名，我的姓也和老子同姓，所以我跟老子是同名同姓的。在我过去的16年的工作经验中，将近有10年是在做项目管理工作的。近5年其实我主要是公司的PMO负责人，管理公司的项目，并帮助组织做一些敏捷转型的相关工作，也辅导过很多的敏捷团队，也组织过或者作为演讲嘉宾参加过国内的一些敏捷或DevOps大会，并翻译过相关的一些书籍。关于专业认证方面，我有41个国际认证，包括项目管理、产品管理、精益敏捷、DeveOps、规模化敏捷和IT服务管理，同时我也是非常热门的火星着陆器和凤凰项目的沙盘授权讲师。

下面我们正式进入今天的课题，今天要分享的内容主要是围绕着敏捷及敏捷的一些反模式的话题所展开的。它其中包括4个小节：

• 乌卡时代的魔盒 
• 潘多拉打开了魔盒 
• 敏捷魔盒中的这些冰与火 
• 敏捷魔盒中的最后的希望

我会通过几个故事和大家聊一下敏捷这个事情。

VUCA时代的魔盒

下面我们开始一起来揭开今天的潘多拉魔盒。说到乌卡这个词，它是由美国陆军在90年代初提出的一个概念，它是应对冷战后世界形势的一种解读。乌卡是由易变性、不确定性、复杂性、模糊性这4个英文单词的首字母所组成的。既然世界形势发生了变化，战略方针、战略行动、组织结构也应该随之而变，所以组织也应会应对这种战略、战术和组织结构做出相应的调整。个人应该做出什么样的转变呢？我觉得可能个人需要做到有愿景、有知识、有勇气和不断适应。

查看原文获取更多材料和音频

内容来源：敏捷+社区线上直播005期，《我在哈啰的敏捷之旅》分享实录

分享者：哈啰出行陈文博

关注本公众号回复**“哈啰”**即可获取本次分享的视频回放、下载PPT

非常开心在空中和大家相聚，希望在接近一个小时的时间我们都能有所收获。首先感谢Bob老师和网易杭研的李岩同学，是因为他们的支持，我才能够在这里和大家分享。在开始之前，先简单自我介绍一下，我是陈文博，供职于哈啰出行PMO部门，一名成长中的敏捷教练，今天有很多敏捷社群的小伙伴来支持，谢谢大家！

【正式分享之前，先上一个彩蛋】

查看原文

言归正传，今天的分享将分为两部分：

• 第一部分是我在哈啰做的一些敏捷实践，包括目前我是怎么操作Scrum的，如何利用透明拉通团队共识，如何利用内驱力模型来激励团队，以及我在兼顾多个Scrum团队时如何培养内部的Scrum Master。
• 第二部分将给大家分享我在内部敏捷社区的一些做法，包括我是怎么发起内部敏捷社区Thor，以及社区是怎么运营的。

一、我的敏捷实践

首先给大家分享的是敏捷宣言的第一句话，“我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。” 分享这句话的原因是，我觉得敏捷实践是没有最佳实践这么一个说法，永远都是在不断地迭代，不断地找到更适合当前组织和团队上下文的一种做法，所以我在这里给大家分享的，也是基于我自己团队的上下文找到的目前最好的方法，后续还会继续迭代，以便做得更好。

查看原文获取更多材料