初識敏捷

背景:在預測型項目中是否遇到計劃趕不上變化快？遲遲無法向客戶交付產品或項目？交付后因與客戶設想的需求不同，導致頻繁改動，團隊士氣、客戶信任度嚴重超支！

身為項目負責人、產品經理、技術負責人的你我遇到上述情況有種回天乏術的感覺？

敏捷的出現，讓我們看到一絲曙光。敏捷是一種理念或者說一種理想，也正是你我在項目中所追求的理想環境，不是嗎？

現在，我們聊一聊敏捷。

在遙遠的過去，軟件者的先驅們，采用瀑布式或預測型項目管理，在研發過程中，花費大量的時間和精力在前期需求信息的收集和確定，然后再去開發，并在開發過程中未交付任何或交付少量的里程碑，軟件交付日即團隊的磨難開始。

終于先驅們在經歷無數次“這不是我想的那樣”、“$@#%$”、"這是什么垃圾，完全不對，我們不接受"等之類的反饋時，先驅者們提出“是否有一種新的編程方式？基于這種方式，讓軟件開發進度、質量、客戶滿意度更好！解放深耕軟件開發的碼農們，讓大伙有更多的時間去做自己想做的事情”。

于是2001年在2月份，漫天飛雪的情況下，一群先驅劃著雪，交流著。最終《敏捷宣言》橫空出事了。

“個體和互動 高于 流程和工具”

"工作/可用的軟件 高于 詳盡的文檔"

“客戶合作 高于 合同/商務談判”

“響應更改/變化 高于 遵循規范/計劃”

可以總結為：

1.以人為本：尊重每一個個體，重視個體間的合作互動

2.以目標/最終交付結果未導向，最終交付的是可使用的軟件（相信我，可用的軟件是堵住客戶嘴巴最好的方法。文檔......不浪費A4紙嗎？不浪費磁盤存儲空間嗎？）

3.客戶為先：理解客戶需求，與客戶合作（天平要始終平衡，偏向研發會引起大量客戶無法理解操作的邏輯，偏向客戶：虧大家都吃過，不贅述，寫到這里，忍不住摸一把眼淚，我太難了。）

4.擁抱改變：基于第三條，客戶實在不斷變化的需求中，明了自己想要的，因此研發團隊要擁抱變化。（別鉆牛角尖，有人反駁“比白色更白、五彩斑斕的黑”這些梗不討論）

文檔還是需要滴，畢竟可用的軟件+規范的文檔，會讓客戶對我們更信任，只是我們應該更關注人、產品模型、寫作和迭代。只有隨時有成品（原型、功能）交付給客戶/項目委員會，才能更好的讓項目進行下去，才會將編碼工作更好的最大利益化。

講到這里，筆者不禁要說上幾句廢話“時間、質量、成本、上級滿意度、客戶滿意度”IE思想不僅僅適用于工廠，同樣適用于軟件行業，這幾條決定我們是否能更好的實現“理想的生活、生活的理想”.......別告訴我，你做軟件是為了興趣等空話，至少筆者目前的覺悟無法達到這種高度。

敏捷原則：

1.我們最重要的目標，是通過持續不斷地及早交付有價值的軟件是客戶滿意。

根據GTD四象試圖，“緊急的但不重要的、緊急但重要的、重要但不緊急的、不重要不緊急的”這種方式，管理生活、工作，發現會很有用，至少對我來說，收獲不錯。敏捷中采用迭代事項按照優先級安排、限制WIP、看板、故事卡等方式，為客戶盡早提供有價值的功能。同過頻繁的刺探和客戶的反饋來及時調整研發方向，提高程序的質量，建立客戶滿意度及客戶利益最大化。

敏捷小組關注完成和交付有價值的功能，而不是鼓勵的任務。基于“作為【用戶類型\需求】，我們希望可以【專業技能/能力】以便實現【業務價值】”的故事方式來分析挖掘需求，原型和文檔也會需要編寫，也是一種交付，只是更多的工作重點，轉到口頭交流、看板、迭代工具、每日批斗會（手抖，打錯了，每日站會。國內大部分都是批斗會，別問我怎么知道的.....）。

2.即使在研發后期，也歡迎更改需求。敏捷過程利用變化來為客戶創造競爭價值。

敏捷者不怕變化，只有通過更改需求，才讓我們更好的理解市場，成為獨角獸，搶占市場份額。（企業做好了，參與者自然....當一天和尚撞一天鐘這種想法地人，實際上在蹉跎光陰，趁早改行，不接受任何反駁。）

3.經常性的交付可以工作的軟件，交付周期可以從幾周到幾個月，交付的時間越短間隔越好。

不予玉璞示人，不適合軟件研發行業。加入這個行業，就是加入高度不確定性的工作。迭代是受實踐框架限制的，意味著要放棄一些我們認為很有創意的功能也必須按時結束迭代。只要我們可以保證交付的軟件會很好的工作，那么交付時間間隔越短，我們和客戶的協助、信任度、回頭度就會大幅上升，產品質量和市場實用性就會更有益。

“需求、分析、迭代、實施、交付”在敏捷的每個迭代周期都會上演，而不是像預測型的項目，只做一次。

4.在整個項目開發周期，業務人員和開發人員必須天天在一起工作。

軟件不可能會依照之前設定的計劃原路執行，中間對業務的理解、軟件的解決方案肯定會存在偏差，所以客戶、需求人員、開發人員以及涉眾之間必須進行有意義、頻發的交互，這樣在早期就可以及時的發現并解決問題。

筆者經歷的項目，一般會和客戶組件項目委員會，參與者有：業務、對方負責人、實際使用人等組成。避免出現負責人不是使用人，使用人不是負責人這種現象，別問什么。

只有通過不斷的刺探、不斷的交付、在一起工作，雙方理解中的差異會越來越小，軟件質量會越來越高，團隊士氣會越來越好。

5.圍繞被激勵的個人來構建項目。給他們提供所需要的環境和支持，并信任他們能夠完成工作。

看到這里，請大伙回答一個問題“團隊里面什么最重要？”答案是：“人”。

SO，碼畜、碼農都是研發人員自嘲的，企業、客戶、團隊負責人別真把研發人員當成.....。一群人，一件事，一定贏，要激勵、善于消除影響團隊士氣的因素，個人目標要和團隊目標一致，團隊也要兼顧個人目標，做到互惠互利，任何偏差都會引起風暴效應。信任、授權、平等的地位、良好的辦公環境會提高生產力！

不以人為本，以人民幣為本的時代已經過去了，身處信息時代、流動的時代要想辦法留住該留的人、淘汰該淘汰的人、沉淀該沉淀文化氛圍，才能把利益最大化.....扯遠了，回歸主題。

6.在團隊內部，最具有效果并且富有效率的傳遞信息的方法，及時面對面的交談。

筆者每周往返于分部和總部進行溝通，原本一周可以完成的跌打，硬生生拖到兩周以上。效率太低了。好在最近要進行集中辦公。

說到集中辦公，敏捷提倡9人左右的團隊集中辦公，面對面的交流，效率從經濟學角度來說，是相當有回報的。

7.工作的軟件是首要進度度量的標準。

用戶是否可以使用、用戶滿意度如何，是首位。筆者在一個長達8年的電商平臺項目中，團隊貫徹的理念，始終是“功能可用、用戶體驗度友好”為首要衡量標準。

我見過，也帶過前端、后端、DB的小伙伴，我發現有兩個極端：1.只管做，不注重結果/質量。2.保質保量。最終給產品帶來的市場反饋是完全兩個樣子。沒有測試通過，寫在多行代碼，在怎么厲害的算法都是無用。質量始終是首位！

8.敏捷過程提倡可持續的開發速度。責任人、開發、用戶應該能夠保持一個長期的、恒定的開發速度。

什么是可持續性的開發速度？要理解持續這兩個字，國內流行風氣”996“、加加班辛苦一下、突擊一下等等這種觀念。

”昨天為什么你不加班，其他同事都加班了“

”咳，老板，加班會影響我心情、影響我心情會影響我的效率“。

不僅讓我想到，曾遇到過的一位小伙和BOSS的對話，最終結果，小伙跳槽，薪水客觀。老板目前苦苦支撐。

一個項目指望加班、不切實際拍腦袋決定工期，其質量、可用性、團隊士氣都會大大折扣。筆者提倡”計劃-執行-反饋“，日日請，事事清這種工作氛圍，才是可持續性、健康的氛圍。

9.不斷地關注優秀的技能和好的設計會增強敏捷能力。

GITHUB、開源項目、敏捷方法等有很多好的技術實踐，可以增強產品的敏捷能力和健壯性。很多的原則、模式和實踐也可以增強敏捷開發能力。

”實踐是檢驗真理的唯一方法“、”要想知道梨子的味道，你必須咬一口“，多么真摯的感悟。

10.簡介文本....極力減少不必要的工作量的藝術。

后期的需求如何變化，我們不得而知。所以不可能一開始就構建一個完美的架構來適應以后的所有變化，事實上也不可能做到。筆者經常給組員灌輸“一個中等的實現方法需要30分鐘，一個優等的實現方法需要3個小時，那么，要毫不猶疑的選擇前者。”

也曾見過，一位小伙遲遲無法交付任務，仔細詢問得知，“我在考慮該模塊對最后期模塊的影響”，這種做法，不能夠說是錯誤的。但，試問一下，當下的模塊都無法交付，那有必要考慮一下這種工作方式對后期迭代的影響了。

贏在當下，如果明日那個問題很簡單，明天可以很好解決，SO，那就留給明天。如果明日的問題很復雜，那也請留給明天，完成今日任務。

11.最好的架構、需求、設計出自組織團隊。

筆者曾有一個想法“每日上班后，組員相互詢問是否需要協助、自發的處理任務、扁平化管理模式、沒有等級之分”，后細思極恐，容易出現信任危機，無人對分歧決策、無人對結果負責。

雖然敏捷小組是以小組為整體工作的，但也需要一些人來承擔一定任務的角色；產品負責人、架構師、UI設計師、程序員、需求人員、測試人員、文檔撰寫者等，還需要一個團隊促進者，項目經理、SCRUM主管、項目團隊等領導或者團隊敏捷教練。但這么多角色，要時刻關注仆人式領導而非脫離群眾高高在上。

12.每個一定的時間，團隊會在如何才能更有效的工作方面進行反省，然后相應的對自己的行為做出改變。

很多不利因素會時刻導致計劃的失敗，如成員減員、技術應用效果、用戶需求更改等都會對我們造成影響，也會迫使我們做出相應的改變。

敏捷不是基于預定義的模式工作，則是基于經驗性的方式，對以上這項變化，需要小組一起不斷的“反省”來調整保持團隊的敏捷性。

常用的敏捷實踐方式有：Scrum、XP極限編程、水晶、DSDM動態系統開發、FDD功能驅動開發、BDD、AUP敏捷統一過程、精益（IE）、看板、OpenUp等，快看看你用了哪一種？