丨怎樣平衡軟件質(zhì)量與時間成本范圍關(guān)系

道該不該，或者如何；其實，這些日常項目中涉及時間、成本和范圍的問題，都離不開“軟件項目管理金三角”的掌握好這個知識點(diǎn)，學(xué)會平衡軟件質(zhì)量與時間成本范圍的關(guān)系，可以幫助你更好的駕馭項目中的各種問題，也可以幫助你更好地理解軟件工程中各個模型，尤其是瀑布模型和敏捷開發(fā)。而在軟件項目中，也有一個類似的平衡關(guān)系，就是軟件質(zhì)量（產(chǎn)品的質(zhì)量，客戶的滿意度）與范圍（需要實現(xiàn)多少功能）、時間（多久可以完成）、成本（花）四個要間的因為軟件工程的目標(biāo)就是要構(gòu)建和高質(zhì)量的軟件，所以項目的質(zhì)量是的。也就是說，“質(zhì)量”這個因素一般不會妥協(xié)，因此把“質(zhì)量”放在三角形中間，然后在時間、成項目管理其實就是項目中一系列問題的平衡和妥協(xié)，而“金三角”理論則為我們的平衡提供了理論指導(dǎo)，了解這三個因素分別對項目其他方面產(chǎn)生的影響，可以幫助你在做決策時進(jìn)行權(quán)衡取舍。當(dāng)你接手一個項目，項目的進(jìn)度、成本和范圍指標(biāo)很容易可以到。有了這些信息，你就當(dāng)項目經(jīng)理，常遇到的問題之一就是時間被壓縮，比如文章中開頭舉的例子，問我一個項目多久能完成，我按照經(jīng)驗，覺得要三個月，覺得三個月太久了，要砍到一個月就上最開始的時候，我就是據(jù)理力爭，說這不科學(xué)，肯定不行呀。說時間點(diǎn)很重要，必須要后來我學(xué)乖了，先用“金三角”知識分析了一下：希望時間是1個月，也就是說時間這條邊被縮短了，那么結(jié)果就是會影響到另兩條邊：范圍和成本，如果另外兩條邊可以調(diào)整，也不是不可以。于是再遇到這種問題，我就換了式跟溝通：“一個月也不是不行，就是我們得需求調(diào)整一下，第一個版本只能做一些功能，剩下的后面版本再加上（調(diào)整范圍）。另外面對這種臨時加需求的情況，我們也不需要直接說不能加，而是清楚的讓產(chǎn)品經(jīng)理認(rèn)識到這樣做的：進(jìn)度延期，需要的成本。如果這個功能真的太重要，可以接受延期，也不是不可以接受，那就重新制定新的項目計劃好了。瀑布模型有嚴(yán)格的階段劃分，有需求分析、系統(tǒng)設(shè)計、開發(fā)和測試等階段，通常在開發(fā)過程中不接受需求變更，也就是說，我們可以認(rèn)為瀑布模型的范圍是固定的，其他兩條邊時間和成本是變量。所以使用瀑布模型開發(fā)，如果中間發(fā)現(xiàn)不能如期完成進(jìn)度，通常選擇的方案就是延期（加前面我們說日常生活中“多、快、好、省”最多只能選兩樣，其實如何平衡好軟件質(zhì)量與時間成本范圍的關(guān)系也是一樣的道理，我們只能最多選擇兩樣，然后在另一邊或者另兩條邊去尋找平衡。02003472003510第一件事當(dāng)然是先應(yīng)用“金三角”分析一下：時間這條邊被固定了，只能一個月；功能也不能少，范圍這條邊也限制住了，那就只能在成本上想辦法了。要么一下子雇很多牛人，要么直接買一個現(xiàn)成的電子商務(wù)，然后修改。從成本角度我們還有可以去做的，比如說有同學(xué)在看完《06|（上）》這篇文章后，也想在團(tuán)隊里面推行代碼和CI，但是苦于搭建這一套git+CI的我的建議就是剛開始就沒必要自己去折騰了，買一套的企業(yè)版，加上支持的商業(yè)CI系統(tǒng)，花不了，而且可以節(jié)約大量搭建這種系統(tǒng)的時間。前面在介紹敏捷開發(fā)的時候，也提到了極限編程（eXtremeProgramming，XP），是目如果做測試好，就讓每個開發(fā)人員都做測試;如果集成測試重要，就每天都做幾次測試和集成;如果簡單的就是好，那么我們就盡可能的選擇簡單的方法實現(xiàn)系統(tǒng)功能;這些實踐幫助我們可以在短時間的迭代中，產(chǎn)生高質(zhì)量的代碼。我們用“金三角”的理論來分析一下極限編程在Sprint中的應(yīng)用。SprintSprint一個Sprint要做的內(nèi)容是確定的，相當(dāng)于成本和范圍這兩條邊都固定了，時間這條邊就成改代碼產(chǎn)生Bug，減少了大量的浪費(fèi)；其實我們在項目中也有很多地方可以借鑒這種思路，比如說寫代碼的時候，少自己造，多使用成開源或者商業(yè)組件，可以提升效率；比如把需求想清楚搞清楚再去開發(fā)，可以減少很多返工的時間成本！MVP這些年流行的MVP（minimumviableproduct，最小化的可行性產(chǎn)品）速推出產(chǎn)品的模式：一開始只推出最的功能，滿足用戶最的需求，然后在用戶的使這種模式怎么誕生的呢？還是應(yīng)用“金三角”理論，要快速推出產(chǎn)品，還想成本不用太高，所以最簡單有效的辦法就是砍掉一些重要性不那么高的功能需求，只保留最的需求。通商，砍掉一些不那么重要的需求，把精力放在需求上，保證項目可以如期上線。顧客對于要交付的軟件和服務(wù)，都是有很多美好的需求的，用戶希望軟件開發(fā)的又快，又便宜（人工便宜），例如，上圖的①說明，如果希望軟件做得又快，又低成本（人工便宜），不考慮其他要求，那么，我們會得到大致什么樣的軟件呢？例如，上圖的⑤說明，如果希望軟件是免費(fèi)的，而且要很快交付，越快越好，那么，這 歸科技所有 不得售賣。頁面已增加防盜追蹤，將依法其上一 07|大廠都在用哪些敏捷方法？（下下一 09|可行性研究：一個從一開始就注定失敗的跨平臺項言言 5 312.快+好=費(fèi)用成本高多半是早期軟件，功能少只實現(xiàn)功能但體驗不錯作者回復(fù): 2小先 風(fēng)再起 2老師請教一下，敏捷開發(fā)中是怎樣做成本估算的？按您所說，開發(fā)過程中每個Tt由開發(fā)團(tuán)隊集體估算，但在項目開始前即立項階段，只有初步的大概的需求，具體的Tt還沒有制定出來或者不完備，如何準(zhǔn)確確定項目的合同金額或預(yù)算？瀑布模型開發(fā)又是如何預(yù)估成本的？都是采專家估算拍袋估算成本工期嗎？件工程書中介紹的估算模型如 O或其他算法模型在實踐中有人用嗎？功能點(diǎn)、用例點(diǎn)等軟件規(guī)模展開 2目里了，所以我把它歸結(jié)為提高效率，實際上也可以理解為TTM（TimeToMarketing） 老師，其實，表達(dá)的是，傳統(tǒng)的大企業(yè)（不是指T這類大企業(yè)），比如我們企業(yè)項目牽涉到三個部門，一個是業(yè)務(wù)需求部門，一個是IT部門，一個是財務(wù)預(yù)算部門，采取的形式一般都是采用外包方式，而且往往是固定合同，也就是合同價格是確定的，需求范圍也是確定的，這樣的話，金三角的兩條邊就定下來了，剩下來的就是時間和質(zhì)量的果然如 1 謝謝老師教的砍需求，而且還有理論支撐，以后PK再也不虛了一些調(diào)整，并不是要PK個輸贏：）一路向 1張 的產(chǎn)品可能規(guī)定的時間內(nèi)都不會有迭代的需求，而是按照產(chǎn)品經(jīng)理某一天提出來