Daily Scrum（每日站會）有沒有替代方案？
Daily Scrum 是敏捷開發必需的嗎？
每日站會有哪些缺點？有哪些替代實踐？
Daily Scrum 並不是敏捷開發必需的，只是 Scrum 或 XP 必需的（？）。
每日站會（XP 中叫 Daily Standup Meeting）大概是 Agile 1.0 中最具程式化、儀式感的一個著名實踐，Scrum 因此得名。可是這麼做真的有必要嗎？是全天下普適的嗎？還是一種宗教傳承？你們不用每日站會，就會愧疚、難過，對不起 Scrum，對不起 Scrum 大師，對不起你交的學費？
我的觀點是：每日站會對於緊急的項目確是有必要的，例如 60 天（尤其 30 天）以內的項目，每一天都很重要，有必要大家每天了解、跟蹤進度，針對發現的問題、障礙及時採取措施，進行應對和調整，把問題消滅在萌芽狀態，否則可能真的來不及，因為工期實在太短。
至於工期 60 天以上的項目，我看就算了吧。隔一兩天團隊不見面不開會，會有什麼惡劣影響呢？何必教條？
我想問的是：大家覺得每周一共要開幾次團隊會議，無論時間長短，才是合情合理的？有沒有一個上限和下限？（這裡指正式的 team meeting，不是幾個人私下碰頭的小會）
其實替代 Daily Scrum 的 Agile 2.0 實踐肯定有多種，發揮大家的創造力。
下面介紹下 Taij/BP 的周三團隊會議（WTM，Wednesday Team Meeting）和敏捷開發日誌（Agile Devlog）等實踐。
一般團隊都會在周一、周末（如周五）開會。周一團隊剛剛開過會，馬上周二又要全體見面 Daily Scrum，有這個必要嗎？這一天內究竟發生了多麼重大的事，需要大家全體集合，再次緊急溝通呢？我們為什麼不能取消周二、周四的 Daily Scrum，讓大家只在周一、周三和周五全體聚會呢？於是，偉大的 WTM 誕生了。
。。。只要我能說得算的項目, 我一定會取消每日例會.
首先每日例會影響的並不止15分鐘, 成員從剛一上班到開會這段時間不太能正經工作. 公司是彈性工作制的話, 例會時間要開在10點半到11點半, 這時候開完會也快吃中飯了, 導致整個上午工作效率都比較低.
每日例會的目標是讓所有成員都能掌握團隊的進度, 能及時反饋. 可說老實話, 團隊中除了Team leader和PM(PO?), 沒幾個人在乎別人的進度. 大家工作都是為了掙那份工資, 沒誰會多操那份心. "管好自己一畝三分地, 別人死活關我屁事"才是中國人的職場觀念. 還不如想知道進度的人自己去看看板(或者用戶故事之類的東西)呢.
各個程序員的效率差別非常大, 可以差上幾倍甚至幾十倍, 但是工資差距不大. 效率高的發現自己進度比別人快很多, 會自己放鬆. 效率低的每天都要發現一遍自己比別人慢, 壓力山大, 但並沒有什麼卵用(我曾經周末去公司取東西時, 見到過有人因為幾天都沒有能彙報的進度,自己偷偷跑來加班的).如果是嫌站立會議浪費時間的話，下面這個替代方式怎麼樣？可以節約70%的時間。
如果你的團隊成員對standup meeting有抵觸情緒了，你是不是把standup meeting開成下面這種了？
最後，一個合理的standup meeting應該是下面圖片這樣的，每人不超過兩分鐘，只需要回答三個問題：what I did today？ what am I going to do tomorrow？any roadblock？在白板上更新一下task的狀態。整個過程出了講個笑話活躍氣氛，不要展開任何其他話題。
1，敏捷開發依賴於開發團隊的自組織特性，而自組織團隊依賴於對團隊承諾的遵守和維護。心理學上說，公開的承諾，我們會更加努力的去遵守和維護。所以每日站會是一個用來加強團隊承諾的重要事情。
2，敏捷開發強調語言溝通，每日站會是一個信息同步的重要渠道，也是同步團隊成員間進度依賴的重要方式。
以上，不建議取消。
結論：不建議取消，小小例會作用比較大，能起到透明化、驗證、糾正的作用。--------------------------------------------------------------------------------------------------------------------------------------------如果想取消也可以啊，大致滿足以下若干條條件吧組織承諾滿足（人力資源、辦公環境、運維資源、商用軟體等）業務穩定明確（比如類似公式等，之前做過)技術框架穩定，風險已知，無學習成本人員業務能力強，深入了解業務，技術能力強，掌控所需技術框架人員士氣可以
團隊協作磨合好，或有過類似的協作經驗
單元測試、功能測試等自動化測試有每日集成構建發布有類似JIRA等任務分配提交系統，能及時提交發布任務安排無強依賴關聯關係無中等以上（影響、概率）風險事項有周例會等計劃排的比較松，考慮了各種風險、依賴、緩衝項目進度質量目標不重要站會不是一日兩日還是三日之爭。
竊以為，把工作時間和工作量切割到最小的粒度，無疑是減少人類對長期估算誤差的好辦法。另一方面敦促團隊進行交流，頻繁檢查計劃以及實施情況，並且對工作的承諾尊重與信任感的培育，不是理論黨能感受到的。
如果每日站會是愚蠢的，那我覺得兩日站會也聰明不到哪兒去。拉長兩個檢查點的間隔，無疑是放縱中間的混亂狀態。個人認為站會是敏捷最佳的導入實踐，容易實施，更加像鏡子一樣，如果發現實施過程有問題，往往隱含著其它方面的問題。時間超時：往往團隊溝通不足，加大溝通力度。無話可說：工作不飽和或者任務顆粒太大。一對多演講：團隊積極性不足未弄成自組織氛圍。……實施scrum的最大的問題就是刪減流程。scrum其實已經是最簡框架了。再刪就會出問題。站立會議取消了，問題多多。建議嚴格執行，而且一定要控制時間。
不可以。
不但如此，我會要求Team的每一個成員在下班前提交代碼，部署程序，為第二天早上的MiniDemo做準備。
嗯。我們在敏捷開發中加入了MiniDemo的概念，每天的晨會除了三件事，還有第四件事，就是快速看一下完成的結果。
除此之外，我還對每日晨會有了一個新的要求，就是要發晨會郵件。簡要寫明晨會中項目的進度，以及是否延期。此篇文章首發於簡書：Scrum—官僚者們的遊戲。
（一）
敏捷開發，恰如其名，恰當的敏捷能激發團隊摧枯拉朽的戰鬥力，以迅雷不及掩耳之勢如破竹的解決掉一個個的軟體項目。而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.不要為了敏捷而敏捷，這只是個方法論，不是放之四海而皆準。
敏捷是不適合大公司的`其中一個很重要的原因是`這套東西想玩好`玩的順`對所有團隊成員的要求都很高`技術能力和工作態度`而大多數公司招人很難達到這
樣的水平`大公司為了工人基數`更是這樣`所以最終變成能過看板之類的工具為團隊分發任務`監控執行`自組織和自管理很難做到`可能有的領導者也不希望這樣
站會是團隊在一起快速地開一個會(通常在物理牆前)，成員逐個更新自己的狀態。主要包含以下幾個方面：
1.昨天完成的工作；
2.今天計劃做的工作；
3.面臨什麼阻礙，需要什麼幫助；
4. 自己手頭用戶故事的進展，是否存在技術風險。
我們試過通過各種工具或者群聊解決，但是效果都不明顯。
既然是快速的會議，站會的時間就不宜過長，10分鐘左右為佳。不會耽誤你效率反而會大大提升的。
可以替代的，用站會工具啊，geekbot、standup bot等，不過都是基於slack平台
每日早報，實際是在幫manager監督；對員工的實際問題無法提供幫助；對於類似流水線，沒有創新的工作，可以及時統計大家的工作量；但是對於需要搜索研究的問題，沒有實際意義，進展也不是一天一個樣.
組內人數多的話是否可以改成每個組員每天早上通過IM向scrum master回報三大問題，然後SM總結後通過郵件分享給組員？
個人覺得效果非常好，但是不能流於形式
推薦閱讀：
※敏捷開發與瀑布開發相比有什麼優勢？
※軟體開發管理流程的困惑——為什麼最後開發的一堆東西都成了無用的代碼堆積？
※如何實施 SCRUM ？