您的位置:軟件測試 > 軟件項(xiàng)目管理 > 進(jìn)度管理 >
成功的軟件管理方式:指導(dǎo)與平衡
作者:網(wǎng)絡(luò)轉(zhuǎn)載 發(fā)布時(shí)間:[ 2013/5/22 13:37:00 ] 推薦標(biāo)簽:

成功的現(xiàn)代項(xiàng)目——以及使用傳統(tǒng)過程開發(fā)的成功項(xiàng)目——通常都有詳細(xì)定義的項(xiàng)目階段性標(biāo)志,即從創(chuàng)造性研究狀態(tài)到生產(chǎn)狀態(tài)的顯著過渡。早期階段著重于實(shí)現(xiàn)可演示的功能。后期階段著重于實(shí)現(xiàn)可供用戶使用的產(chǎn)品,這種產(chǎn)品關(guān)注的是健壯性、性能、適用性以及完整性。

另一個(gè)重要方面是從創(chuàng)造性世界到生產(chǎn)世界的過渡對整個(gè)團(tuán)隊(duì)的影響。結(jié)構(gòu)良好的團(tuán)隊(duì)通常不喜歡嚴(yán)格的過程、細(xì)節(jié)以及不成熟的精確性。生產(chǎn)能力強(qiáng)的團(tuán)隊(duì)通常會對松散的、不固定的、粗糙的結(jié)果感到不愉快。項(xiàng)目管理者需要管理各種團(tuán)隊(duì)的平衡性,這樣技術(shù)上領(lǐng)導(dǎo)的重力中心可以在整個(gè)生存周期發(fā)展進(jìn)化,從初始階段的管理團(tuán)隊(duì),到細(xì)化階段的架構(gòu)團(tuán)隊(duì),到建構(gòu)階段的開發(fā)團(tuán)隊(duì),再到過渡階段的測試/評估團(tuán)隊(duì)。軟件項(xiàng)目管理中人的因素被低估了,而且團(tuán)隊(duì)動態(tài)性的主題值得被給予比大多數(shù)項(xiàng)目管理課程所給予的更多的關(guān)注。

進(jìn)展

經(jīng)典開發(fā)過程的很多方面造成了涉眾關(guān)系退化到相互間的不信任。信任對在用戶需要、產(chǎn)品特性以及計(jì)劃中通過指導(dǎo)和協(xié)商取得平衡是基本的。迭代過程加強(qiáng)了涉眾間的有效交流(通過一系列可演示的發(fā)布實(shí)現(xiàn)),允許基于更為客觀的所有人理解的協(xié)商。這需要客戶、用戶、以及管理者集中于可用系統(tǒng)的發(fā)布,而不是篤信標(biāo)準(zhǔn)和合同條款。它同時(shí)還需要開發(fā)組織致力于用能獲得利潤的方式創(chuàng)造價(jià)值。

迭代過程需要對一個(gè)不斷完整的系統(tǒng)進(jìn)行順序的建構(gòu),這個(gè)系統(tǒng)展示了架構(gòu),實(shí)現(xiàn)了客觀的需求協(xié)商,證實(shí)了技術(shù)方法,并指出關(guān)鍵風(fēng)險(xiǎn)。理想的情況下,所有涉眾都著眼于這些里程碑,把它們視為有用功能的遞增發(fā)布,這不同于那些投機(jī)的對終觀點(diǎn)的論文描述。向可演示驅(qū)動的生存周期的過渡造成了非常不同的項(xiàng)目外觀。一個(gè)健康的項(xiàng)目將誠實(shí)地展示出一個(gè)進(jìn)展與背離共存的序列,而不是一個(gè)線性發(fā)展價(jià)值遞增的軌跡(通常是不誠實(shí)的)。

下面是兩個(gè)我從未見過的反例的相關(guān)觀察:

1.一個(gè)具有一張價(jià)值持續(xù)不斷增長曲線圖的軟件項(xiàng)目一定會有一個(gè)待解決的很大的回歸。
2.在解決不確定性,會師于一個(gè)可接受的解決方案的過程中,健康的軟件項(xiàng)目表現(xiàn)為一個(gè)進(jìn)展不斷增加,彎路不斷減少的序列。

雄心勃勃的展示是一個(gè)健康的項(xiàng)目的發(fā)展道路上絕好的里程碑。在生存周期早期進(jìn)行展示的目的是暴露設(shè)計(jì)缺陷,不是粉飾門面。涉眾不應(yīng)對早期錯(cuò)誤、背離或不成熟的設(shè)計(jì)反應(yīng)過激。如果早期工程階段受到過分限制,開發(fā)組織建立的中間檢查點(diǎn)將不會那么有抱負(fù)。早期的增量是不成熟的。外界涉眾,比如客戶和用戶,不能指望初始發(fā)布的版本擁有終發(fā)布版本的規(guī)格和性能——也是完整、完全可靠、擁有目標(biāo)級的質(zhì)量和性能。

另一方面,開發(fā)組織必須對連續(xù)增量之上的切實(shí)的進(jìn)展負(fù)責(zé),并對之進(jìn)行展示?陀^地量化變化、修改以及更新將會為進(jìn)展和質(zhì)量提供誠實(shí)的指示。公開和專心的追隨對解決問題是必須的。好的和不好的項(xiàng)目性能在生存周期的早期往往更為明顯。采用指導(dǎo)式的領(lǐng)導(dǎo)方式,成功會孕育成功。在發(fā)布一系列可演示的結(jié)果以后,你可以很好地預(yù)測結(jié)果了。持續(xù)沒有進(jìn)展或者停滯的結(jié)果序列是項(xiàng)目需要認(rèn)真重新考慮資源、范圍或者項(xiàng)目價(jià)值的標(biāo)志。軟件項(xiàng)目的經(jīng)驗(yàn)已多次表明,早期階段決定項(xiàng)目的成敗。這是使用小型的、能力強(qiáng)的出發(fā)團(tuán)隊(duì)處理計(jì)劃和架構(gòu)設(shè)計(jì)階段工作的原因。如果這些早期階段處理得當(dāng),項(xiàng)目將會由能力中等規(guī)模的團(tuán)隊(duì)向終產(chǎn)品發(fā)展,并成功完成。如果計(jì)劃和架構(gòu)設(shè)計(jì)階段處理不好,即使出動全世界的程序和測試專家可能也無法在后續(xù)階段取得成功。

質(zhì)量控制

如果你按照迭代開發(fā)的精神正在成功管理一個(gè)項(xiàng)目,那么多數(shù)集成測試應(yīng)在部件測試之前進(jìn)行。停下來思考這一陳述。盡管在任何時(shí)候都有兩種活動在混合進(jìn)行,你應(yīng)該認(rèn)識到初始的部件開發(fā)和測試更多的是作為在一個(gè)集成的、系統(tǒng)級的線程或行為內(nèi)執(zhí)行一個(gè)部件的接口和功能的方法。一旦接口和集成行為被成功測試,部件的完整性也可以測試了。先進(jìn)行集成測試加速了架構(gòu)上重要的問題更早進(jìn)入生存周期的相應(yīng)階段。它還為持續(xù)的系統(tǒng)級和部件級進(jìn)展和性能的評估提供了演進(jìn)的測試模板。

這種先進(jìn)行集成測試的方法的一個(gè)關(guān)鍵副產(chǎn)品是測試和測試人員成了項(xiàng)目過程中的頭等公民。在傳統(tǒng)方法中,測試人員建立計(jì)劃、過程和文檔,它們都是次要于分析和設(shè)計(jì)工件的。測試人員的工作和生存周期早期的工件對項(xiàng)目的成功沒有太多指示作用,在多數(shù)組織內(nèi)都是由“B選手”(意思是,不能成為分析和設(shè)計(jì)師的人)來完成的。在健康的迭代項(xiàng)目中,生存周期早期的演示需要重要的測試觀念和產(chǎn)品。很多測試團(tuán)隊(duì)對一些有效的“分析”活動和結(jié)果負(fù)有責(zé)任。太多分析人員在抽象模型內(nèi)單獨(dú)工作,他們的分析受到的制約是有限的。但是測試人員面臨的是建立“測試用例”——真實(shí)世界中用例或者評估標(biāo)準(zhǔn)或者預(yù)期行為的表現(xiàn)。他們提出一整套不同的問題并從一個(gè)不同的角度看世界,因?yàn)樗麄兊墓ぷ魇前殉橄蟮臇|西翻譯為可測試的東西。

這是一個(gè)例子,F(xiàn)在很多項(xiàng)目都面臨著對商業(yè)上可獲得的部件和應(yīng)用程序是采取買還是自己寫的辦法的抉擇。如果第一個(gè)面向結(jié)果的項(xiàng)目的里程碑是通過演示來作出自己寫/購買的決定的,那么你應(yīng)該對你的團(tuán)隊(duì)進(jìn)行如下分工:

分析團(tuán)隊(duì):與用戶一起工作,捕捉產(chǎn)生差性能的關(guān)鍵用例的情況,比如數(shù)據(jù)量峰值或者關(guān)鍵的控制畫面。
設(shè)計(jì)團(tuán)隊(duì):設(shè)計(jì)可以運(yùn)行候選商業(yè)部件的原型。
測試團(tuán)隊(duì):構(gòu)建測試用例(比如,一個(gè)消息集合、一個(gè)測試驅(qū)動、一個(gè)智能樁模塊、一個(gè)有數(shù)據(jù)的數(shù)據(jù)庫、一個(gè)圖形用戶界面操作的序列等等)。這些用例能夠反映關(guān)鍵用例,驅(qū)動原型并記錄它的相應(yīng)。

為了實(shí)現(xiàn)這第一個(gè)里程碑,你的團(tuán)隊(duì)可以只關(guān)注其中兩個(gè)關(guān)鍵用例(約為用戶需要的10%)、少數(shù)幾個(gè)關(guān)鍵部件以及少數(shù)幾個(gè)測試用例,但是它們以及用戶將會在生存周期非常早的時(shí)候解決掉30%的風(fēng)險(xiǎn)。通過把測試觀點(diǎn)作為過程早期一個(gè)同等伙伴包括進(jìn)來,你將可以吸引更多作出更好分析的人才,因?yàn)檫@項(xiàng)工作更為有趣,而且對成功的貢獻(xiàn)更為有效。

傳統(tǒng)軟件測試方法遵循相同的、應(yīng)用于軟件開發(fā)的文檔驅(qū)動方法。開發(fā)團(tuán)隊(duì)在建立任何源文件或可執(zhí)行文件之前先建立需求文檔、頂層設(shè)計(jì)文檔以及詳細(xì)設(shè)計(jì)文檔。相似地,測試團(tuán)隊(duì)在建立任何測試驅(qū)動、樁模塊或工具之前先建立系統(tǒng)測試計(jì)劃文檔,系統(tǒng)測試過程文檔、集成測試計(jì)劃文檔、單元測試計(jì)劃文檔以及單元測試過程文檔。這一文檔驅(qū)動方法對測試活動造成的問題與它對開發(fā)活動造成的問題是相同的:對大量廢物的刨光,還要留待日后重新組合整理。

為了在生存周期中提早進(jìn)行集成測試,測試序列應(yīng)該由迭代過程來組織,而不是根據(jù)部件來組織。典型地,它應(yīng)該被一組用例和其它文本表現(xiàn)的、能有意義地為用戶進(jìn)行演示的實(shí)體所捕獲。下面是一個(gè)抽象的描述:

初始迭代:大約五到十個(gè)評估標(biāo)準(zhǔn),抓住與主要用例(對結(jié)構(gòu)選擇和整體商業(yè)案例有影響的)相關(guān)的驅(qū)動問題。
細(xì)化迭代:十幾個(gè)評估標(biāo)準(zhǔn),當(dāng)用候選架構(gòu)進(jìn)行演示時(shí),為主要用例檢驗(yàn)實(shí)體框架,并證明關(guān)鍵風(fēng)險(xiǎn)已經(jīng)被解決了。
構(gòu)建迭代:大約數(shù)百個(gè)與有意義的用例集相關(guān)的評估標(biāo)準(zhǔn),這些用例集通過測試以后將組成有用的產(chǎn)品子集,可以轉(zhuǎn)為產(chǎn)品的alpha或beta發(fā)布版本。
產(chǎn)品化迭代:完整的用例集和相關(guān)的評估標(biāo)準(zhǔn)(可能有上千個(gè)),組成了與真正發(fā)布產(chǎn)品相關(guān)的接受測試結(jié)果的標(biāo)準(zhǔn)。

現(xiàn)代過程在產(chǎn)品的測試活動中使用的基本工具、語言、符號以及工件與在產(chǎn)品的開發(fā)過程中使用的是相同的。測試是指對某些組件在一個(gè)控制情境下的執(zhí)行以及期望的客觀結(jié)果的外在評估。一個(gè)測試的成功取決于在一般意義上定義的成功標(biāo)準(zhǔn)下期望結(jié)果與實(shí)際結(jié)果的比較情況。測試是可以大規(guī)模自動化由機(jī)器完成的評估形式。

上一頁1234下一頁
軟件測試工具 | 聯(lián)系我們 | 投訴建議 | 誠聘英才 | 申請使用列表 | 網(wǎng)站地圖
滬ICP備07036474 2003-2017 版權(quán)所有 上海澤眾軟件科技有限公司 Shanghai ZeZhong Software Co.,Ltd