咳咳。。好吧，以上纯属小π姐姐YY，其实，故事的起因是这个样子的：

Mike Cohn老师在2018年2月份写了一篇博客，博客标题是“The Beatles 教会我关于敏捷的十件事情”，文中提到有一天Mike老师清理家里办公区的时候，发现有很多之前收藏的The Beatles 的专辑,于是他决定从1963年的《Please,please me》到1970的《Let it be》再听一遍，在听了他们的歌曲后，他发现学到了很多和敏捷相关的知识，于是，Mike老师列举了他认为从中学到的最重要的10件事情：

备注：以下附的有些是原唱，有些是翻唱哦！

在这首歌中，John Lennon向一个女孩唱着“除了爱情之外我什么也没有，宝贝，一周八天也不够。” 当然，一周并没有八天，所以Lennon唱的是超时。于是我想到，我们虽然在大多数情况下最好能够避免加班，但是当正常工作周不足以表明我在关注这件事时，这时可能加加班就是最好的选择。

在这首歌中，Lennon把自己看作是使用敏捷的用户或是客户的角色。 他提醒我们，我们的目标是“不要让我失望。”为了确保我们的客户满意，我们的敏捷团队必须始终专注于提供价值。

Come together

团队为客户和用户创造价值的最佳方式之一就是与他们合作。The Beatles鼓励团队和核心干系人“come together”，共同打造最好的产品。 特别是，Lennon调侃那些忽视用户需求只是一心构建他们自己想要的东西的开发人员。 他称这些开发人员是“Jokers（笑话者）”，然后唱道：“他必须成为一个小丑，他只是做他喜欢的事情。” 最好的敏捷团队是不会存在这样的Jokers的。

流行的敏捷短语“你不需要它”通常简化为YAGNI(You ain't gonna need it)。 这指的是要求的设计水准，其难度超过近期就能够完成的。 那么，在我们遇到YAGNI之前，John Lennon警告我们“明天永远不会知道”，这意味着我们应该关注的是当天的设计内容，不用纠结不远。

Lennon和Paul McCartney之间的合作也向向团队和核心干系人提出了一个小小建议，在解决问题时，“we can work it out ”。

歌词“Do I have to keep on talking till I can't go on?（我不得不继续说话，直到我不能继续？）” 提醒着团队的代码解决争论。 我们应该构建它，发布它，先看看客户的想法，而不是一直在内部争论。

通过提醒团队“only time will tell if I am right or I am wrong（只有时间会证明我的对错）”，Lennon和McCartney敦促团队创建一个最小的可行产品（MVP），提前展示给客户，看看目前的产出如何改进，与客户的需求相匹配。

I Am the Warlus

在这首歌中，Lennon唱出我们通常所说的“吃自己的狗粮”。 这里得到的启发是，如果可能的话，团队成员应该使用他们自己正在构建的产品。 这也意味着开发人员不仅仅是开发人员，也是用户。正如Lennon唱的那样：“I am he as you are he as you are me and we are all together（我和他一样，他就像你一样，我们都在一起。）”

在这首尖锐的曲调中，The Beatles警告说，只有通过观察用户“woke up, fell out of bed, and dragged a comb across his head醒来，从床上摔下来，并将梳子拖到头上”，敏捷的团队成员才能真正理解他们的用户。 为了开发出满足用户需求的产品，敏捷团队成员应该走出办公室，在用户的真实体验场景中去学习。

每日站会是敏捷团队中最常见的仪式之一。 在会议中，应该鼓励团队成员提出他们面临的任何障碍，并向团队中的其他人寻求帮助。 那些在敏捷团队中工作的人很快就会知道他们可以“get by with a little help from [their] friends.从他们的朋友那里得到一些帮助。”

在1964年的第三张专辑《A Hard Day's Night》中，Paul McCartney提醒敏捷团队，有些东西是金钱无法买到的。 McCartney唱到，“I don't care too much for money, money can't buy me love,我不太在意钱，金钱不能买到爱情”（是的是的！爱情不是你想买，想买就能买！！）

然而，在敏捷团队中，我们理解他正在为团队的产品唱出对客户的爱。 McCartney劝告团队，应制作高质量的软件。 他知道，如果是一个低质量的版本，会让顾客不再喜欢这个产品，我们不能用低质量的产品失去顾客的爱！

即使是优秀的敏捷团队也一定还有可以提升的空间，变得更好。 所有优秀的敏捷团队都追求持续改进。 McCartney知道这一点并撰写了这首歌，以鼓励团队始终“getting better, a little better all the time.变得越来越好，总是变得更好”。

OK，这是我从The Beatles歌曲中学到的其中最重要的十件事。

Mike Cohn老师在结束时，写道：The Beatles难怪会获得Fab Four的昵称。 除了伟大的音乐和富有哲理的歌词，我相信，只要他们下定决心，一定可以开发出一些令人惊叹的产品。

将歌词寓意与敏捷结合的方式，瞬间吸引了一票敏捷小伙伴的注意，他们纷纷在Mike Cohn老师的博客下面留言：

下面这位姐姐提到了企业文化：

当然还有一些持不同观点的，比如这位：

接下来，放大瞳孔！Emmmm,设计回家了，小π姐姐只能截图配文字得简单粗暴呈现出来这篇测测你的视力有多好的文章了：

嘻嘻，我喜欢！看起来在每次回顾会议前我需要唱一首“当我的吉他开始轻声吟唱”了！

然后出现了一位敏捷爱好者Robin告诉Mike Cohn老师，他去年也整理过一份“敏捷交付歌单”，以歌名的排序呈现出从瀑布转变为敏捷的变化过程:

Robin整理的歌单

Mike Cohn老师看到不禁大赞啊，他说这是一份伟大的歌单，他本人就非常喜欢Adam and the Ants的“Stand and Deliever",里面有他炒鸡喜欢的歌词。

而且Mike Cohn老师还建议说“You can't always get what you want"适用于团队平时和核心干系人的沟通，同时，礼尚往来，Mike Cohn老师又回送了一篇文章，说是其他团队成员总结的，以歌名为主题来寓意敏捷开发。(这样下去，这个聊天恐怕是无法结束咯）

在Mike Cohn老师再次推送的这篇文中提到，有些Sprint阶段的命名是以Sprint1或者Sprint2,也有稍微改动的Sprint2.1,Sprint2.2,还有一种命名方式是以Sprint结束的日期命名，比如5月18结束的Sprint就是Sprint5.18（只有我一个人想起了京东618吗？）,还有更具体的，大家会以Sprint完成的工作内容命名，比如购物车Sprint，发票管理Sprint。

一份不用数字，日期，工作内容命名，而是以歌名为主题的歌单，如下：

果然，音乐是一种沟通，任何人都可以爱音乐，从音乐中我们释放自己的天性，表达自己的心境，拉近彼此的距离，敏捷圈热热闹闹的歌王争霸赛也是敏捷人爱音乐的最佳方式啦！

除了音乐，前段时间，发现敏捷行动派的群里（如需加入400+敏捷行动派群，可扫描文末海报二维码哦），群友将Scrum与火锅生动得结合在了一起，讨论得好玩又开心，肚子还有点咕咕咕呢（吃货的表情）。。。

将敏捷玩得如此有趣，敏捷圈的小伙伴可以说是非常有意思了，音乐无国界啦，小π姐姐就想着如果我们出一期国内的敏捷圈歌王争霸赛，大家会不会也玩得不亦乐乎呢？如果你也有同样的想法，欢迎给小π姐姐留言咯！

原文还有更多歌神们的优异表现，意犹未尽的小伙伴可以打开原文链接慢慢欣赏咯！

https://www.linkedin.com/pulse/ten-things-beatles-taught-me-being-agile-mike-cohn

https://enigmacas.com/agile-delivery-playlist/

https://www.mountaingoatsoftware.com/blog/number-name-date-stamp-or-sing-your-sprints