暑期參加ThoughtWorks公司的暑期特訓營，我對敏捷開發有了一定的認識，並在做專案中得到了實踐。

專案是我們團隊經過討論和思考，提出的。
專案第一階段：
1、畫MVP圖：最小可行產品（Minimum Viable Product）是一種避免開發出客戶並不真正需要的產品的開發策略。MVP不是每個迭代做出產品功能的一部分，而是每次迭代都要交付一個可用的最小功能集合，這個集合的功能可以滿足使用者的基本需求，雖不完善但至少可用，即MVP產品僅包含必要的功能。
Example：要計劃製造一輛汽車，它最核心的功能是可以在路上跑，所以我們可以先製造一個踏板車，依次迭代為滑板車，自行車，摩托車，汽車。
2、寫User Story：模擬過程類似角色扮演遊戲。這個雖然簡單，但對於理清各個角色的關係特別重要。同時也不斷地認清了客戶的真正需求。但是對於較複雜的系統，深入客戶企業，瞭解客戶企業員工的工作流程更為重要。
Example

：在這個過程中，因我們團隊對其背後真正支援的思想沒太理解，所以寫的User Story含糊不清。
一個好的使用者故事包括三個要素：
角色：誰要使用這個功能；
活動：需要完成什麼樣的功能；
商業價值：為什麼需要這個功能，這個功能帶來什麼樣的價值。
使用者故事通常按照如下的格式來表達：
英文： As a , I want to , so that .
中文： 作為一個<角色>, 我想要<活動>, 以便於<商業價值>
3、在Trello看板寫Backlog:將使用者故事寫到看板上，為實現程式設計，不偏離MVP
4、在Trello看板上建立To do欄目，針對MVP進行拆分功能、寫功能卡片
5、對每一卡片（每一個功能）進行估點，可以分為簡單，容易，複雜，非常難，放棄等，給其賦予相應的點數，然後對功能卡的難易程度作出評估
6、團隊組織人員根據自己的能力領卡片
專案第二階段：
1、根據自己領到的卡片，進行分析。畫原型圖、State圖、Action圖、Api圖、元件圖
2、畫例項圖。就是測試先行原則，Request，Response
3、領卡片，實現功能
……
在實現功能時堅持極限程式設計，快速決策，多與團隊溝通，做好單元測試。
極限程式設計：我認為就是測試先行。要求在編寫程式碼之前先寫測試，這樣可以強制你在寫程式碼之前好好的思考程式碼（方法）的功能和邏輯。前期工作比較慢，但實際上是為了避免“返工”時大的工作量。
極限程式設計中，基本過程是這樣的：構思－> 編寫測試程式碼－> 編寫程式碼－> 測試，而且編寫測試和編寫程式碼都是增量式的，寫一點測一點，在編寫以後的程式碼中如果發現問題可以較快的追蹤到問題的原因，減小回歸錯誤的糾錯難度。 極限程式設計的核心價值觀是：”溝通（Communication）、簡單（Simplicity）、反饋（Feedback）、勇氣（Courage）、謙遜（Modesty）”
快速決策和充分溝通：小步前進，快速迭代來逐步逼近專案目標，溝通是一個很重要的環節。否則一次迭代完成後，專案得不到及時和正確的反饋，專案很難進行下去。
單元測試:單元測試其實就是為了程式最後交付時減少Bug，側重業務，而不是為了寫程式而測試。
靈活運用敏捷開發 我們老師曾說敏捷開發本身強調的就是擁抱變化。我個人理解的是，敏捷開發過程本身是可剪裁的。
Example：在專案進行的第一週，我們效率低下，產出低，然後老師就針對其做了調整，讓我們重新去開發。 在專案進行的第三週，因為時間所限，我們就只能讓BA砍掉需求，僅僅去做核心功能，因為其他功能的使用率相對比較低。
我的個人感悟： 一個善於合作、溝通以及互動能力強的程式設計師一定是一個優秀的團隊成員。這時時刻刻提醒我們，與客戶，團隊其他成員，其他團隊成員的溝通非常重要。構建一個優秀的團隊比構建環境更重要。
結對程式設計：是兩個人共同完成一個模組程式碼任務，一個人手頭程式設計，另一個人檢驗並想出後續策略。在結對程式設計時候，我們是讓基數相對薄弱的人去編寫，技術好的人，檢驗，指導。這樣可以同時提高了程式碼正確率也提高了兩人的技能。同時，也鍛鍊了個人的協調、溝通、合作能力。互幫互助，團隊之間互相瞭解到熟悉。
案例1（個人）：
開始接觸敏捷開發的時候，因技術基礎弱，自己領到新卡總是埋頭苦幹，遇到問題容易鑽進去。更嚴重的是，有時候明明知道自己很有可能不會完成任務，但是也沒有直接給“技術指導”提出來，嚴重影響整個團隊的專案進度。
就我個人來分析，沒有很好地溝通，沒有站在全域性看待問題，缺少不懂就問的精神。自己做不出的就及時問別人，遇到問題要及時和相關人員溝通。這樣從專案角度看，降低了專案的風險；從個人角度看，管理了管理者的期望值。雙贏的事。
案例案例2（團隊之間）：
一個專案中會有開發團隊、測試團隊、需求團隊。 在專案的初級階段，老師為了讓我們理解介面，就把測試和開發獨立開了。寫測試的人員與寫功能實現的成員之前沒有溝通好，就出現了使用者返回的Message不一致，命名不一致，函式名不一致等。因為是單元和整合測試，所以功能沒有實現，就沒有辦法測試功能。
就我個人來看，我們太缺少專案內團隊之間的瞭解。開發人員需要理解測試知識，這樣更有利於寫單元測試，知道測試中常常出現的問題，可以提早預防。測試學習開發知識就可以更好地做測試，更容易理解開發在那些地方容易出問題。我覺的，如果你是開發人員，那麼你除了要精通開發外，還需要懂需求和測試，這樣才能大量減少交流成本，會從專案全域性看問題。
案例3（專案團隊和“領導”之間）：
經過實訓，我意識到死命的加班對軟體這種高思維、高協作的活動意義不大，甚至起到反作用。
Example：在最後一週，專案組的所有人都知道專案不能完成，士氣低落，人員疲憊。 作為專案經理，就是保證專案如期完成。專案經理就要和管理層的領導溝通，市場人員溝通，專案經理需要有勇氣，去頂住兩層壓力； 作為專案經理，要與產品經理進行溝通，去裁剪功能，專案人員負責估時做完改功能的時間，達到預期的結果。
專案第三階段
CodeView，回顧總結，ShowCase
……
總結：敏捷開發
敏捷宣言
“個體與互動 勝於 過程與工具 ,可工作軟體 勝於 複雜文件 ,
使用者協作 勝於 合同談判 , 響應變化 勝於 遵循計劃”
擁抱變化優於循規蹈矩
敏捷開發： 5月6號騰訊宣佈對組織進行調整，提出微信理念包括使用者、價值觀、敏捷開發、迭代、系統思維、口碑、思辨等。 我覺得敏捷開發是網際網路產品發展的更好形式，也是方向。最近剛剛接觸到這方面，提到敏捷開發，極限程式設計很重要。TDD是是敏捷開發中的一項核心實踐和技術，它強調的是測試先行原則。如果你沒有想清楚怎樣實現功能，TDD可以幫助你進步的。
一個敏捷開發的團隊多少人最合適呢？ 在這個問題上，Scrum（敏捷專案管理理念與方法之一）給出建議，對於團隊組建“兩塊披薩”人數足以，也就是4到9個人。我們團隊是五個人，有五種角色，五種職責（技術指導、專案經理、產品經理、Git專家、效率專家）。Scrum的一個精髓是“15分鐘會議”。我們在專案進行的時候每天也開站會，是“5分鐘會議”。我認為這和我們做的專案大小，個人能力產物有關，特別是遇到的問題，更重要的是我們在適應階段，大家有抵觸心理，每次都需要老師或者專案經理去提醒或者組織監督，所以壓縮時間，越快越好。大家團隊成員每天在相同的時間、相同的地方開會，開會時開啟Trello看板，看著自己做的卡那一欄目，會上只討論三個問題：你，昨天做了什麼、今天準備幹什麼、遇到哪些問題。 站會有助於我們去了解團隊每個人的進度，去交流，去解決問題。
在開發中程式設計知識其實只佔了很少一部分，之前我最頭疼的就是寫程式碼，不僅要注意很多的規則，還要想出策略，還要統籌整個框架。這樣往往導致很疲憊，工作效率低。敏捷開發很好的解決了這個問題。
敏捷開發也許不是最好的，最普遍的，但在整個發展階段，它是一個符合現有邏輯的產物。