|
敏捷開發(fā)在軟件開發(fā)領(lǐng)域越來越受到歡迎,。它的優(yōu)點(diǎn)顯而易見：靈活定義需求、所見即所得,、迭代的開發(fā)和測試,、軟件任何時(shí)候都在可用狀態(tài)、資源利用高效,、提高軟件質(zhì)量等等,。但是，是否所有的軟件項(xiàng)目或者團(tuán)隊(duì)都適合使用敏捷開發(fā)模型呢,？答案顯然是否定的,。 今天和大家分享一個(gè)案例，背景是：公司高層對之前的軟件質(zhì)量和資源使用效率不甚滿意,，想推行敏捷開發(fā)模型,。項(xiàng)目的性質(zhì)是軟硬件協(xié)同項(xiàng)目，即軟件產(chǎn)品的很多功能需要在硬件產(chǎn)品上面驗(yàn)證和運(yùn)行,。 老板在某個(gè)軟件版本啟動會議上宣布即將采取敏捷模型,，項(xiàng)目經(jīng)理開始撓頭皮，因?yàn)轫?xiàng)目的干系人對于敏捷開發(fā)的概念不甚了解,。開發(fā)團(tuán)隊(duì)還算是好的,，因?yàn)橛泻芏嗤夤蛦T工在之前的項(xiàng)目中曾經(jīng)接觸過敏捷開發(fā)。這個(gè)苦了測試和商務(wù)團(tuán)隊(duì),，敏捷開發(fā)對于他們來說純粹是一個(gè)“新潮”的概念,。不要說敏捷開發(fā)，就是軟件開發(fā)瀑布模型也是做了幾個(gè)發(fā)布以后才慢慢熟悉起來的,。 老板宣布意味著這個(gè)版本必須要使用敏捷模型,，行也得行，不行也得行,。更要命的是,，質(zhì)量不能含糊—軟件發(fā)布以后，客戶的投訴不能上升,，并且還要看到顯著的下降；資源不能含糊—不可以使用更多的資源,，不可以有更多的加班,。否則老板使用敏捷開發(fā)的目的就沒有達(dá)到！這個(gè)難題如何破解,。 千絲萬縷中,，我們發(fā)覺對于這個(gè)項(xiàng)目和這個(gè)團(tuán)隊(duì)來說，首先要做的是溝通計(jì)劃,。因?yàn)橹饕上等藢τ谌绾螌?shí)施敏捷開發(fā)還沒有一致意見,！ 溝通計(jì)劃和管理 溝通計(jì)劃主要包括： 1. 敏捷開發(fā)模型介紹,。 很多概念比如sprint、backlog等等對于測試團(tuán)隊(duì)來說都是全新的,。市場部,、售后服務(wù)部等干系人對于這些概念更是聞所未聞。這里要指出,，當(dāng)時(shí)的溝通計(jì)劃雖然提到了sprint和backlog的概念,，但是沒有定義清楚timebox。導(dǎo)致后來項(xiàng)目的實(shí)施碰到了不小的爭執(zhí),。在“進(jìn)度定義和管理”中詳細(xì)說明,。 2. 敏捷開發(fā)角色定義,。Scrum Master, product owner, team member的職責(zé)和責(zé)任要定義清楚,。Product owner必須在SPRINT評審之前非常明確自己要干什么 有了溝通計(jì)劃,，項(xiàng)目實(shí)施會順暢很多,。但“跨國”,、“軟硬件協(xié)同”等性質(zhì)還是在實(shí)施過程中碰到了諸多的實(shí)際問題,。本文從范圍,、進(jìn)度,、質(zhì)量等方面做一些分享,。 范圍定義和管理 1. 需求說明書如何集成到流程中 正宗的敏捷開發(fā)應(yīng)該是不需要需求說明書就可以開工的,。敏捷開發(fā)的宗旨之一就是去掉繁冗的文檔審批流程，讓用戶和開發(fā)人員直接接觸并定義出一個(gè)短時(shí)期的可交付成果,。雙方都認(rèn)可就行了,，甚至不需要一個(gè)文檔和簽字流程。但事實(shí)是,，第一,，沒有這樣自我嚴(yán)格控制的開發(fā)人員。第二,，需求沒有清楚到兩個(gè)人一拍即合,。有的需求是隱形的，比如性能要求,，你不規(guī)定我就不做,。第三，用戶不是某一個(gè)特定客戶,，不可能把用戶直接請過來,。在這個(gè)項(xiàng)目中，“用戶”主要是市場部的代表和售后服務(wù)部門的代表,。結(jié)合項(xiàng)目的實(shí)際,，我們做了一個(gè)妥協(xié)：項(xiàng)目需求說明書還是需要的，在進(jìn)入每個(gè)SPRINT之前必須定義清楚本SPRINT需要完成的工作,，并且有各方（開發(fā),、測試,、干系人）管理團(tuán)隊(duì)的簽字認(rèn)可。和以前的區(qū)別是,，不需要在項(xiàng)目一開始定義所有SPRINT的需求,，因?yàn)槿齻€(gè)月后的事情現(xiàn)在還說不清楚。這個(gè)也算是一個(gè)進(jìn)步吧,。不過,，需求的討論變得頻繁了，以前每半年（一個(gè)版本）一次,，現(xiàn)在每個(gè)月一次（SPRINT）,。 進(jìn)度定義和管理 1. SCRUM 會議 敏捷開發(fā)中的SRUM會議每天都要做。這個(gè)跨國項(xiàng)目,，有中美各方參與,。如果定義SCRUM會議的參與方和時(shí)間呢？大家都不想晚上過多開會,。如果每天SCRUM加上所有的干系人,，顯然晚上的會議是無法避免的。由于這個(gè)項(xiàng)目的開發(fā)團(tuán)隊(duì)和大部分的測試團(tuán)隊(duì)都在中國,，我們定義中國的白天每天早上九點(diǎn)準(zhǔn)時(shí)SCRUM,，這個(gè)會議美國團(tuán)隊(duì)是選擇性參加—即想?yún)⒓硬⑶矣袝r(shí)間就來，沒時(shí)間不方便可以不來,。會議紀(jì)要每天都發(fā),，如果美國團(tuán)隊(duì)有意見可以通過電子郵件溝通。每周五上午的SCRUM約定為全球都要參與,。美國團(tuán)隊(duì)至少每周一次,，主要討論的議題是重要的話題，比如timebox的關(guān)閉,、是否有重大缺陷導(dǎo)致無法繼續(xù)測試等等,。 SCRUM會議還有一個(gè)重要任務(wù)就是重新安排資源。由于每天跟進(jìn),，SCRUM MASTER很好的掌控實(shí)際進(jìn)度,，他有權(quán)限微調(diào)各個(gè)部分的資源，做到最優(yōu)分配,，削峰平谷,。以滿足老板的第一個(gè)期望（節(jié)約資源） 2. Timebox的結(jié)束 在溝通管理中提到了，Timebox的關(guān)閉一開始沒有定義清楚,。于是有了一場爭論。在某個(gè)SPRINT中,，開發(fā)團(tuán)隊(duì)由于技術(shù)原因,，定義的某個(gè)BACKLOG工作項(xiàng)無法完成,。測試團(tuán)隊(duì)以這個(gè)SPRINT沒有完成為由，拒絕繼續(xù)測試,。而當(dāng)時(shí)項(xiàng)目的整體進(jìn)度上測試就是關(guān)鍵路徑,。一天都不能耽擱，停工一天就意味著項(xiàng)目的延宕,。軟硬件結(jié)合項(xiàng)目,，結(jié)束日期是死的。如果延宕,，就意味著硬件的出貨要延宕,，對于項(xiàng)目來說，就是“死”,！開發(fā)團(tuán)隊(duì)認(rèn)為Timebox結(jié)束了就結(jié)束了,，即使有東西沒有完工，也應(yīng)該進(jìn)入下一個(gè)SPRINT,。沒有完工的東西順延到下一個(gè)SPRINT,，并且調(diào)整下一個(gè)SPRINT的范圍定義，即可以少做一些功能,。最終,，進(jìn)過漫長和艱苦的討論，測試才同意繼續(xù)測試,。但是這個(gè)爭論原本不必要,，只要雙方在項(xiàng)目前期做了約定即可。 質(zhì)量定義和管理 1. 質(zhì)量度量標(biāo)準(zhǔn) 對于本項(xiàng)目,，質(zhì)量度量標(biāo)準(zhǔn)定為總得缺陷數(shù)和缺陷生命周期以及缺陷曲線形態(tài),。因?yàn)榉秶x更加確切，所以從管理層期望更少的缺陷和更及時(shí)的修復(fù),?？?cè)毕輸?shù)不必解釋，生命周期代表一個(gè)缺陷從發(fā)現(xiàn)到修復(fù)的時(shí)間周期,，敏捷開發(fā)的周期應(yīng)該更短,。傳統(tǒng)的模型中缺陷數(shù)形態(tài)有一個(gè)上升期和一個(gè)下降期，像一座小山,。敏捷開發(fā)的模型期望缺陷是以一個(gè)相對均勻的速度被發(fā)現(xiàn)并被修復(fù),。道理很簡單，做多少,，測多少,，完成多少。不是一股腦先做，再測,，修復(fù),，完成。 2. 發(fā)現(xiàn)缺陷曲線異常的應(yīng)對措施 SCRUM MASTER需要監(jiān)控缺陷曲線,。一旦發(fā)現(xiàn)缺陷有上升勢頭,，并且持續(xù)3天以上，SCRUM會議上他就會逐個(gè)定義缺陷的應(yīng)對措施,，并限期修改,。把項(xiàng)目從做新需求轉(zhuǎn)向到專注修復(fù)目前的缺陷。這種及時(shí)的調(diào)整保證項(xiàng)目的質(zhì)量始終在一個(gè)可控的范圍,?？?cè)毕輸?shù)的下降，意味著在測試方法不變的情況下,，將有更少的缺陷流入到用戶手中,。這樣將顯著提高項(xiàng)目的滿意度。完成管理層的第二個(gè)目標(biāo)（提高質(zhì)量）,。 綜上,，以上的一些考慮和實(shí)踐保證了“跨國”、“軟硬件協(xié)同”項(xiàng)目初步實(shí)施了敏捷開發(fā)并且滿足了管理層的一些基本考慮,。在以后的工作中需要不斷總結(jié)和交流,，把一些深層次的問題予以解決。（比如團(tuán)隊(duì)的士氣,、自我激勵,、流水線形態(tài)的開發(fā)—知人善任等等） |
|
|
