敏捷軟件開發(fā)項目管理的相關理論基礎概述目錄TOC\o"1-3"\h\u19136敏捷軟件開發(fā)項目管理的相關理論基礎概述 1306131.1項目管理 1168541.1.1項目管理概念 1222101.1.2項目管理過程 1192371.2敏捷軟件開發(fā) 3271291.1.1敏捷軟件開發(fā)方法 364551.1.2敏捷軟件開發(fā)介紹 4105541.1.3敏捷軟件開發(fā)項目管理流程 574661.3軟件項目管理模型 976521.3.1瀑布模型 9278471.3.2增量開發(fā)模型 963591.3.3各模型之間分析比較 101.1項目管理1.1.1項目管理概念項目是一個有時間和資源要求，并且循序漸進的獨一無二的任務。為了能夠解決項目復雜多變的風險產生了項目管理學科。項目管理是管理學的一個分支學科，對項目管理的定義就是指在項目活動中運用專門的知識、技能、工具和方法，使項目能夠在有限資源限定條件下，實現或超過設定的需求和期望的過程。項目管理是對一些成功地達成一系列目標相關的活動（譬如任務）的整體監(jiān)測和管控。這包括策劃、進度計劃和維護組成項目的活動的進展。項目管理有一套獨特的管理理念和方法體系，它的實現就是關于“在復雜多變的風險中，處理好一個事”的理念和技術。1.1.2項目管理過程項目管理的過程是將項目的開啟、項目的規(guī)劃、項目的實施、項目的驗收、項目的維護相互串聯起來，每個階段都缺一不可，都有規(guī)定自己的時間范圍，必須審核完成了上一個階段才能進入到下一個階段，不同的階段也會產出對應的文檔，為下一階段提供幫助。（1）項目的開啟項目的開啟是一個項目管理過程的首要階段，意味著一個新項目的開始。項目啟動前需要銷售跟客戶簽訂相關的合同，預付定金，合同簽訂后開啟項目啟動會，啟動會需要需求人員、項目經理、產品經理了解這個項目現有的業(yè)務需求和未來的方向，并針對其做需求分析，總結出客戶的真實想法和該想法是否真實可行，如果項目可行，就會產出軟件需求文檔，簽定合同，隨后會組織項目啟動會，項目經理、產品經理、需求人員、開發(fā)人員、測試人員、實施人員等都必須參與項目啟動會，啟動會結束后就會進行項目的規(guī)劃。（2）項目的規(guī)劃項目的規(guī)劃是項目管理中最為繁瑣的階段，項目經理需要掌握多個領域的技術知識，有一定的實施經驗。做好規(guī)劃主要是為其他的階段做一份更明確的計劃，以便于后續(xù)階段工作能夠正常有序的開展。項目成員如果按照制定的項目規(guī)劃執(zhí)行可以降低項目的成本，也能提高項目收益。項目規(guī)劃文檔包含項目目的和范圍、項目的背景、項目的術語和定義、項目的參考資料、項目的技術方案。項目規(guī)劃一般可分為需求設計規(guī)劃、開發(fā)規(guī)劃、測試規(guī)劃以及工程實施規(guī)劃，每項規(guī)劃都會將項目需求分解，制定階段性任務以及每項任務的人力、成本、進度規(guī)劃，并規(guī)劃不同階段產出不同的文檔。（3）項目的實施項目的實施是針對項目規(guī)劃階段制定的項目需求、開發(fā)、測試、工程實施任務的實際操作，此階段需要花費大量的人力資源和時間去完成不同的工作。需求完成分析才能進行開發(fā)，開發(fā)完成才能進行測試，測試完成就會進入到具體的工程實施階段，為了能夠讓項目具體實施，還需要進行以下幾項步驟：首先，項目的實施需要確定需求、開發(fā)、測試、工程負責人熟知各團隊成員的技能，根據每個人的能力分配具體的任務以及具體的完成時間，一般會使用project進行，最后產出更加詳細的任務分解計劃表。其次，項目需求人員需要將原始需求進行詳細分析，產出需求分析文檔，需求人員需要給開發(fā)人員、測試人員詳細講解需求，此過程中開發(fā)、測試可以針對需求不合理的提出自己的建議并要求需求人員更改；需求分析完成后開發(fā)人員針對需求產出自己的設計文檔、測試人員針對需求產出自己的測試用例，開發(fā)設計文檔提供給測試人員和需求人員評審，此過程可以讓需求人員了解開發(fā)人員的設計是否符合要求，讓測試人員了解開發(fā)的邏輯思路便于后續(xù)用例編寫以及驗證自己用例設計思路是否跟開發(fā)一致；測試用例產出后需要需求人員、開發(fā)人員一起評審，評審過程中可發(fā)現需求是否考慮周全、開發(fā)人員的開發(fā)邏輯是否與測試一致；需求開發(fā)、測試完成后需要工程實施人員進行生產部署，并產出相應的部署文檔，供客戶參考，也為以后其他項目組部署該項目提供方便。最后，各階段的執(zhí)行過程中需要控制項目人力資源、溝通、進度、成本、質量的風險，把控需求、開發(fā)、測試進度，快速響應需求變更、嚴格按照項目規(guī)范控制開發(fā)、測試質量，確保能夠按照計劃執(zhí)行，順利交付產品。（4）項目的驗收項目的驗收意味著開發(fā)、測試工作的完成，項目即將結束，產品使用人員需要對該項目的產品參照部署文檔進行部署，部署成功后進行測試，確認產品的功能是否與原始需求一致，測試通過后方可驗收，驗收通過后需要簽定對應的驗收合同，銷售根據驗收合同督促客戶結算尾款。項目驗收后開發(fā)、測試人員需參與項目回歸會議，總結項目中的問題以及優(yōu)點，針對問題提出解決方案并嚴格執(zhí)行，針對優(yōu)點需要繼續(xù)保持。（5）項目的維護項目的維護是指項目驗收后，產品已經投入生產使用，使用過程中會出現硬件、軟件等問題，為了能夠確保產品投產后能夠正常使用，需要對其進行后期的維護。維護過程中可針對解決的問題產出問題維護清單，記錄問題并詳細記錄解決方法，方便后續(xù)出現同類問題可以快速解決。維護期一般沒有固定的時間，維護期的長短依賴于該產品使用時間長短，若該產品被其他產品替代不再使用后，那么也就意味著維護期的結束。1.2敏捷軟件開發(fā)1.1.1敏捷軟件開發(fā)方法敏捷含義是指動作或者思維反應迅速快捷，能夠非常靈活。敏捷開發(fā)注重項目團隊成員之間的溝通協(xié)作，將項目分解成多個小項目，使每個小項目能夠循序漸進執(zhí)行。敏捷軟件開發(fā)方法是當前使用最流行的軟件項目管理方法，目前很多大型企業(yè)都在使用敏捷項目管理方法，它具有簡潔性、靈活性，強調該做什么不該做什么，減少資源的浪費，已經為很多企業(yè)帶來了很大的利益，提升了團隊的溝通能力，提高了軟件的質量。許多使用敏捷軟件開發(fā)項目管理的都會使用ScrumBoard和Kanban，他們都是以成功為目標，一起對敏捷思維進行歸納總結，形成一套統(tǒng)一的敏捷價值觀。上世紀80年代后期，ScrumBoard開始流行，它將團隊的工作量分解成更小的事故（story），事故又可以分級成更小的子任務，然后將這些事故或子任務分成多個迭代并確定優(yōu)先級，優(yōu)先處理優(yōu)先級高的迭代，每個迭代預計2周時間，優(yōu)先級高的迭代確認后讓項目團隊成員評估自己的工作量，然后一個迭代一個迭代的完成任務，每個迭代需要嚴格填寫實際的工作量，當一個迭代完成后，可以根據評估工作量和實際工作量進行對比，為下一迭代評估工作量做好樣本，縮小后續(xù)迭代實際工作量與評估工作量之間的差距。自2004年起，豐田工程師創(chuàng)建了Kanban方法，Kanban在開發(fā)團隊流行起來，與ScrumBoard相比，Kanban就沒有顯得那么規(guī)范，允許項目有變化并且能夠快速響應需求的變化，為了不浪費資源，提供了一套透明的持續(xù)的工作流程，將工作細分成任務，可以根據細分的任務通過狀態(tài)區(qū)分，便于看出已登記、已受理、已分配、開發(fā)中、待測試、測試中、已解決、已關閉狀態(tài)下工作任務的數量和運行狀態(tài)，確保每個人的任務都在合理范圍內。每一個任務只能處于一個狀態(tài)中，減少了團隊之間轉開發(fā)、轉測試、轉發(fā)布之間的溝通問題，降低了團隊的溝通成本。此方法也便于負責人針對每個人的工作量進行預估，制定相應的計劃，合理的分配每個迭代的團隊人員的工作任務。通過對敏捷ScrumBoard、Kanban的特點分析對比，結果如下表2-1所示：表2-1ScrumBoard與Kanban的比較ScrumBoardKanban任務大小任務細分任務細分圖表使用燃盡圖無圖標，使用發(fā)布狀態(tài)區(qū)分工作周期以迭代為周期，每個迭代2周時間以任務為周期，計算每個任務完成的時間需求變更不允許需求新增、變更在時間、資源允許的條件下允許需求變更、新增優(yōu)先級每個迭代需優(yōu)先處理級別高的需求未設定優(yōu)先級適用團隊適合成熟一點的產品和團隊團隊的個人能力要求比較高，靈活些，適合新開的產品通過上述方法對比，可以看出ScrumBoard與Kanban方法各有優(yōu)缺點，J公司作為金融軟件供應商，為了適應需求快速變更，J公司的敏捷軟件開發(fā)項目管理優(yōu)化需要同時結合他們的優(yōu)點使用。1.1.2敏捷軟件開發(fā)介紹敏捷方法是一種以人為核心的，循序漸進的新型軟件開發(fā)方法，它更加強調團隊之間的合作，從而有效提升了軟件開發(fā)以及用戶使用的效率，更能滿足現今快速發(fā)展的社會需求。敏捷軟件開發(fā)方法是一種可以應對快速需求變化方法，強調的是人與人之間的交流，靈活的調動了團建成員之間的相互合作、相互溝通，更能注重團隊成員間的作用。敏捷軟件開發(fā)最重要的是能夠盡快的滿足客戶的需求，同時也要快速靈活的接受客戶的需求變化，它是一種可持續(xù)交付開發(fā)的方法，持續(xù)時間最少不能少于2周，最長不能超過4周，持續(xù)周期盡量不要太長，項目的需求、開發(fā)、測試人員應該都在整個團隊中工作，為了更好、更方便溝通，團隊中的成員應該坐在一起，或者相隔距離較近，盡可能的減少不必要的溝通，簡單明了的描述問題，每個迭代結束后，項目組的成員應該組織一次回顧會議，總結團隊的問題，針對問題提出相應的解決方案，針對好的規(guī)范需要繼續(xù)保持，用于提升團隊的工作效率。敏捷開發(fā)應該遵從四條基本原則：遞增，而不是連續(xù)的：如果開發(fā)實踐是真正的敏捷精神，那么交付的工作軟件是一小部分一小部分遞增的。不必等到一個階段完全完成后才開始另一個，工作也不是向大的發(fā)布日期而努力。完成的工作，但并不是業(yè)務最終期限，驅動著敏捷交付。但敏捷精神也承認業(yè)務操縱著最后截止日期。避免不必要的開銷：如果實踐仍然是真正的敏捷精神，那么團隊就致力于盡可能多地減少項目計劃和文檔。與其討論要做什么，然后再寫下來，不如趕緊動手去做，否則，就是浪費時間在工作上。在工作對工作中，敏捷精神有利于實際工作——交付的軟件。而且它也值面對面的交流通過郵件和其他書面文件。協(xié)作：根據需求，團隊成員一直與其它人進行交互，以及一些外部利益相關者。在敏捷教練世界中，整個團隊的負責人能夠解決所有問題。在問題出現之前，真正的敏捷精神團隊是自主的。他們分配需要做的工作。雖然每個成員承擔的任務都在他們的專業(yè)技能范圍內，他們還是需要與團隊協(xié)作的。沒有人的工作是孤立的，也沒有團隊本身是獨立工作的。沒有業(yè)務利益相關者，以及諸如用戶體驗方面的外部專家的重大投入，團隊就不可能使項目向前發(fā)展。說真話：為了保證真正的敏捷，團隊探討的與項目相關的一切都要是真實的。在一些至關重要的專業(yè)領域，如沖刺測試的編碼技能，他們承認存在差距。關于實際生產力，他們的要講事實；這也就是說，在一定時間內，團隊是否有能力做到。他們承認錯誤，說真話是一項挑戰(zhàn)，因為他們害怕承認缺點會讓他們顯得很弱。但敏捷精神說出事實需要勇氣，承認問題需要信心，然后快速地去解決問題。1.1.3敏捷軟件開發(fā)項目管理流程敏捷通用過程模型敏捷軟件開發(fā)是將一個產品分成多個迭代，每個迭代有包含迭代計劃、迭代開發(fā)、迭代驗收、迭代回顧4大過程，其中迭代計劃可通過PB（productbacklog，產品待辦列表，一個最終會交付給客戶的，根據商業(yè)價值來排列優(yōu)先級的產品待辦列表，項目的列表為JIRA中的需求）查看，迭代開發(fā)則可通過SB（springbacklog，迭代任務列表，從PB中挑選高優(yōu)先級需求，SB中的需求可被細化為更小的子任務，子任務工作量建議小于16小時）查看，詳細明細見下圖2-1：圖2-1敏捷通用過程模型敏捷過程管理模型敏捷過程管理分為每個迭代的項目啟動會前、項目啟動、項目執(zhí)行、項目回歸及回顧，該迭代完成后進入下一迭代，且每個過程都需要相應的人員參與，其中PO（ProductOwner，產品負責人）、master（敏捷教練）、團隊成員在各個階段都會參與其中，詳細明細見下圖2-2：圖2-2敏捷過程管理模型1.1.4敏捷軟件開發(fā)優(yōu)點和缺點敏捷軟件開發(fā)的優(yōu)點在每個迭代的交付過程中相對于其他的項目管理模型來說有一定的優(yōu)勢；可以通過迭代交付；敏捷的目的主要是提高客戶的滿意度，使用迭代的方式進行敏捷的項目管理，每個迭代完成后會完成相對應的需求功能提交給客戶部署，客戶部署測試的過程中，可以針對這些需求的不完善提出更好的建議，項目團隊也會對其進行快速的響應，并完善；能夠應對頻繁的需求變更；客戶比較關注最終的產品是否能夠滿足其要求，在大量的真實軟件項目管理過程中，大部分的產品在實際實施過程中都會存在經常變更的情況，特別是需求不明確的，后續(xù)需求變更就尤為突出，因為敏捷軟件開發(fā)的項目管理是針對迭代進行的，每個迭代的范圍固定，變更某個需求只是針對當前迭代產生影響，其他未開始的迭代并不會受影響，所以就能夠隨時應對這些變化；溝通能力的提升；敏捷開發(fā)強調的是當面溝通，敏捷團隊的成員都會在一個辦公區(qū)，當面溝通就會避免因為距離遠浪費時間，也可以避免因為通過聊天工具討論造成的一些溝通不暢；每個產品在實踐過程中需求、開發(fā)、測試、工程、服務人員都是需要相互磨合，相互溝通的，溝通的次數多了，就會慢慢成長，提高個人的溝通能力；團隊便于管理；敏捷團隊一般都是要求團隊有一定人數限制的，最合理的安排是不能超過10個人，人數太多一般就不便于管理，溝通也會產生分歧，因此團隊人數較少能夠更加便于管理，也能更加靈活。敏捷軟件開發(fā)的缺點相對于瀑布模型、增量開發(fā)模型等等就會突出的更加明顯；文檔相對簡單；敏捷開發(fā)注重的是團隊成員間的當面溝通能力，因此，很多東西都是通過口頭討論，并未形成完整的文檔，因此就會造成后續(xù)維護困難，找不到原始的需求記錄當初設計的原因，以及不知道功能模塊的用處，需要花費大量的時間去重新熟悉該功能，如果文檔較為詳細，那么就可以通過文檔很快知道該功能的作用，也可以將此文檔提供給其他項目組需要熟悉該功能的人員使用，以及提供給新人學習新業(yè)務知識；人員要求較高；敏捷開發(fā)的項目管理人員需要有較強的項目經驗，針對大型的項目，經驗豐富的人能夠堅定的做出正確的選擇，少走彎路，帶領團隊朝著目標一步一步的前進；其次項目團隊成員也要有項目經驗，如果都是新人，那么沒有老員工帶領，新人缺乏項目經驗以及業(yè)務知識，溝通困難，導致很難把控項目質量，不利于迭代的進行。1.3軟件項目管理模型1.3.1瀑布模型瀑布模型是最早的軟件開發(fā)模型，為后續(xù)的其他模型提供了最基礎的架構，它將產品研發(fā)過程分為4個階段，分別是需求分析和定義、軟件開發(fā)、軟件測試和軟件維護，這幾個階段自上而下相互銜接，如同瀑布流水、逐級落下。瀑布模型最主要的是將產品簡化成多個階段，每個階段分工協(xié)作，目前大部分軟件公司一般都是使用瀑布模型進行軟件開發(fā)的，其流程圖如下圖2-3所示：圖2-3瀑布模型圖瀑布模型按階段劃分，只有當前一個階段完成后，下一個階段才會啟動，每個階段之間反饋較少，如果某個階段因為需求變更或需求分析不完善，那么必將導致該階段延期，后面階段的完成時間也會延長，最終導致整個項目延期，項目的結果只能在最后項目結項才能知道，因此，此模型只適用于需求文檔更完善并且不會變更的軟件系統(tǒng)。1.3.2增量開發(fā)模型增量開發(fā)模型是在瀑布模型的基礎上進行了優(yōu)化，該模型隨著