首先聲明1：敏捷毒藥不是說敏捷是毒藥，而是指敏捷中有損組織整體的負面實踐，或者說在敏捷旗幟下的負面實踐。筆者認為敏捷整體上是很好的，當前研發開發不學習利用敏捷，那就是固步自封了。

聲明2：本文做說的組織是多于200人的商業組織，尤其不包括少于50人的創業組織。

聲明3：來自Scrum創始人的一句話-There are a lot of development centric practices that are being passed off as Scrum, and worse the best way to do business with customers. These hurt rather than help us.
--- Ken Schwaber?

#敏捷毒藥#之沒有數據支持的計劃會議細節任務估算。識別小于16工時的任務，并對每個任務花2分鐘以上的時間進行頭腦風暴式估算。結果：不可能識別所有細節任務，估算的任務不足，加班；基于不完整工時估算的燃盡圖無法使用；計劃會議本身耗時過長。

#敏捷毒藥#之以Excel為工具，每天跟蹤以任務小時為單位來繪制燃盡圖，共享Excel為載體，模式一：每人各自跟蹤自己的任務，張三修改時，李四最好別改，一個一個輪著改；模式二：一個人修改，這個人每天詢問團隊每個人:手頭任務還需要多少小時做完啊？ 無論哪種模式，都是#敏捷毒藥#

由于燃盡圖是每天需要跟蹤，那么剩下多少人天的填寫與剩下多少小時的填寫是一樣的。 //@JoneQian:如果是按人天呢？我覺得還是毒藥！ //@張克強-敏捷307:回復@JoneQian: 所以我將它來繪制任務小時燃盡圖的做法稱為#敏捷毒藥#。

#敏捷毒藥#之以xp的隱喻為依據，不維護設計文檔，假設團隊共享記憶。在競爭變化的環境下，指望穩定的團隊及其記憶是不恰當的。

#敏捷毒藥#之無視長遠和整體的簡單設計，簡單設計， “收錢走人，剩下不歸我管”，設計文檔如何做到剛剛好！

#敏捷毒藥#之相信代碼就是設計，忽略設計文檔溝通，以代碼作為設計溝通基礎，居然就有人相信這個更好？！

#敏捷毒藥#?之追求建設多面手團隊。人類數千年的歷史表明，分工是提升生產效率的一個關鍵。各專其能、優勢互補的團隊在現實和銀幕上大展神威。建設一支合格的多面手團隊耗費太高的成本和時間，對絕大多數組織而言都是不合適。但是多面手能力培養對個人而言是有強大的誘惑力。作為團隊的領導尤真是團隊以上的領導不要迷信多面手

#敏捷毒藥#之以團隊自組織為名義，不遵守組織的書面流程和要求，言稱我們團隊認為……我們團隊的情況是……，我們的實踐沒有必要如何……，將團隊決策凌駕于組織決策之上，號稱自組織團隊是不應當被命令與控制的。

#敏捷毒藥#?之全職Scrum Master，有觀點說?Scrum Master原則上不應該參與具體的任務，而是應該扮演一個敏捷教練，關鍵在于empower團隊。如果全職Scrum Master只指導一個團隊，那成本很高。就算是指導多個團隊，其本身也是不穩定因素。因為有如下矛盾：
所掌握的技能 vs. 所在崗位和薪酬
所掌握的權限 vs.所擔當的職責
所獲得的學習計劃 vs.晉升空間

當然如果組織已經對全職Scrum Master的績效考核和職業路徑有方案，那會相對好些，但并不能徹底解決。不如取消全職Scrum Master。

#敏捷毒藥#之理想工時和Capacity，一般的計算公式是Capacity=理想工作時間/總工作時間，在使用的時候是理想工作時間=總工作時間×Capacity。Capacity常見的取值范圍是50%～80%，在強調價值交付的敏捷中，為程序員爭取到了這樣的Capacity。
這含糊的指標貌似對程序員有利，從長遠看這個指標是含糊的，對團隊和組織長遠都沒用。

#敏捷毒藥#之承諾代替數據，按優先級依次逐個回答是否能在本迭代完成，承諾完成的待辦事項。?無視歷史數據，?將歷史數據比喻為昨日天氣，無法預測今日天氣。

#敏捷毒藥#之讓他們犯錯，然后從中學習。未來需要他們做決定，所以我從現在開始就讓他們自己做決定。They decide for themselves, not I. --- 作為指導者，旁觀者，可以讓他們犯錯。 但如果作為上級，最好是追求第一次就做對。

總結

以上是生活随笔為你收集整理的敏捷毒药-敏捷中有损组织整体的负面实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。