國考資訊處理工作室(高考二級資訊處理/高考三級資訊處理/調查局三等/關務人員三等/地方特考三等)

第一章 緒論

1-1 專案管理

[資訊管理]

[專案管理] 14 | 84,85,91,97,98,103,104,106,107,108,109(3),111

84地三、85高三、91警三、97高三、98普、103警員晉高、104身三、106警特三、107警三、108關簡、109地四(2)、109地三、111高三

[系統分析與設計]

[專案管理] 22 | 92,93,98,99(2),100,101,102(3),103,104(2),105,106,107,108(2),109(2),110,111

92公簡、93電員晉高、98關薦、99檢三、99技高、100高二、101技高、102高二、102技高、102地三、103高二、104高二、104技高、105高三、106關簡、107高三、108調三、108外四、109高二(2)、110高二、111高二

一、專案管理的定義

就是專案經理需要負責的工作，包含「定義、組織、用人、計畫、控管」等五種類別，而這些工作的主要目的在透過專案管理的方法、技術和工具來有效管理專案的人、事、時、地、物、錢等。其最終的目的在確保專案的順利完成。

※參考資料：https://www.krispmschool.com/blog/pm/pm-principle/pm-def/

二、專案管理的內涵

108年關務人員升官等簡任資訊管理研究

(一)目的

1.透過組織內不同單位人員臨時編組，達成「追求資源效率的極大化」。

2.追求資源效率的極大化就是在時間成本上如期達成或縮短時限提早完成；在預算成本上，以最低成本達成最大效果；在研發成果上，達到預期目標或較 預期更優；在品質改善上，遠較預估為佳等四項綜效 (synergy)。

※參考資料：現代化經營與管理-專案管理.ppt

(二)生命週期

1.起始：取得授權定義專案需求及釐清相關需求回應。

2.規劃：詳盡策劃表列解決之道，並且以最佳方式完成。

3.執行：持續檢視監控，必要時適當修正調整。

4.結案：驗證查核是否滿足需求及留下完整記錄。

※參考資料：現代化經營與管理-專案管理.ppt

(三)成員選擇

可以經由外聘、招募、人才庫查詢、借調、支援等路徑實施。

※參考資料：現代化經營與管理-專案管理.ppt

(四)專案成功與否決定3C

1.協調：由高階主管負責籲請各部門參加。

2.溝通：

  人員調度委派、權責分際、獎懲績效、內容範疇、經費工具、案例諮詢等等。

3.合作：時間結構、經費審核、企劃創意、獎金報酬、專案說明等等。

※參考資料：現代化經營與管理-專案管理.ppt

(五)專案終止

1.消失：任務達成、失敗結束、政治腰斬。

2.涵蓋：由非正式向正式轉移。

3.整合：專案結束後的歸建、合併、精簡。

※參考資料：現代化經營與管理-專案管理.ppt

三、專案管理中的主要變數：專案管理5個主要的變數

106年關務三等資訊管理、107年警察人員特種考試資訊管理人員三等資訊管理

在資訊系統的專案管理中必須處理的主要變數如下：

(一)範圍

1.界定哪些工作是或不是包含在專案內。

2.例如建置一個新的訂單處理系統的專案範圍，可能包含新的訂單輸入模組與傳送訂單至生產與會計，但是並不會對應收帳款、製造、配送，或存貨控制等系統有產生影響。

3.專案管理定義成功完成專案所需要的一切工作，而且確保專案範圍不會超出原先所制訂的。

(二)時間

1.表示完成一個專案所需要的時間。

2.專案管理規定完成一個專案中主要元件所需的時間，這些主要元件會更進一步的細分為活動與任務。

3.專案管理試著決定完成每個任務所需要的時間，並且制訂這些工作的行程表。

(三)成本

1.是以完成專案所需要的時間乘以人力資源成本為基礎考量。

2.資訊系統專案成本也包含硬體、軟體與工作空間的成本。

3.專案管理訂定專案所需要的預算，並且監控專案執行的開銷。

(四)品質

1.是一項指標，主要用來衡量專案成果是否滿足管理階層所設定的目標。

2.資訊系統專案的品質的好壞，通常取決於增進組織績效與幫助決策制訂。

3.品質也考量到新系統處理資訊的正確性與即時性，以及系統的易用性。

(五)風險

是指威脅專案成功的潛在問題，這些潛在的問題可能增加專案的成本與時間、降低專案的品質，以致無法達成專案所制訂的目標，或是影響專案無法結案。

※參考資料：周宣光-管理資訊系統-管理數位化公司第十版 p.599~p.600

四、專案管理的目標

(一)控制範疇(Scope Control)

1.專案範疇是指為完成專案目標所必須做的所有工作內容，好的專案管理必須要能堅持有效的文件製作與管理。

2.控制範疇是對造成專案範圍變更的因素加與管制影響，控制變更造成的後果， 當變更產生時一定修改工作分解結構 (WBS)、程序、流程、時程與預算，以便於監控專案執行結果，防止工作內容在未經授權情況下擅自變更，專案項目變更是不可避免的，但是必須強制實施某些形式的變更控制管理，以確保專案符合規格及目標的需求。

(二)時程及預算控制(Scheduleand Budget Control)

1.專案所有的時程及預算應該依據工作分解結構 (WBS) 中各工作包 (Work Package) 及活動項目 (Activity List)、組織結構、資源類別 (Resource Type) 來做計劃及規劃控制，判斷專案目前進度狀況，對造成進度變化的因素加與控制影響。

2.無論是使用何種時程控制程式或是何種網路分析技術 (如 CPM，PERT)，都必 須能夠隨時掌握目前進度、預估剩餘未執行的預算成本、預判任何一個特殊工作是否能夠如期完成並對整個專案時程及成本的影響程度。

(三)成本控制(Cost Control)

1.包含所有成本的有效管理，例如成本預估、成本會計、專案現金流與公司現金流、直接人工成本及管理間接成本、其他成本 (如獎勵金、罰款、利潤分攤等)。

2.當專案執行過程中必須要適時控制任何一項成本的發生，經常保持對成本的敏感度。

3.最重要是衡量實際支出與預算的差異，了解其差異因素為何？掌握其差異性及差異數 (Variance)，無論正負變異差數都必須做其差異分析，雖然有些變異數是可以接受的，但是也需要分析是否超出預先估算範圍並採取修正對策解決。

4.對造成費用基準變更因素施加控制並確保變更請求獲得核准，監督費用的績效找出費用與預估成本的偏差，防止錯誤的變更及不恰當或未核准的變更被納入費用資源中，造成專案後期產生無法接受的巨大專案資金不足風險。

(四)專案品質管理(Project Quality Management)

1.專案品質管理包括執行組織所決定的品質政策、目標和責任，使專案能滿足其所設定需求的一切活動及 ISO 品質管理系統的要求。

2.專案品質管理是透過政策、程序與品質規劃、品質保證及品質管制等過程，以執行品質管理系統，並且視需要在專案期間採取持續性的流程改善活動，以使專案品質能達到要求的標準。

3.專案品質管理的流程：

  包括下面三個步驟：

  (1)品質規劃(Quality Planning)：

確認有那些品質標準與專案有關，並且決定如何滿足這些標準。

  (2)執行品質保證(Perform Quality Assurance)：

    應用已經計畫且系統化的品質活動，以確保專案滿足需求。

  (3)執行品質管制(Perform Quality Control)：

    監視專案各個工作項目執行的結果，以決定它們是否符合相關的品質標準，並且辨識及找出可以消除造成不符合績效原因的辦法。

※參考資料：

1.https://www.tp.imc.org.tw/%E7%AC%AC55%E5%B1%864%E6%9C%88%E6%9C%88%E5%88%8A-%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86%E6%8E%A7%E5%88%B6-%E5%8A%89%E6%AD%A6%E9%9B%84-%E5%B8%B8%E5%8B%99%E7%9B%A3%E4%BA%8B/

2.https://blog.xuite.net/bjmwu/twblog/119754108

※如何激勵成員達成專案目標？

108調三

1.薪酬激勵：達成專案目標，給予加薪。

2.福利激勵：達成專案目標，給予特別福利，例如入股分紅、績效獎金。

3.團隊激勵：

  如果群體的工作氣氛是友好、友愛、滿足、諒解、愉快的，那麼成員的工作心態是積極的。

4.感情激勵：

通過強化感情交流溝通，協調領導與員工的關係，讓員工獲得感情上的滿足， 激發員工工作積極性的一種激勵方式。

5.寬容激勵：

  領導者的寬容品質能給予下屬良好的心理影響，使員工感到親切、溫暖和友好，獲得心理上的安全感。一個領導者只有具備寬容的氣度，才能團結眾人的力量，最大限度地發揮人才的效能。

6.尊重激勵：

  管理者要發自內心的去尊重每一位員工，對待員工有禮貌，不嘲笑、不輕視員工，尊重員工的人格，認真聽取員工的建議，讓員工感到自己對組織的重要性。

7.讚美激勵：

  讚美使人的努力得到他人的肯定與贊同，獲得心理上的滿足，因此也就有了繼續努力的動力。

※參考資料：

1.https://kknews.cc/career/amlvb86.html

2.https://wiki.mbalib.com/zh-tw/%E6%84%9F%E6%83%85%E6%BF%80%E5%8A%B1

3.https://wiki.mbalib.com/zh-tw/%E5%B0%8A%E9%87%8D%E6%BF%80%E5%8A%B1%E6%B3%95

※要避免那些激勵方式？

108調三

1.只有獎勵方式沒有處罰措施：

  企業總是希望員工盡其所能做到最好，但是當員工犯了某些錯誤或對待工作的態度不好時，企業就必須施以約束和懲罰制度，將員工的行為引導到特定的方向上，絕不能採取視而不見甚至縱容的態度任其發展。激勵就是對好的行為和表現，利用獎勵措施加以強化，對差的行為和表現，利用處罰措施進行約束。

2.沒有差異化的激勵：

  (1)激勵應該要有差別的，如果沒有對員工的績效仔細分析，把同樣的激勵手段用於所有人，必定適得其反。

  (2)不同類型的人有不同的需求，找到他們的需要，並且實施有針對性的激勵措施，這樣才是最有效的。例如從事簡單工作的員工，他們的需求屬於較低層次，採用物質激勵是較為經濟和適宜的。而從事複雜工作的技術人員和管理人員，他們在精神方面的需求會較多一些，為了能夠留住人才，應該注重精神方面的激勵措施 (如晉升、授予榮譽等)。因此激勵應該注重差異化，沒有差異的激勵是起不了作用的。

3.過度依賴金錢激勵：

  調查發現，最能激勵員工的前三名分別為學習活動、彈性工時和個人讚美。對員工發自內心的關懷是激發其工作熱情的關鍵。金錢激勵並不是最有效的辦法，它往往因為形式的單一和老化使激勵政策失效，因此，在儘量避免使用金錢激勵的同時，管理者應該不斷創新以保證激勵政策的有效性。

4.將激勵制度當成萬靈丹：

  有些企業實施激勵制度後，卻反而降低員工工作的努力程度。這是因為有些管理者把激勵當作萬靈丹，只要建立了激勵政策就能發揮作用。事實上，當員工的能力達到一定的程度和極限以後，即使再如何以充滿吸引力和誘惑力的激勵措施也不能令他們發揮績效。

5.讚美小事：小事不需要讚美，做出大成績再讚美即可。

※參考資料：http://businsess-coach.blogspot.com/2008/11/blog-post_2292.html

※軟體產品的模型(software product model)：

[軟體產品的模型(software product model)] 1 | 104

104高二

104年高考二級軟體專案管理研究

答：

軟體設計文件(Software design description, SDD)：

1.定義：

(1)是軟體產品的文字描述，由軟體設計者撰寫，目的是提供軟體開發團隊有關軟體產品的架構指引。

(2)軟體設計文件一般會配合軟體的架構圖，其中會再針對軟體中的各模組說明其細部規格。

(3)實務上，若要統合一個大的團隊，在單一的觀點看軟體，就需要有軟體設計文件。

(4)軟體設計文件本身需要是一個穩定的參考資料，簡述軟體的所有部份及其工作原理。

(5)一般會建議此文件可以提供相對完整的描述，但又可以以高階的觀點來看待軟體。

2.軟體設計文件可以分為兩種：

(1)HLDD (高階設計文件)：描繪出系統高階的抽象樣貌。

(2)LLDD (低階設計文件)：描寫實作的細節。

3.軟體設計文件包括以下的文件：

(1)資料設計：

a.描述軟體中的結構。

b.物件的屬性和物件之間的關係會影響資料結構。

(2)架構設計：

a.使用資訊流動的特性，和程式的架構相對應。

b.會利用轉換對應方式在輸入和輸出資料之間建立明確的邊界。

c.資料流圖會包括控制輸入、處理及輸出等三個立的模組。

(3)介面設計：

a.描述內在及外在的程式介面，也包括人機介面的設計。

b.內在及外在的介面設計是以分析模型時得到的資訊為基礎。

(4)程序設計(procedural design)：

a.是由圖像、表格或文字標示的方式描述程序結構的概念。

b.此設計媒介可以讓設計者表達程序的細節，方便轉換為程式碼。

c.軟體實現的藍圖也是後續軟體工程工作的基礎。

※參考資料：

1.https://zh.wikipedia.org/wiki/%E8%BB%9F%E9%AB%94%E8%A8%AD%E8%A8%88%E6%96%87%E4%BB%B6

2.http://www.ctimes.com.tw/art/print.asp?O=HJN75BLKCV4AR-STDN

五、敏捷專案管理(Agile Project Management)

108地三、109高二、111高二

(一)定義

1.敏捷專案管理始於敏捷軟體開發，這種方法論將開發過程分成小迭代 (small  iterations)，從而使決策和解決問題變得更加容易。

2.在每次迭代中，都會設計、開發和測試可交付使用的產品功能特徵 (shippable product feature)。

3.敏捷專案宣言保護著敏捷專案管理：

  敏捷宣言是一套十二條原則，適用於軟體開發。

※參考資料：

http://www.masterplus.com.tw/portal/project/37-%E7%B2%BE%E5%AF%A6%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86%E8%88%87%E6%95%8F%E6%8D%B7%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86%E7%B0%A1%E4%BB%8B/

(二)主要概念

1.迭代開發(Iterative Development)：

  (1)敏捷開發將產品開發工作分解為小部分 (small increments)，從而最大程度地減少了前期計劃和設計量。

  (2)敏捷專案經理不是將目標定為未來幾個月或幾年的目標，而是與團隊合作，將工作分解為可管理的小塊 (chunks)。完成這些迭代可能需要幾天或幾週的時間，具體取決於工作量 (piece of work)。

  (3)最大程度地降低了風險，並且允許開發過程具有靈活性。

  (4)這些迭代中的每一個目標都是在每次迭代結束時創建具有最少錯誤的價值。

  (5)工作軟體 (working software) 或者可工作產品模組是進度的主要衡量標準。

2.高效溝通(Efficient Communication)：

  (1)面對面的對話是敏捷專案的核心和靈魂。敏捷會議 (Agile meetings) 提供了一種在面對面環境中進行交流的方式。

  (2)敏捷專案的會議具有特定的目的和特定的時間量，以便使開發團隊有時間工作，而不是花費時間參加會議。

  (3)敏捷工件 (Agile artifacts) 為結構化的書面交流提供了一種格式，但並不麻煩或不必要。

  (4)對於專案經理來說，敏捷開發週期 (Agile development cycle) 可以實現更好的溝通。在迭代過程中，敏捷專案經理直接與從事工作的人員或團隊進行溝通 (為全球團隊的時區差異留出必要的餘地)，並且及時了解與實現特定價值相關的任何相關資訊。與管理更大、更複雜的工作相比，這使他們可以更加專注於手頭的實際工作。

  (5)敏捷專案管理允許專案經理透過利用他們的時間和精力優化團隊的工作 並幫助消除阻礙價值交付 (delivery of value) 的任何障礙，而不是更新電子表格，從而為團隊增加更多的價值。

3.注重品質(Focus on Quality)：

  (1)敏捷專案管理還可以幫助提高產品和工作品質。

  (2)在交付每一個迭代的價值之後，敏捷團隊通常會透過一次名為反思會議 (retrospective) 的會議來反思自己從迭代中獲得的經驗。然後，他們致力於開發提高品質和增強產品開發敏捷性的方法。

  (3)敏捷的專案經理可以幫助團隊確定哪些特定的工具和技術 (如自動化、結對程式設計和測試驅動的開發) 可以幫助他們改善工作方式。

※參考資料：

http://www.masterplus.com.tw/portal/project/37-%E7%B2%BE%E5%AF%A6%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86%E8%88%87%E6%95%8F%E6%8D%B7%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86%E7%B0%A1%E4%BB%8B/

※規劃撲克方法(Planning Poker)：Scrum Poker

111高二軟體專案管理研究

(一)定義

1.這個詞是 James Grenning 創造，然後由 Mike Cohn 推廣。它是一個簡單但功能強大的工具，使團隊評估更快、更準確，以及更有趣。

2.以共識為主的評估方法，用於評估工作的努力 (effort) 以及相關的大小 (size)。是在敏捷專案管理 (Agile Project Management) 中廣為使用的一種技術，特別是極限編程 (eXtreme Programing, XP)。

(二)使用原因

1.是為了避免其他參與者的影響。如果說出一個數字，它聽起來像是一個建議，並且會影響其他參與者的數字大小。

2.規劃撲克應該迫使人們獨立思考並同時提出他們的數字。這是通過要求所有參與者同時展示他們的卡片來實現的。

(三)好處：用途

111高二軟體專案管理研究

提供了對程式設計的任務完成時間的準確估計。在回合中討論的任務比未討論的任務需要更長的時間來完成，並且有更多的程式碼 (code) 在討論過程中被刪除，這代示對程式碼品質有更多的關注。研究參與者認為它可以有效促進團隊協調和討論實施策略。

(四)裝備

1.計劃撲克基於要交付的功能列表、一副紙牌的幾份副本，以及可選的用於限制討論每個項目所花費的時間的彩蛋計時器。

2.功能列表，通常是用戶故事列表，描述了一些需要開發的軟件。

3.費氏數列(Fibonacci Number)：菲波納契數列

  (1)牌堆上的牌上有編號。典型的一副牌有顯示斐波那契數列的卡片，包括0、1、2、3、5、8、13、21、34、55、89；其他套牌使用類似的級數，每個值之間具有固定比率，例如 1、2、4、8 等。

  (2)使用費氏數列而不是簡單地將每個後續值加倍的原因是因為估計一項任務與另一項任務的工作量完全相同是誤導性的。

  (3)一項工作量大約是5分的兩倍的任務必須被評估為比兩倍少 (8) 或比雙倍多一點 (13)。

  (4)幾種市售牌組使用0 (表示這個故事已經完成或這個故事幾乎沒有，只需要幾分鐘的工作)、½、1、2、3、5、8、13、20、40、100，以及可選的 ? (表示不確定)，一個無限符號 (表示需求明確，但是超過最大的那一張數字卡，代表這個需求需要再被細分成多個粒度較細的需求)，一個咖啡杯 (表示我我太累了，無法思考。我們稍作休息吧)。之所以在13之後不完全遵循費氏數列，因為13之後的數字不確定性高。

  (5)為什麼沒有21？

     a.數字越大，細微性越小。有下列幾個原因：

       (a)通過限制選擇的數量 (即卡的數量) 來加速估計過程。

       (b)避免高估計的錯誤準確性。

       (c)鼓勵團隊將大型故事分成小型故事。

     b.高估計 (如 > 20) 通常意味著故事沒有被詳細了解。討論故事是19, 20 還是22.5是浪費時間的。這只是一個大故事，而20將反映出這一點。如果想詳細介紹，可以把故事分成幾個小故事。可以更詳細地估計較小的故事。

4.採取費氏數列做為每張卡牌的點數的原因：

  (1)使用比例判斷大小相對容易：

    因為在所有估計的過程中，實際上越大的數字代表估計的結果越不準確，當估計一個故事需要20故事點 (story point) 時，那麼21和20故事點差別不大，沒辦法很快速且明確的指出是20的理由。對人類而言，使用比例判斷大小相對容易，當採用費氏數列的卡牌時，一旦決定從13選擇21時，差距將近高達1.5倍，所以能避免估算時發生「到底這個複雜度是20還是21」的這種差距極小的情形。

  (2)鼓勵將較大的故事切成更小的故事去評估：

越大的數字與下一個數字的差距會更大，實際上是變相鼓勵團隊在估算每個故事時將較大的故事切成更小的故事去評估。

  (3)切成較小的故事討論，則調整的彈性相對較大：

    當將所有的故事都切成較小的故事討論時，因為較前面的卡牌彼此之間的數值差距較小，代表可以調整的彈性相對較大。

(五)步驟

111高二軟體專案管理研究

在估算會議上，每個估算者都會得到一副牌。所有的牌組中都有相同的牌組。會議進行如下：

1.一位不會玩的主持人主持會議。

2.產品負責人簡要概述了要估計的一個用戶故事 (user story)。團隊有機會提出問題並進行討論，以澄清假設和風險。例如由主持人記錄討論的摘要。

3.每個人將一張卡片正面朝下，代表他們對故事的估計。使用的單位各不相同， 它可以是天數、理想天數、T 卹尺寸或故事點。在討論期間，絕對不能提及與特徵大小相關的估計，以避免錨定 (anchor)。

4.每個人都通過翻牌同時叫牌。

5.估計值高和估計值低的人會得到一個肥皂盒 (soap box)，以提供他們估計的理由，然後繼續討論。

6.重複估計過程，直到達成共識。可能擁有可交付成果的開發人員擁有很大一部分共識投票 (consensus vote)，儘管主持人可以協商共識。

7.確保討論是結構化的；主持人或產品負責人可以在任何時候翻轉彩蛋計時器， 當計時器用完時，所有討論都必須停止，並且進行另一輪撲克。肥皂盒重新介紹了對話中的結構。

(六)在新冠疫情盛行期間的遠距辦公模式下該如何施行規劃撲克方法？

111高二

當團隊不在同一個地理位置時，可以使用網際網路上的協作軟體 (collaborative software) 來替代實體卡。

※參考資料：

1.https://medium.com/%E8%87%AA%E7%A8%B1%E5%A5%BD%E4%BA%BA%E5%A4%A7%E5%8F%94/tech-planning-poker-%E9%81%8A%E6%88%B2%E5%8C%96%E7%9A%84%E8%A9%95%E4%BC%B0%E6%96%B9%E5%BC%8F-703c3ccf443f

2.https://en.wikipedia.org/wiki/Planning_poker

3.https://dotblogs.com.tw/Unified_Modeling_Language/2019/03/20/170055

4.https://planningpokeronline.com/

六、精實專案管理(Lean Project Management)

[精實專案管理(Lean Project Management)] 1 | 109

109高二

(一)定義

1.起源於製造業，其主要目標是提高最終產品對客戶的價值。

2.是一種源於精實方法的專案管理方法。

3.是一個管理系統 (management system)，致力於提高組織運作的整體品質。

4.考慮了組織中的每一個流程，並且有助於提高每一個員工和每一個流程的效率和效力。它有助於減少時間和資源的浪費，同時提高產品或服務的質量，並且為最終客戶帶來更高的性價比。

5.消除了沒有為最終產品增加價值的任何活動，例如不必要的會議。

(二)使用工具

1.價值流程圖(Value Stream Mapping, VSM)：

  (1)是豐田公司用來定義和優化從頭到尾獲取產品、服務或增值專案所涉及的各個步驟的精實工具。

  (2)典型的價值流程圖實踐會識別工作流的當前和將來狀態，以及進入和退出工作流的所有活動，以便可以交付價值。

2.A3思維(A3 Thinking)：

  (1)是一種結構化的問題解決方法，可以促進有意識的持續改進。

  (2)圍繞問題定義、分析和發展假設，每一個概念都應該小巧且易於管理，以適合一張 A3 紙。簡單地說，A3 思維的核心是持續改善，讓你從普通的問題解決者，成為出色的問題解決者。

  (3)基於 Edwards Deming 的 PDCA (Plan-Do-Check-Act) 模型。它鼓勵組織清楚、準確地定義每一個問題，然後提出計畫執行以解決問題。

3.看板(Kanban)：

  [看板(Kanban)] 1 | 109

  109地三

  (1)定義：

     a.是工作流管理 (workflow management) 的一種可視化方法，使團隊可以可 視化，確定優先級並改進其工作。

     b.透過使用白板上的便利貼建立工作的圖片，來幫助團隊利用視覺資訊的力量。

     c.工作任務一般可分為待辦 (To Do 或 Backlog)、執行中 (In Progress)、待確認 (Under Review) 和已完成 (Done) 四種狀態。

  (2)功能：

     a.規劃工作流程：

       建立一個清楚的流程，並且確保任務在每個階段順利進行。

     b.輕鬆發現瓶頸：優化工作流程，以幫助團隊提升工作效率。

     c.追蹤工作進度：

       視覺提示可以幫助團隊成員了解任務是否已經準備就緒或已經完成。

     d.協助專案經理：

       可以幫助專案經理一目了然地了解所有相關工作資訊，而不必打擾其團隊以獲取有關狀態、瓶頸、障礙等資訊。這意味著專案經理可以集中精力優化交付流程，團隊可以專注於為客戶創造價值。

  (3)四大核心原則：

     a.從現在執行的任務開始做：

       可以應用在任何當前正在執行的工作流程或過程，與敏捷管理流程 (如 Scrum) 擁有明確的定義不同，它具有足夠的靈活性，可以在團隊的核心實踐中使用。

     b.同意追求漸進式的變化：

       一次性的大幅度更改可能會對團隊造成破壞，導入的新系統則可能無法正常工作，框架索引持續改進，以便隨著時間的推移真正發展團隊流程，而非一次全部做變更。

     c.遵守當前流程、任務、職責、職位：

       與其他精實方法不同，它沒有任何內建角色，所以可以維持當前的團隊結構和流程中的工作。

     d.鼓勵各級領導：

       在組織中，從個人貢獻者到高級管理層的各級領導的行為應當受到激勵。

※參考資料：

1.http://www.masterplus.com.tw/portal/project/37-%E7%B2%BE%E5%AF%A6%E5 %B0%88%E6%A1%88%E7%AE%A1%E7%90%86%E8%88%87%E6%95%8F%E6%8D%B7%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86%E7%B0%A1%E4%BB%8B/

2.http://www.rwlee.cn/Read8.html

3.https://www.businesstoday.com.tw/article/category/80408/post/201708140022/%E8%B1%90%E7%94%B0%E6%B1%BD%E8%BB%8A%E9%83%BD%E5%9C%A8%E7%94%A8%E7%9A%84%E3%80%8C%E7%B4%99%E4%B8%80%E5%BC%B5%E3%80%8D%E6%95%B4%E7%90%86%E6%8A%80%E8%A1%93

4.https://www.ekban.com.tw/

5.https://www.devops.com.tw/post/asana-board-view-%E4%BB%80%E9%BA%BC%E6%98%AFkanban-board

6.https://zh.wikipedia.org/wiki/%E7%9C%8B%E6%9D%BF_(%E8%BD%AF%E4% BB%B6%E5%BC%80%E5%8F%91)

109年地方特考三等系統分析與設計

答：

(二)

1.代表人力資源閒置。

2.可以增加工作任務數量避免人力資源的閒置，但是不可以超過工作任務數量的限制 [WIP (Work in Progress) limit]，以免工作效率變低。

3.當設定了 WIP limit 後，每個階段只能處理一些工作任務數量，因此在某個階段流動不順利時，就可以看到哪個地方有工作任務堆積，也就是可以看到哪個地方的開發過程是有問題的。

※參考資料：

1.https://dotblogs.com.tw/mystic_pieces/2019/03/12/223533

2.https://kojenchieh.pixnet.net/blog/post/341622353

※精實專案管理與敏捷專案管理的共同點與差異性：

109高二

(一)共同點

(二)差異性

※參考資料：

http://www.masterplus.com.tw/portal/project/37-%E7%B2%BE%E5%AF%A6%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86%E8%88%87%E6%95%8F%E6%8D%B7%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86%E7%B0%A1%E4%BB%8B/

※傳統專案管理與敏捷專案管理的比較：

※參考資料：劉雯瑜-專案管理6e p.581

七、軟體專案管理量度

※資訊系統軟體量度的主要評估指標：

衡量軟體本身的特徵，其主要類型如下：

1.程式行數：反應軟體的規模大小，可以分為新增、修改與重複使用的程式行數。

2.功能點：計算程式所完成的功能數。

3.文件數：各類文件的頁數。

4.複雜性量度：以程式結構、變數使用及執行路徑來反應程式的複雜度。

5.軟體科學量度：以 Halstrad 的軟體科學 (Software Science) 為主的量度。

1-2 專案管理知識體系(Project Management Body of Knowledge, PMBOK)

[PMBOK(Project Management Body of Knowledge)] 3 | 97,100,110

97技高、100高二、110關簡技

一、專案管理知識體系(Project Management Body of Knowledge, PMBOK)

(一)定義

1.詳細說明專案管理所依循的五大程序群組 (Process Groups) 和十大知識體系領域 (Knowledge Areas)。

2.五大程序群組 (Process Groups) 有起始流程群組、規劃流程群組、執行流程群組、監控流程群組以及結束流程群組。

3.十大知識體系領域有專案整合管理、專案範疇管理、專案時間管理、專案成本管理、專案品質管理、專案人力資源管理、專案溝通管理、專案風險管理、專案採購管理以及利害關係人管理。

※參考資料：https://wizxpand.pixnet.net/blog/post/23435676

二、五大程序群組(Process Groups)：專案生命週期(Project Life Cycle)

(一)起始程序群組(Initiating Processes Groups)

1.藉由獲得授權以啟動專案或者階段，用來定義新專案或者既有專案新階段的過程。

2.為了完成工作，設置了明確的階段以及初始化團隊，並且在工作開始之前製定預算，對於跨行業的任何項目的強大開端至關重要。

(二)規劃程序群組(Planning Processes Groups)

1.為了建立專案範疇、優化專案目標以及實現專案目標而定義行動方針的過程。

2.該流程小組還針對所有項目目標和期望進行了更為狹隘的澄清，並且根據時間表和預算限制實現了這些目標所必需的項目基礎設施。

(三)執行程序群組(Executing Processes Groups)

1.整合人力和資源去進行專案。

2.執行流程小組涉及有效管理團隊，同時協調時間表並期望達到基準目標。

3.利用這組技能的項目經理將展示高度的組織和溝通技巧，同時解決團隊關注或者與在預算內按時完成工作相關的其他複雜情況。

(四)控制程序群組(Controlling Processes Groups)

1.追蹤、審查以及調整專案進度與績效，辨識計畫中需要變更的事項，並且啟動相對應變更所需要的過程。

2.經驗豐富的管理人員不斷前進，通過積極監控進度，利用遠見和快速響應來應對項目挑戰，防止項目停滯不前。

(五)結案程序群組(Closing Processes Groups)

1.完成橫跨所有程序群組的所有活動，以正式結束專案或者階段的過程。

2.該流程小組面臨的最大挑戰就是使項目成功結束，這意味著專案要按時且在預算範圍內完成。

※參考資料：

1.https://zh.wikipedia.org/wiki/%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86%E7%9F%A5%E8%AD%98%E9%AB%94%E7%B3%BB%E6%8C%87%E5%8D%97

2.Team Work.pdf

3.https://ithelp.ithome.com.tw/articles/10212298

4.https://blog.yveslin.com/2015/08/20/pmp-project-management-5-process-groups-xi ang-mu-guan-li-liu-cheng/

※專案管理的五大流程：軟體專案管理的五個階段

109年地方特考三等資訊管理與資通安全

(一)起始階段：定義問題並辨識專案利害關係人

1.主要工作是定義問題，並且針對問題發展出解決方案和專案章程，以及辨識出與專案相關的利害關係者 (如顧客、供應商、贊助者、職能經理等)，使專案順利進行。

2.由於有賴於專案經理的居中協調，使大家達成共識，因此較著重在整合管理及溝通管理這兩類知識。

(二)規劃階段：思考完成專案所需要做的事

1.待問題釐清、專案的目標也明確訂定出來，之後便要進行縝密的規畫，釐清專案「要做些什麼」、「誰負責做」、「該如何做」、「什麼時候完成」、「需要耗費哪些成本」、「需要供應哪些資源」，以及如何預防及減輕風險。

2.一般而言，專案管理在起始及規畫階段通常要投入最多心力，因為計畫得愈周詳，活動切割得愈細緻，顧全的層面愈多，進展到執行和追蹤階段時，就會更加順暢、有效率，進而協助專案目標順利達成。

(三)執行階段：整合各方訊息，輔助專案推行

專案經理的主要任務是運用溝通管理知識來了解及掌握專案利害關係者的需求與期望；運用人資管理知識來建立並發展自己的專案團隊；以及運用採購和品質管理知識來輔助專案的推行。

(四)監控階段：隨時隨地檢視專案是否符合計畫

在過程中不斷監督及控制各個流程是否都符合原先計畫。一旦發現有偏差，就必須立即採取必要措施，將流程導回正軌；但是如果已經無法還原，也要做出修正或彌補，以因應新變數加入之後所產生的影響。

(五)結束階段：將經驗文字化，供後續的專案參考

1.專案經理運用採購管理知識，針對專案中所採購產品或服務進行「合約結案」(驗收賣方完成的工作及交付成果，是否符合專案的需求與標準) 以及稽核審查工作。

2.在團隊成員「專案各個階段結束／整個專案結束」之後，將所學到的成功及失敗經驗轉化成文件化記錄下來，做為日後其他專案的參考及借鏡。

※參考資料：

https://www.bnext.com.tw/article/42016/5-steps-teach-project-management

三、專案管理的十大知識領域：專案管理的組成 / 整範時成品人溝風採利

109年地方特考四等資訊管理概要

(一)專案整合管理：整合系統建置專案中各種資源。

(二)專案範疇管理：確保所需執行的工作與活動均能包含在專案中。

(三)專案時間管理：協助系統建置專案如何有效的安排時程。

(四)專案成本管理：指導系統建置專案規劃時所需的成本估計。

(五)專案品質管理：協助專案進行時的品質維護。

(六)專案人力資源管理：確保以最有效的方式運用人員。

(七)專案溝通管理：協助專案團隊運用溝通，讓專案可以更加正確、有效的進行。

(八)專案風險管理：有效監看風險，藉由定性、定量分析訂定風險計畫。

(九)專案採購管理：確保專案外購的物品或委外的服務能有效獲得。

(十)利害關係人管理

改善專案與利害關係人之間的關係，採取主動和建立彼此互信應是利害關係人管理的良好策略。

四、十大知識領域(Knowledge Areas)和五大流程群組(Process Groups)的關係

※參考資料：PMBOK2012第五版初探有感.pdf