（一）

敏捷開發(fā)，恰如其名，恰當?shù)拿艚菽芗ぐl(fā)團隊摧枯拉朽的戰(zhàn)斗力，以迅雷不及掩耳之勢如破竹的解決掉一個個的軟件項目。而Scrum作為一種兼顧計劃性與靈活性的敏捷開發(fā)過程，簡直是忽如一夜春風來，使得管理者無人不知無人不曉，奉為無字天書，三叩六拜，恨不得立馬進行實踐。

當然，敏捷的優(yōu)勢不在本文的探討范圍之內，本文就筆者經歷的兩家軟件公司，聊聊過度敏捷、形式敏捷——一場官僚者們的游戲。

（二）

東門慶是一位項目經理，他對Leader畢恭畢敬，堅持貫徹Scrum敏捷開發(fā)的流程。潘小煉是團隊中是核心程序員，編碼能力強，執(zhí)行力強且性格較溫順，吳達朗是潘小煉的好基友，一名只在乎把任務完成的程序員。

東門慶在每天的站會上都要宣導一下這次迭代的目標，這次版本要在領導面前做演示，非常重要，口若懸河滔滔不絕，一番說教下來，程序員們或是呆若木雞，或是埋頭開小差，終于，站會開完，潘小煉看了下手表：臥槽，才用了半個小時，今天效率奇高。

公司采用浮動的上班時間，為照顧大家作息，因此站會定在10點半，潘小煉喜歡早點來上班，通常9點就到公司了，離站會還有一個半小時，想起昨天有個業(yè)務上的問題需要問下離自己3米遠的同事吳達朗，但又轉念一想，等會就開站會了，到時候再問唄。于是約著他一起去蹲馬桶，半個小時后，兩個人一起走出了洗手間。剩下一個小時，潘小煉打開京東，36kr，知乎，Github，開始了一天中最愜意的時光。

10點的時候，東門慶突然接到通知，要參加一個短會議，于是通知整個團隊，將站會推遲到11點。這種事情已經見慣不驚了，站會的時間其實取決于項目經理東門慶是否方便，于是，一早上的工作時間嚴重的碎片化了。開完會來，東門慶面色凝重，將服務端、客戶端、QA等跟項目相關的人員全部召集開站會，于是，浩浩蕩蕩的15,16人的站會……之后便是午飯時間。

（三）

東門慶身負與多個職能部門協(xié)調的重責，伺候領導和溝通的工作占據(jù)了大部分時間，自然而然花在業(yè)務細節(jié)上和技術實現(xiàn)上的時間就少了，因此迭代計劃會成為了他了解業(yè)務細節(jié)和技術實現(xiàn)的最佳機會。潘小煉作為得力干將，一早就根據(jù)需求將產品清單羅列出來，于是，團隊成員不(wu)厭(li)其(tu)煩(cao)的一遍遍重復的解釋用戶故事和若干技術細節(jié)，東門慶聽明白之后，在他的電腦上，復制粘貼著用戶故事到思維導圖，于是，團隊成員們對著投影出來的墻面，N個人等待著1個人，鴉雀無聲，哈欠連天——迭代計劃會向來冗長而又枯燥。

什么？團隊估算？撲克牌估算？別開玩笑了，我不敢相信任何團隊能一直堅持用這種方式來對任務所需要的時間進行評估，這是敏捷里無聊、耗時而矛盾的一個環(huán)節(jié)。項目總的時間周期是固定的，所有的任務都必須壓榨在一定的時間內完成，哪個項目能根據(jù)程序員的真實時間估算而不斷的迭代下去？而且！大家在這個行業(yè)浸淫這么多年，需要用撲克牌來達成共識？而且！！既然稱之為估算，就是不一定準確的，為何還要達成一共識？而且！！！達成共識了有個屁用，明天要演示，今天就要做完！

幸好，東門慶還沒搞清楚撲克牌估算的含義，也搞不明白為什么5后面是8，再后面是13，當然，公司也沒配備Scrum撲克牌，總不能用斗地主的撲克牌來代替吧。萬幸，沒有這個環(huán)節(jié)。所有的時間節(jié)點由潘小煉擬定，然后東門慶敲定。

迭代計劃向來漫長，基本上每個人只能在開始一個小時左右的時間集中精力，之后便是思考著如何配合整個會議盡快結束，然后艱難的從會議狀態(tài)轉換為編碼狀態(tài)。

（四）

在互聯(lián)網時期，大部分項目都沒有甲方和乙方的關系，因此沒有了直接客戶這種概念，那么評審會演示給誰看？沒關系，沒有用戶可以制造用戶，于是，老板，領導、部門經理等成為了演示對象。

東門慶為了快速出成果，及時的給領導演示和評審，讓領導得知自己每周的工作成果，于是將每個版本的迭代周期縮短成為了一周，很棒的決策，在互聯(lián)網時期，任何公司的文化里都喜歡加上“快速”、“唯快不破”、“開始了嗎已經結束了”之類的價值觀。

一周時間里，站會和站會引起的時間碎片+冗長的迭代會議+為了演示而花費的配置環(huán)境的時間+演示的時間+制作文檔+程序員偶爾不舒適的大姨夫時間+……，試問，留給程序員的開發(fā)時間有多少？答案是加班。夜里此刻，大洋彼岸的科比正在duang~duang~，而東門慶正在ken~ken的拍照，作為一個項目經理，自然不會錯過這樣的機會發(fā)微信、微博：“深夜，我們可愛的工程師們仍然奮斗在一線，為我們團隊而驕傲，加油，棒棒噠~”，點擊發(fā)送，這個晚上，微信通訊錄里的領導們睡得十分踏實。

評審會成果斐然，因為一場評審會下來，下個迭代的任務清單里，會增加上領導們屁股決定腦袋的十幾條建議，而東門慶全盤接受。

（五）

潘小煉的大局觀較強，因此很快的總結了這一周迭代中做得不到位的地方，也算是一針見血。吳達朗并沒有這么好的表達能力，憋出了內傷也無法憋出關于本周工作中的優(yōu)缺點，只好提出了一個觀點——這一周內蹲馬桶的時間太久，影響了開發(fā)效率。東門慶覺得這個觀點提得很到位，對此還展開了半個小時的分析和糾正方案，對上廁所的時間、姿勢、廁紙的長度和厚度都詳細的進行了探討并記錄。

是的，這個會議叫反思會，一種無病呻吟的會議。

下個迭代到來時，反思會上的內容會習慣性的遺忘，吳達朗依舊保持著自己上廁所的習慣，長進的是他會在這個時間點思考下個迭代的反思會要講些什么，從而避免沒話可講的尷尬。

（六）

公司給大多數(shù)scrum團隊都配備了白板，白板上寫著待開發(fā)，開發(fā)中，開發(fā)完成，QA測試，測試完成，發(fā)布等幾個狀態(tài)，字跡可謂歪瓜裂棗，并貼滿了五顏六色的寫滿了任務的卡片，感謝scrum給我們提供了練字的機會。站會中，吳達朗總會與QA妹紙就這個任務是否能從開發(fā)完成切換到測試完成的狀態(tài)而爭執(zhí)半天，而立場不堅定的QA通常會睜一只眼閉一只眼，但是，大多數(shù)QA原則分明立場堅定，于是站會過后，往往還有長時間的私人PK。

這一切似乎都是合情合理，站會給了團隊每個人充分溝通的機會，也給了每個人足夠的約束保證每天都有產出，同時白板上的任務卡片的狀態(tài)趨勢也體現(xiàn)著每天的項目進度狀況。

工具部門在決策者的授意下，開發(fā)了個Scrum的信息化系統(tǒng)，UI，交互都做得很棒，可以在WEB上寫story，可以拖拽任務的狀態(tài)，并且很貼心的定義了格式：“作為一個【**用戶】，我希望可以【**】，這樣才能【**】，使用者只需要在【】中進行遣詞造句就可以完成story，是不是很貼心，很萌萌噠！！

可是，可是，各位大哥大姐，大爺大媽，我們希望通過短暫的站會大家互相溝通情況，互相了解彼此的進度和進行中的業(yè)務，我們已經有白板了，我們已經寫在紙上了，為什么還要錄入一遍到系統(tǒng)里。錄入到系統(tǒng)里，誰會去看，誰TMD天天登陸WEB系統(tǒng)里，去查看彼此的任務和進度？又或者，錄入系統(tǒng)里，要采集數(shù)據(jù)，要做大數(shù)據(jù)分析，要證明你這個團隊作戰(zhàn)能力？

呵呵。。

（七）

聊了那么多，還沒切題。為什么說Scrum是官僚者們的游戲？

腹黑而論，Scrum提供了一種思維方式，讓項目經理更好約束開發(fā)者以及更好伺候上層的思維方式。

第一、站會無形中給開發(fā)者增加了約束和壓力，每個人都需要每天有所產出，能在站會上有所描述，當然這一點有利有弊。從成果的角度來看，一個三天的任務，第三天能夠完成就OK了，過程自己安排，但是這樣風險顯然更大點。所以，站會是管理者對開發(fā)者進行監(jiān)控的十分有效的工具。

第二、評審會的周期往往兩周一次，更有甚者一周一次，甚至一天一次內部評審。評審會提供了一個很好的機會，讓項目經理展示工作成果的機會，所謂臺上一分鐘臺下十年功，短周期而頻繁的演示，會讓開發(fā)人員花費大量的時間在重復的環(huán)境配置和調試演示腳本的工作中。而這部分工作往往以前一個月只需要做一次或者里程碑事件里才做。

第三、Scrum之下，成果必然不會差，大部分迭代都能如期進行，這是項目經理加官進爵的有效籌碼。而在這背后，是開發(fā)團隊夜以繼日的工作，長時間的加班付出。

第四、長時間的高壓之下，必然心生抱怨。但是Scrum提供了這樣一套方法論，而且成果卓越，一切似乎理所當然，有理有據(jù)之下，似乎抱怨顯得無理取鬧。

（八）

開發(fā)者們經歷了很多項目，無論敏捷與否，往往都能順利的完成項目開發(fā)。在這眾多項目中，我們經歷過很多軟件開發(fā)模式，每種模式都有其華麗的學術名稱，瀑布、原型、迭代、螺旋、敏捷，還有放羊式的。而其實這些模式最大的區(qū)別，不在于成果，而在于達成目標的過程的難易程度。

打個比方，每個人從家里到公司上班，可以選擇多種方式，比如開車，電動車或自行車。無論哪種方式，我們最終都會在規(guī)定的上班時間抵達公司。區(qū)別在于，開車可能最快，但是要忍受高峰期堵車。電動車靈巧方便，但是要注意安全。自行車最慢，但是強身健體。而使用哪種方式上班，取決于當天的路況和我的心情。

所以，請去掉敏捷華麗的外衣：

1. 站會一定要簡短，時間一定要固定。
2. 迭代計劃會之前，核心人員參與分析和計劃，做好充足的準備，會上，其他人傾聽和提問即可。
3. 去掉任何的信息化系統(tǒng)，使用白板。
4. 請延長評審周期，不要太過頻繁，實在苦不堪言。
5. 若做不到團隊扁平化，有官僚傾向，那就別敏捷了，換其他一種方式。
6. 敏捷中會議的種類很多，開會不是程序員該干的事情。適當刪減，以及無需每次都全員參與，把時間還給程序員。
7. 不要為了敏捷而敏捷，這只是個方法論，不是放之四海而皆準。

原文轉載自：