# 專案開發與管理 <中華電信> 共筆
[TOC]

這個筆記是我們講座時用來記錄講者內容與筆記的地方～
希望大家都能參與共同撰寫共筆的過程
此共筆也可以幫助我們的期末報告哦！

參訪連結：https://teams.live.com/meet/9595449804423

參訪問題集：https://docs.google.com/document/d/19qJUzJK-VUCkZcpjj0ahaazwqqcmDlKXnLzHdhCWToU/edit

---

## 大綱（範本上的，可依照講者的內容進行更改）

1. 摘要
2. 目錄與圖表目錄
3. 參訪動機
4. 經歷簡述
5. 開發標準
- CMMI
- CMMI Level 3
- ISO 27001
6. 開發模型
- Waterfall
- Agile
- Waterfall、Agile 比較
7. 實務開發經驗
- code review
- 團隊經營
- PM
- etc.
8. 此次參訪與軟體工程課程之相關性
9. 結論
10. 訪談照片/視訊會議軟體螢幕截圖
11. 參考文獻

---

## 分工
1. 整理資料、摘要
2. 參訪動機、經歷簡述
3. 開發標準
4. 開發模型
5. 實務開發經驗
6. 相關性、結論

---
## 演講內容

早年如果要有公司的標案，需要用到CMMI。
現在 -> Agile（但不完全取代 CMMI）
- 經歷簡述
- 研發工程師
- Task Leader 不知道細節，但會大概知道內容
- Task Leader 特質：研發外，也會注意別人的工作內容，關注別人的完成度，Leader會私下問進度可以分享別人的進度。
- PM (分項經理)
- ICT障礙維運管理系統(ex.資安艦隊、車訊快遞、路口監控)
- 雲端障礙管理系統(雲端服務之資源監控(後端-通報後自動派工)、自動供裝異常單、提前告知該補CPU,硬碟等、維運報修、追蹤、維修品質管理)
- 企業員購網系統（新創計畫、發放福利金(禮卷）、收容各企業）
- ICT
- 支撐公司維運
- 早期只有CT
- 雲端障礙管理系統
- 壞掉 -> 與專案經理報帳 -> 把這張單派給相關的單位派工並追蹤修復的進度
- 雲端障礙管理系統
- 自動派工
- 前端 VM 壞掉要到這邊派工
- 企業員購網系統
- 後端有間通系統去爬往年網站的價錢
- 用最低價買到商品

- CMMI 簡述
- 能力成熟度的整合模型
- 政府會要求廠商的能力要到 Level 2 以上
- 任何一家有管理的公司就有 Level 1
- 5個Level、25個流程
- 導入Level 3，後面就轉到Agile去了
- 
- 現在不太需要 CMMI 認證，所以導入 agile
- 因為導入 Agile ，所以沒有再追求 CMMI 認證
- 需求訂出來就要鎖進建構管理，得到一個標準版，如果因為需求變更就要從建構管理庫 checkout 一個版本，才有最終版本的管控，Agile 的 backlog也有共通點。
- level3: 需求發展會有流程要跟客戶談，引導客戶講出他的需求。(Level 2的只要有需求就好，不管需求是怎麼來的。)
- 整合的專案管理：大型系統需要跟別的系統有合作關係
- 風險管理：人員離職，如何降低風險，解決方案可能是訓練同仁的時候要有 backup 的觀念，demo 時請大家一起參加，大家都能了解狀況，年初會訂出有哪些風險，每個月都會去監控。
-
-
- level3: 訂好風險並提出解決方案
- 組織流程專注：企業關注的點，以 CMMI 為例每一個流程都要訂出一份規格書。
- 組織流程定義：定義成一個範本請大家遵守相關規定
- 研發了平台去做專案管理
- Level 4, 5 往組織的概念去走
#### 研發生命週期 (Level 3)
- 需求發展, 專案規劃, 設計研發(技術解決方案、利用評分機制(決策與解決方案), 產品整合, 驗證（內部自己驗證）&確認（拿給需求提供者，確認是否符合需求), 上線交付
- 決策與解決方案：將各種解決方案，列出所有優缺點，進而決定要以哪一個實作，ex. App 跟 Web 都很好，要怎麼選擇
- 需求管理，風險管理，專案監控、度量與分析...
- 建構管理庫：當有需要對專案某一部份做更動時，需要從建構管理庫取出最新的版本，做影響分析之後再放回開發流程裡。

#### 瀑布式與敏捷開發 Agile 之執行心得
- 敏捷比較抓後半段(設計研發(開發)~上線交付)，較快速
- 敏捷並非強調在研發速度上，而是強調在**反應能力**上(一定程度即可上線，可依照市場變化得到feedback，再做調整)
- 陸續上線，敏捷是對於產品與市場反應能力的強弱
- 技術架構、平台架構要先搞出來，再階段性的把功能丟上去 -> 針對已有基礎的會比較容易開發 (已有基礎的系統研發，更適合Agile)
- 系統初期開發花比較多時間在架構設計（資深同仁、PM），資深同仁打造 Framework，
- 已經有系統的研發比較適合使用敏捷開發
- Daily Meeting 是研發的同仁一起 co-work，適時反映市場的狀況，在敏捷開發要跟需求提供者、創新者、測試者做互動
- 需要讓測試的同仁知道 Know how 才知道測試的重點
- 透過測試人員參與小 demo
- 軟體研發流程各有優缺點，因應市場變化、用戶反應快->敏捷開發，需求穩定度高->瀑布
- 瀑布式和敏捷開發方法之間的切換：以需求變動程度作為依據，可以適當針對執行方法調整，例如調整scrum的頻率。
- 模型只是一個方向，可以針對團隊的需要做調整，都有優缺點

## Q & A
演講問題集
1. 分項經理與PM的差別？ 一樣的
- 在講者的團隊，分項經理 == PM
- 一個計劃裡有很多個分有個大目標在細分目標再細分，每個分項經理等同一個PM
- Task Leader(資深同仁) 負責小小組(小事情、子專案)，PM臨時問進度都是問Task Leader
- 一個分項底下通常有一個專案
- 主管會議：PM(決定是否採納並與其他PM協調人力、時間)、架構師(影響未來的計畫、技術的走向和架構)
2. Level 是去哪裡認證的？
- 有專門的認證公司，顧問會先帶領導入
- 半年或一年後會規劃兩週的時間由顧問跟研究員來評估
- 預算高低會影響有沒有顧問協助導入
- 研究院各所派幾位同仁組成小團隊負責導入，小組也會下去監控執行狀況、對PM要求，PM再要求下面
3. 為什麼到Level 3的時候就不需要 CMMI 認證？
- 流行(坊間對CMMI的要求不高)，以前CMMI對軟體公司是很明確的證明，標案通常都會說要CMMI的認證
- ISO 27001評鑑 (資安方面的評鑑)
- 評鑑標準改變，大家跟著趨勢走不同路
- agile出來之後大家希望研發流程更趨近於用戶端，更快速反應市場變化，所以企業會試圖去導入Agile (適合的前提之下)。
4. 一個公司從 level 1 -> level 2，level 2 -> level 3 平均要花多少時間
- 沒有辦法這樣問耶，depend on the size of company
- 先切分成兩半，一半level 2成功後另一半隔年完成level 2的認證，再導入level 3
- Level 3是政府覺得可以信任的標準了嗎?
- 感覺自然就是要到level 3
5. PM 是要特別去學軟工嗎？這些東西是怎麼學到的呢？
- 我覺得哦...我自己讀書沒學過軟工
- 從做中學，從主管的處世方式學習
- 參加公司課程、自己讀書
- PMP課程提供大家上課 (主管要同意)
- CMMI 導入小組，剛剛好有機會學到這些內容，不是每個人都有機會的哦
- 軟體工程還是對當PM有幫助的。不是很會寫程式(技術能力強)就可以當，主要是管理能力(含管理雜事、情緒等等)要強。
- 管理能力強才當PM，行政事務多要去配合(Ex.關心沒有回傳體溫的同仁)，PM也要涉獵人的互動跟心情，程式能力強的不建議來當，建議當架構師或task leader
6. 規格書是自己訂定的嗎？還是公司本身就有規格書？
- 公司有一定的研發流程(範本)，只是沒那麼制度化
- 導入CMMI後更為嚴謹，才會把重點訂定到規格書中，之後都要遵守規格書的內容 (初期甚至有人負責規格書內容)
- 公司本來有給範本，按照範本設計規格書(導入CMMI前)
- 需求 -> 設計模組 -> 測試案例 (in excel) 作為影響評估的依據、最後也會測試所有相關的testcase
- 相關的測設案例會一併做測試，才不會改A動到B，要去思考相關性
7. 處理障礙系統需要用到 Agile 開發嗎？
- 障礙系統是一種資訊系統，研發過程就可以採用Agile模式，不用把所有需求做好再一次上線，可以階段性的上線
- 需求：單子進來做自動派工、催單
- 從人工審稿走向自動監控，不同的 sprint
- 資訊系統ㄏㄨㄚ

---
## 問題集
- 洪偉豪
1. 軟體專案的品質是如何被定義與控管的？
- ......
2. 是否有實行過 code review？pair programming？若有，實行的結果如何，若否，為什麼不實行？
- 架構師或有經用的同仁做 code review
- 良率達到 85% 才可以上線
- bug單 → 分成重大 bug (寫到資料庫有問題)跟小 bug (訂測試規格書就會訂定出嚴重程度，同仁也會自行判斷)
- Critical, Moderate, Minor是在規格書就會定義了，測試同仁也會自己判斷...
- 沒有 pair programming
3. 如何決定好軟體的需求面？客戶端會有明確的只是還是需要不斷地幫客戶引導與溝通？

4. 以 PM 的角度，以您的經驗底下再開發專案的過程中覺得最棘手的事情為何？
- 時程
- 跟上級要人力來support
- 最困難都是人的問題，有人不好搞ㄞ
- 根據人的特性派工作，也可以去詢問同仁的要求分派工作
- 發生同仁不合要想辦法排解
- 根據邏輯性或功能完整性給予意見，不打code吧
5. PM 以上的經理會對 PM 有什麼樣的要求，還是全權交由 PM 來做專案開發，只要滿足客戶需求即可？

- 丁緒慈
1. 雲端管理系統、ICT 障礙申告管理系統、公用電話管理系統、員工購物網站各自的困難之處是什麼？
- 大同小異，真正需要去學習的是不同資訊系統的業務的know how
- 要了解不同專案的特性
- (行銷的快速反應和活動)
- 如何學習 know how?
- 多去和需求單位討論
2. 如果會議中雙方僵持不下，會怎麼處理呢？
- 看狀況，如果純粹研發技術議題有所堅持，會請雙方做研究然後報告給PM聽，PM決定適合的方式 (統整不同面相做決定，包括上層)
- 技術：雙方研究->報告->抉擇
- 流程：評分表->決定
- 喬人力資源時間等：請上一級幫忙要
- 若真的協調不出來，請上一級的主管做決定
3. 如何維護程式的品質？
- 單元測試 → code review (單純code的話)
- 功能業務流程:利用測試案例
- 其他的(beside code)：測試案例，功能性、業務性的測試
- PM底下分為測試團隊及專門寫扣
4. 曾經被問過「如果工作無法在預定時間內完成，會怎麼處理」，想請問以 PM 的角度，會希望工程師怎麼處理呢？
- (大家一起快樂)加班(請同仁幫忙一下) 挖屋OMG 哇嗚~~~ (歡呼...
- 緊急狀態+loading決定加班多久。只是現在不能加班加那麼久了，而且同仁們也會反彈哦! Sol: 讓他們覺得加班好棒，有意義
- 時程可以調的情況下，PM也會去做協調。若真的無法，加班哪！
- 做資源的調配，平均的loading和資源是PM需要考慮的哦!
- 現在的人加班比較不能加班太久
- 加班能想到的解決方法可能會比較多
- Waterfall延宕較久(要達到每個milestone)嗎? 不這麼認為，but有些功能可能拖到太久會被忘記，agile一開始就把功能分散，我覺得比較好，且可以搶先其他企業上市。
- 使用agile加班時間會變少(or變彈性)嗎?我不這麼認為，因為要趕時程，在對手之前搶先上市
- 如果注重的是因應市場變化，所以也會因此讓PM急著想要搶在競爭對手前交付產品
- 團隊同仁跟 PM 是否有相同的目標(企圖心、認同度、成就感)，避免感到無趣
5. 團隊通常多少人？會怎麼分工呢？
- 測試團隊：不屬於某個專案，可能同個部門的專案都交給他們測試(可放在研發同仁或獨立)
- PM 管 10~12人，不超過 15 人
- 雲端：很大的系統，所以有多個 PM 管不同層次
- 研發同仁(打扣的，包含架構師)：分成資深與新人

- 郭晏昀
1. 想請問在實際上運用Agile上，有沒有什麼困難點？
- 雖然會在每次sprint挑要做的項目和預估時間，但是難免sprint結束還是沒完成，因為身上還有之前的功能要做or行政事務，導致時程受影響，但可以延續到下個sprint，but間接影響整個專案完成時間，有時真的沒辦法排解
- 受到臨時性事務干擾
2. ~~當團隊中有人延遲進度，影響到整個專案的進行時，該如何進行處理？~~
3. 管理一個團隊要注重很多小細節，例如進度、多樣的意見、能力問題...,想請問在當PM時，有沒有什麼管理技巧？
- 碩士以上的學歷大家都好棒棒不會每天盯狀況，兩週開一個檢討會，請大家demo (展現成果)，在會議上面會做相關的呈現跟討論，有狀況會調撥同仁協助他。
4. 通常在開發一個專案的時候，會最在意專案的哪個部分？例如：品質、需求、功能...
- 都在意
- 一個做不好都會影響到別的項目或階段，沒有priority
5. ~~當客戶臨時提出需求時，關於增加新的backlog以及為了不影響目前已經在進行的進度，通常的處理流程會是什麼？~~
6. 鮭魚幫我問一下在調撥人力的時候會不會考慮人月迷思的東東？
- 加人不會減少時間，需要溝通的時間：n*(n-1)/2 (slide上的公式)
- 可能會有影響，但是現在不完成，milestone會影響不了
- 調提早完成且能力足夠的同仁去support他
- By Critical path in PERT chart，調度適當的人力
- 還是不能完成的話，就跟需求單位說 (盡早讓老闆知道)，同仁也應該要盡早提出，才可以提早部屬，PM再提早告訴經理此風險
- 不能保證進度不受影響，權衡之下找傷害小的

- 陳昭汝
1. ~~若團隊成員之間有糾紛或意見分歧，通常如何解決？~~
2. 在時間短的情況下，會帶給團隊成員壓力大等負面情緒，有時為了比別人更早推出該軟體而無法避免此情況發生。但也曾聽說過有的公司會給予能夠在短時間內完成專案的團隊金錢上的獎勵，激發團隊成員的動力。想請問以PM的角度，會覺得此種方法好嗎？另外，您以前的團隊是以「給予時間壓力」還是「足夠的時間」的模式給予時間限制呢？
- 第一個問題：Good (有時候是需要的? ，但是如果團隊氣氛不好也沒用
- 第二個問題：年初會跟產品分公司討論今年要做的需求，以這一年不會再成effort太中的角度去評估，會以時間足夠的角度去考量，但agile會中途插進一些緊急的需求，所以在那種情況下會造成時間壓力，就必須請同仁幫忙，所以 PM 要跟同仁保持良好的感情，了解家庭狀況，革命情感哦。
- 中途會插入其他需求，擠壓到原本的需求
- 接受時間壓力的方式
- 專案願景，讓同仁了解，傳達給同仁知道 (成就感)
- 給他糖吃，如果與團隊成員處得不夠好，再多錢都沒用（？ (金錢誘惑)，但不應該是主要的(?
3. ~~因為您之前曾經參與四個專案產品的開發團隊，想請問這四種專案管理方式有什麼不一樣嗎？還是其實都大同小異？~~

- 謝承彧

1. ~~穩定的軟體開發需求真的存在嗎？如果在使用waterfall的時候發現有軟體需求變動的話，通常怎麼處理呢？~~
2. 如果使用敏捷開發方法，會不會遇到客戶不太合作，不好溝通的情形呢？如何解決呢？
- agile 在開始先講好需求，而且是他拍板確認的需求（會畫押過），需求規格書會在回傳回去給產品分公司（需求端），避免之後的需求變更太頻繁
- 能夠掌控的是確認需求，如果是客戶本人的個性問題就沒辦法處理
- 寫完客戶需求規格書後，請需求單位的窗口簽核，此為畫押
3. ~~面對眾多利害關係人，如果他們的需求有衝突時，會怎麼協調但又不傷感情呢？~~
4. 在向上面報告專案評估的時間時，通常都怎麼報告才可以要到最合適的時間呢？上面的人會知道如果把時間壓縮下面的人要付出的努力會增加很多的事實嗎？(Putnam model)
- 這是 PM 的責任！會先了解需求單位的需求有哪些，今天訂出今年能做到的範圍，一定得要的需求一定要做，有沒有其他的需求可以先湊合著做，做簡報，報告個功能的特性、技術，長官可能有些東西更重要要先做，所以 PM 要去跟老闆做溝通協調。
- (2)長官也會有臨時壓力，但是可以看有沒有現在適合的人可以調過來，若真的不行PM可以跟老闆協調。真的都不行就只能拜託同仁去加班。
- PM要調配人力、調整資源，把事情順利處理掉，如果沒資源只能盡量跟老闆溝通
5. ~~如果有使用過Pair programming的話，實際上兩個人一起打程式真的會達到預期嗎？會不會有什麼預防措施，讓這項機制可以達到它的最大效益呢？~~
- 沒有使用哦

- 余侞璇
~~1. 在您參與的四個專案開發團隊中，身為PM，您認為最常遇到(出現頻率最高)的困難
是甚麼？~~
~~2. 根據您的經驗，您認為使用waterfall有沒有需要特別注意的地方？~~
~~3. 根據您的經驗，您認為使用agile有沒有需要特別注意的地方？~~
4. 您認為一個優秀的開發團隊需要具備哪些特質？
- 人員：PM、架構師、研發人員、測試人員
- 人的彼此互動、氣氛要好、會分享，才會長久
- 一套的管理方式
5. 如果發現某位同仁不好，PM如何處理？
- PM 要觀察每個人的特質，並給予適合的工作
- ex. 發現某個脾氣壞的同仁對女生不會這樣
~~5. 您最常使用哪種專案管理方式？為何會選擇該專案管理方式？~~

### PM要根據人格特質調配、分配人力 (分組)