敏捷開發簡介

2021-09-05 17:52:10 字數 3153 閱讀 4495

前幾天和同事們去西交大做校園宣講,當然我是去幫忙加旁聽的。:-)  hr和同事們介紹了很多關於公司的情況,包括文化,價值觀,敏捷開發等等,很多東西我都是第一次學習到,後來我對馬同學說,你那富有激情的關於公司的敏捷介紹讓我收穫很大,他說我這句話給他很大的鼓舞,呵呵。

下面我將馬同學的講解簡單介紹一下,首先看下面這個圖:

這兩個圓圈表示不同的視角上的敏捷實踐,包括開發者視角和專案管理的視角。接下來從裡向外進行介紹,因為有些實踐我了解得不清楚,如果下面有哪些說得不對的地方也請大家指出。

test-driven development,測試驅動開發,它是敏捷開發的最重要的部分。在thoughtworks,我們實現任何乙個功能都是從測試開始,首先對業務需求進行分析,分解為乙個乙個的story,記錄在story card上。然後兩個人同時坐在電腦前面,乙個人依照story,從業務需求的角度來編寫測試**,另乙個人看著他並且進行思考,如果有不同的意見就會提出來進行討論,直到達成共識,這樣寫出來的測試**就真實反映了業務功能需求。接著由另乙個人控制鍵盤,編寫該測試**的實現。如果沒有測試**,就不能編寫功能的實現**。先寫測試**,能夠讓開發人員明確目標,就是讓測試通過。

continuous integration,持續整合。在以往的軟體開發過程中,整合是一件很痛苦的事情,通常很長時間才會做一次整合,這樣的話,會引發很多問題,比如build未通過或者單元測試失敗。敏捷開發中提倡持續整合,一天之內整合十幾次甚至幾十次,如此頻繁的整合能儘量減少衝突,由於整合很頻繁,每一次整合的改變也很少,即使整合失敗也容易定位錯誤。一次整合要做哪些事情呢?它至少包括:獲得所有源**;編譯源**;執行所有測試,包括單元測試、功能測試等;確認編譯和測試是否通過,最後傳送報告。當然也會做一些其它的任務,比如說**分析、測試覆蓋率分析等等。 在我們公司裡,開發人員的桌上有乙個火山燈用來標誌整合的狀態,如果是黃燈,表示正在整合;如果是綠燈,表示上一次整合通過,開發人員在這時候獲得的**是可用而可靠的;如果顯示為紅燈,就要小心了,上一次整合未通過,需要盡快定位失敗原因從而讓燈變綠。在持續整合上,我們公司使用的是自己開發的產品cruisecontrol

refactoring,重構。相信大家對它都很熟悉了,有很多很多的書用來介紹重構,最著名的是martin的《重構》,joshua的《從重構到模式》等。重構是在不改變系統外部行為下,對內部結構進行整理優化,使得**盡量簡單、優美、可擴充套件。在以往開發中,通常是在有需求過來,現在的系統架構不容易實現,從而對原有系統進行重構;或者在開發過程中有剩餘時間了,對現在**進行重構整理。但是在敏捷開發中,重構貫穿於整個開發流程,每一次開發者check in**之前,都要對所寫**進行重構,讓**達到clean code that works。值得注意的是,在重構時,每一次改變要盡可能小,用單元測試來保證重構是否引起衝突,並且不只是對實現**進行重構,如果測試**中有重複,也要對它進行重構。

pair-programming,結對程式設計。在敏捷開發中,做任何事情都是pair的,包括分析、寫測試、寫實現**或者重構。pair做事有很多好處,兩個人在一起**很容易產生思想的火花,也不容易走上偏路。在我們公司,還有很多事都是pair來做,比如pair學習,pair翻譯,pair做ppt,關於這個話題,錢錢同學有一篇很有名的文章對它進行介紹,名為pair programming (結對程式設計)。

stand up,站立會議。每天早上,專案組的所有成員都會站立進行一次會議,由於是站立的,所以時間不會很長,一般來說是15-20分鐘。會議的內容並不是需求分析、任務分配等,而是每個人都回答三個問題:1. 你昨天做了什麼?2. 你今天要做什麼? 3. 你遇到了哪些困難?站立會議讓團隊進行交流,彼此相互熟悉工作內容,如果有人曾經遇到過和你類似的問題,那麼在站立會議後,他就會和你進行討論。

frequent releases,小版本發布。在敏捷開發中,不會出現這種情況,拿到需求以後就閉門造車,直到最後才將產品交付給客戶,而是盡量多的產品發布,一般以周、月為單位。這樣,客戶每隔一段時間就會拿到發布的產品進行試用,而我們可以從客戶那得到更多的反饋來改進產品。正因為發布頻繁,每乙個版本新增的功能簡單,不需要複雜的設計,這樣文件和設計就在很大程度上簡化了。又因為簡單設計,沒有複雜的架構,所以客戶有新的需求或者需求進行變動,也能很快的適應。

minimal documentation,較少的文件。其實敏捷開發中並不是沒有文件,而是有大量的文件,即測試。這些測試**真實的反應了客戶的需求以及系統api的用法,如果有新人加入團隊,最快的熟悉專案的方法就是給他看測試**,而比一邊看著文件一邊進行debug要高效。如果用書面文件或者注釋,某天**變化了,需要對這些文件進行更新。一旦忘記更新文件,就會出現**和文件不匹配的情況,這更加會讓人迷惑。而在敏捷中並不會出現,因為只有測試變化了,**才會變化,測試是真實反應**的。 這時有人會問:**不寫注釋行嗎?一般來說好的**不是需要大量的注釋嗎?其實簡單可讀的**才是好的**,既然簡單可讀了,別人一看就能夠看懂,這時候根本不需要對**進行任何注釋。若你覺得這段**不加注釋的話別人可能看不懂,就表示設計還不夠簡單,需要對它進行重構。

collaborative focus,以合作為中心,表現為**共享。在敏捷開發中,**是歸團隊所有而不是哪些模組的**屬於哪些人,每個人都有權利獲得系統任何一部分的**然後修改它,如果有人看到某些**不爽的話,那他能夠對這部分**重構而不需要徵求**作者的同意,很可能也不知道是誰寫的這部分**。這樣每個人都能熟悉系統的**,即使團隊的人員變動,也沒有風險。

customer engagement ,現場客戶。敏捷開發中,客戶是與開發團隊一起工作的,團隊到客戶現場進行開發或者邀請客戶到團隊公司裡來開發。如果開發過程中有什麼問題或者產品經過乙個迭代後,能夠以最快速度得到客戶的反饋。

automated testing ,自動化測試。為了減小人力或者重複勞動,所有的測試包括單元測試、功能測試或整合測試等都是自動化的,這對qa人員提出了更高的要求。他們要熟悉開發語言、自動化測試工具,能夠編寫自動化測試指令碼或者用工具錄製。我們公司在自動化測試上做了大量的工作,包括selenium開源專案。

adaptive planning,可調整計畫。敏捷開發中計畫是可調整的,並不是像以往的開發過程中,需求分析->概要設計->詳細設計->開發->測試->交付,每乙個階段都是有計畫的進行,乙個階段結束便開始下乙個階段。而敏捷開發中只有一次一次的迭代,小版本的發布,根據客戶反饋隨時作出相應的調整和變化。

敏捷開發過程與傳統的開發過程有很大不同,在這過程中,團隊是有激情有活力的,能夠適應更大的變化,做出更高質量的軟體。

敏捷開發簡介

敏捷軟體開發宣言 n 個體和互動 勝過 過程和工具 n 可以工作的軟體 勝過 面面俱到的文件 n 客戶合作 勝過 合同談判 n 響應變化 勝過 遵循計畫 雖然右項也有價值,但是我們認為左項具有更大的價值。敏捷宣言遵循的原則 n 我們最優先要做的是通過盡早的 持續的交付有價值的軟體來使客戶滿意。n 即...

敏捷開發簡介

前幾天和同事們去西交大做校園宣講,當然我是去幫忙加旁聽的。hr和同事們介紹了很多關於公司的情況,包括文化,價值觀,敏捷開發等等,很多東西我都是第一次學習到,後來我對馬同學說,你那富有激情的關於公司的敏捷介紹讓我收穫很大,他說我這句話給他很大的鼓舞,呵呵。下面我將馬同學的講解簡單介紹一下,首先看下面這...

Scrum敏捷開發簡介

本文 scrum是一種靈活的敏捷軟體開發管理過程。這個名詞 於英式橄欖球。scrum方法由ken schwaber和 jeff sutherland 提出,它將軟體開發團隊比作橄欖球隊,全隊有明確的最高目標 發布產品的重要性高於一切。團隊高度自治,隊員們熟悉開發過程中涉及到的各種技術,緊密合作,確保...