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

第199講|：怎樣平衡軟件質(zhì)量與時間成本范圍的關(guān)系2019-04-04Groupon資深工 進入課你好，我是Groupon資深工程師，也是極客時間《軟件工程之美》專欄的作者，我今你會發(fā)現(xiàn)，在實際的軟件項目中不乏這樣一個項目，正常估算，要三個月才能完成，但是或客戶要壓縮到一個月完成，而你不道該不該，或者如何；其實，這些日常項目中涉及時間、成本和范圍的問題，都離不開“軟件項目管理金三角”的掌握好這個知識點，學會平衡軟件質(zhì)量與時間成本范圍的關(guān)系，可以幫助你更好的駕馭項目中的各種問題，也可以幫助你更好地理解軟件工程中各個模型，尤其是瀑布模型和敏捷開發(fā)。在現(xiàn)實生活中，我們都知道，做產(chǎn)品想“多快好省”都占著，是不可能的，最多只能選兩樣。想要便宜和質(zhì)量好，就要花時間等；想要快還要質(zhì)量好，那就得多花錢；想要又便宜又快，那就得接受難用質(zhì)量差。而在軟件項目中，也有一個類似的平衡關(guān)系，就是軟件質(zhì)量（產(chǎn)品的質(zhì)量，客戶的滿意度）與范圍（需要實現(xiàn)多少功能）、時間（多久可以完成）、成本（花）四個要間的為什么四個要素，是“質(zhì)量”放在三角形的中間因為軟件工程的目標就是要構(gòu)建和高質(zhì)量的軟件，所以項目的質(zhì)量是的。也就是說，“質(zhì)量”這個因素一般不會妥協(xié)，因此把“質(zhì)量”放在三角形中間，然后在時間、成項目管理其實就是項目中一系列問題的平衡和妥協(xié)，而“金三角”理論則為我們的平衡提供了理論指導，了解這三個因素分別對項目其他方面產(chǎn)生的影響，可以幫助你在做決策時進行權(quán)衡取舍。當你接手一個項目，項目的進度、成本和范圍指標很容易可以到。有了這些信息，你就我來舉兩個例子，看看“金三角”是如何應用的要壓縮項目時間當項目經(jīng)理，常遇到的問題之一就是時間被壓縮，比如文章中開頭舉的例子，問我一個項目多久能完成，我按照經(jīng)驗，覺得要三個月，覺得三個月太久了，要砍到一個月就上最開始的時候，我就是據(jù)理力爭，說這不科學，肯定不行呀。說時間點很重要，必須要后來我學乖了，先用金三角知識分析了一下：希望時間是1個月，也就是說時間這條于是再遇到這種問題，我就換了式跟溝通：“一個月也不是不行，就是我們得需求調(diào)整一下，第一個版本只能做一些功能，剩下的后面版本再加上。（調(diào)整范圍）還得給我加兩人，不然真做不完！（增加成本）”這樣的方案一提出來，就好溝通多了，最后重點就變成了砍多少功能和加多少人的事情了產(chǎn)品經(jīng)理要臨時加需求怎么在文章開篇我提到一種情況，項目開發(fā)一半，產(chǎn)品經(jīng)理告訴你，有一個非常緊急的功能，要增加到這個版本中，怎么辦？我們拿“金三角”知識先套用一下。增加需求，也就是范圍這條邊要增加，那就必然對成本和時間這兩條邊造成影響，要么延期，要么增加成本。面對這種臨時加需求的情況，我們也不需要直接說不能加，而是清楚的讓產(chǎn)品經(jīng)理認識到這樣做的：進度延期，需要的成本。如果這個功能真的太重要，可以接受延期，也不是不可以接受，那就重新制定新的項目計劃好了。瀑布模型有嚴格的階段劃分，有需求分析、系統(tǒng)設計、開發(fā)和測試等階段，通常在開發(fā)過程中不接受需求變更，也就是說，我們可以認為瀑布模型的范圍是固定的，其他兩條邊時間和成本是變量。所以使用瀑布模型開發(fā)，如果中間發(fā)現(xiàn)不能如期完成進度，通常選擇的方案就是延期（加這就是為什么在敏捷開發(fā)中，每個Sprint開始前都要開Sprint計劃會，大家一起選擇下Sprint能做完的任務，甚至于在Sprint結(jié)束時，沒能完成的任務會放到下個Sprint做這時候再想想文章開頭我們提到的問那么怎么樣才能平衡好軟件質(zhì)量與時間成本范圍的關(guān)系前面我們說日常生活中“多、快、好、省”最多只能選兩樣，其實如何平衡好軟件質(zhì)量與時間成本范圍的關(guān)系也是一樣的道理，我們只能最多選擇兩樣，然后在另一邊或者另兩條邊去尋找平衡。下面，我來分析一些案例，幫助你更好地淘寶第一個版本是怎么做到一個月上線的這個故事其實我是從極客時間《從0開始學架構(gòu)》專欄看來的，老師在《架構(gòu)設計2003年4月7日提出成立淘寶，2003年5月10日淘寶就上線了，中第一件事當然是先應用金三角分析一下：時間這條邊被固定了，只能一個月；功能也不能少，范圍這條邊也限制住了，那就只能在成本上想辦法了。要么一下子雇很多牛人，要么直接買一個現(xiàn)成的電子商務，然后修改。上“”，網(wǎng)購需求增大，淘寶網(wǎng)一下子就火爆起來了從成本角度我們還有可以去做的，比如說有同學在看完《06|大廠都在用哪些敏捷（上）》這篇文章后，也想在團隊里面推行代碼和CI，但是苦于搭建這一套git+CI的我的建議就是剛開始就沒必要自己去折騰了，買一套的企業(yè)版，加上支持的商業(yè)CI系統(tǒng)，花不了，而且可以節(jié)約大量搭建這種系統(tǒng)的時間。極限編程是怎么做到“極限”前面在介紹敏捷開發(fā)的時候，也提到了極限編程（eXtremeProramming，XP），是目前敏捷開發(fā)主流的工程實踐方法，極限編程的“極限”（Extreme），意思就是如果某個實踐好，就將其做到極限。比如：如果做測試好，就讓每個開發(fā)人員都做如果集成測試重要，就每天都做幾次測試如果簡單的就是好，那么我們就盡可能的選擇簡單的方法實現(xiàn)系統(tǒng)一下極限編程在Sprint中的應用。在一個Sprint，計劃好了當前Sprint做的工作內(nèi)容后，那么極限編程怎么幫助我們提一個Sprint要做的內(nèi)容是確定的，相當于成本和范圍這兩條邊都固定了，時間這條邊就成極限編程，就是通過幫助我們提升效率和減少浪費這方面來做的。比如持續(xù)集成，通過自動化的方式幫助我們部署，節(jié)約了大量需要人去手動部署的時改代碼產(chǎn)生bug，減少了大量的浪費；只做剛好的設計，避免設計時考慮了太多不必要的可能，造成浪其實我們在項目中也有很多地方可以借鑒這種思路，比如說寫代碼的時候，少自己造，多使用成開源或者商業(yè)組件，可以提升效率；比如把需求想清楚搞清楚再去開發(fā)，可以MVP模式是怎么誕生這些年流行的MVP（minimumviableproduct，最小化的可行性產(chǎn)品）模式，是一種快速推出產(chǎn)品的模式：一開始只推出最的功能，滿足用戶最的需求，然后在用戶的使所以最簡單有效的辦法就是砍掉一些重要性不那么高的功能需求，只保留最的需求。通商，砍掉一些不那么重要的需求，把精力放在需求上