常見問題A

A：公司: 文化、風氣、高階主管支持

A1: Scrum PO要怎么跟管理階層溝通計劃進展？

因為上層都會說要訂WBS，先將時程安排下來，但Scrum比較都屬于短期目標，很難訂長期的規劃時間 。當項目急的時候，主管就會開始進入”有追有進度”的模式，甚至細到每一個人把時間花在哪，認為這就是精益(Lean)！要如何管理以便符合Scrum和主管的需要？

優普豐敏捷顧問回答:?

任何的項目管理手法，最好是高層、中層及低層人員大家要一起先建立共識，是要采用純PMP瀑布手法？純敏捷開發？還是雙模混合模式？

近期：就這問題的情境，目前應該是混合模式，產出的工作藍圖沿用WBS，而每個工作包可依照時間優先排序后，視為產品待辦清單，搭配Scrum的迭代規劃會議，進行兩周工作的規劃，每日Scrum站會來分享進度，并進行評審及回顧會議

遠期：跟高層舉辦共識會議，未來仍要用混合模式還是純Scrum，但前提要先厘清該項目的客戶需求是高確定性還是復雜多變！

A2:實踐上，項目除了Code開發，還需要許多匯報、協調、跨Team溝通或行政事務。項目經理在敏捷導入中該如何采納轉型?

優普豐敏捷顧問回答:?

建議可令Project Manager 行使Scrum Master職責（SM不是一個職位，也不單純是一個角色，更是一個責任），充分了解敏捷精神并實踐相關實踐。

在 《Scrum指南》 并未定義對公司進行匯報、協調、跨團隊溝通或行政事務是由PO、SM或Dev Team誰來處理，但是我們身為CSM是否要去思考這些工作內容是否反敏捷? 如果是的話，日后我們如何讓公司管理階層投入敏捷，創建一個更支持敏捷的企業文化。

A3:如何解決依賴Dependency的問題

優普豐敏捷顧問回答:?

Dependency 問題通常來自于DT 無法單獨完成客戶的所要的 Feature. 有四個方法可以解決. 設原有的 Feature 需4個 Functional team A->B->C->D 方能完成:

1.完全移除: 將團隊納入 Dependency 的團隊，這需要比較大的權限，需Management的投入.

2.減弱:  假設該 Dependency 由一個A 負責團隊所 own, 而這團隊正在忙其它的事務。此時可以由其它團隊來修改 Code, 但實際上線前仍由owner 團隊來派駐評審和把關質量

3.透明和持續曝露: 善用自動化的CI/ CD

4.管理力量的介入: 聯合 Sprint 會議, Task board 管理, Review Meeting

常見問題B

Ba： 敏捷運作:  敏捷運作原理不熟悉、 敏捷會議操作不順暢

Ba1：成員的能力差異大，無法如時交付產出或是質量不一。

優普豐敏捷顧問回答:?

每個人的個性和能力本來就是差異很大，特別是腦力型的工作環境中。

個人能力要予以投入培養和刻意練習，管理者的責任是成為園丁，給團隊要創造一個互相Polish(打磨碰撞)的環境，取長補短，形成跨職能團隊。另外，師傅帶徒弟、結對編程(Pair Programming) 也是很好培養能力的方式。

時間是主觀、靠經驗值預估的，即使再資深的PM也難以給出準確的估算，除非之前有做過類似的項目經驗。因此，在敏捷的每一個Sprint 過程中，也會讓估算越來越符合實際產出。

Ba2:評估工作項的所需工時的時候，如何避免短時間可完成的項目，成員預估過高?

(例如修改表單可能實際做3小時，但預估需要大改所以要21小時)

優普豐敏捷顧問回答:?

敏捷不是避免犯錯，害怕犯錯，懲罰犯錯。而是從過程中求取寶貴的經驗，估算不準確沒有關系，迭代回顧會Retrospective 可以提出討論，以及找出未來類似狀況下，要如何因應的機制。發生錯誤是可預期且OK的。但能不能保持持續改善，才是重點。也就是說一個3小時可以完成的任務被團隊估成21小時，于Retrospective 時，擔任PO/SM的主管可以給予修正的建議。于下一個Iteration時，再觀察是否類似任務工時估算膨脹的情形發生。

估算就是拍腦袋(主觀)，并不存在絕對正確的“預估”，即時是有做過類似任務也不能保證和昨天的結果完全一樣。通過分解、持續面對面討論，PO與Team協作編寫Acceptance Criteria(驗收條件)，都是有助于加深理解，從而對細節達成一致理解，估算也會更加接近實際。另外，人員的經驗能力培養，允許從失敗中學習，也會使估算也會更加接近實際。

Ba3:如何判斷”人”不勝任 Agile 需要回到以前的 瀑布模式？

優普豐敏捷顧問回答:?

建議可觀察成員是否具備Scrum價值觀中的特質：Commitment、Focus、Openness、Respect、Courage。觀察團隊成員是否能夠自組織自管理，經過多個Sprint(Iteration)后，團隊成員仍無法遵從團隊規范(Team Charter/Ground Rule)或完成Retrospective中改善要求。建議讓該成員離開團隊。

身為好CSM思維不應只有 0 與1，如何把一不勝任 Agile 的團隊成員引領為自我組織的成員也是很好的挑戰，如喬布斯的Parable of Stone視頻，石頭和石頭互相敲擊, 團隊才能往前成長。怎樣培養團隊的開放性，也是SM存在的價值。

Ba4:請問每個 Sprint 的結束跟開始時間是否需要隔一段時間準備下個 Sprint 的計劃會議，還是這個sprint就可以召開下個 Sprint 的計劃會議？

優普豐敏捷顧問回答:?

依照 Scrum Guide, Sprint 與 Sprint 之間是無縫接軌的, 若隔周周一是每個 Sprint 的開始, 就維持固定這一天開 Sprint Planning. Sprint 不宜時大時小, 會亂了團隊的步調. 故, 若 Sprint 尚在進行中, 已經沒有Feature可以做, 可請PO和DT增加能做到DoD的User story, 最好不改變Sprint goal. 不用為此而提前召開Sprint Planning.

Ba5:如果 Agile 是可以接受不斷改變，那 release date 需要訂出來嗎?還是需要每個 Sprint 調整?

優普豐敏捷顧問回答:?

Release date/上市時間固定或可調，要因開發的產品或服務而不同。有時上市時間很死, 需倒推要做什么工作。有時Release date 無法達成，就采最高價值舍棄低價值的features。如果該產品或服務是可能有對手競爭的。團隊在開發前便已一起參與Release date的制定，通常會因為已達到目的而提前，不會延后。開發的目標本就是一個預訂的方向與上線時間。用敏捷方式來開發產品或服務依開發的目標進行不斷的調整(改變)。

Ba6:遇到完成不了 task的狀況，是直接放入下一個 Sprint 嗎? 重新估時(or 累積估時)

優普豐敏捷顧問回答:?

PO 在 Sprint planning 把該 Sprint 要開發的  User story 說明給團隊聽. 團隊再依自我組織方式將這些User story拆成 tasks. 依 Scrum Guide, 未完成的 task 應放回 Product backlog, 由PO重排優先順序在未來的 Sprint planning 重新發包給 DT 來開發. 若是未來再拆成新 Tasks, 理應由接球的成員重新估算時間. Task的估算不像User story一般需由團隊一起估算, 而是執行的人估算即可. 估算單位為工時.

Ba7:遇到大型且流程相關復雜的項目(MVP很大)在MVP部署(Deploy)之前，可有項目方法檢查需求是否要調整

優普豐敏捷顧問回答:?

MVP是指以最小的投資取得最大化對客戶需求的學習。這是一個正常的項目，每個Sprint 皆依該 Sprint 應完成的DoD即可, 怕的是會有些技術債及Undone features可能無法在該Sprint 內完成. 

以下為一個IT系統較完整的DoD. 一開始團隊能力不足, 可能沒有辦法一次全部執行, 可以先完成Green的部分. 后續團隊能力會起來, 團隊默契會越來越好, 自動化工具會越來越多, 可以再多實施Yellow的部分. 如果達到Red的部分, 幾乎所有系統部分問題都可以卡下來了, 只是在于團隊能力是否可以做到而已.

MVP Agile Alliance 定義： http://bit.ly/2QtTin8

A minimum viable product (MVP) is a concept from Lean Startup that stresses the impact of learning in new product development. Eric Ries, defined an MVP as that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

Ba8:如果晚期需求變更跟原先方向差異過大，會造成項目無法準時交付該如何處理?

優普豐敏捷顧問回答:?

每個Sprint都與PO討論并細化需求、每個Sprint都將成果展示給需求者，并取得需求者的回饋，取得需求的變化走向，需求晚期是可能與原方向差異大，這是正常的現象。但敏捷的精神本來就是擁抱變更來發現使用者的真正需求。若是因為變更需求太大，導致無法準時交付，其實不會在最后才發現，而是過程中就會發現。PO需諒解團隊無法準時交付，SM也需努力保護團隊，使PO不會予取予求。

Ba9:成果(產出物)之質量如何確保?

優普豐敏捷顧問回答:?

敏捷團隊以DoD 來確保每個Sprint的質量。一開始團隊能力不足可以實施少量的質量把關機制，后續能力起來了可以再增加更多的質量測試。請參考B9。

Ba10:Scrum 如何運用在測試/驗證? (有限時間/人力) 

優普豐敏捷顧問回答:?

是否應用Scrum，先決條件仍是判斷開發的商品或服務，甚或是公司文化是否適合使用Scrum。比如用一把小刀轉開螺絲或是挖土，應該做得到，但是否合適？容易上手？或有效率？

如果測試/檢驗的內容所需技術都不是太確定，是可以考慮套用Scrum架構。成員們討論并估計測試/檢驗的大小，PO排序優先順序，計劃本Spring完成哪些，邀請Stakeholder參與驗證”測試/檢驗”、并給予團隊回饋意見，然后進行下一輪的Sprint。最重要的是對PO有價值，團隊有成就感&拿到錢，雙贏。

Ba11:Task 在 Task Board 的 Done 和 DoD 是不同的, 對嗎？

優普豐敏捷顧問回答:

在Scrum的Task Board有US (User Story) 及Task之分, US要放在Done的話要滿足DoD, 但是Task則不用. 一個US可能被拆解成10個Task, 這10個Task要滿足什么樣的條件需DT討論出規則即可, 但若US要放在Done 欄位則需滿足DoD.

Ba12:task done是否要更新燃盡圖？

優普豐敏捷顧問回答:

Task 本身并沒有故事點數, 有點數的只有US, 所以task完成后不用更新燃盡圖，US才需要.每個US完成后, 可以即時給PO驗收, 驗收OK再更新燃盡圖.

Ba13:燃燒圖是依工時或故事點？

優普豐敏捷顧問回答:

要看管理者最關心的是什么。時間軸單位是release還是sprint。

敏捷的burndown沒有規定一定要用什么單位。

Bb：敏捷運作實踐_五個事件及項目

Bb1:?要不要中斷進行中的Sprint？

如果上級有ㄧ個緊急任務要團隊的人去執行，而這時也才開完?Planning?會議開始一個?Sprinit，SM?說要等?Sprinit?結束后下一個?Sprinit?執行，這時是要怎么做呢？??謝謝！

優普豐敏捷顧問回答:?

通識專才是敏捷團隊培養成型后的組織特性，所以這個不會是大問題，同樣的工作會有別人可以勝任。但是在整體工作量上，可能會有資源短缺不足的狀態，SM要與PO同步，并且要團隊的成員一起取舍，若是這個人力損耗無法避免，看看Sprint goal會不會被這個影響到。若是不會，看看什么work item可以犧牲，若是會，只能Sprint砍掉重來。

同時，SM身為change agent，要教育好上級主管敏捷的好處與精神，讓組織了解敏捷的本意與思維，最后再分析團隊成員任意變更的潛在負面效應。（切勿倒因為果去先講壞處；對于不懂敏捷的人來說，會被誤認為『找理由搪塞』）

緊急任務真的很緊急嗎？或許可以等一等。緊急任務容易使大家忽略了真正“重要”的任務。假如真的是緊急，可以采用置換原則，從Sprint換出一個優先順序最低的任務，從而維護節奏。注意，任何緊急任務都要通過PO才能交予Team。

Bb2:若無法在每個  Sprint 內將問題解決，導致無法順利 release 交付物時，應如何處理?如何避免發生?

優普豐敏捷顧問回答:?

在回顧會議中，討論問題的情境，操作方式：

1.團隊要能具體描述問題

2.用5Why法探索原因

3.提出3~5個解決方案

4.一同選出一個最佳解決方案

5.獲得大家的認同

6.用便利貼寫成一個行動方案

7.放入Product backlog

8.作為下一個Sprint要執行的方案

Bb3:如何執行一個好的回顧會Retro ? ( 畢竟華人比較不勇于開口)

優普豐敏捷顧問回答:?

Retro 有很多開會的方式. 有兩種方式: 

第一種方式是Retrospective Process：

1.Set the stage

2.Gather data

3.Generate insights

4.Decide what to do

5.Close the retrospective

第二種是WWW及EBI 都可以用便利貼方式來寫出意見. 為求聽到真聲音, 卡片可匿名. 

WWW: What went well

EBI: Even Better If

第三種是LS釋放性結構共創工具箱（Liberating?Structures）。

在一些 Retro 作法,可以在一開始讓大家先 Check in, 用簡單的問題讓大家在一開場都能有發言, 如此先開了話匣子, 后續更容易帶動討論.

常見問題C

C. 團隊管理: 一人多工 (同時多個項目) 、團隊成熟度不足、責任心不夠

C1:客戶或PO對產品需求本身也不是很清楚，如此可以跑Agile？會不會造成予取予求或不符成本之現象？

優普豐敏捷顧問回答:?

Agile?敏捷管理正是為了應對變化和不確定性而生，產品需求也是在不斷的回饋中慢慢清晰和調整的。解決業務問題，符合市場需要才是企業生存的根本，而不僅僅是為了符合預定計劃中的成本時間要求。要完成的工作量是PO?和?Team?達成一致，才不會有PO予取予求的現象發生。

敏捷沒有予取予求、任意索取而不考慮成本的問題，因為以每一個Sprint為單位，只做當下高價值的items，做到沒有價值時結束。如果怕有成本的控制問題，可以把故事點數轉換成單位成本，團隊用掉多少工時就向客戶/PO 收取多少費用。PO、SM及團隊要盡量謹守穩定的步調規則，別有工作峰期忽高忽低的情況，即可持續產出高績效。

敏捷強調團隊swarming effect(蜂擁而上)，群策群力，互助提出援手，責任是共同的。敏捷要培育通識專才，藉由工作的pairing(結對)，cross-training(跨職能訓練)，讓每個人至少成為π型人才。

PO不是一個client relationship manager (客戶關系經理)而已，這個角色要能夠對于市場走勢洞燭先機，對于產品未來嗅覺強烈。敏捷沒有予取予求，不符成本的問題，因為以每一個Sprint為單位，只做當下高價值的items，做到沒有價值時結束。

C2: Scrum Master可以同時兼任Dev Team成員或PO代表？

優普豐敏捷顧問回答:?

在人力不足的情況下，SM是可以兼Dev Team的角色。但全職的SM，自然可以專注在敏捷團隊的帶領。

在SM 身兼 Dev Team時，在任何場合或時刻，這個人若是要發言，或是要與項目成員互動時，當下自己頭上戴的是哪一頂帽子（也就是角色為何），不能同時兩個角色交叉浮現（雙重人格）。

SM可兼職，但盡量避免與PO重疊，因為一個是守護團隊福祉，傳達敏捷思維的人，一個是商業利益導向，客戶價值優先的人，在利益沖突的考量下，把這兩個角色擺在同一個人身上，到最后團隊成員被犧牲的機率非常大，敏捷平衡一旦打破，穩定的步調無法維持，客戶拿不到最佳產出，團隊也創造不出來可能的好價值。

C3:目前PO多是由主管擔任，但似乎應由產品或業務部門擔任，請問何種方式較為合理? 若應由產品或業務部門擔任，TL主管適合擔任何種角色?

優普豐敏捷顧問回答:?

誰對于產品路線發展，以及最后成敗負全責，就是PO（他絕對不是任何人的棋子，也不是任何的傳聲筒，他對于產品的方向有絕對的自主權，并且能夠與團隊成員每日互動至少三小時以上）重點是同時要把PO當作是團隊成員的一份子。

PO適合由產品或業務部門派有決策權的人擔任之，須能與團隊共同工作，隨時厘清團隊的需求。但當產品或業務部門無法派適當的人選擔任PO，則主管出任PO是一個選擇（同時也要清楚地知道這樣做的弊端），因為PO負項目成敗之責。注意，授權要足夠充分情況下才能這樣做，否則PO無法決策，實際的決策權還是在產品或業務部門手上。

若PO由產品或業務部門有決策權的人擔任之，主管適合擔任SM角色，給予適當的協助。

所需要注意的是，PO也是需要經由足夠的敏捷訓練，方能成為稱職的PO(CSPO是不錯的任職認證要求)。要不然只會一味地打亂成員的步調，對團隊予取予求，造成團隊疲于奔命。或者，要求不當，造成將帥無能，累死士兵的情況發生。

若是PO神龍見首不見尾，只有出現在Scrum Planning 及Review Meeting的話，這個不是敏捷的思維與做法，也不會得到敏捷可能帶來的好處。

C4:?課堂上說Sprint與Sprint中間不可改變Sprint Goal，但實踐上幾乎不可能

(E.g.主管臨時交辦、線上系統有緊急bug…etc.)，請問有無合適的處理方式? ?開發人員預留緊急交付項目處理人力或加班處理非Sprint項目議題?

優普豐敏捷顧問回答:?

所謂的敏捷Sprint 開始后不變是指Sprint Goal 盡量不要變動，Sprint Goal是指PO在此Sprint 所要完成的功能，但是這些功能底下的工作任務則掌握在Dev Team身上，是可以因應需求調整修改或是刪除的。若是真的有新的需求(User Story)，則是先擺在Product Backlog，待下一個Sprint 再開發 。或預留一些工作量的buffer，以應對可能的變化。

如果真的有需要插單，可以檢查一下在這個Sprint 有沒有尚未開始的User story, 用交換的方式，但可能的風險是大小不一定相等，也可能要花時間拆解任務。但至少交換的方式比新做一個User story 好。 另，如插單情況常常發生，每次選定任務時，保留一定的緩沖，作為突發狀況的處理。同時，也可以評估Scrum 手法是否適合團隊。救急不是辦法，可以回到源頭找出根本解決之道。

一個好的敏捷實施PO、Dev Team 需要有共同的共識，如果PO一味地忍不住在已經開始的Sprint 提出新的需求，自然會打亂 Dev Team 穩定的步調。但，敏捷精神是Customer Collaboration 及 Responding to change，客戶有緊急需求的變更，還是需要配合。

C5:執行的項目類型是自主研發，客戶并沒有強烈的需求而是由主管每周group meeting方式追蹤進度，請問這樣的形態要如何逐步導入Agile?

優普豐敏捷顧問回答:?

有沒有市場時間表的壓力并且傳達給研發單位？

有沒有產品路線圖的方向？

有沒有一個好的PO？

可否在一個Sprint 內產出客戶能驗收的Increment(產品增量)? 

上線交付的目的和市場價值在哪里？

這幾個條件缺一，建議不要硬導入敏捷，不用為導入敏捷而敏捷。若是以前的方式可以做得很好，為何不維持?  

敏捷有其適用條件，就是符合快速變動環境、需求不確定性的項目。如果，一個規格或是目標明確，已經有具體作法、反復執行過多次的項目，用瀑布式的方式，反而成功機率高并且單純。

瀑布式項目的優點是規劃充分考量，包含十大知識領域，如整合、范疇、時程、成本、質量、資源、溝通、風險、采購及利益干系人管理。這些預先規劃皆可擺在敏捷項目之前，可以有效提高敏捷項目成功機率。

當我們把瀑布式及敏捷手法混合使用，稱為Hybrid雙模手法。可以有效地提高項目的成功機率，也可以大幅降低一家習慣導入瀑布式項目公司推動敏捷的阻力。

C6:可否分享如何”有效”引導團隊形成自組織”Self organized”?

優普豐敏捷顧問回答:?

讓團隊能形成自組織的關鍵是授權、不干擾、觀察支持、創造環境。先要不管！（Leading, not Managing), 以下方法可以有效激發起團隊的自組織.

1.把問題帶給團隊

2.忍受錯誤及陣痛學習期

3.培養積極主動的行動文化. 問一下每一位員工你為什么來這里工作？(Motivation)

4.從招聘開始, 尋找Open-minded的人, 愿意不斷地學習. 對本公司及技術充滿熱情, 充滿好奇心及愿意做不同事情的人. 

5.打造全棧或一專多能, 實現任務分配的拉動系統 (按優先順序別)

6.團隊共同對目標作出承諾, 從實現目標獲得成就感

7.沒有個人的失敗, 只有團隊的失敗

8.簡單的、可視化、 即時更新的工具

9.充分利用團隊內部互相匯報機制, 如計劃會議及每日例會全體參與

10.成員面對面坐在一起

11.多做結對工作

12.簡單的團隊約定規則, 包括DoD等

13.不斷的審視團隊有沒有功能障礙

14.引導團隊充分利用回顧會議來做持續改進

15.避免人員經常更換

C7:  “IT” 傳統角色定位 “PM,SA,SD,PG” 如何轉換成 agile “PO, TL, Developer” 過渡期如何減低陣痛?

優普豐敏捷顧問回答:?

傳統角色直接轉換為敏捷三角色肯定會有陣痛和排異反應, 實施敏捷的單位需要有強烈的導入動機, 自然可以克服. 建議過渡轉換流程如下: 

1.先確定三角色（PM中個性適合的人過渡為Scrum Master, SA過渡為PO  剩下的人皆是Developer）

2.大家熟悉三角色的職責

3.彼此說出: 喜愛的溝通方式、脾氣的接受區間、彼此的雷區

4.一同訂出團隊的工作協定

5.先試行2個Sprint

6.每一個Sprint都要都要一同回顧檢討及修正

C8:如果在資源上的考量，有人同時在Sprint以及新項目中該分開管理或合并 (eg:晨會)

優普豐敏捷顧問回答:?

Scrum會議每個都有其目的，通常是要發會團隊的自我組織。而公司的管理會議是管理的機制監控，員工是否達到其績效。如果目的相沖突，就不建議合并一起開，要不然就會形成表面是敏捷會議，內里是管理監控機制. 那就是偽敏捷了。

C9:Scrum如何組成跨公司團隊? (外部伙伴/委外廠商)

優普豐敏捷顧問回答:?

外部伙伴/外包廠商的人員要成為三角色的一員（開發團隊），初期2~3個Sprint要積極參與面對面會議，項目的有時候可以接受用視頻會議方式＆電子任務板等來進行溝通.

C10:Scrum團隊的組成是由誰來組織?

優普豐敏捷顧問回答:?

SM或DT沒有負責召募及裁撤成員的權力, 這是屬于管理階層的權力, 有時可以從內部召募適任的人來形成 SM+DT, 若內部無人力可再外部召募. 在此, PO我們假設是外部客戶, 不會管理公司內部的員工. 

C11:Scrum Master 應該同時接住 Dev 工作嗎?

優普豐敏捷顧問回答:?

如果人力不足時, SM也可以接DT的工作. 就是角色扮演要清楚. 例: 他在 Daily Scrum 也是要報告三個問題. 同時若發現有人在 Daily Scrum 討論三個問題以外的問題, 也要隨時糾正.

SM唯一不能兼的角色是PO, 因為PO是要求團隊績效, SM則是保護團隊避免被PO予取予求. 兩者由同一人角色扮演, 會形成角色失衡.

C12:Scrum Dev Team 應該同時承接2個以上的項目嗎?

優普豐敏捷顧問回答:?

就公司的商業利益及成本來看，開發團隊只做一個項目是很難的，故可能同時承接2~3個項目，但要做好自己的時間管理和PO間的協調（輕重緩急）

敏捷的精神是期望團隊可以做到Co-location與Delicated. 做兩個項目是沒有符合后者, 但是公司的成本考量一人做多個項目只能折衷. 故, 僅能讓成員做最少的項目及一次只做一件事情 (不 Multi-tasking)

C13:團隊如何證明自己在錯綜復雜的工作中越來越有效?

優普豐敏捷顧問回答:?

個人的部分可以用用戶故事完成及被允收的情況來評估, 團隊可以用交付產品讓客戶允收及滿意度來評量, 團隊可以用每個Sprint的速度來評估, 團隊可以用共好的情感來評估.

常見問題D

D.PO問題:PO需求無限上綱，導致許多重工、成本激增、PO被過度授權、團隊不合理頻繁交付、疲于奔命

D1:Project Manager 可以當 Scrum Master嗎?

優普豐敏捷顧問回答:?

思考這問題前，建議先將 PM 與 Scrum Master 這兩個角色定義清楚。若是你所認定的PM是指采用瀑布式生命周期來帶領項目的傳統式項目管理者的話，那就不建議你以同樣的方式來擔任Scrum Master。但是，若你是現在遇到了組織變革，組織希望你未來能以敏捷方式帶領項目的話，只要你能成功轉型成 Scrum Master，并教育組織及團隊理解與接受 Scrum 的話，那你當然可以擔任 Scrum Master職責。不過，由傳統式領導型的PM 轉變成仆人式領導的 Scrum Master，其功能與思維真的差異蠻大的。另外，組織若想轉換成以 Scrum Master 來帶領項目的話，建議要先確認組織高層對于 Scrum 的期望是什么，以免他們將 Scrum 想象得過度美好。Scrum 并不會增加產出，也不會讓團隊變成超人。但 Scrum 可以讓產品更容易符合客戶的期望，成員也可以更有自信，更愉快地工作。

常見問題E

E. 文檔管理問題: 文檔太少要求，無法交付業主或公司知識管理（KM）系統

優普豐敏捷顧問回答:?

敏捷不是完全不要文檔，而是更加關注產品首先能跑起來，能進行驗證和反饋。有價值的文檔需要寫，可以后補，也可以考慮用可視化需求分析工具或BDD來替代文檔。

常見問題F

F. 項目

F1: Impact mapping、 DDD算是Agile的手法嗎? 

優普豐敏捷顧問回答:?

不是，Impact mapping 與DDD皆是Agile的輔助工具而已，應用范圍不止是敏捷。impact mapping（影響力地圖）是最近很多團隊會使用在敏捷項目上的技術，有時也可使用 user story mapping（用戶故事地圖），以協助團隊關注系統的全貌。這是因為，撰寫程序前，如果對于所開發的系統缺少「整體感大局觀」，最后的系統設計就很容易長歪掉。另外，Domain-Driven Design；DDD（領域驅動設計）不是只專注于技術上，而是專注于與開發人員及領域專家的討論與交流，以達成共識，并在此基礎上建立一個domain model 與通用語言，有這兩項的話，后續不管你想怎么設計，都可以得心應手。

F2:scrum/sprint planning 如何運用在 sales/marketing 工作上?

優普豐敏捷顧問回答:?

可以參考這本書

F3:所有項目都可以敏捷嗎?系統重構該怎么拆敏捷story以及周期

優普豐敏捷顧問回答:?

不是所有的項目都適合用敏捷，主要是客戶需求不明確+創新的項目( Stacey Model) 才適合, 依照適合的工作量(2~3天能完工的), 拆成一個用戶故事. 這種方式對于無形產出的知識型項目很合適, 例如: 資訊系統開發

重構是屬于DoD的一環, 也是User story task的一部份. 如果整個系統所有程序都完成后才來重構, 那一定是會來不及, 所以該每個Sprint都該做好自己的重構, 以滿足DoD. 

像傳統產業的建筑工程或是地鐵工程就無法使用敏捷, 因為沒有辦法階段性交付給客戶, 要全部蓋好, 試車OK后, 方能全部交付給客戶. 如果客戶不喜歡打掉的話, 就會浪費許多成本. 

F4:How to measure progress if my product is not a software, is a campaign or an event or an activity?

優普豐敏捷顧問回答:?

可正常運作的軟件只適用于軟件產業, 若是非IT項目, 試想每個 Sprint 能產出客戶什么價值? 例: 市場營銷項目分成4個Sprint, 每個 Sprint 提供客戶可以使用行銷方案, 文宣, 文案… 這些產出客戶皆可馬上使用及創造價值, 我們稱之為 Working “System”. 

F5:沒有自動化測試的公司可以跑 Agile ? (常常瓶頸QC) 以及質量的管理

優普豐敏捷顧問回答: 

基本上使用敏捷很重要的一點在于團隊會進化，工作的方式會改善，減少浪費。如果經過多次的改善后，解決了QC瓶頸問題，那就已經解決了問題。如果開發的產品或服務需要并進行頻繁的部署，減少上線后出錯的負擔，改善分析結果需要自動化測試，減少人力浪費，增加團隊效率，那就建議增加自動化測試。一個很簡單的準則是考慮運轉的工作量和收益。

F6:非IT項目的DoD可否舉例

優普豐敏捷顧問回答:?

DoD 指的是一套通用的檢查表, 任何給客戶的 Feature 都要滿足這些檢查表的內容. 以出菜為例, 某一星米其林餐廳每道菜皆應符合：

• 菜色好看
• 聞起來香
• 味道好吃
• 衛生
• 裝盤
• 健康: 少鹽、少油、少味精

本文由優普豐敏捷學院和臺灣長宏共同整理，版本:2020/03/24