（一）
敏捷开发，恰如其名，恰当的敏捷能激发团队摧枯拉朽的战斗力，以迅雷不及掩耳之势如破竹的解决掉一个个的软件项目。而Scrum作为一种兼顾计划性与灵活性的敏捷开发过程，简直是忽如一夜春风来，使得管理者无人不知无人不晓，奉为无字天书，三叩六拜，恨不得立马进行实践。
当然，敏捷的优势不在本文的探讨范围之内，本文就笔者经历的两家软件公司，聊聊过度敏捷、形式敏捷——一场官僚者们的游戏。
（二）
东门庆是一位项目经理，他对Leader毕恭毕敬，坚持贯彻Scrum敏捷开发的流程。潘小炼是团队中是核心程序员，编码能力强，执行力强且性格较温顺，吴达朗是潘小炼的好基友，一名只在乎把任务完成的程序员。
东门庆在每天的站会上都要宣导一下这次迭代的目标，这次版本要在领导面前做演示，非常重要，口若悬河滔滔不绝，一番说教下来，程序员们或是呆若木鸡，或是埋头开小差，终于，站会开完，潘小炼看了下手表：卧槽，才用了半个小时，今天效率奇高。
公司采用浮动的上班时间，为照顾大家作息，因此站会定在10点半，潘小炼喜欢早点来上班，通常9点就到公司了，离站会还有一个半小时，想起昨天有个业务上的问题需要问下离自己3米远的同事吴达朗，但又转念一想，等会就开站会了，到时候再问呗。于是约着他一起去蹲马桶，半个小时后，两个人一起走出了洗手间。剩下一个小时，潘小炼打开京东，36kr，知乎，Github，开始了一天中最惬意的时光。
10点的时候，东门庆突然接到通知，要参加一个短会议，于是通知整个团队，将站会推迟到11点。这种事情已经见惯不惊了，站会的时间其实取决于项目经理东门庆是否方便，于是，一早上的工作时间严重的碎片化了。开完会来，东门庆面色凝重，将服务端、客户端、QA等跟项目相关的人员全部召集开站会，于是，浩浩荡荡的15,16人的站会……之后便是午饭时间。
（三）
东门庆身负与多个职能部门协调的重责，伺候领导和沟通的工作占据了大部分时间，自然而然花在业务细节上和技术实现上的时间就少了，因此迭代计划会成为了他了解业务细节和技术实现的最佳机会。潘小炼作为得力干将，一早就根据需求将产品清单罗列出来，于是，团队成员不(wu)厌(li)其(tu)烦(cao)的一遍遍重复的解释用户故事和若干技术细节，东门庆听明白之后，在他的电脑上，复制粘贴着用户故事到思维导图，于是，团队成员们对着投影出来的墙面，N个人等待着1个人，鸦雀无声，哈欠连天——迭代计划会向来冗长而又枯燥。
什么？团队估算？扑克牌估算？别开玩笑了，我不敢相信任何团队能一直坚持用这种方式来对任务所需要的时间进行评估，这是敏捷里无聊、耗时而矛盾的一个环节。项目总的时间周期是固定的，所有的任务都必须压榨在一定的时间内完成，哪个项目能根据程序员的真实时间估算而不断的迭代下去？而且！大家在这个行业浸淫这么多年，需要用扑克牌来达成共识？而且！！既然称之为估算，就是不一定准确的，为何还要达成一共识？而且！！！达成共识了有个屁用，明天要演示，今天就要做完！
幸好，东门庆还没搞清楚扑克牌估算的含义，也搞不明白为什么5后面是8，再后面是13，当然，公司也没配备Scrum扑克牌，总不能用斗地主的扑克牌来代替吧。万幸，没有这个环节。所有的时间节点由潘小炼拟定，然后东门庆敲定。
迭代计划向来漫长，基本上每个人只能在开始一个小时左右的时间集中精力，之后便是思考着如何配合整个会议尽快结束，然后艰难的从会议状态转换为编码状态。
（四）
在互联网时期，大部分项目都没有甲方和乙方的关系，因此没有了直接客户这种概念，那么评审会演示给谁看？没关系，没有用户可以制造用户，于是，老板，领导、部门经理等成为了演示对象。
东门庆为了快速出成果，及时的给领导演示和评审，让领导得知自己每周的工作成果，于是将每个版本的迭代周期缩短成为了一周，很棒的决策，在互联网时期，任何公司的文化里都喜欢加上“快速”、“唯快不破”、“开始了吗已经结束了”之类的价值观。
一周时间里，站会和站会引起的时间碎片+冗长的迭代会议+为了演示而花费的配置环境的时间+演示的时间+制作文档+程序员偶尔不舒适的大姨夫时间+……，试问，留给程序员的开发时间有多少？答案是加班。夜里此刻，大洋彼岸的科比正在duang~duang~，而东门庆正在ken~ken的拍照，作为一个项目经理，自然不会错过这样的机会发微信、微博：“深夜，我们可爱的工程师们仍然奋斗在一线，为我们团队而骄傲，加油，棒棒哒~”，点击发送，这个晚上，微信通讯录里的领导们睡得十分踏实。
评审会成果斐然，因为一场评审会下来，下个迭代的任务清单里，会增加上领导们屁股决定脑袋的十几条建议，而东门庆全盘接受。
（五）
潘小炼的大局观较强，因此很快的总结了这一周迭代中做得不到位的地方，也算是一针见血。吴达朗并没有这么好的表达能力，憋出了内伤也无法憋出关于本周工作中的优缺点，只好提出了一个观点——这一周内蹲马桶的时间太久，影响了开发效率。东门庆觉得这个观点提得很到位，对此还展开了半个小时的分析和纠正方案，对上厕所的时间、姿势、厕纸的长度和厚度都详细的进行了探讨并记录。
是的，这个会议叫反思会，一种无病呻吟的会议。
下个迭代到来时，反思会上的内容会习惯性的遗忘，吴达朗依旧保持着自己上厕所的习惯，长进的是他会在这个时间点思考下个迭代的反思会要讲些什么，从而避免没话可讲的尴尬。
（六）
公司给大多数scrum团队都配备了白板，白板上写着待开发，开发中，开发完成，QA测试，测试完成，发布等几个状态，字迹可谓歪瓜裂枣，并贴满了五颜六色的写满了任务的卡片，感谢scrum给我们提供了练字的机会。站会中，吴达朗总会与QA妹纸就这个任务是否能从开发完成切换到测试完成的状态而争执半天，而立场不坚定的QA通常会睁一只眼闭一只眼，但是，大多数QA原则分明立场坚定，于是站会过后，往往还有长时间的私人PK。
这一切似乎都是合情合理，站会给了团队每个人充分沟通的机会，也给了每个人足够的约束保证每天都有产出，同时白板上的任务卡片的状态趋势也体现着每天的项目进度状况。
工具部门在决策者的授意下，开发了个Scrum的信息化系统，UI，交互都做得很棒，可以在WEB上写story，可以拖拽任务的状态，并且很贴心的定义了格式：“作为一个【**用户】，我希望可以【**】，这样才能【**】，使用者只需要在【】中进行遣词造句就可以完成story，是不是很贴心，很萌萌哒！！
可是，可是，各位大哥大姐，大爷大妈，我们希望通过短暂的站会大家互相沟通情况，互相了解彼此的进度和进行中的业务，我们已经有白板了，我们已经写在纸上了，为什么还要录入一遍到系统里。录入到系统里，谁会去看，谁TMD天天登陆WEB系统里，去查看彼此的任务和进度？又或者，录入系统里，要采集数据，要做大数据分析，要证明你这个团队作战能力？
呵呵。
（七）
聊了那么多，还没切题。为什么说Scrum是官僚者们的游戏？
腹黑而论，Scrum提供了一种思维方式，让项目经理更好约束开发者以及更好伺候上层的思维方式。
第一、站会无形中给开发者增加了约束和压力，每个人都需要每天有所产出，能在站会上有所描述，当然这一点有利有弊。从成果的角度来看，一个三天的任务，第三天能够完成就OK了，过程自己安排，但是这样风险显然更大点。所以，站会是管理者对开发者进行监控的十分有效的工具。
第二、评审会的周期往往两周一次，更有甚者一周一次，甚至一天一次内部评审。评审会提供了一个很好的机会，让项目经理展示工作成果的机会，所谓台上一分钟台下十年功，短周期而频繁的演示，会让开发人员花费大量的时间在重复的环境配置和调试演示脚本的工作中。而这部分工作往往以前一个月只需要做一次或者里程碑事件里才做。
第三、Scrum之下，成果必然不会差，大部分迭代都能如期进行，这是项目经理加官进爵的有效筹码。而在这背后，是开发团队夜以继日的工作，长时间的加班付出。
第四、长时间的高压之下，必然心生抱怨。但是Scrum提供了这样一套方法论，而且成果卓越，一切似乎理所当然，有理有据之下，似乎抱怨显得无理取闹。
（八）
开发者们经历了很多项目，无论敏捷与否，往往都能顺利的完成项目开发。在这众多项目中，我们经历过很多软件开发模式，每种模式都有其华丽的学术名称，瀑布、原型、迭代、螺旋、敏捷，还有放羊式的。而其实这些模式最大的区别，不在于成果，而在于达成目标的过程的难易程度。
打个比方，每个人从家里到公司上班，可以选择多种方式，比如开车，电动车或自行车。无论哪种方式，我们最终都会在规定的上班时间抵达公司。区别在于，开车可能最快，但是要忍受高峰期堵车。电动车灵巧方便，但是要注意安全。自行车最慢，但是强身健体。而使用哪种方式上班，取决于当天的路况和我的心情。
所谓的项目管理或者软件开发模式，我认为最大的目的不在于将软件开发完成，而是如何让团队以一种更健康和轻松的方式达成目标。而评价什么方式是健康而轻松的唯一标准，就是加班的次数。
所以，请去掉敏捷华丽的外衣：
1.站会一定要简短，时间一定要固定。
2.迭代计划会之前，核心人员参与分析和计划，做好充足的准备，会上，其他人倾听和提问即可。
3.去掉任何的信息化系统，使用白板。
4.请延长评审周期，不要太过频繁，实在苦不堪言。
5.若做不到团队扁平化，有官僚倾向，那就别敏捷了，换其他一种方式。
6.敏捷中会议的种类很多，开会不是程序员该干的事情。适当删减，以及无需每次都全员参与，把时间还给程序员。
7.不要为了敏捷而敏捷，这只是个方法论，不是放之四海而皆准。
