網(wǎng)站建設(shè)現(xiàn)在是一個(gè)信息的載體，把有用的信息傳播給需要的人。網(wǎng)站建設(shè)包括軟件。在擔(dān)任多起軟件訴訟案件專家證人的工作中，筆者注意到一個(gè)長期存在的軟件項(xiàng)目管理問題。許多失敗的項(xiàng)目，以及進(jìn)度嚴(yán)重延誤或重大質(zhì)量問題的項(xiàng)目，都是在開發(fā)過程中通過正常的進(jìn)度報(bào)告發(fā)現(xiàn)的。從各種證人證言和案件證據(jù)中可以看出。軟件工程師和一線項(xiàng)目經(jīng)理都知道自己的項(xiàng)目存在問題，但是當(dāng)這些問題第一次被發(fā)現(xiàn)時(shí)，項(xiàng)目經(jīng)理并沒有將這些問題寫入給客戶的報(bào)告和高層的狀態(tài)報(bào)告中。直到很久以后，當(dāng)嚴(yán)重的進(jìn)度延誤、質(zhì)量問題或其他重大問題真正被高層管理人員或客戶認(rèn)識到時(shí)，情況往往是不可逆轉(zhuǎn)的。

當(dāng)被問及為什么要隱藏項(xiàng)目中存在的問題時(shí)。我得到的大部分答案是，下級管理人員不希望高級管理人員看到項(xiàng)目的糟糕狀態(tài)。當(dāng)然，當(dāng)問題最終浮出水面時(shí)，底線管理人員實(shí)際上相形見絀。成功的軟件項(xiàng)目總是以更理性的方式處理項(xiàng)目中的問題。他們及早發(fā)現(xiàn)問題，組建專門的工作組來解決問題，并經(jīng)常在問題變得嚴(yán)重到無法解決之前將其控制住。敏捷方法的一個(gè)有趣特征是每天討論項(xiàng)目中的問題，團(tuán)隊(duì)軟件過程(TSP) 也是如此。

軟件項(xiàng)目的問題有點(diǎn)像嚴(yán)重的醫(yī)療問題。它們通常不會自行消失，需要許多專業(yè)的“療法”才能消除它們。軟件項(xiàng)目的問題有點(diǎn)像嚴(yán)重的醫(yī)療問題。它們通常不會自行消失，需要許多專業(yè)的“治療”才能擺脫它們。軟件項(xiàng)目啟動后，通常沒有固定、可靠的準(zhǔn)則來判斷項(xiàng)目的實(shí)際進(jìn)展速度。民用軟件行業(yè)長期以來一直使用特定的里程碑來確定項(xiàng)目進(jìn)度，例如設(shè)計(jì)完成或編碼完成。但這些里程碑也是出了名的不可靠。

軟件項(xiàng)目狀態(tài)跟蹤需要解決以下兩個(gè)不相關(guān)的問題：(1) 達(dá)到特定的、定義的里程碑； (2) 在規(guī)定的預(yù)算金額內(nèi)使用項(xiàng)目資源和資金。由于軟件項(xiàng)目里程碑和成本受到需求變更和“范圍擴(kuò)展”的影響，因此擴(kuò)大需求變更變得很重要，因?yàn)檫@些變更會影響功能點(diǎn)的總數(shù)。但是，正如本章上一節(jié)所述，一些稱為“需求波動”的需求變化并不影響功能點(diǎn)總數(shù)，而需求蠕變和需求波動往往是隨機(jī)出現(xiàn)的。需求波動比需求蠕變更難衡量，只能通過“回火分析”或程序代碼語句數(shù)與功能點(diǎn)指標(biāo)之間的數(shù)學(xué)換算來衡量。

截至2009 年，有許多自動化工具可以幫助項(xiàng)目經(jīng)理記錄項(xiàng)目里程碑報(bào)告所需的各種重要信息。這些工具能夠記錄項(xiàng)目進(jìn)度、資源、規(guī)模變化和各種項(xiàng)目問題。對于一個(gè)擁有60 年悠久歷史的行業(yè)來說，沒有一套通用或通用的項(xiàng)目里程碑來標(biāo)記項(xiàng)目的實(shí)際進(jìn)展，這多少有些令人驚訝！

我們專注高端建站，小程序開發(fā)、軟件系統(tǒng)定制開發(fā)、BUG修復(fù)、物聯(lián)網(wǎng)開發(fā)、各類API接口對接開發(fā)等。十余年開發(fā)經(jīng)驗(yàn)，每一個(gè)項(xiàng)目承諾做到滿意為止，多一次對比，一定讓您多一份收獲！