敏捷社群正在如火如荼地討論什麼情況下團隊能真正地敏捷起來，又有哪些是實施敏捷的正確方法。jason little撰寫了博文《你幹得比你認為的更出色》，分享了他的觀點：面對敏捷實施的各種意見，我們該何去何從？
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n敏捷社群可以迅速地找出你隊伍中的問題。你「scrum用得不對」，你在「照搬(doing)敏捷」，而沒有「變得(being)」敏捷，或者類似的一些廢話。但你究竟有什麼是做得對的呢？
\u0026#xd;\n
他認為，敏捷不是「照搬敏捷」或者「變得敏捷」，而是意味著行動上的改變和進步。
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n我知道大家在進步，因為我看到了不一樣的表現，這是幾個月前不曾有過的。我感到大家在進步，因為大家給我講了一年前的生活和現在的生活的種種不同，工作上的各種改進。
\u0026#xd;\n
jason建議多關注做得好的地方，並引以為傲：
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n我不認為公司足夠關注大家做得好的事情，因為各種權威總是指出大家做得不好的地方。……我現在所在的團隊就為他們所取得的進步感到非常驕傲……昂首挺胸，我為你們驕傲。
\u0026#xd;\n
tommy bryntse寫了一篇名為《什麼是敏捷》的部落格，其中他指出了團隊可以號稱敏捷的關鍵點。他闡述了他所理解的敏捷，以及什麼情況下不算敏捷：
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n敏捷宣言是敏捷的靈魂。宣言中的十二法則充分詮釋了敏捷。無須贅述……變得敏捷就是遵循宣言精神及其身後的法則。如果你沒做到，不好意思：不能算敏捷！
\u0026#xd;\n
他建議如果做不到，還是暫時不要說自己要做敏捷了，先做個列表出來，告訴自己「算不上敏捷」的原因。
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n請不要只因為開了日常站立會議，用白板記錄故事、分派工作，就標榜自己在做敏捷開發。……要實現敏捷，你得先檢查前面提到的「算不上敏捷」列表……如果榜上有名，你就不算敏捷。話雖這麼說，我並不是讓大家停止手中的實踐。那些優秀實踐可以幫助你交付更好的軟體。只是如果你沒有真正做到，就別說在做。
\u0026#xd;\n
在infoq對jeff sutherland題為《敏捷團隊真的敏捷嗎？》的採訪中，他回顧了敏捷宣言發布以來這十年的歷程。他也就如何判斷是不是敏捷發表了自己的觀點：
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n……在sprint結束時能夠交付可執行的產品確實很有挑戰，如果沒有完善的敏捷團隊很難做到，而正如我們所討論的，這一點又是相當關鍵的基本原則，做不到就算不上敏捷。
\u0026#xd;\n
jeff還舉了幾個實施scrum的正面和反面例子：
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n……有資料表明，做得好的scrum效率要快10倍。
\u0026#xd;\n
要做好scrum，頭一件事就是要在sprint結束時交付可工作的軟體。……另一件重要的事是sprint所需要的backlog：backlog準備好了嗎？是否清晰？是否每個待辦項都大小合適？團隊能夠理解backlog從而做出估算？是否有驗收測試條件?
\u0026#xd;\n
我和ken發明並在軟體開發中運用了scrum，我們把能想到的軟體知識都用上了，但結果是，如果scrum不精益，就是糟糕的scrum。一旦開始實施精益**，就意味著要從系統中移除浪費。而scrum就是致力於掃除障礙，和減少浪費一脈相承。
\u0026#xd;\n
在名為《嬰兒和洗澡水》的博文中，jim york**了如何看待五花八門的敏捷實踐、工具和技術。他就如何決定選用哪些敏捷實踐給了些建議：
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\nscrum的乙個基本前提是如果事情進展順利，就繼續做。反言之，如果什麼事情進展不利，一定要及時改變。scrum並沒有規定哪些敏捷實踐在它的框架之內，而是將做這個決定的權利留給了自組織團隊自由發揮。而這個「自由發揮」往往是scrum實施中最難的部分。
\u0026#xd;\n
他認為團隊應該通過了解哪些實踐合適他們，哪些不合適來自己發掘敏捷的真諦：
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n我更願意將scrum看作是乙個學習加速器。每個sprint都是個實驗，是個學習的機會。……公司從過去他們經常使用的開發增量產品的流程中學到新的東西。學到的經驗可以進一步地改進流程。
\u0026#xd;\n
檢視英文原文：right way(s) of doing and being agile
敏捷實踐 微軟實施敏捷的經驗
此處會介紹微軟在分布式團隊環境下如何實施敏捷開發的一些經驗。對於面向全球市場 想節省成本的公司，分布式團隊是應用非常廣的一種方式。每乙個團隊的組成 產品經理 代表客戶，幫助團隊更好的了解需求。對product backlog排列優先順序並為每一次迭代確定user story。微軟為乙個團隊安排一名產...
敏捷開發的實施步驟
這個人必須知道帶領的團隊需要做什麼 製造什麼產品以及取得什麼成果，必須會面考慮到風險與回報 什麼具有可行性 什麼能做以及他們對什麼富有熱情。真正做事的是誰？這個團隊必須能夠落實產品負責人的願景。團隊規模宜小不宜大，一般3 9人較為合適。主管為scrum過程負責，負責培訓團隊其他成員，確保scrum得...
如何實施敏捷開發
如果嚴格按照書本上的 scrum 法則一條條地看，那麼我們隊伍現在的做法也許根本不算 scrum。不過好歹我們也被稱作 scrum 一段時間了，我的資歷比不上前面的資深開發者，只能說一些目前的一點經驗。經驗一 整個團隊必須理解 scrum 的目的和限制。如果管理團隊把 scrum 當作一種新的管理流...