你肯定遇到過這樣的場景： 老闆交代了你一個任務，這個任務聽起來簡單，但是推敲起來又很複雜，老闆又無法在一時之間把任務細則描述清楚，稍微一聊又感覺老闆想做的事其實很多，又不是一兩天就能做完的。。。
通常情況下，我們都希望老闆，或者客戶，或者甲方能把想做的事一下子說清楚，能把功能範圍定的特別清晰。這樣我們才能根據手頭上的人力資源進行任務拆分，耗時估算，任務追蹤，進度彙報，風險管理。但是現實哪會總這麼如意如意，隨你心意。更多的情況下，我們都會遇到如下三種情況：
- 甲方對於他想要的東西，只是一個大概其的幻想，根本不清楚他真正想要的；
- 甲方知道他想要的，但是他傳達給我們（乙方）之後，信息在傳遞過程中產生了衰減，雙方的理解產生了不一致；
- 甲方知道自己想要的，雙方傳遞完美對接，但是過兩天，甲方的想法變了，方的想法變了，的想法變了，想法變了，法變了，變了，了。。。
所以，遇到類似這種情況，我首先想到的就是用Scrum框架。來看看我真正遇到的一個任務吧。
任務描述
任務描述：我們要在全公司範圍內宣傳敏捷，目的是讓辦公室內儘可能多的員工瞭解敏捷基礎知識和公司敏捷轉型的狀態。、
任務分析：乍一看任務難度好像不大，貌似也沒有多少事做，無非是發表寫文章，舉辦些training培訓，讓大家多讀多看多參加就好。不過稍稍再一琢磨，這裏面其實有如下幾個open questions需要考慮。
- 需要發什麼文章，做什麼活動誰來定？
- 哪些是可以碰的，哪些是我們不能碰的誰來定？
- 先做什麼，後做什麼誰來定？
- 需要多少人來組成核心團隊？
- 誰來組織團隊的各種會議，保證任務進展？
- 會議頻率如何定既不過分打擾團隊，又能保證溝通效果？
- 如何保證團隊做的工作符合領導期望？
- 如何激勵團隊保持工作熱情？
- 如何保證我們的工作方法可以持續迭代提升？
- 用什麼工具來管理任務？
- ... ...
你可能會問，至於要考慮這麼多事嗎，我跟你說，真至於的
。而且你會發現，其實無論任務怎麼變，要考慮的問題也都差不多就是這些。
Scrum框架精髓
這裏不去贅述Scrum的3355框架。我總結了這個框架裏的幾點精髓之處。你可以不完全懂Scrum，但是這些精髓之處你總會用到。
- 3個角色可以解決Do the right thing和Do the thing right的問題
- Backlog的DEEP特性能教我們更好的管理需求優先級，粒度，狀態
- Sprint時間盒可以保證團隊以一個穩定的工作節奏輸出價值（也許能讓團隊緊張，但也能讓團隊卓越）
- 5個儀式能告訴我什麼時間該幹什麼事
接下來我們看一下，這些精髓之處是否能幫助我們解決實際問題。
任務分析與Scrum框架一一對應
| 任務分析 | Scrum框架解決方案 | 備註 |
|
需要發什麼文章，做什麼活動誰來定？ |
Product Owner & Backlog | 讓甲方（或領導）擔任Product Owner |
|
哪些是可以碰的，哪些是我們不能碰的誰來定？ |
Product Owner & Backlog | 可以和團隊一起定，哪些內容我們可以發表，哪些我們不要碰，比如和敏捷沒有直接關係的內容。 |
|
先做什麼，後做什麼誰來定？ |
Product Owner & Backlog | PO的主要職責就是對需求的優先級進行排序 |
|
需要多少人來組成核心團隊？ |
Scrum Development Team | 多少人是根據Backlog來定的，先兩三個人幹起來，後續再調。 |
|
誰來組織團隊的各種會議，保證任務進展？ |
Scrum Master | 任務的主要Owner擔任Scrum Master比較好，確保流程順暢。 |
|
會議頻率如何定既不過分打擾團隊，又能保證溝通效果？ |
5 Ceremonies | 建議根據實際情況調整一下開會頻率和時長（前提是你確保能滿足守破離法則）。 |
|
如何保證團隊做的工作符合領導期望？ |
Review/Demo meeting | 演示一下我們發表出去的內容和蒐集到的反饋是否符合甲方期望。 |
|
如何激勵團隊保持工作熱情？ |
5 Ceremonies & Retrospective | Scrum中的5大儀式本身就是一個特別好的Team building，另外在回顧會上聊一下保持團隊熱情的話題也可以 |
|
如何保證我們的工作方法可以持續迭代提升？ |
Retrospective | 經典的回顧會，不贅述 |
| 用什麼工具來管理任務？ | Backlog | Excel/Trello/Jira/WIKI/...哪個合適用哪個 |
運行效果
這裏分幾點說明一下我用Scrum框架做這個任務的實際效果。
- 甲方滿意度。我們定了兩週時長的Sprint，沒兩週的週三我們會給甲方演示發出去的文章，舉辦的活動和反饋，並且梳理下一個sprint要做的事。甲方對這種模式很滿意，因爲可以很快看到進展並且還能適當調整未來需求。靈活性極高。
- 開會頻率與時長。我們沒有完全按照5大儀式來開會，我們定每週一下午的30分鐘時間大家同步一下各自的進展和遇到的問題，每兩週的週三演示成果，梳理和接受新需求。沒一個月的週一在原來30分鐘的基礎上再加30分鐘做回顧，用來提升工作方法。
- 工具使用。我們選擇Trello作爲主要得需求管理工具，trello的種種優點就不多說了。反正用起來就感覺一個字-棒。
總結
有人說，簡單的問題用瀑布，複雜的問題用敏捷。我個人覺得，像Scrum這種輕量級又極高效的敏捷實踐框架，無所謂你的問題是簡單還是複雜，都可以用起來。
況且，在當今大環境下，還真沒有簡單問題。你說呢？