感覺需求都沒有搞清楚，就開始弄的所謂敏捷開發 其實浪費了更多的時間 和製造了大量無用的消耗

---

敏捷不是坑

但是敏捷吹得太狠

以至於很多搞不定事情的人一看見敏捷就以為找到了救星

把敏捷當成筐，什麼都往裡裝，然後就坑了

需求未定就開工這種事情，換哪種方法都搞不定。

瀑布要求全部定好一次搞定，敏捷要求定一部分就做一部分。不定哪能做出東西。

敏捷說穿了也只是管理方法論和框架而已。

搞定一個事情，方法有很多，能搞定的人從不拘泥方法，搞不定的人套再多方法也沒用。還是從解決現有問題著眼吧

---

那些所謂的敏覺開發諮詢師，忽悠的居多，遠離那些人，得敏覺。

---

對於多數國內企業和團隊來說，以 Scrum+XP 為代表的轟轟烈烈的「敏捷運動 1.0」確實是一個坑（還不止一個坑），一不小心就容易掉坑裡。

中美的軟體工程處於不同的發展階段與水平，論平均水平至少還差 8-10 年吧，尤其是人們的科學、工程意識與水平。Scrum+XP 並不是普適的，從一開始就不是針對中國軟體工程的現狀和特點提出來的，所以許多做法基本上不適合國內，適用面非常窄。

Scrum+XP 主推的那些實踐有點用，但缺陷也很明顯，比如理想化、片面、偏激、失衡，極端主義傾向，忽視需求分析、系統建模、架構設計，因此不能很好、有針對性地，或從根本上解決國內團隊面臨的一些現實主要問題，而 Scrum+XP 實踐所要解決的那些問題也並不是國內多數團隊所面臨的真正的短板。

顯然，兩者（賣方與買方）的不匹配，水土不服，加上長期的商務洗頭和運動洗頭式傳播，結果導致國內的偽敏捷、偽 Scrum 比比皆是。

感覺需求都沒有搞清楚，就開始弄的所謂敏捷開發 其實浪費了更多的時間和製造了大量無用的消耗

題主提到了需求分析，這正是 Scrum+XP 最薄弱的環節之一。

XP 中的需求分析實踐其實是很弱的，Kent Beck 發明了用戶故事（User Story），想要取代用例故事（Use Case）。

然而，有多少人相信，在實際的工程項目實踐中，僅靠一堆文字量非常有限的故事卡片（用完之後還要優雅地撕掉），加上口頭溝通，而不需要做大量科學、系統、細緻的需求分析，建立起高質量、書面的需求文檔和需求模型，就能把複雜軟體的需求真正搞清楚？

連最上游的軟體需求都沒搞清楚，自然會導致開發中的許多返工和浪費，更談不上敏捷了。

---

謝邀，我就是樓上說的所謂的敏捷開發諮詢師，雖然不是專職的，至少扮演過上面的角色。

你的問題，我想推廣成一個范型：

「感覺需求都沒有搞清楚，就開始弄的所謂《XX開發》 其實浪費了更多的時間 和製造了大量無用的消耗」

好像任何過程的方法的實例都可以放進去，而且看上去成立。

這裡無法長篇大論的討論敏捷，我只寫幾個我想到的點吧。

• 正是因為需要沒有搞清楚，敏捷的開發方式，更加適合。瀑布型的開發方式，面對需求模糊和需求變更的成本更高。
• 在項目開始的時間，很多時候需求是搞不清楚的，或者搞清楚的時候就已經過時了。
• 敏捷是軟體界向工業生產學習的產物，這個產物還在不斷發展，比如現在的LEAN。
• 敏捷開發方法同樣也不是銀彈，不會適合所有的項目。
• 有很多人靠鼓吹敏捷吃飯，CMM又何嘗不是呢？

---

其實你們做的並不是敏捷開發。只得其形，而不得其神。scrum和極限編程有著完整的流程和方法來解決這些問題。只不過我們都沒有嚴格去按照流程去走，而把問題歸結于敏捷開發。

比如scrum會強調需求一定要做排序，一定要做估算，這些有沒有做呢？每天的站立會議有按時召開嗎？一個個環節的忽略，會逐漸的被放大，到最後，也是一團糟。

---

不是坑，是一種思路的積累和升華，只不過和打仗一樣，光有兵書也是打不過的

我目前聽過很多周圍朋友的吐槽，感覺敏捷里的專業術語，已經成為了頂著各種title經理們的救命稻草，例如:

需求拍腦袋隨意改動，叫快速試錯迅速響應用戶需求；

代碼質量低劣不停出更新版本，叫快速迭代中；

不寫正規設計文檔，叫降低溝通成本和最好的文檔是代碼；

領導站身後指揮碼農寫代碼，叫結對編程；

產品質量不靠設計靠測試的，叫測試驅動研發；

最後，boss們一致認為，研發時間短了，就叫敏捷了

---

問題的描述比較模糊，缺少一些輔助判斷的細節信息，期待你的補充。

簡單來說：

• 瀑布就是總共100個需求，逐個階段往下：先完成100個需求的分析，才進入100個需求的設計，再才進入100個需求的實現，然後是100個需求的測試，然後是100個需求的發布或部署。
• 敏捷是，如果最後總共是100個需求，那麼：先完成5個需求的分析、設計、實現、測試、發布或部署全過程，然後再完成下5個需求的全過程，然後再下5個，循環，直到覺得沒有更多需要完成的需求了，而此時可能完成了100個也可能只完成了80個，也可能更多，而時間可能是原來的節點，也可能不是，但重要嗎？不一定重要。更重要的是，最先完成的都是最重要的需求。

在這個情況下，如果你說的模糊，是說沒有100個需求都清楚就開始開發，那麼這個確實就是敏捷的特點，因為它認為沒有必要那麼早鎖定，你怎麼確定現在對這100個需求的理解一定準確呢？為什麼不能現開發最重要的幾個需求，其他慢慢澄清，更何況，你完全可能會有新的想法嘛。

但另一方面，如果你說的模糊，是連馬上要開始的這5個需求都不清楚，那就有問題了，更有可能的是你們的敏捷是在掛羊頭賣狗肉，找個高手指教，或者請個教練、顧問去輔導吧。

---

領導一聽，啥？需求設計開發測試只用一幫人就搞定了？還只用付一份工資？贊啊！就搞敏捷吧！

---

敏捷開發並不適用於所有企業IT組織，有一些問題企業應該在事先解決。

我的一篇文章中總結了一些情況，你可以看看。知乎專欄

企業什麼時候不應該採用敏捷開發(Agile)？

作者：胡爾王

鏈接：知乎專欄

來源：知乎

著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。

敏捷開發作為最近的時髦辭彙，已經迅速席捲了IT界，以前Agile的使用僅僅適用於網站和手機APP的開發範圍，而今傳統企業IT也想引進Agile模式，來打造新的企業IT服務模式。Agile的好處我此處就不再描述了（本人目前主要的工作就是負責在公司內部內部普及Agile和DevOps），我在此主要是說說Agile本身的局限性或者說是她的適用情況，給那些想做Agile轉型的公司做一個參考。

1，當你不能用迭代法開發你的產品時，不要使用Agile。

不是所有的產品都是可以先推出一個簡單的有著很多bug的版本，而後按著用戶反饋逐步的更新和改進的。企業用戶和普通用戶的需求特點十分的不同，如果企業用戶的產品指向生產，銷售和CRM環節，產品的高質量往往是第一位的，高質量往往意味著長時間，目前流行的Scrum方式其實很難打造高質量的產品。

2，當你的客戶不能保證全身心的投入的開發工作時，不要採用Agile。

敏捷的模式不僅僅是針對IT的開發和管理人員，同時也是對客戶或用戶的，還是以Scrum為例，業務部門需要有專門並且全職的人員和開發人員在一起完成工作，不斷做需求更新和排位，不斷收集業務部門的反饋來調整開發目標。業務人員的參與程度的高低直接決定了Scrum方式的成敗。 但是傳統企業中的業務部門是否做好了這個準備，是否有相應的資源來匹配新的交付模式，都值得事先花更多的時間開準備。

3. 當整個團隊的規模太大，並且跨越了不同的時區，不要採用Agile。

俗話說，「船小好掉頭」，只有規模夠小才能敏捷靈活，但是傳統大型企業IT有一個致命的問題，就是IT服務資源的全球化。以前這是一個引以為豪的地方，但是現在卻成為一個絆腳石。大部分的企業會把IT系統架構/方案設計放在歐美國家，把IT運維放在中國或印度，軟體開發和測試也會放在中印等國家，業務關係管理（BRM）則可能緊挨著有業務部門的地點。這種分散的模式很難把Agile模式所需要的資源集中在某一個物理位置，所以企業IT只能採取虛擬團隊的模式來應付這種情況，或者從長遠上來看準備進行大的組織結構調整。

虛擬團隊的工作效率其實無法滿足agile的模式，如果是短期還可以，但是長期來說（以Scrum為例）天天的會議對於跨時區的團隊實際上是挺痛苦的，更不要說當前企業合作服務（比如，電話會議+文件實時共享）和面對面的溝通還是有不少的差距的。我相信經常使用這些服務的人明白我的意思，電話會議作為信息共享還可以，但是用來支持開發項目，效率就要打個大折扣。

組織結構的轉變影響不小，目前我還沒有看到哪個大企業為了實現Agile和DevOps改變傳統的IT組織架構。估計都是在做小範圍的測試。

4.在預算固定的開發項目中，不要採用Agile。

當前企業IT的預算都是在年初制定，但是Agile的開發模式往往會面臨需求比較大的改變，與之相對的就是預算不好確定，採用相對寬鬆和靈活的預算體系是企業需要提前做好準備的。

上面僅僅是一些我認為比較重要的地方，還有一些我沒有列出來，大家可以在實際中仔細觀察，比如企業文化是否支持高透明度，企業是否有強大的工程師文化影響等等...

知乎專欄

---

1，敏捷不是銀彈，是幫團隊解決問題的框架，如果你的團隊沒有問題 or 敏捷對你們並不對症，那你們不需要硬搬敏捷

2，敏捷開發不代表不需要搞清需求，不整理需求就盲目動手的是真·稀里糊塗開發

3，你真的認為目前的競爭條件下，軟體產品能夠提前整理好所有需求再一波推過去？程序寫代碼可能有bug，產品一樣可能整理錯需求。需求錯了肯定要改，到時候別抱怨，儘快修正才是該做的

4，敏捷不是不需要整理需求，而是把整理需求與開發一樣當做一個逐漸推進的過程，通過迭代開發等方式來降低需求錯誤的代價，努力專註核心需求，儘早產出可用的軟體來幫助需求的準確推進

潛水三年，首答

---

坑不坑，看管理者，加班文化盛行的地方，你敏捷開發也是通過加班來保證質量

---

推薦魚骨 協同辦公提高團隊整體工作效率

敏捷開發——產品、研發、測試整體化協作工具

產品看板

歸集產品、運營需求，支持按業務優先順序提交研發、定義產品版本和版本需求，記錄版本發布歷史，分階段多泳道管理Story、分Sprint管理研發任務，Bug高效集中管理。

Story看板

進入研發的需求（Story）待辦(Backlog) 可自定義研發階段、泳道、衝刺 ( Sprint )周期，還可自定義看板任務卡片展示內容。

Task看板

當前衝刺 ( Sprint )的需求 （Story）管理 快速拆分研發任務到項目成員

負責人看板

查看成員工作狀況 快速調整任務分配

這是從國外引進的開發方法 相較於傳統的瀑布型開發法 擁有 大幅減少文檔的數量 由技術自行領取任務 每日站會彙報工作進度提出並解決工作中的問題等優勢

魚骨精益敏捷開發項目更是將產品、技術、設計、測試的工作融合在一張看板中

產品建好需求 技術認領工作 完成後直接拖拽到測試中 測試一秒收到通知開始測試

動作一氣呵成 大幅減少時間的浪費 提升工作效率！

您還可以從周期、task等多角度查看項目工作進展

自動生成燃盡圖、任務完成情況等統計數據

為您推薦魚骨軟體

還有日程管理、文檔管理、即時通訊、同事圈、財務審批、人事行政等……

歡迎試用！好用的任務管理，項目管理和敏捷開發軟體，提升企業執行力！

---

敏捷是指開發過程，和需求的合理性沒有直接關係。

敏捷開發的需求，是由產品經理提出和負責的。產品經理在敏捷項目開始之前應該和客戶進行了足夠交流，並在敏捷開發的計劃會上和開發人員一起確認。

敏捷開發不背需求不合理的鍋。

---

是。

敏捷確實有敏捷的好處，但是如果全盤套用，就是個坑。看到很多公司或者項目組效仿敏捷，最後把自己做死了的。

適當的流程與文檔的精簡，以及溝通效率和工具使用便捷的提升是對的，這也是正常的，其他的都是扯淡，不僅會降低效率，而且還對實際項目沒有任何幫助。

學敏捷，學這一部分就可以了，其他的要慎重。

Lean enterprise也是，適用於大公司的精簡，但是小公司不思考好了自己各方面的問題，上來就lean，就呵呵了，真正有腦子的創業公司沒人會迷信敏捷這套東西。

---

雖然和題主的問題關係不大，但是有很多幹活，對於我這種從傳統模式的管理者轉變思維和管理方式上，有很大的指導意義，多謝！

---

軟體工程是工程技術，是關於人的技術。

---

敏捷開發中應該使用那些敏捷工具

發表於：2011-09-05來源：程序員雜誌作者：蔡煜點擊數： 5439標籤：敏捷開發敏捷工具

敏捷軟體開發絕不再是一個新名詞了，但理解還是時時有偏差。敏捷宣言中的第一條「個體和互動高於流程和工具」，有人就誤讀為「有了溝通，一切都迎刃而解」 ，因此花費大量精力整頓團隊合作，卻輕視了工具(技術)。其實宣言中的意思只是想強調個人和溝通更重要

　　敏捷軟體開發絕不再是一個新名詞了，但理解還是時時有偏差。敏捷宣言中的第一條「個體和互動高於流程和工具」，有人就誤讀為「有了溝通，一切都迎刃而解」 ，因此花費大量精力整頓團隊合作，卻輕視了工具(技術)。其實宣言中的意思只是想強調個人和溝通更重要而已。

　　實際上，既然是軟體開發，在所難免得面臨工具的選擇，而且很多優秀軟體實踐離開強有力的工具支持都玩不轉。在如今的軟體開發世界中，工具(這裡談的是軟體工具)層出不窮，數不勝數，那麼到底該怎麼去選擇適合的工具呢?

　　本文將根據我十幾年的企業級軟體開發經驗給出一點建議，和大家一起來探討敏捷和工具(特別是在企業實施中的工具)這個話題。

　　為了避免不必要的麻煩，文中盡量用開源軟體作為介紹，但這並不是說我排斥商業軟體，恰恰相反，在很多時候，只有商業軟體才提供了你需要的功能(當然大部分情況下開源軟體會很快迎頭趕上)。

　　背景知識：應用程序生命周期管理

　　聊到軟體開發中的工具，一般都會提到這個術語「應用程序生命周期管理(Application Lifecycle Management ，ALM)」 ，說句老實話，有點爛，誰都想把自己往上靠，誰都有自己的一套說法，圖1為我心中貫穿企業開發項目全程的ALM全局觀。

　　圖1中列出了ALM中的各個子系統，以及我略有研究的相對應工具的名稱，讓我們一起先來簡單地過一遍整個過程。

　　圖1 開發項目中應用程序生命周期管理及其工具

　　產品開發始於一定的需求，需求有好幾個層次，從產品需求到項目需求，進而產生出用戶故事(User Story)， 然後團隊會分解出任務(Task)。團隊開發者利用IDE(如Eclipse)去完成相應的代碼，單元測試完成後，再推送到代碼庫(git)，這些和軟體配置管理(Software Configuration Management，SCM)相關。

　　構建系統會從代碼庫中獲取最新的代碼，進行編譯、打包、功能測試和系統測試，可以設置在質量系統中顯示一些相關信息，如果一切順利，甚至能直接上傳到在線系統更新上線。此外不管是開發中還是運行中一般還都會有一個缺陷管理系統。

　　BugZilla大家應該很熟悉了，用Redmine的人少一些，但它實際上是一個非常靈活的項目管理系統，國內也有越來越多的公司在使用了，Nexus是一個Java軟體包的管理工具，需要和Maven結合使用，Sonar是一個Java項目的質量控制工具，它集成了如單元測試、覆蓋率、靜態質量檢查等內容。為什麼任務管理下的Redmine有紅叉呢?我們稍後會解釋。

　　限於篇幅，本文只會談到其中的一部分工具。作為參考，可以閱讀Manning出版社的新書《Agile ALM》，它對SCM、單元測試、功能測試等話題進行了更深入的探討。

　　敏捷中有些工具是必需的

　　如果你說敏捷實施大半年了，但持續集成 (Continuous Integration，CI)伺服器卻還沒有架起來，那我實在是不曉得你都在敏捷些啥東西了。無論你究竟「信仰」哪種敏捷，產品開發各個方面的自動化(Automation)和持續集成都必不可少。要了解持續集成，可以看看Martin Fowler的文章，可謂白皮書級別的經典，有中文翻譯版。

　　使用CI就一定會用到CI伺服器，可選的有很多，其中Jenkins是現在最流行的一個，而且架設起來也很方便。它是從Hudson繼承而來(自從2011年5月Oracle決定把Hudson捐獻給Eclipse組織，兩者的關係和將來的發展方向也可能帶來更多變數)。

　　在Jenkins構建伺服器中，可以定義任務(在Jenkins中叫job)，以完成一些構建步驟(如簽出代碼、編譯、各種類型的測試、打包等)，它有極豐富的插件(plugin)資源作為支撐，可以來集成產品軟體開發的各個要素，它把你所需要的一切都自動化起來。

　　圖2 Jenkins項目自己的Jenkins構建伺服器

　　在Jenkins構建伺服器的首頁，每個任務還都有一個天氣圖標表示其狀態，非常直觀，例如「太陽」就代表著一切正常(至少從構建結果來看)。它是產品項目開發的晴雨表，項目狀態是否正常一目了然。不管是對Jenkins不了解還是想提高，我強烈推薦閱讀John Ferguson Smart的Jenkins開源書：Jenkins: The Definitive Guide。

　　對敏捷來說，並沒有「CI伺服器要還是不要」一說，它就是必須的，一定要好好地實施。基於持續集成再往前走，就是持續交付(Continuous Delivery)了，這也是敏捷的一個新熱點，其中加入了很多新元素(如自動化驗收測試、持續部署等)。

　　別讓工具牽著鼻子走

　　工具很重要，但會不會有些誤區呢?當然有，我們一起來看個我經常碰到的一個例子。

　　講到敏捷實施一直都會提到白板(Whiteboard)的使用，先得提醒大家，它也是一個「工具」 ，白板的其中一種用法叫任務白板，主要是提供給團隊使用的。

　　圖3 每日例會用的任務白板(圖來自《硝煙中的Scrum和XP 》一書)

　　圖3就是常見的任務白板，團隊的需求，一般是用戶故事(User Story)，被放在最左邊一欄「NOT CHECKED OUT」，作為團隊一個迭代的輸入，然後分解成任務(Task)用報事貼(俗稱黃貼)貼在白板上「CHECKED OUT」那一欄，並簽上自己的名字，就算是領任務啦。當做完了一個任務就把它(黃貼)挪到下一欄「DONE!:o)」，代表做完了，最右邊一般還會留出部分空間，用來記錄進度條和注意事項來提醒團隊一些重要的事情。

　　如果說Jenkins構建伺服器是產品開發的晴雨表，那麼任務白板就是團隊開發的晴雨表。

　　一般一大早在每日的站立會議(Daily Standup Meeting)上，整個團隊所有人都會圍在白板前，分享所負責任務的進度，順便挪動一下任務到相應的狀態欄，用這種方式能夠減少很多不必要的彙報型會議，而且團隊成員也能很快地了解開發的整體狀況。相信如果某個黃貼在白板上連著三天都沒動，團隊里一定會有人站出來幫忙的。(沒有?!那還是先組織他們參加團隊合作的培訓吧。)

　　有時候團隊坐得比較分散，或者有人喜歡流行的在家辦公方式，這時可能會開始使用一些圖形化的電子白板來管理團隊任務，大家對著屏幕介紹進度，效果似乎還不錯，其他人(包括經理們)也非常高興，因為他們可以隨時從網上了解到團隊的進度了。慢慢地，面對面的時間看起來也可以節省下來，只要窩在座位上點點滑鼠，挪挪電子黃貼(如果支持漂亮的拖拉就更好了)就已經足夠了。

　　這是敏捷的好實踐嗎?

　　是否嗅到了一點怪味道?它就是我想談的工具帶來的誤區，電子白板會削減團隊之間的溝通，降低團隊的透明度，違背了敏捷重視人和團隊的原則。如果你的團隊成員不經常去更新電子白板上的任務時間，慢慢地你看到的都是不太準確的信息了。有人可能說我們還是面對著電子白板開每日站立會議呀，那我希望你有個很大的屏幕吧(否則這樣子效果會更差)。

　　那為什麼沒說它不對呢，因為在一些場合下，它還是有作用的。關鍵是團隊要能充分認識到它的局限性，因此我極力反對在團隊組建初期用電子白板，可以等團隊充分領會到敏捷中人與人溝通的重要性後再引入。

　　這也是在圖1中特意用紅叉提醒不要用Redmine來管理任務(這個白板功能的插件也很差，因為沒人用)。

　　所以要了解你的需求，不要讓一些工具牽著鼻子走，要了解敏捷實施的目的，否則出了問題還以為工具不到位，拚命要更強的功能，結果陷入大誤區。

　　有些工具會帶來意想不到的好處

　　傳統的敏捷著述中通常會提到CI的部分，然而工具的運用並不限於此，例如我在實際項目中用到的Gerrit，它非常契合敏捷的宗旨，也給我們帶來了意想不到的好處。

　　代碼審閱是一個不錯的敏捷開發實踐，讓人非常頭疼的是實施。大企業中通常是制定出一大堆相關的規範和流程來指導代碼審閱。我聽說好多公司都會把代碼列印出來，進行走讀，這可真是累啊。這種方式會給人不信任的感覺，而且應該是挺浪費時間的。

　　結對編程(Pair Programming)也是非常好的一種代碼審閱的方式，值得好好地學一學，只是我對它並不太感冒，體會是在大企業實行結對編程的難度很大，當然如果能找到合適的推動者，那還是可以嘗試嘗試的。

　　那看看開源社區是怎麼解決這個問題的呢，使用的又是什麼工具呢?Google的Android系統是現在非常熱門的開源項目，它的代碼審閱(包括貢獻者的代碼)使用的是Gerrit，非常棒的東西，在自己的企業中架設起來也非常方便，我一用就愛上它了。

　　Gerrit是一個基於Web的代碼評審和項目管理的工具，面向基於Git版本控制系統的項目，所以如果你沒用git(幹嘛不用呢)，就沒法用Gerrit了，接下來來看看在Gerrit中怎麼實施代碼評審的。

　　● 首先開發者(貢獻者)的代碼變更通過 git 命令被推送(push)到Gerrit管理下的Git 版本庫，推送的提交轉化為一個一個的代碼審核任務(見圖4)。

　　● 代碼審核者可以通過Web界面查看審核任務、代碼變更，通過Web界面做出通過代碼審核(Review)或者拒絕(Reject)等決定。

　　● 測試者(一般可以設定為CI伺服器執行)可以通過訪問來獲取(fetch)代碼變更進行相應測試，如果測試通過，就可以把這個評審任務設置為校驗通過(Verified)。

　　● 最後經過了審核(Review)和校驗(Verified)的代碼變更可以通過Gerrit界面中提交動作合併到版本庫的對應分支。

　　相比代碼走讀，它的好處在於，審閱動作發生在向主幹提交代碼前，可以只看變更的部分顯得很貼心，網上隨時隨地審閱起來也很方便，這也是有別於結對編程的一個好處。

　　任何人都可以審閱提交的代碼，整個團隊的代碼都一目了然，審閱起來更方便，非常符合開放、透明的敏捷精神。使用之後能夠顯著提高代碼質量，甚至於等到習慣了以後，代碼不被審閱一下，都覺得實在是不好意思提交代碼到主幹上去。

　　Gerrit中，通過特定分支，任何審核任務的代碼變更都能訪問，所以如果需要細看或是合併到本地都異常方便。

　　Gerrit剛開始實施可能會有點不習慣，畢竟整個工作流有所變化，因此實施時需要通盤考慮。

　　如上只是近期我特別喜歡的一個工具，其實類似的工具還有許許多多，這不過是滄海一粟而已。

　　總結

　　水能載舟，也能覆舟，工具和敏捷的關係亦如此，下面我給出幾點建議：

　　● 積極嘗試新工具，如今的軟體開發世界中，工具層出不窮，要不斷與時俱進，了解最新動向和如何用有效的工具去輔助敏捷的實施，在自己的軟體開發環境中去嘗試和了解這些工具，嘗試這一點很重要，不要只看說明或戴有色眼睛去看待這些工具，應該通過實踐摸索找到最適合你的選擇。

　　● 人總是第一位的，要了解你的團隊，了解他們的需求，有些時候甚至可以為了團隊，冒險一下採用新技術、新工具，這樣可以提高團隊的凝聚力(敏捷要素之一)。我待過的一些部門推動Git時，就是這麼來的，很多時候過多的討論其優缺點反而是浪費時間，不如多花點時間多試試。

　　● 實施敏捷也離不開組織的支持，特別大型企業涉及到的人很多(可能水平不一)，這時候推動者就必須用專業的手段建立一個持續漸進的工具引入過程，這樣會使得實施更容易些。

---

推薦閱讀：