观点
PDF站立和交付：为何我讨厌站立会议
Phillip A. Laplante，宾夕法尼亚州立大学
站立会议是“全团队”的重要组成部分，“全团队”是极限编程（XP）的基本实践之一。
根据极限编程网站，站立会议是极限编程规则和实践的一部分：“整个团队之间的沟通是站立会议的目的。它们应该每天早上举行，以便沟通问题、解决方案并促进团队专注。其理念是每个人站成一个圈，以避免长时间的讨论。比起与少数开发人员进行多次会议，一次每个人都必须参加的简短会议效率更高。” [1]
站立会议与XP的理念相一致，即软件开发应该是有趣的，任何干扰——例如会议过多或过长——都会消耗团队的能量。站立会议旨在保持沟通，而无需通常繁琐的会议，并最终节省时间。根据XP网站，“每日站立会议不是另一个浪费人们时间的会议。它将取代许多其他会议，净节省的时间是其自身时长的数倍。” [2]
显然，站立会议受到了一些人的欢迎。例如，以下是Jonathan Rasmusson的说法
仅仅是将每个人放在一个房间里，快速地在高层次上分享知识，就能有效地实现团队成员和利益相关者之间的大规模沟通。团队成员将站立会议在他们认为对项目成功至关重要的因素中排名非常高。它们变成了每个人都想参加以获取最新信息的“市政厅会议”。……从开发人员到项目经理，每个人都随时了解项目的状态。[3]
极限编程的主要倡导者Laurie Williams也同意。“通过每日站立会议，团队成员了解其他人在做什么以及正在努力解决什么问题，以及他们如何互相帮助，从而使整个团队取得成功。” [4]
虽然我可能会首先通过质疑XP网站上关于“净[时间]节省是其自身时长数倍”的说法来开始我对站立会议的批评，但我更关心的是组织层面的影响。尽管有热情洋溢的赞誉，但我并不确定站立会议适合所有人。我认为它们只在最佳情况下才能奏效，或许只在抽象意义上奏效，因为有太多因素不利于它们的成功。
为何站立？
我认为站着开会有些不对劲。站立本身就是一种负担。它在学校和军队中被用作惩罚：“站在角落里”，“立正”等等。站立隐含着专制主义和X理论控制的因素（X理论认为人们只会对威胁做出反应）。
我忍受了三年的定期站立会议。让会议最痛苦的是我的老板（我称他为沃利）。他举行站立会议的主要原因不是为了提高效率或拥抱XP，而是为了缩短与工作产品没有直接关系的人际互动。这位老板也从不带我出去吃午饭，因为他认为那是浪费时间。然而，我认为午餐会议可能具有Rasmusson报告的站立会议的相同好处。然而，对于沃利来说，站立会议（就像早上7点的周一会议和下午5点的周五会议一样）是一种忠诚度测试，旨在加强雇主与雇员的关系。
请看以下摘自twelve|71网站的片段，该网站提倡XP的站立会议
每天早上，整个团队都会参加“站立”会议。站立的原因是，如果没人太舒服，会议必然会很简短。这个会议至少每天将整个团队聚集在一起一次，并允许问题被提出，进度变得可见。
会议不是为了解决问题或长时间讨论，而是为了讨论和提出问题。
令人惊讶的是，每天只需站立在一起10分钟，就可以省去白天许多毫无意义的会议。[5]
这听起来不像我描述的沃利吗？这种对站立会议的描述是否与Rasmusson和Williams的描述有些不一致？关键是，在专制管理者的手中，或在等级森严、命令和控制的环境中，站立会议可能成为一种武器。
为何要短会？
将团队互动限制在10到15分钟的片段是人为的，并暗示着脱节和冷漠。为什么不进行五分钟的会议？六十分钟？多久都可以——甚至在某一天完全不举行会议？15分钟的会议传达了一个明确的信息：“让我们保持简短扼要。”但还有另一个更微妙的信息：“我们不能浪费时间社交；只需 menyampaikan 事实。”
我的另一位老板（我们称他为鲍比）过去常对他的管理团队说，“我们需要更多的沟通。”然后他举行了更多的会议。这些会议没有任何良好沟通的要素；它们只是冗长的训斥。
这是否意味着长会本身就不好？我认为不是；较长的会议提供了传达温暖、关怀和“全团队”意识的机会。套用爱因斯坦的话，会议应该尽可能短，但不能更短。
性格缺陷
考虑一下在站立形式中性格问题会被放大。例如，在专制领导者面前举行的站立会议会让人联想到电影《叛舰喋血记》中布莱船长对“克里斯蒂安先生”的怒吼，或者《军官与绅士》中枪炮士官路易斯·戈赛特对着新兵大喊大叫，甚至爱德华·詹姆斯·奥尔莫斯敦促他的学生们《为人师表》。你当然不会想和沃利或鲍比一起开站立会议。令人难以忍受的经理到处都是，但想象一下，像小学生一样立正站好，会增加多少压力。
即使经理是好经理，团队成员之间也可能存在不良的人际关系动态。不和谐在任何类型的会议中都很常见，但在每天早上站立的情况下忍受性格难相处的人，这尤其痛苦。
即使像我这样在任何类型的会议中都会变得不耐烦和坐立不安的人也会发现，站立会议比坐着开会更不舒服，更容易让人分心。站立似乎只是让会议中已经存在的所有问题变得更糟。
敏感问题
站立会议可能不适合出于身体原因的人。例如，那些无法站立或有言语、听力或语言障碍的人肯定会觉得这些会议令人痛苦——如果不是屈辱的话——那么这种做法难道不是歧视性的吗？
那些害羞且难以发言或在公共场合露面的人肯定非常害怕这些会面。对于那些性格不适合高度互动会议的人来说，每天被迫忍受一次这样的会议肯定非常困难。
实际问题
现在让我们谈谈关于站立会议机制的一些实际问题。谁是这次会议的领导者？你可能会说没有人是领导者。即便如此，也必须有一些协议。与会者应该按顺序站立并发表他们的演讲吗？随机？最胆大的先来？
这些会议中是否有任何责任制？例如，谁在何时说了什么？分歧如何解决？
如果有人缺席怎么办？由于没有会议记录，如果有人长时间外出，如何跟上进度？如果成员错过太多会议会受到处罚吗？
这一切似乎都像一场自由放任。
站立会议的替代方案
我并不是提倡回到议程冗长、结构化、有行动项目和会议纪要的会议。虽然你可以争辩说这些类型的会议有一些好处，但不可否认的事实是，长会可能很枯燥、乏味、令人恼火，而且通常只是浪费时间。
但是，难道没有其他机制可以实现频繁、简短、非正式的愉快和非结构化信息交流，并且仍然符合敏捷方法论的原则吗？为什么会议必须站着举行？将会议结构化得与站立会议完全相同，但坐着呢？如果舒适地坐着意味着会议时间会更长，则可以使用鸡蛋定时器来确保任何会议不超过15分钟。
将早餐或午餐的非正式性与坐着开会相结合怎么样？这是一种有效利用时间的方式，比立正站好更放松。作为一名经理，我经常在非正式场所（例如休息室、休息室或自助餐厅（非工作时间，当它安静时））举行定期的“员工”会议。
我还会每天拜访我的员工进行15分钟的坐下会议。我去他们的办公室是为了让他们放松——以及了解他们在做什么。这与走动式管理（四处走动）相一致。它还帮助我理解他们的观点。我们会从寒暄开始，然后谈论我或他们关心的事情。虽然这不是多播沟通，但它提供了一些优势——特别是，我可以控制不良的人际关系动态。
偶尔，我会和我的直接下属举行步行会议。这些会议是在办公区外进行的10到15分钟的散步。这结合了站立会议的一些好处，并为所有人带来了锻炼的额外好处。
一个矛盾之处
对于一种强调人胜于过程的方法论来说，站立会议似乎是矛盾的：不要结构化会议，因为非正式沟通是最好的；举行高度结构化的会议，以阻止非正式沟通。
我已经描述了对站立会议的几个反对意见，虽然我的一些替代方案也可能被驳斥，但我希望那些拥抱XP——或考虑拥抱它——的人会明白，站立会议不一定像它看起来那样。我怀疑许多团队成员认为这种方法中最繁琐的方面。或许应该将替代方案作为XP文化的一部分来接受。毕竟，敏捷方法论的原则之一是“拥抱变化”。
参考文献
1. 极限编程：参见 http://www.extremeprogramming.org/rules/standupmeeting.html。
2. 极限编程：参见 http://www.extremeprogramming.org/rules/standupmeeting.html。
3. Rasmusson, Jonathan. Introducing XP into Greenfield projects: Lessons learned, IEEE Software (May-June 2003), 21–28.
4. Williams, Laurie. “The XP programmer: The four-minute programmer,” IEEE Software (May-June 2003), 16-20.
5. Twelve|71: 参见 http://www.twelve71.com/xp/standup.jsp。
PHILLIP LAPLANTE，博士，是宾夕法尼亚州立大学大谷研究生院的软件工程副教授。他的研究兴趣包括实时和嵌入式系统、图像处理和软件需求工程。他撰写了大量论文、17本书，并共同创办了期刊《实时成像》。他编辑了CRC出版社的图像处理系列，并担任四种期刊的编委会成员。Laplante在史蒂文斯理工学院获得计算机科学学士学位、电气工程硕士学位和计算机科学博士学位，并在科罗拉多大学获得工商管理硕士学位。他是IEEE高级会员、和国际光学工程学会（SPIE）会员，以及宾夕法尼亚州注册专业工程师。
最初发表于 Queue vol. 1, no. 7—
在数字图书馆中评论本文
更多相关文章
Catherine Hayes, David Malone - 质疑评估非密码哈希函数的标准
虽然密码哈希函数和非密码哈希函数无处不在，但在它们的设计方式上似乎存在差距。出于各种安全要求，存在许多针对密码哈希函数的标准，但在非密码方面，存在一定程度的民俗，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布很有意义，但当面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 行动
随着领导者在财政紧缩和人工智能等变革性技术的背景下寻求优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。技术领导者凭直觉接受良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改善DevEx的拟议倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过介绍使用基于代码、低代码和极低代码技术进行的实验室实验结果来研究生产力差异，从而为该主题提供新的见解。低代码技术显然显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来服务于商业和社会，但它也很健忘。在其快速前进的步伐中，它容易受到时尚的摆布，并且可能会忘记或忽略针对其面临的一些永恒问题的成熟解决方案。用例最初于1986年引入，后来普及，是这些成熟的解决方案之一。
© 保留所有权利。