本次吐槽献给 Scrum Master 们。毕竟了解了软件社区其实对 Agile 和 Scrum 的情绪已经有些像走到结尾的爱情故事，也许可以让大家在工作中不要把自己和大家 SM 得太惨。加上我们进新公司之后也在推行敏捷流程，不如整理一下本座对这套东西好鬼复杂的情绪…

Agile，中文翻译为「敏捷」，是在 90 年代逐渐引起广泛关注的一系列新型软件开发方法的总称。其中「敏捷」的语义主要是指应对快速变化的需求。

敏捷思想发展到顶峰的标志是Agile Manifesto的正式定稿。当时大概谁也没有想到，2001 年二月这群敏捷方法发起者和实践者在美国犹他州雪鸟滑雪圣地的一次聚会后的产物，能在软件工程和方法论范畴独领风骚这么多年。

但敏捷再好，它毕竟是人写的不是神写的，也会随着技术的不断革新慢慢变得过时。类似的，[Scrum](http://en.wikipedia.org/wiki/Scrum_(software_development)这种用于实践敏捷的开发流程虽然也大红大紫了这么多年，但它也暴露出了不少缺陷。

瀑布文档过多，敏捷文档过少

世界变平了之后，大多数的公司团队是分散在多处的。即便是 TestBird 这样没有超过 100 人的公司，办公地点也分布在多个国家和地区。而在编写 Agile 指南的 2001 年，本座还细皮嫩肉，Subversion 还是新鲜货，Git 还没有被发明，Skype 这类 VoIP 的方案还没有出现，云还仅仅是用来下雨的。因此里面说到：

在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈

当然，值得一提的是强调沟通本来就不是 Agile 的发明。在 Agile Manifesto 刚刚被编写出来时还占据着主流的瀑布式开发里，要求编码开始前撰写非常详细的文档，然后再对这些文档进行充分的评审：沟通和讲解其实是完成这些工作的前提。只不过 Agile 不但高度推崇面对面的交流，而且鄙视文档活动，结果虽然在一定程度上减少了瀑布流程里面写文档写到程序员晕厥的状况，但又对公司造成了新一轮的伤害。

讨论之后还得多写写

在软件开发中，有些工作通过口头交流本身就是低效的。

当然有适合面对面讨论的部分：比如对关键模块的技术选型，比如对业务流程和需求的澄清。

但进入设计和实现阶段的活动，应该是看得见摸得着版本化可回溯的，所谓”a wireframe is worthy than one thousand words，a prototype is worth a thousand wireframes”。

比如下面是一次提交之后 Gitlab 上提供的查看 diff 的界面：通过这样的方式 review 整个改动，比小伙伴坐在自己怀里结对编码要清楚得多（而且小伙伴坐在怀里的时候引发的羞赧常常让你难以把他的错误直接打到他脸上不是么）：

所以我会经常在公司里面鼓动大家把输出都落到代码和文档里面。经过一段时间，就会慢慢看到有人在群里面问「那个什么什么是怎么回事」的时候，后面的回复是「你去看看 confluence 上 xxx 页面」或者是「这个是 jira 的 xxx 问题单讨论的」。

如果你的员工经常需要重复回答同一个问题，包括来个新员工这个环境怎么配那个 Wifi 的密码还需要人告诉他/她，你也好意思说自己是敏捷的？

讨论之前最好多写写

强调面对面沟通，而弱化文档和代码本身在沟通中的作用，造成的一个更严重后果是面对一个问题，大家不仔细思考就开会讨论。结果会上随便放炮，下来各不认账。

我在 M 记做 PM 的时候，项目组里面有几位韩国同事。因为是远程办公，每天除开代码之外，我们只能通过 Skype 交流。这里面有个叫 Jason 的同事，无论分给他什么活，他不但做得飞快，而且还会以Confluence上一篇甚至几篇洋洋洒洒的文章作为交付。

在回顾那个项目的时候我发现，我和他没有每日站会，没有 Sprint 结尾的 demo，但我们之间的沟通是整个团队里面最高效的：每天查看他提交的代码和文档，我就非常清楚他的进度和问题了。

这样做的收益并不仅仅是我们之间沟通的高效。

在他第三个小孩儿出生之后一周，他搞定了一个非常复杂的调研任务。聊天的时候我问他怎么可以在那么多私事需要处理的情况下弄得这么快。他说，有很多时候在 confluence 上写着写着，自己的思路就清晰了。

这也是我自己的感受。很多次我在写邮件问其他人问题的时候，邮件写完自己就有了答案。我自己呆过的团队，厉害的工程师都非常能写：他们的区别不过是有些人只记录给自己看，有些人会写给大家看。

流程、工具和个体究竟谁更重要

前面说了技术的革新使「面对面沟通」的重要性变得过时和有害。那么下面这个 Agile 核心思想呢：

个体和个体间的交流比流程和工具更重要

我自己对这种「人定胜天」的论调天生有抗拒感。就像当年主席发明这句话是因为大家日子过得足够糟一样，只有你为团队提供的工具足够糟才需要这么去忽悠大家。

软件开发是一项和工具高度相关的工作。除去你的生产活动的效率很大程度上取决于你对工具的熟悉程度以外，你还需要使用工具参与到流程中：和其他人交流、配环境、提单、解 bug、记录工作时间等等，都离不开工具。

无论你的团队好好工作的意愿多么强烈，如果你还在用 sametime 而不是 slack，还在用破破烂烂自己开发的测试用例管理工具而不是 rally，你的开发流程就是不如别人顺畅。

因为使用的工具可以「塑造」你的团队沟通的方式（反过来你团队沟通的方式也可以塑造他们使用工具的方式）。

这也就是Marshall McLuhan的著名论断The medium is the message （Wired杂志把他视为办刊的精神导师，我觉得搞互联网的人都该看看他的书）:

Daily StandUp or Daily FuckUp

市场销售人员和开发人员应该在整个项目过程中每天都在一起工作

首先，严格的区分市场销售人员和开发人员本身就是个糟糕的主意。

其次，「每天都在一起」也是奇怪的号召，而在 Scrum 流程中，这种奇怪的号召被具体化，成了每日站会。我经常在参与站会的时候听到小兄弟们说的其实是「我昨天说我要三天做完的事情，真的还要两天」。作为职业玩家，职业程度很多时候就体现在不需要每天都告诉其他人自己要怎么做。可以想象一下 830 每天开个站会，然后梅西说，我今天可能需要在训练里面给伊涅斯塔传 5 个过顶球，你做好胸部停球转身抽射的准备……

敏捷文化

我本身是挺讨厌「方法论」者和他们发明的术语的。当然，可能也不是我一个人讨厌。参与了 Agile Manifesto 制定的 Dave Thomas 在Agile Is Dead里面说过：

I haven’t participated in any Agile events, I haven’t affiliated with the Agile Alliance, and I haven’t done any 「agile」 consultancy. I didn’t attend the 10th anniversary celebrations.

Why? Because I didn’t think that any of these things were in the spirit of the manifesto we produced...

The word 「agile」 has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.

在我看来，就好比真正明白某个知识的人总是能用大白话把你讲明白一样，在敏捷开发流程里面被某些公司鼓吹的那些活动和术语在我看来都是些没有价值的东西（ThoughtWorks，说你呢！）。

比如 Scrum，我从来不说我们用 Scrum，而说我们搞迭代（如果和老外我也说 iteration 而不是 Scrum）。 比如 Sprint，我从来不喜欢说我们这个 Sprint，而是说我们这个迭代。 迭代本身是个有语义的好词语，为什么不用它呢。

就像 Gregg Caines 在这篇文章里面说的一样：

when you want to get people to change the way they work, and you want them to understand the completely foreign concepts you’re bringing to them, it’s absolutely crucial that you name the thing in a way that also explains what it is not.

然后他还说：

In Scrum, it’s also common to have a 「sprint commitment」 where the team 「commits」 to a body of work to accomplish in that time frame. The commitment is meant to be a rough estimate for the sake of planning purposes, and if a team doesn’t get that work done in that time, it tries to learn from the estimate and be more realistic in the next sprint. Developers are not supposed to be chastized [sic] for not meeting the sprint commitment — it’s just an extra piece of information to improve upon and to use for future planning. Obviously naming is hugely important here too, because in every other use of the word, a 「commitment」 is a pledge or a binding agreement, and this misnomer really influences the way people (mis)understand the concept of sprints. Let’s face it: if people see sprints as just more frequent deadlines (including those implementing them), the fault can’t be entirely theirs.

的确，问工程师要个 estimation 然后把它当成 commitment，这不是耍流氓么。不仅仅是 Scrum，大多数的组织里面推行一年半载的敏捷流程，大多数人还是对它究竟每个阶段在干什么迷迷糊糊。即便是靠培训敏捷流程混饭的公司也承认要把他们鼓吹的流程落地是非常难的：

In our experience, it takes a team two to six months to become fluent at the one-star level. About 45% of the teams we talk to say they’re fluent at this level.

Reaching the two-star level takes another three to 24 months, depending on the amount of technical debt in the code. About 35% of teams report fluency at this level.

Three-star teams are much more rare. About 5% of teams report fluency at this level. We’ve heard reports ranging from a year to five years to reach this level of fluency.

我们的选择

敏捷开发的很多思想是有益的，但我们没有用 Scrum 和它那堆奇怪的活动（standup、sprint planning 等等）。我们鼓励少开会，多通过异步的方式沟通而不是经常让大家停下手里的工作来进行讨论。我们也从来不对 estimation 之类的东西认真，更不去做什么 burndown 或者计算点数，因为 Agile Manifesto 里面说过：

可以工作的软件是进度的主要度量标准

自动化测试、持续集成、自动部署、有效的监控和运维，让你的软件随时可以发布，才是产品可以不断演进的根基。

I wrote this in English because it is a habbit I have: when I’m frustrated, I wrote in English.

It feels safer and warmer because it seems no one will take time to read it carefully when the language is switched.

Today one of our freind told me she decides to resign to brew her drawing skill dedicatedly. She is working with us since Myriad, then Palm4fun, then Testbird. And she is not just a colleague for us, but a talent, honest freind. So I feel kinda upset.

But I know it will happen sooner or later since we join Testbird.

It doesn’t have to be her, but it will happen.

It doesn’t have to be Testbird, but it will happen.

I know it because everytime when you join a new team you will have the disappointment and confidence problem.

On the very first day of the new job. When you walk in the building knowing practically no one. Everyone is pleasant and nice… almost too nice. Everyone (including you) is not quite themselves because everyone understands the power of the first impression. They’re watching every single move and attempting to interpret how these moves might be perceived. It’s exhausting and it doesn’t reflect the natural steady state of the team.

You listen. You talk to every single person who is willing and you slowly form the impression of the tangible and intangible aspects of this group of people. A picture slowly forms in your mind of how it fits together and, as an aside, it’s almost always wrong because your brain hates discord. As quickly as possible, your brain wants a framework that efficiently predicts what is going to happen next. Your initial framework is a calming hodgepodge of past experience combined with your three most recent epiphanies, and you call this weak sauce, 「The way they work.」

And this poor assessment goes both ways. It’s the beginning of the disappointment. You discover your model for them is incorrect. They discover that you are not who they expected. It’s the end of the honeymoon and the fact the end has begun is progress, but it mostly feels like disappointment. You’re in an unfortunate hole. It’s buyer’s remorse. It’s understanding the world is never, ever that simple.

You sense their disappointment, so you listen harder. You push yourself to talk with a wider variety of unfamiliar humans, because you continue to erroneously believe that one of them could tell you that elusive one rule that would explain this particular clan’s culture in a immediately useful and revealing way. You read every decrepit wiki page. You attend every meeting. You’re attempting to rebuild yourself in a new culture and it’s exhausting because you took all of this for granted in your prior gig. You had built blazing fast intuition, but it took months…perhaps years.

Or maybe never.

How can you start climbing out of the disappointment? The only way I know is through small, unexpected wins.

Find something small enough that you can fix it without breaking other things.

No one expected you to fix that; no one even knew it was broken; and no one thought it was that important. When you fixed it, no one really noticed. When the consequences of the fix became obvious, they thought, 「She/He can do that? Hmmm….interesting.」

Your fix is your first legitimate reputation defining moment, because while people were told who you were, they didn’t believe it because people don’t believe what they have not seen.

Disappointment vanishes slowly and quietly each of these small wins. The wins don’t feel substantive or impactful, but they continue to incrementally define who you are to the rest of the team. They start to build a realistic model of you in their minds. You’re not who they expected, it’s not what you expected, but after three months you start to think of this strange place as home.

I wish all the best for her and hope she take the time to relax and learn, and come back not just with her enhanced UX expertise, but also with the knowledge that everybody boarding on a new ship will have the same disappointment problem and you can always conquer it with small wins.

Good Luck!