Stand-Up 2.0: 是时候抛弃从1993年就创建的每日站立会议了
每日站立会议是失败的
毫无疑问，这是30年前就创立的东西，但是我们现在还每一天都使用同样的方式来运行。
当每日站立会议在90年代早期创立的时候，软件开发流程和现在比起来有很大的不同。那时候没有git，没有Jira，没有任何合作的工具。没有DevOps。自动化工具也不存在，分析的工具也不存在。
别误会我，其实我还是很爱90年代初期的。
开发者的典型技术栈已经有了很大的变化。
我们使用git来管理代码，我们的同事可以通过GitHub，Gitlab或者Bitbucket来进行交流。
我们有无数的DevOps工具可以使我们的工作自动化。
我们通过Slack和Teams和同事交流。
我们有分析仪表盘来衡量所有的东西。
这些技术已经改变了我们工作的方式。哪怕相比5年之前，软件开发现在也更加连接，合作，自动化，以及数据驱动了。
因此，为什么我们每天最重要的活动去按照一个已经30年之前的架构来运行呢，他已经过时了，他没有集成Jira的数据，没有自动化，没有使用这些工具。
个人的问题
个人来说，对于每日站立会议的几乎所有角色，我都感觉不太舒服 — 作为一个开发者，作为一个团队的leader，作为一个scrum的管理者，作为一个工程师VP或者作为一个产品的leader。
下面这些是我经历的，看到的或者听说的问题：
开发者是怎样认为每日站立会议的
咖啡第一，然后才是别的事情
大多数我知道的开发者只想把他们的状态更新到Slack，然后回去继续工作。假如没有什么block他们的工作，为什么要去参加站立会议。
这就是问题所在，大多数开发者都不认为站立会议是为他们设计的。这个是我们团队的leader或者scrum master或者产品的leader来设计的会议。反正肯定不是为了我设计的。当团队中大多数人都觉得这个会议没有价值，宁可取消掉，那么这个会议就会有问题了。
还有另外一个问题，就是很多开发者不喜欢在他的同事面前寻求帮助，对很多人来说，说要帮助是一件很难得事情。所以在他们和这个会议最有价值的部分之间，其实是有壁垒的。
还有一件事，我就直说吧。我出现在这个会议上，我听每一个人分享他们的update，尽管我可以在Slack上看到这些update，然后我分享我的update，我们花费了很长时间。然后还是会在之后的白天ping超过10次来询问相关事情的进展。那么这个会议的有什么意义。
开发团队的leader和scrum master是如何看待每日会议的
当我是一个团队的leader的时候，我发现每日会议特别有用。它是我来保证分析迭代风险以及保证我们在轨道上的重要工具。但是我也有我的问题。
对那些新手，我需要得到所有的更新才能得到我关心的内容：障碍和风险。我们可能花费了80%的时间在分享状态的更新。只有很少的时间在有价值可以操作的讨论上。尽管我们的目标是把解决问题放到会后，但是我很难有足够的时间收集足够的信息以便于我会后去处理。
我们花费了很多时间讨论Jira是否更新了，而大多数情况他都没有更新。
每个人都在用一个固定方式分享他们的状态，这让我很难受。他们有些只说了10个单词，花费了20秒。有些人则分享了过去24小时整个长长的历史。
最糟糕的地方在于很多时候，我不能得到整个事实。对一些开发来说，让他们说出问题，有时就像拔牙一样。
尽管我们有一个时间限制（每人2分钟），我们几乎还是每一天都超时了。大多数时候，我都能够感觉到每个人只想回去继续工作。
CTO,VP和工程Directors是如何看待每日会议的
当我是一个工程VP，我喜欢偶尔去参加一个团队的站立会议，或者去看一个我关心的商业功能的开发状况。
我知道他们在我在的时候会表现得不一样，甚至会说得更少，但我还是会出现，因为对我来说，我没有别的什么更好的机会可以看到团队所有的人。
但是，很不幸，当我回头看看的时候，我很确定我的出现使得这个会议偏离了轨道。为什么？因为我出现在那里的理由和这个会议的宗旨是不符合的。我想要的是和团队的成员见见面或者某一个状态的更新。而我根本不关心他们的特定迭代是怎样的。
产品所有者是怎样看待每日会议的
我和很多产品所有者都工作过–他们有些一般，有些很好。帮忙管理产品是我现在工作的一部分，所以我总结了我观察到了这些很好的产品所有者的行为，并尝试去复制他们。
一般的产品所有者偶尔会出现在站立会议上，尤其当他们需要更新的时候，而且他们会用他们的问题来主导整个讨论。
很好的产品所有者会在每个早上的站立会议出现，因为他们不想错过任何可以解放团队成员的机会。他们大多数时候只会倾听，只有在他们最关心的问题上才会插上两句。他们只有解释用户使用的时候，才会说很多，这样开发团队可以更了解他们工作和真正使用的场景之间的联系。
当这个会议全部都是状态的更新的时候，一个好的产品所有者是没有机会表达他们的价值的。
他们想要摆脱什么呢？我们期限 — 我们能够按期完成吗？这是我关于每日会议最大的抱怨了，我很难确定我们是不是真的所有都在正轨上。
每日站立会议2.0
我们不得不解决这个问题。每日的站立会议是一个不可多得机会来使得团队一天都工作得很开心。但是我们浪费了这个机会。
那么2020年的每日站立会议应该是怎样的呢？
你看过电影《少数派报告》（“Minority Report”）吗？我就是按照这个来想的。但是我们这里不是Tom Cruise而是软件开发者。我们不是思考犯罪，而是思考我们什么时候会错过交付日期或者我们会有质量的问题。
防止你没有看过这个电影，这个电影中的Tom Cruise是一个来自未来的警察，他使用一个三维的图表来预测和阻止犯罪。
每天早上，他来到办公室的时候，他们的图表已经帮他创建好了他上一天的工作，过滤了最重要的事实，并且通过可视化的方式把这些表示出来了，这样他的团队就知道哪些方面是需要注意的。然后他们讨论他们的计划，这就使得他们的时间都节约下来了。他们的会议特别快，有效，这也帮助他们很快就抓住了坏人。
这个电影是2003年，那时我还在Villanova攻读我的计算机科学学位。我很喜欢他，也想象当我毕业的时候可以有一个工作可以像他那样在空中移动虚拟的屏幕。
为什么是现在？
我花费了很多时间在我的楼梯下面的一个没有镜子的衣帽间 — 这是我在家工作的办公室。有时候事情有点奇怪。很显然，我正在把站立会议和一个斯皮尔伯格的科幻电影相比较。
我有很多时间来思考。我不停意识到的一件事就是时间真的太宝贵了。我喜欢创建那些人们喜欢的使用的产品。我喜欢和别的工程师一起闲逛。我也喜欢花费时间和我的家庭已经刚出身的女儿一起。而这些没有一件事是我每天花费45分钟，一周五次，去参加一个大多数人都不愿意参加，而且没有什么产出的会议。
声明
我其实也没有解决这个问题的所有办法。但是我已经思考这个问题很久了，这里把我的想法说出来也算抛砖引玉了。更重要的是，我自己正在切身体验着这些，事实上整个LinearB的开发团队都在进行着这个尝试。详细的内容见下面：
假设
所有的开发者一般都不太喜欢开会，但是创建一个所有开发都想参加的会议是不太现实的。
假想：每天的站立会议不仅仅给会议室中的每一个人提供有价值 — 包括开发者 — 他也可以成为一个每个人都想参加的会议。结果就是，合作会增强，每一个人都想为团队的目标做贡献，团队也能够更加及时的发布高质量的迭代。
我想要想实现这个假想，有下面这些想法可以让它变为现实。
- 更新框架：“我昨天做了什么”以及“我今天要做什么”是这个问题的核心。这些都是可以通过Slack来更新的状态。我想我们可以在会议上讨论一些更好的问题，特别是在会后可以继续跟踪的问题。
- 新的合约：每一个参加会议的人都应该知道他能提供什么，以及他所期望能得到什么。得到的应该和投入的相等。
- 更新的准则：这个会议应当就总是15分钟吗？假如没有任何重要的事情说，我们是否还有必要让每个人来参加这个会议。我不确定。
- 新的技术：就像我们做别的事情一样，站立会议也应当是数据驱动的，并且应当自动化。为什么不能把所有的更新放到一个仪表上，并显示在屏幕上。所有的数据都在Git或者Jira上，所以，我认为这完全是有可能的。
更新的框架
昨天做了什么？
今天要做什么？
我被什么block了？
有哪些事情影响我做我最高优先级的任务？
我们能够按时完成任务吗？
用问题来指导会议对我来说还是有意义的，但是在这之前：
需要每一个参会者都需要做准备吗？我所读的关于会议的最佳实践告诉我是的。
假如我们每个人在参加会议之前都已经知道了别人昨天做了什么，并且知道今天会做些什么，那么我们可以快速地进入正题。
这是我的第一个建议：
让我们把“昨天”和“今天”这两个表格作为我们参加会议的筹码。
我也意识到，“昨天”和“今天”是我们对团队承诺的一部分也是我们的责任。这非常对也很有用。事实上，这是为什么我说我们需要向Slack或者一个自动的仪表盘来分享这些内容。写下来其实就够了。
现在，让我们回到什么问题是有价值的这个事情上来。什么问题可以给每一个与会者提供最大的价值呢？包括参会的开发者。
我被什么block了？
给与和寻求帮助是非常有用的。每一个我面试的人都说这个部分是很有效的，所以我们保留他。
有哪些事情影响我做我最高优先级的任务？
那我们想有哪些block的时候，我们只关注两个方面：
技术：我在写代码上有问题。我在和一个新的API的连接上有问题，我不能在StackOverflow上找到我要的答案，哈哈。
依赖：我在等一个UI的mock up，我在等某人review我的pull request，我在等某人完成他的服务，然后我能够做我的。
但是这里其实还有一种另外一种blocker，我们在每天的站立会议没有讨论：被拉去做一些并不是我最高优先级的任务。
我最高优先级的任务是什么？有哪些事情让我们不能集中精力来处理这个任务？他可能是一个来自于CEO的我事先没有预料到的bug。也可能是有太多的会议。也许甚至会是在家里工作时间有限。
每天早上来思考这个问题，可以让我们的开发者更加直观地思考并且让他们能够想清楚如何更好的处理最高优先级的任务。这也可以使他们有能力去把一些不必要的事情推回去 — 这也是很多开发者需要提高的地方。
团队的leader和scrum owner也会从中受益，因为他们能够更真实地知道究竟是什么影响了当前的迭代，已经如何更好的让团队成员集中精力处理团队关注的事情。当我是一个团队leader的时候，我觉得最糟糕的事情就是我发现一个团队的成员在处理一个本来我认为不应该是他处理的事情。
除了可以在当前的迭代受益，其实随着时间的推移，整个团队都会得到好处。因为，你会发现有些事情会一直不停地打扰你，然后你就可以发明一个新的策略来解决这个问题了。
这些问题和我之前使用的一个称之为“迭代流失率”的指标非常吻合 — 在我们迭代开始的时候有多少问题来来回回。
迭代流失率和专注被打扰都说的是团队每个人都关注的可预测性。
我们能够按时完成任务吗？
按时交付迭代是团队的终极任务。所以，难道不应该每一个团队成员都参与到这个讨论中来吗？ — 我们能按时交付吗？
大多数开发者关于能否及时交付有个清晰的认识。大多数开发者对他们有太多或者太少工作也有所了解。大多数开发者对他们是否在一个复杂或者有危险的分支上开发很清楚。假如我正在做一些别的开发者依赖的工作，那么我就应该知道我的延迟有可能导致整个项目的延迟，从而影响这个团队。
某些人可能会知道一些可能影响整个团队的信息，比如公司的调整，比如一个大的客户又要求了XYZ功能等等。
另外，我们应该感激地问他们这些问题，所以他们不需要像现在这样：走出会议室，然后握紧拳头说：“我就知道，我们永远不可能结束！”
他们关于迭代能否及时完成的观点对团队的leader和scrum master来说很重要，因为这就是他们想从团队会议中得到的核心信息。假如一个开发者对对时间，WIP平衡，危机没有什么感觉，那么他们会在不断的重复中慢慢学会这些的。这对管理来说也是很好的，因为他让每个人都得到了提升。
产品也会希望这样的讨论，因为他们是精简的专家，并且他们可以搞清楚怎样花费50%的时间得到80%的价值。
下一步
我致力于解决这个问题，我正在努力，也希望得到你的帮助。
下面这些是我将会尝试的：
- 我将会继续写这个，在我的下一篇博客中，我将会分享我关于新的合约和更新准则的内容。
- 我们开发团队正在设计一个体验来验证这些假想。我们正在内部运行这个新的站立会议，所以我们会有结果的，到时再和大家分享。
- 我们正在Minority Report上创建新的关于站立会议的仪表板，我们期待你的反馈。
原文地址：https://dzone.com/articles/stand-up-20-its-time-to-ditch-the-daily-from-1993
Recent Comments