# 敏捷式開發

## Scrum
[什麼是scrum-不是工程師也能懂的scrum入門教學](<https://medium.com/doflowy/%E4%BB%80%E9%BA%BC%E6%98%AFscrum-%E4%B8%8D%E6%98%AF%E5%B7%A5%E7%A8%8B%E5%B8%AB%E4%B9%9F%E8%83%BD%E6%87%82%E7%9A%84scrum%E5%85%A5%E9%96%80%E6%95%99%E5%AD%B8-1cc6683575f8>)

Scrum 團隊建議為十名成員的團隊而設計的，他們以迭代 （iterative）
與增量（incremental）式的方式交付工作，每個迭代稱作 Sprint。
一個 Sprint 的時間不超過一個月，通常是兩星期。Scrum 團隊在每個
Sprint 都專注在唯一一個共同的目標 （Sprint Goal），每天會有稱為
Daily Scrum的站會，團隊中的開發人員（Developers）會檢視朝向共同目標的進度，和調適當下的計畫。在 Sprint 結束時，團隊會進行 Sprint 審查 (Sprint Review) 跟利害關係人 (Stakeholders) 一起檢視當下的結果與調適計畫，這是互相資訊交流的機會。最後，團隊會進行 Sprint 回顧（Sprint Retrospective）來持續改善。
迭代（iteration）是重複回饋過程的活動，其目的通常是為了接近並且到達所需的目標或結果。每一次對過程的重複被稱為一次「迭代」，而每一次迭代得到的結果會被用來作為下一次迭代的初始值。
增量亦稱改變量，指的是在一段時間內，自變量取不同的值所對應的函數值之差。

Scrum是一個包括了一系列實踐和預定義角色的過程骨架。 Scrum中的主要角色包括：
Scrum Master是Scrum教練和團隊帶頭人，確保團隊合理的運作Scrum，並幫助團隊掃除實施中的障礙；
產品負責人，確定產品的方向和願景，定義產品發布的內容、優先級及交付時間，為產品投資報酬率負責；
開發團隊，一個跨職能的小團隊，人數5-9人，團隊擁有交付可用軟體需要的各種技能。
在每一次衝刺或迭代（一個15到30天的周期，其長度由開發團隊決定）當中，開發團隊創建可用的（可以隨時推出）軟體的一個增量。每一個迭代所要實現的功能來自產品訂單。產品訂單按照優先級排列工作需求。在迭代計劃會議中，產品負責人告訴開發團隊需要完成產品訂單中的哪些訂單項。開發團隊決定在下一次迭代中他們能夠承諾完成多少訂單項。在迭代的過程中，沒有人能夠變更迭代訂單，這意味著在一個迭代中需求是被凍結的。


# 如何用Jira建立Scrum專案

**1. 創建 JIRA 專案：**

登入 JIRA，點擊「創建專案」。這是你整個專案的家。你可以自己設定專案的名字和屬性。

**2. 列出你的需求：**

把你的專案需求寫成一個個「用戶故事」，就像是一個短小的故事一樣，這樣更容易理解。每個故事都包含了你想要的功能。

**3. 建立一個看板：**

在 JIRA 裡，一個「看板」就像是一個工作計畫，能夠幫助你追蹤進度。你可以建立一個「Scrum 看板」，這會幫助你更好地管理工作。

**4. 設定你的工作流程：**

在看板裡，你可以自訂不同的「列」，每一列代表了你工作的不同階段。比如「待處理」、「進行中」、「測試中」和「已完成」。這就像是你工作的流程圖。

**5. 列出你的任務和故事：**

在你的看板裡，建立「任務」和「用戶故事」卡片，這些代表著你要做的事情。這樣你可以很清楚地看到還有哪些工作需要完成。

**6. 計劃你的迭代：**

在看板裡，你可以設定每個「迭代」，就是你計劃內容的時間段。每次迭代，你的團隊會專注於完成一部分工作。

**7. 讓每個人知道他們該做什麼：**

每個團隊成員可以看到在哪個階段的工作。他們可以挑選要做的任務，然後移動這些卡片到適當的列。

**8. 每天討論進度：**

每天有個短短的「站立會議」，每個人輪流說出昨天做了什麼、今天要做什麼、遇到的困難是什麼。這有助於大家保持同步。

**9. 進行迭代工作：**

在迭代期間，團隊專注於完成任務和故事。每天都會有進度更新，以確保順利。

**10. 回顧和改進：**

在每個迭代結束後，有個「迭代回顧」會議。團隊討論過去迭代的成就和改進的地方，以便於下一次迭代做得更好。

## Jira Ticket & Type

**1. 問題（Issue）類型：**

問題類型通常用於報告問題、錯誤、缺陷等。這意味著當你的團隊在專案中遇到任何可能影響品質或功能的問題時，你可以使用這種類型。這可以是軟體的錯誤報告、網站的異常行為、技術支援請求等。

**2. 用戶故事（User Story）類型：**

用戶故事是一種簡潔的描述，專注於描述端用戶或利益相關者的需求、目標和期望，以及他們希望系統能為他們創造的價值。用戶故事通常遵循以下結構：

"As a [user/role], I want [goal] so that [benefit]."

例如：「作為一個網站訪客，我希望能夠通過社交媒體分享按鈕分享有趣的內容，以便能夠輕鬆地將它分享給我的朋友。」

用戶故事強調了用戶的需求和價值，以及完成這些需求所帶來的好處。這有助於團隊更好地理解和專注於用戶的需求，並確保產品能夠提供實際的價值。

**3. 任務（Task）類型：**

任務是工作項目的小步驟，它們是實際執行某些操作或活動的細項。在 Scrum 開發中，用戶故事可以被拆分成更小的任務，以幫助團隊更好地追蹤進度和執行工作。

例如，如果你有一個用戶故事是「作為一個網站訪客，我希望能夠通過社交媒體分享按鈕分享有趣的內容」，相關的任務可能包括：

設計社交媒體分享按鈕的界面
實施社交媒體分享按鈕的功能
測試社交媒體分享按鈕的正確運作
這些任務有助於更好地分解和管理工作，並確保每個細節都得到了處理。

**4. 改進（Improvement）類型：**

改進類型用於建議、討論或實施流程、效率等方面的改進。當你的團隊想要優化現有流程或提升效能時，這是一個適用的類型。

**5. 新功能（New Feature）類型：**

新功能類型通常用於引入新的功能或特性。如果你的專案需要增加全新的功能，或者是基於用戶需求或新的創意想法，這是一個適合的選擇。

**6. 子任務（Sub-task）類型：**

子任務類型用於將主要工作項目分解為更小的部分，以便更好地管理和追蹤進度。如果你希望細分大型任務，讓團隊成員可以更具體地執行工作，這是一個有用的類型。

**7. 其他特定類型：**

根據你的專案需求，你可能需要其他特定的類型，比如測試用例（Test Case）類型，用於描述測試需求和測試步驟；變更請求（Change Request）類型，用於申請變更或修改；文檔編寫（Documentation）類型，用於管理文檔的創建和維護。

# 敏捷式開發 vs 瀑布式開發

軟體開發生命週期
分析與計畫、原型設計、軟體開發、測試、上線、維運

瀑布式開發的實現方式是完整並一步步執行上述聲明週期，敏捷式開發則是拆成數個子項目不斷循環生命週期，藉由前一個循環優化下個循環
瀑布式開發的目的是把事情做完，敏捷開發的目的是把事情做好
瀑布式開發有具體的完成時間，敏捷開發是持續投入沒有具體時間，直到認為不用再投入為止
瀑布式開發適合嚴謹且大型的案子，敏捷開發適合相對較小的案子
瀑布式開發的需求只會定一次，敏捷開發的需求隨時變動

敏捷開發可以適應不斷變動的環境(例如：線上影音平台Netflix等)，但若遇到該專案是具有一個具體的專案金額，且有一個明確的專案目標（達成該目標後，該專案工作告一段落）與完成時間(例如：大部分的系統導入軟體專案)，就適用於瀑布式開發

也因為敏捷開發並沒有一個具體時間，所以完成時間並不一定比較快，敏捷的意思應為彈性

## 技術實踐與敏捷開發

[原文連結:當技術實踐碰上敏捷開發](https://ithelp.ithome.com.tw/articles/10233996)
1. **專業版本控制的追求**:每段程式碼的改動，都必須提出 Merge Request，並且由另一位同事 Code Review 後，才可以合併回主線。但是這裡不只檢視程式碼而已，連 Commit Log 都十分重視，會要求每個 MR 都透過 Git Rebase編修紀錄過，讓這份變動的 log 是易讀的。在確認程式碼都沒問題、且 log 都能呈現修改的部分時，最後才會留言「LGTM」(Look Good to Me）並將那份變動合併為主線。透過編修程式碼紀錄，確保我知道每一次提交是為了什麼、我清楚知道我變動過哪部分的程式碼、也檢查過這些變動是和提交的訊息相關的、這些變動都和我這次要改動程式碼的目的相符、我也期望我的同事能直接透過這些 log 暸解我的變動。這是軟體開發工程師負責任的展現、是一種美。而透過這樣 Code Review 的過程，也是一種同事之間對彼此程式碼暸解的交換。不只程式碼的理解程度，更重要是的在檢視時提出的建議或是直接指出瑕疵，都有助於彼此教學相長，而成為更好的程式設計師。在敏捷開發裡，我們期望團隊是 cross-functional 的，也期望不會有一份知識只有一個人知道、讓那個人成為瓶頸，所以這樣的知識交換是一個很重要的環節。我自己會認為版本控制是 DevOps 在技術上的基礎，需要先有好的版本控制、才能有好的流程去觸發每一次的自動化、才能有一個穩定且流暢的 CI/CD。所以我十分注重現在主流版本控制工具 —— Git 的能力，我認為如果團隊的工程師對於 Git 都不熟悉，那就很難讓軟體開發這件事敏捷起來。

2. **自動化以降低交付時間**(DevOps):俗話說的好：「程式設計師的美德就是懶惰。」因為懶惰就會把把重複性的工作給自動化，進而推動社會的進步（？）。我認為這在喜愛敏捷文化與 DevOps 文化更應是如此，只有將重複性的事情自動化，我們才有額外的時間與精力去追求適應變化的能力；只有將整合與部署的流程自動化，我們才能持續的交付。而我在實驗室所做的第一件事情，就是將實驗室軟體的安裝流程從手動複製檔案與改環境變數，透過 NSIS 腳本自動化，省去我們要舟車勞頓的去客戶辦公室、在沒有網際網路的環境下，協助因為安裝程序太複雜無法自行操作的客戶，用 USB 進行檔案複製與各種環境設定去安裝我們最新版本的應用程式。在有了自動安裝程式之後，只要透過 e-mail 就可以將新版安裝程式交付給客戶自己安裝，更快的得到他們對應用程式的回饋。這樣降低交付耗損的時間，是 DevOps 所追求的；而快速得到回饋的節奏，也是敏捷文化所追求的。

3. Code Review 以建立知識與文化的傳承:實驗室在文化塑造最困難的地方在於，每一年多承接專案的人員就會進行一次交替；換個說法，就像是公司每年都一定會有 N 個最資深的員工離開，然後同時再來 N 個新員工進來。在這樣來來去去的環境中，文化是最難建立、也最容易遺失與稀釋的。而開始承接實驗室專案後，我就感到實習時良好開發文化與實驗室開發文化強烈的反差對比。其中，我最難以接受的就是沒有一個共通的 Coding Stlye 以及沒有 Code Review 的文化。沒有共通的 Coding Style，除了強迫正如我會感到渾身渾身不對勁外，也會造成程式碼可讀性降低，讓更改軟體本身的成本提高。而沒有 Code Review 的文化，就會讓許多劣質的程式碼合併進主線造成技術債、也會有造成專案建置失敗的提交讓開發進度停擺。這些缺陷都是降低從需求到交付的絆腳石。另外，沒有 Code Review 更長遠的後果就是知識傳承的成本會不斷積累。正如前面所提到的，實驗室最大的困境就是人員更迭頻繁，所以知識的傳遞容易斷層。所以指導教授努力的想要研發更好的文件專寫方式與 IDE 相關輔助擴充套件。但是這些都是治標不治本。但是會造成斷層的原因，更主要是專案的知識總是在人員要離開時才交接，而那時候正是離開人員於論文水深火熱之際，而論文寫完後也就急急忙忙地辦理離校手續而離開了，實際能好好交接的時間與精力是難以將這些知識完整的傳遞的。而這就顯得平時的 Code Review 是重要的。每一次合併主線前的 Code Review，除了前述有避免劣質程式碼與缺陷進入主線的優點外，更有知識傳遞的效果。資深開發者透過 Code Review，讓新手暸解到自己可以更好的地方。而新手透過 Code Review，去更近一步暸解軟體的架構與概念。任何專案成員，都可以透過 Code Review開啟更多的討論、激盪更多的想法。經過這樣一年的開發，等新人成長起來、資深者要離開前，其實真正需要交接的地方已經不多了，如此就可以避免知識的斷層。
4. 嘗試導入新流程與標準:在我開始承接實驗室的專案後，我一直努力要改善整個開發文化。我認為「工欲善其事，必先利其器」，在個人部分可能是建立自己習慣的開發環境，在團隊部分就是有好的流程、文化。經歷過實習後，就更加深這樣的價值觀。昨天有聊到在無法改變資深的夥伴後，我開始對新進的夥伴進行嘗試，包括建立 Code Review 文化、制定 Coding Style 標準等等。這些都在當下與日後收到好的回饋，改善了專案的體質。

## 敏捷開發的困境

### 跨職能與專業分工的衝突

因為敏捷團隊的成員是必須具備「在 Sprint 內創造價值所需的所有技能」，而傳統的瀑布式開發中，分工相當明確，寫規格書、產品設計、前端開發、後端開發、QA測試，各有各自的專業。若以敏捷式開發期望的2-4周一個衝刺，這樣從定規格、產品設計、程式撰寫到功能測試，每個階段可以分配到的時間就會變的非常的短暫。

所以，才會強調敏捷團隊是跨職能的，任何一位敏捷團隊成員都能執行「寫規格書、產品設計、前端開發、後端開發、QA測試」這些工作，因此，敏捷團隊的工作安排上就會相當困難。

### 自組織與習慣派工的衝突

敏捷式開發中，希望的是團隊是可以自己決定「誰做什麼、何時做以及如何做」，但是，很多時候，我們習慣的工作方式卻是「派工」，PM安排工作後，再進行工作的執行，對於主動去決定「工作」這件事，往往會「怕怕的」。就跟從小父母都希望我們專心念書，不要談戀愛，可是一旦出社會後，卻一直問我們什麼時候交女友、結婚，從來都沒學過「談戀愛」這件事，卻希望我們瞬間學會「如何談戀愛」，一樣的不切實際。

### 擁抱變化與規格清楚的衝突

在敏捷的精神中，希望團隊是可以「擁抱變化」的，但是在開發的世界，「變化」是我們所厭惡的，「變化」代表的是改需求、改規格，對於執行團隊來說，就是「重工」、「重做」、「浪費時間」，因此團隊希望的總是「規格不要變」，規格改變就是當時需求沒想清楚，但是又有誰可以知道現在想的需求，明天是不是還需要？

### 發現阻礙與防禦心理的衝突

每日站立會議希望達到的，除了每天進行資訊同步外，另外最重要的是可以快速「發現阻礙」，進而「排除阻礙」，但是往往在說明「有沒有遇到阻礙」時，成員的防禦心就會立刻升起，接著，就是一陣「解釋大會」與抓「戰犯」，最後這個站立會議，變成每個成員都瑟瑟發抖的「顫慄會議」，每個人都很害怕自己成為別人的「阻礙」。於是，為了不要和其他人衝突，就草草帶過，相對的，也就失去「發現阻礙」的意義。

### 回顧改進與避免得罪的衝突

在回顧會議中，希望達到的是團隊的經驗學習與成長，透過每一次的回顧來改善流程，然而在這樣的過程中，團隊成員常常因為不想得罪其他人，都會語帶保留，如果要討論團隊做的好的地方，那就變成「拍拍手大會」，效果往往不好，更別說「留下好的，改掉不好的」，這樣的目標了。

那怎麼辦？

其實，這些年有了新的概念，叫做「混和式開發」，說穿了就是「瀑布式開發」加上「敏捷式開發」的綜合版，

## 混合式開發
有時，使用純敏捷管理會遇到障礙，這時可以採用混合式開發

1.使用混合模式，即將瀑布模型和敏捷開發元素結合在一起，可以在特定情況下充分利用兩種方法的優勢，以滿足項目的需求和挑戰。以下是一些使用混合模式的理由：

2.項目複雜性： 如果項目的複雜性高，可能需要更嚴格的計劃、設計和控制。在這種情況下，可以使用瀑布模型的方法來確保項目的可控性，同時在某些階段使用敏捷的迭代方式進行開發，以快速反饋和調整。

3.需求穩定性： 如果項目的需求相對穩定，不太容易變化，那麼瀑布模型可能更適合。但如果在開發過程中出現新的需求或變更，則可以引入敏捷的元素，以快速適應變化。

4.交付壓力： 如果項目有嚴格的交付期限，但仍需要一些靈活性來應對可能的變化，可以採用混合模式。在某些階段使用瀑布模型，以確保按時交付，同時在其他階段使用敏捷方法以快速響應需求。

5.技術挑戰： 如果項目涉及複雜的技術挑戰，可能需要較長的時間進行設計和準備。在這種情況下，可以使用瀑布模型的前期階段，然後在實際開發階段引入敏捷的迭代進行。

6.客戶參與： 如果客戶參與度較低，或者他們需要確保項目在預定時間內完成，可以在瀑布模型的基礎上進行，但在部分階段引入敏捷的迭代來確保客戶的需求得到滿足。

7.組織文化： 如果組織對瀑布模型有較高的接受度，但同時也希望引入敏捷的靈活性，可以使用混合模式來實現兩者的平衡。

參考資料
https://hero-mi.com/2022/10/02/%E3%80%8A%E6%88%91%E7%9A%84%E5%B0%88%E6%A1%88%E7%AD%86%E8%A8%98-23%E3%80%8B%E6%90%9E%E6%87%82%E6%95%8F%E6%8D%B7%E5%BC%8F%E9%96%8B%E7%99%BC%EF%BC%8C%E9%81%BF%E5%85%8D%E6%8E%89%E9%80%B2%E5%B0%8E/

混合式做法的優點
1.由於計劃會遵循瀑布式方法，因此團隊可以獲得專案需求的寶貴見解，並可以更準確地預估時間和成本
2. 工作是在小的反覆式區段中進行，因此可以輕鬆地適應不斷變化的需求和要求
3. 鼓勵團隊和利害關係人之間的協作
4. 允許固定的期限和預算
混合式做法的缺點
1. 對於習慣於更靈活和敏捷做法的人來說，這可能有些限制
2. 團隊必須全心投入協作式做法
3. 需要熟練的專案經理來定義和指派衝刺
4. 過多的利害關係人和過程中的變更可能會導致預算超支及錯過期限

## 什麼是 Agile

敏捷式管理又稱為「Agile」，源自於軟體開發，其核心理念為「快速試錯、即時回應、顧客導向、排定優先順序分配資源」

四大價值分別為：

:::success
「個人與互動」重於「流程與工具」

團體共事中，人與人之間的溝通比制式的流程和工具更重要，因為專案是透過人來完成，工具只是輔助，專案執行過程遇到的困難也是由人來解決。
:::

「可用的軟體」重於「詳盡的文件」

以開發軟體來說，如果空有詳盡的文件，卻沒有在過程中持續產出可用的軟體或功能，最後的產品可能就不符合客戶的需求，因此與其重視非常詳盡的文件，不如持續產出可用的功能。
「客戶的合作」重於「合約協商」

這個原則的意思是重視持續和客戶合作，而不是拘泥於原本的合約、計畫。在執行專案的過程，最好做到靈活、包容、不死板。

「回應變化」重於「遵循計畫」

有完善的計劃很好，但是敏捷精神認為，能因應變化進而調整的計劃才更有價值。

萃取出敏捷的精神在專案導入裡：
簡單的Daily站會：每天及時確認團隊的進度和阻礙點。
透明化的工作看板：可用輕量級的方式來追蹤進度，也可及時看出團隊的進度。
每月的Retrospective回顧會議：團隊定期每月來檢討和改善工作執行的內容。
將專案範圍切成碎片化：在訂定專案milestone時，我常以3~6個月作為一個恰當的專案里程碑，這時間點的專案團隊也會是穩定的班底，產出也會較穩定。

## Scrum工作法

如果用一句話來說它能替團隊帶來的最大價值，我會說：

「它讓團隊能用相同時間，更快達到目標。」

Scrum是什麼？可以做什麼？
Scrum起初被用在軟體、產品開發，適合大約6-9人的團隊合作模式。尤其是在產品狀態在很早期、模糊、不知道未來方向，或是需要調整成長的情況下，更適合用Scrum的工作模式。例如新創團隊、新部門、新品開發。

值得一提的是，它不只能用在程式開發，其實在一般的業務團隊、行政團隊、行銷團隊中使用也可以。

事實上，我們公司在起初引入Scrum時，就將它用做一般行政庶務、行銷規劃的調整，許多項目與一般我們所說的「產品」沒有直接關係，但依然可以帶來不少好處。我自己把這個流程，運用到了人生規劃、平日活動安排。

因此，如果你希望自己或團隊能

在同樣時間，希望更快達到目標
創造更多良性溝通、團結一致
希望在即便模糊不清的狀況下，團隊仍能有步調地往前
就非常有機會運用到Scrum的流程與精神。

Scrum解決了什麼樣的問題？
在專案、團隊管理，或是任何計畫中，多少都會面臨到以下的問題：

「沒有按照時間進行」、「案子之間彼此卡住」、「管理者無法全面掌握狀況」、「過多的討論會議」、「執行冗長的感覺」、「應變能力不足」。

以上問題，如果以Scrum的模式協作，就能很有效地減少

邏輯不同，所以可以解決許多團隊問題
一定有人會好奇，憑什麼Scrum的工作模式可以解決那麼多問題？我認為關鍵在於：

「做事的邏輯不同。」

舉個專案管理的例子來說吧！

傳統上，可能更重視從企劃案開始，大家不斷開會討論、思考怎麼建置功能，從提案、規劃、製作，交到客戶手中的過程，可能會拉長到三個月甚至半年。

但Scrum模式中，更注重透過從消費者、使用者得來的訊息，思考要現在該做什麼事，並調整優先順序。它用跌代的方式，從原本預計3個月產出的東西，變成先從7天做一個60分(甚至更少)的產品，再慢慢每7天都讓60分的產品變得更好。

因為並不是等到一切都就位，才開使做產品，而是透過先做出60分的產品，獲得一些資訊，來決定下一步該做什麼。

此時，團隊關注的會是「能做什麼事情，來盡快獲得不錯的反饋」。這個反饋可能是使用者經驗、營收變化、流量變化、觸及人數...等等。

由於更關注在短期的目標、價值，因此產品的範圍縮小，更注重可驗證的數據，所有的會議與互動，也都盡量縮減專注在價值最高、最有用的資訊上，因此減少「無意義的會議」、「PM不斷督促詢問」...等問題。

Scrum的重要精神，你的團隊適合Scurm嗎？
因為做事邏輯不同，讓Scrum可以解決許多問題，但要培養不同的邏輯，團隊的想法就得不一樣。所以其實在合作以前，價值觀、企業文化的磨合與培養就變得很重要，而在漸漸了解Scrum後，我認為有最重要的精神有三點：

永遠彈性調整，並優先做最重要的事情
團隊的所有人都要能「隨時掌握情況，幫助彼此解決問題」
要專注在「如何於固定時間內，產生更多價值」
這三個重點，不但是是我認為Scurm的精神指標，也還能用來評估一個團隊是否適合Scurm，以下就讓我們一一介紹吧！

．

永遠彈性調整，並優先做最重要的事情
這對於管理階層，聽起來是理所當然，但對於普通員工而言，在實務上往往是十分抗拒的。

例如，當一個案子被要求大幅度修改時，員工常會想：

「那之前做的不就白費了嗎？」
「為什麼當初不先講，現在才在那邊改？」

光是有這種想法，在Scurm中都是個大忌，因為理論上，我們過去所做的，都是當時最好的決定，只是因為現在情況變了，才做了不一樣的調整。

如果員工無法接受這樣的事實，任憑管理者怎麼推廣Scrum，都不太可能讓團隊緊密合作。

．

而相反的，團隊的總時間也是有限的，不可能在舊Case還沒結束時又開始新的Case，管理者如果只想著新Case，卻沒留時間讓執行人員完成舊的，大家就勢必得加班。

相對於員工要甘願任務改變，管理者也有責任判斷哪些是重要的事，捨棄不重要的事，並且良好地分配時間，而非認為所有事情都重要，一味要求大家改善效率、掏出更多時間加班。

．

也就是說，要想良好地與Scrum接軌

開發團隊要問：
「我可以接受主管隨時調整我的工作內容嗎？」

專案管理人則要問：
「我可以讓我的團隊成員，完全不加班嗎？」

答案越肯定，就越能讓整個團隊符合Scrum的首要精神：

「彈性調整，並持續著做最重要的事情。」

．

隨時掌握情況，幫助彼此解決問題
一個團隊績效是否良好，可以從兩個方面來看。一個是前面說的「能不能持續解決最重要的問題」，另一個則是「能不能更快地解決問題」。

以團隊而言，如果我們能互相合作，即便個人能力不變，依然有辦法讓團隊績效提升。

Scrum精神的第二點，就是希望「以團隊為核心來解決問題」。

既然是以團隊為核心，Scrum中的每個執行人員，都該對所有任務負責、有勇氣承擔，不會有「哪項目應該由誰做」或「這是某人的問題」。

．

舉例來說，如果有個任務是與客戶開會，而A被分配到了這項任務，但當天早上卻頂著不適的身體參加，最後使得簡報狀況糟糕、丟了案子，這不該是他一人的責任，而是所有人都得扛起這個結果。

「為什麼A沒有說身體不適？」
「為什麼即便身體不適，主管卻仍派他來簡報？」
「為什麼沒有人能跳出來幫他完成這項任務？」

這都是Scrum在問責時，以團隊為核心來檢討的方式。

．

問責的反面則是互助。

只要有上碰到困難，每個人都該積極想辦法。因為，只要任務沒完成，整個團隊的目標仍舊不會達成，既然我們關注目標、價值，就更該傾力互助。

值得一提的是，互助的前提是「大家都知道出問題了」，也就是每個人都得誠實地說出自己碰到的困難，不要怕麻煩夥伴、不要怕被認為實力不足、不要怕被責難。

但在一般的公司中是很難做到的，可能是受文化影響，使我們不願在會議上公開地說「我做不到、完成不了、我不會、我做錯了」這些話。

．

所以，要想良好的與Scrum接軌，還得先調整團隊的文化：

開發團隊要問：
「我願意誠實地告訴所有人，我現在碰到困難嗎？」
「有人碰到問題時，我會主動思考並有具體行動來幫他？」

專案管理人則要問：
「我可以不責怪、輕視任何一位成員，而只想著該如何解決問題嗎？」

答案越是肯定，就越能讓整個團隊符合Scrum的第二個精神：

「隨時掌握情況，幫助彼此解決問題」

．

如何於固定時間內，產生更多價值
一個運作良好的Scrum團隊，個人能力不需要有任何顯著的提升，就能讓團隊的效率成長非常快速。最主要就是源自於前面兩點。

但當這些到達了極限之後，不論是管理層還是執行者，都得更常問一些問題來幫助團隊加速：

有沒有不同的做法，但能更快地完成任務？
能不能少做一些事，但仍能達到相同的目的？
能不能換個流程，讓事情進展更順利？
能不能先完成某些事，讓日後的許多事一勞永逸？
這些問題都是簡單的技巧，但更重要的是，每個人都要有一個想法，就是真心地去想「怎麼讓事情更快被解決」，要真的去思考「原本預計花3天才能完成的報告，應該如何在3小時內完成。」

唯有達到以上的三點，才能讓Scrum團隊一直保持高效高速的狀態

「讓團隊在固定時間內，產生更多價值。」

有了基本概念與精神，下一步就來我們來聊聊，如何準備開始Scrum的第一個流程，規劃會議！

https://www.slideshare.net/lhliutw/view-of-vendor-pm-to-agile