初識敏捷

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

身為項目負(fù)責(zé)人、產(chǎn)品經(jīng)理、技術(shù)負(fù)責(zé)人的你我遇到上述情況有種回天乏術(shù)的感覺？

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

現(xiàn)在，我們聊一聊敏捷。

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

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

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

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

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

“客戶合作 高于 合同/商務(wù)談判”

“響應(yīng)更改/變化 高于 遵循規(guī)范/計劃”

可以總結(jié)為：

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

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

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

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

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

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

敏捷原則：

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

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

敏捷小組關(guān)注完成和交付有價值的功能，而不是鼓勵的任務(wù)?；凇白鳛椤居脩纛愋蚛需求】，我們希望可以【專業(yè)技能/能力】以便實現(xiàn)【業(yè)務(wù)價值】”的故事方式來分析挖掘需求，原型和文檔也會需要編寫，也是一種交付，只是更多的工作重點，轉(zhuǎn)到口頭交流、看板、迭代工具、每日批斗會（手抖，打錯了，每日站會。國內(nèi)大部分都是批斗會，別問我怎么知道的.....）。

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

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

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

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

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

4.在整個項目開發(fā)周期，業(yè)務(wù)人員和開發(fā)人員必須天天在一起工作。

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

筆者經(jīng)歷的項目，一般會和客戶組件項目委員會，參與者有：業(yè)務(wù)、對方負(fù)責(zé)人、實際使用人等組成。避免出現(xiàn)負(fù)責(zé)人不是使用人，使用人不是負(fù)責(zé)人這種現(xiàn)象，別問什么。

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

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

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

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

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

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

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

說到集中辦公，敏捷提倡9人左右的團(tuán)隊集中辦公，面對面的交流，效率從經(jīng)濟(jì)學(xué)角度來說，是相當(dāng)有回報的。

7.工作的軟件是首要進(jìn)度度量的標(biāo)準(zhǔn)。

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

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

8.敏捷過程提倡可持續(xù)的開發(fā)速度。責(zé)任人、開發(fā)、用戶應(yīng)該能夠保持一個長期的、恒定的開發(fā)速度。

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

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

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

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

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

9.不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計會增強敏捷能力。

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

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

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

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

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

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

11.最好的架構(gòu)、需求、設(shè)計出自組織團(tuán)隊。

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

雖然敏捷小組是以小組為整體工作的，但也需要一些人來承擔(dān)一定任務(wù)的角色；產(chǎn)品負(fù)責(zé)人、架構(gòu)師、UI設(shè)計師、程序員、需求人員、測試人員、文檔撰寫者等，還需要一個團(tuán)隊促進(jìn)者，項目經(jīng)理、SCRUM主管、項目團(tuán)隊等領(lǐng)導(dǎo)或者團(tuán)隊敏捷教練。但這么多角色，要時刻關(guān)注仆人式領(lǐng)導(dǎo)而非脫離群眾高高在上。

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

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

敏捷不是基于預(yù)定義的模式工作，則是基于經(jīng)驗性的方式，對以上這項變化，需要小組一起不斷的“反省”來調(diào)整保持團(tuán)隊的敏捷性。

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