敏捷的方法論

敏捷的方法論

跟蹤變化

惡魔：「軟件技術的變化如此之快，勢不可擋，這是它的本性。繼續用你熟悉的語言作你的老本行吧，你不可能跟上技術變化的腳步。」

你不須要一口氣爬上10樓，而須要一直在攀登，因此最後看起來就像只要再上一二層。若是你對全部這些技術都一無所知，想要立刻登上這10樓，確定會讓你喘不過氣來。並且，這也會花很長時間，期間還會有更新的技術出現。

現今有不少方法和工具能夠幫助咱們繼續充電：

1. 迭代和增量式學習：天天計劃用一段時間來學習新技術，它不須要很長時間，但須要常常進行。記下那些你想學習的東西——當你聽到一些不熟悉的屬於或者短語時，簡要地把它記錄下來。而後再計劃的時間中深刻研究它。
2. 瞭解最新行情：互聯網上有大量關於學習新技術的資源。閱讀社區討論和郵件列表，能夠了解其餘人遇到的問題，以及它們發現的很酷的解決方案。選擇一些公認的優秀技術博客，常常去讀一讀，以瞭解那些頂尖的博客做者們正在關注什麼。
3. 參加本地的用戶組活動：各類技術在不少地區都會有用戶組。聽講座，而後積極加入到問答環節中。
4. 參加研討會議：計算機大會在世界各地舉行，許多知名的顧問或做者主持研討會或課程。這些聚會上向專家學習的最直接的好機會。
5. 如飢似渴地閱讀：找一些關於軟件開發和非技術主題的好書，也能夠上一些專業的期刊和商業雜誌，甚至上一些大衆媒體新聞。

天使：「跟蹤技術變化。你不須要精通全部技術，但須要清楚知道行業的動向，從而規劃你的項目和職業生涯。」

切身感覺

• 你能嗅到將要流行的新技術，知道它們已經發布或投入使用。
• 若是必需要把工做切換到一種新的技術領域，你能作到。

平衡的藝術

• 許多新想法從未變得羽翼豐滿，成爲有用的技術。即便是大型、熱門和資金充裕的項目也會有一樣的下場。你要正確抱我本身投入的精力。
• 你不可能精通每一項技術，沒有必要去作這樣的嘗試。只要你在某些方面成爲專家，就能使用一樣的方法，很容易成爲新領域的專家。
• 你要明白爲何須要這項新技術——它試圖解決什麼樣的問題？它能夠被用在什麼地方？
• 避免在一時衝動的狀況下，只是由於想學習而將應用切換到新的技術、框架或開發語言。在作決策之卡沒，你必須評估新技術的優點。開發一個小的原型系統，說對付技術狂熱者的一劑良藥。

對團隊投資

惡魔：「不要和別人分享你的知識——本身留着。你說由於這些知識而成爲團隊中的佼佼者，只要本身聰明就能夠了，不用管其餘失敗者。」

團隊中的開發者們各有不一樣的能力、經驗和技術。每一個人都各有所長。不一樣才能和北京的人混在一塊兒，是一個很是理想的學習環境。

在一個團隊中，若是知識你我的技術很好還遠遠不夠。若是其餘團隊成員的知識不夠，團隊也沒法發揮其應有的做用：一個學習型的團隊纔是較好的團隊。

當開發項目的時候，你須要使用一些術語或者隱喻來清晰地傳達 設計的概念和意圖。若是團隊中的大部分紅員不熟悉這些，就很難進行高效的工做。再好比你參加了一個課程或者研討班以後，所學的知識若是不用，每每就會忘記。因此，你須要和其餘團隊成員分享所學的知識，把這些知識引入團隊中。

找出你或團隊中的高手擅長的領域，幫助其餘的團隊成員在這些方面迎頭遇上（這樣作還有一個好處是，能夠討論如何將這些東西應用於本身的項目中）。

「午飯會議」是在團隊中分享知識很是好的方式。在一週之中挑選一天，事先計劃午飯時彙集在一塊兒，這樣就不會擔憂和其餘會議衝突，也不須要特別的申請。爲了下降成本，就讓你們自帶午飯。

每週，要求團隊中的一我的主持講座。他會給你們介紹一些概念，演示工具，或者作團隊感興趣的任何一件事情。你能夠挑一本書，給你們說書哦其中一些特別內容、項目或者實踐。不管什麼主題均可以。

從每週主持講座的人開始，先讓他講15分鐘，而後，進行開放式討論，這樣每一個人均可以發表本身的意見，討論這個主題對於項目的意義。討論應該包括所能帶來的益處，提供來自本身應用程序的示例，並準備好聽取進一步的信息。

這些午飯會議很是有用。它促進了各鎮團隊對這個行業的瞭解，你本身也能夠從其餘人身上學到不少東西。優秀的管理者會重用那些能提升其餘團隊成員價值的人，所以這些活動也直接有助於你的職業生涯。

天使：「提供你和團隊學習的更好平臺。經過午飯會議能夠增進每一個人的知識和技能，並幫助你們彙集在一塊兒進行溝通交流。喚起人們對技術和技巧的激情，將會對項目大有裨益。」

切身感覺

• 這樣作，會讓每一個人都以爲本身愈來愈聰明。
• 整個團隊都要了解新技術，並指出如何使用它，或者指出須要注意的缺陷。

平衡藝術

• 讀書小組逐章一塊兒閱讀一本書，會很是有用，可是要選好書。
• 不是全部的講座都能引人入勝，有些甚至顯得不合時宜。無論怎麼樣，都要未雨綢繆。
• 儘可能讓講座走入團隊中
• 堅持有計劃有規律地舉行講座。持續、小步前進纔是敏捷。稀少、間隔時間長的馬拉松式會議非敏捷也。
• 若是一些團隊成員由於吃午餐而缺席，用美食引誘他們。
• 不要侷限於純技術的圖書和主題，相關的非技術主題也會對團隊有幫助。
• 午飯會議不是設計會議。總之，你應專一討論那些與應用相關的通常主題。具體的設計問題，最好是留到設計會議中去解決。

懂得丟棄

惡魔：「那就是你一向的工做方法，而且是有緣由的。這個方法也很好的爲你所用。開始你就掌握了這個方法，很明顯它是最好的方法。真的，從那之後就不要再改變了。」

隨着科技進步，曾經很是有用的東西每每會靠邊站。它們再也不有用了，它們還會下降你的效率。對於大多數的商業應用，技術已經有了巨大的變化，再也不像過去那樣，到處考慮內存佔用、手動的重複佔位及手工調整彙編語言。

Expensive mental models aren't discarded lightly
丟棄已經會的東西並不容易，不少團隊在猶豫。在學習一門新技術的時候，多問問本身，是否把太多舊的態度和方法用在了新技術上。打破舊習慣很難，更難的是本身尚未意識到這個問題。

這也不是說你真的要徹底丟棄它們。其實，根據具體狀況還能夠運用舊知識。

應該力求儘量徹底轉入新的開發環境。例如，學習一門新的編程語音時，應使用推薦的集成開發環境，而不是你過去開發時用的工具插件。用這個工具編寫一個和過去徹底不一樣類型的項目。轉換的時候，徹底不要使用過去的語言開發工具。只有更少被舊習慣牽絆，才更容易養成新習慣。

天使：「學習新的東西，丟棄舊的東西。在學習一門新技術的時候，要丟棄會阻止你前進的舊習慣。」

切身感覺

• 新技術會讓人感到有一點恐懼
• 你確實須要學習不少東西。
• 已有的技能和習慣爲你打下了很好的基礎，但不能依賴它們。

平衡的藝術

• 要果斷丟棄舊習慣，一味遵循過期的舊習慣會危害的你的職業生涯。
• 不是徹底忘記舊的習慣，而是旨在使用適當的技術時才使用它。
• 對於所使用的語言，要總結熟悉的語言特性，而且比較這些特性在新語言或新版本中有什麼不一樣。

打破砂鍋問到底

惡魔：「接受別人給你的解釋。別人告訴你問題出在了什麼地方，你就去看什麼地方。不須要再浪費時間去追根究底。」

前面談到的一些習慣是關於如何提升你和團隊的技術的。下面有一個習慣幾乎老是有用，能夠用於設計、調試以及理解需求。

假設，應用系統出了大問題，它們找你來修復它。但你不熟悉這個應用系統，因此他們會幫助你，告訴你問題必定是出在哪一個特殊的模塊中——你能夠放心地忽略應用系統的其餘地方。你必須很快的解決這個問題，由於跟你合做的這些人耐心也頗有限。

當你受到那些壓力的時候，也須要會以爲受到了脅迫，不想去深刻了解問題，並且別人告訴你的已經夠深刻了。然而，爲了解決問題，你須要很好的瞭解系統的全局。你須要查看全部你認爲和問題相關的部分——即便其餘人以爲這並不相干。爲了解決問題，你須要知道許多可能的影響因素。當找人詢問任何相關的問題時，讓他們耐心的回答你的問題，這是你的職責。

或者，假設你和資深的開發者一塊兒工做。它們可能比你更瞭解這個系統。但他們也是人，有時他們也會忘記一些東西。你的問題甚至會幫助他們理清思路。你從一個新人角度提出的問題，給他們提供了一個新的視角，也許就幫助他們解決了一隻使人困擾的問題。

「爲何」時一個很是好的問題。事實上，在一本流行的管理圖書《第五項修煉》中，做者建議，在理解一個問題的時候，須要漸次地問5個以上的「爲何」。它是很好的方式，進一步挖掘簡單直白的答案，經過這個路線，設想就會更加接近事實真相。

真的嗎？爲何呀？

爲何呀？

天使：「不停地問爲何。不能只知足於別人告訴你的表面現象。要不停地提問直到你明白問題的根源。」

切身感覺

• 你不停篩選掉無關的物質，一次比一次深刻，直到找到發光的寶石。
• 你要能感受到真正地理解了問題，而不是隻知道表面的症狀。

平衡的藝術

• 你可能會跑題，問了一些與主題無關的問題。問爲何，可是要問到點子上。
• 當你問爲何的時候，也許你會被反問：「爲何你問這個問題？」在提問前想好你提問的理由，這會有助於你問出恰當的問題。
• 「這個我不知道」是一個好的起點，應該由此進行更進一步的調查，而不該在此戛然結束。

把握開發節奏

惡魔：「咱們很長時間沒有進行代碼複審，因此這週會複審全部的代碼。此外，咱們也要作一個發佈計劃了，那就從星期二開始，用3周時間，作下一個發佈計劃。」

在許多不成功的項目中，基本上都是隨意安排工做計劃，沒有任何的規律。那樣的隨機安排很難處理。你根本不知道明天將會發生什麼，也不知道什麼開始下一輪的全體「消防演習」。

可是敏捷項目會有一個節奏和循環，讓開發更加輕鬆。例如約定30天以內不該發生需求變化，這樣確保團隊有一個良性的開發節奏。這有助於防止一次計劃太多的工做和一些過大的需求變動。

咱們先來看某個工做日的狀況。你但願天天工做結束的時候，都能完成本身的工做，你手上沒有遺留下任何重要的任務。固然，天天都能這樣說不現實的。但你能夠作到天天下班離開公司前運行測試，並提交一天完成的代碼。若是已經很晚了，而且你只是嘗試性地編寫了一些代碼，那麼也許最好應該刪掉這些代碼，次日從頭開始。這個建議聽起來十分極端，但若是你正在開發小塊的任務，這種方式很是有助於你管理本身的時間：若是你工做的時候沒有一個固定的最終期限，就應該好好想一想了。

敏捷開發者能夠從多方面獲得反饋：用戶、團隊成員和測試代碼。但時間自己就是一個很是重要的反饋。
你可能不知道完成全部的任務須要多少個迭代，但每一個迭代必須是短時間的、有限的，而且要完成具體的目標。
迭代的時間是固定的，但在一個具體的迭代中完成哪些功能是靈活的。類似地，你會爲設計討論會設定時間期限，會議結束必需要作出最終的設計決策。
當你遇到艱難抉擇的時候，固定的時間期限會促使你作決定。你不能在討論或功能上浪費不少時間，這些時間能夠用於具體的工做。

站立會議最好天天在固定的時間和地點舉行，好比上午9點左右。要養成這樣的習慣，在那時就準備好一切參加站立會議。

最大的節拍就是迭代時間，通常是1～4周的時間。無論你的一個迭代是多長，都應該堅持——確保每一個迭代週期的時間相同很重要。運行有規律的開發節奏，會更容易達到目標，並確保項目不停地前進。

天使：「解決任務，在事情變得一團糟以前。保持事件之間穩定重複的間隔，更容易解決常見的重複任務。」

切身感覺

• 項目開發須要有一致和穩定的節奏。
• 編輯，運行測試，代碼複審，一致的迭代，而後發佈。
• 若是知道何時開始下一個節拍，跳舞就會更加容易。

平衡的藝術

• 在天天結束的時候，測試代碼，提交代碼，沒有殘留的代碼。
• 不要搞得常常加班。
• 以固定、有規律的長度運行迭代。也許剛開始你要調整迭代的長度，找到團隊最舒服可行的時間值，但以後就必需要堅持。
• 若是開發節奏過於密集，你會精疲力盡的。通常來講，當與其餘團隊合做時，你須要減慢開發節奏。
• 有規律的開發節奏會暴露不少問題，讓你有更多鼓起勇氣的藉口。

敏捷工具箱

• Wiki：Wiki是一個網站，是一種很好的支持協做的工具，由於團隊中的每個人均可以根據須要動態地新增和從新組織網頁中的內容，實現知識共享。例如，局域網Wiki。
• 版本控制：項目開發中全部的產物——所有的源代碼、文檔、圖標、構建腳本等，都須要放入版本控制系統中，由版本控制系統來統一管理。例如，微軟的TFS和Github。
• 單元測試：用代碼來檢查代碼，這是開發者得到反饋的主要來源。例如，微軟的GTest。
• 持續集成：無論是在本身的本地機器上實現構建，仍是爲整個團隊實現構建都是全自動化並可重複的。