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