初識敏捷

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

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

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

現在,我們聊一聊敏捷。

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

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

於是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等,快看看你用了哪一種?

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章