很多人都在強調用“敏捷”辦公，但實際上并沒有嚴格按照這個流程來，還存在著很多問題。作者結合自己的實戰經驗，總結了一些會遇到的問題以及實戰中的幾點經驗，希望對你有所幫助。

前言

前段時間聽身邊的一個朋友吐槽自己公司喊著敏捷的口號，實際上卻跑著假敏捷的流程（即非瀑布非敏捷），兩個模式混著用，一天一個流程，搞得團隊成員都非常難受。

本人是17年開始接觸敏捷模式的，在18年的時候公司由瀑布模式正式轉換為敏捷模式，期間也遇到過許多挑戰和問題，所以趁機復盤總結一下心得。

一、問題剖析

聽完朋友的吐槽之后，再結合我過往的經驗，大概總結出了3個經典的問題：

1. 看似是不信任的問題，實則是不理解的問題

很多初次了解敏捷的人都會對敏捷不太信任，認為敏捷就是亂來胡搞，用敏捷反而會降低原來的效率，總之是各種不看好敏捷。于是我專門找了幾位資深的瀑布研發大佬調研，在跟大佬們溝通完后，發現他們普遍存在2個誤區，他們認為敏捷提出的“擁抱變化”=“產品經理可以隨意變更需求” 以及 “輕文檔”=“零文檔”。

這其實是對敏捷不理解的原因，首先擁抱變化指的是整個團隊擁抱變化，是公司的整體方向擁抱變化，當方向有變動時，可以及時調整，而不是說產品經理可以隨意變更需求，在敏捷模式中產品經理變更需求或任務都是需要和研發團隊商討確認的。

其次輕文檔并不是零文檔，必要的文檔該有還是要有的（如功能流程說明、業務邏輯說明等），敏捷強調的是重溝通輕文檔，表示的是團隊之間的一種協作模式。我們可以想一想文檔的目的是什么？當然，不同類型的文檔定位肯定是不同的，但所有的文檔無非是2個目的：

1. 傳遞信息
2. 記錄留存

而傳遞信息的最高效方法就是面對面溝通，所以在敏捷模式中強調的是重溝通；至于記錄留存，如果有必要則可以將每次溝通的關鍵內容作為會議記錄，甚至只需要記一張流程圖或思維導圖即可。而且在敏捷模式中，團隊之間本身就有用戶故事作為橋梁連接，用戶故事也屬于文檔的一種。

2. 看似是推進困難重重，實則是沒有上級支持

在企業剛開始推進敏捷時，勢必會遭到大部分人的抵觸和抗拒，這點很正常，從心理學上來講人們都有習慣心理，我們習慣于常規事物，當有新鮮事物興起時，這會與我們意識中的默認事物相沖突，所以我們會本能的選擇逃避和抗拒，而新事物往往要求人們做出改變，但改變往往是伴隨著痛苦的，所以會更加抗拒；其次是恐懼心理，人們最大的恐懼來自對未知的恐懼，而新事物帶來的未知恐懼也會加強抵觸情緒。

生活中如此，工作中更是如此，在生活中我們不能強迫他人接受新事物，但在工作中我們可以通過公司制度來管理團隊。所以欲成其事，必先得領導支持，方可推進敏捷之事，否則這事兒就趁早打消念頭吧。

3. 看似是團隊低效的問題，實則是工具不行的問題

那位朋友還吐槽了一個經典的情況，就是他們的老板經常抱怨他們上了敏捷模式之后效率還是低下的問題。具體詢問之下才知道他們還在用一種在線版的Excel來管理研發任務，那效率不低才怪呢，Excel固然很強大（各ERP系統的盡頭就是導出Excel），但強大的工具也是要分使用場景的，工具使用不當，那效率必然低下，正所謂工欲善其事必先利其器，有了高效的工具才能有高效的輸出。

市場上有很多關于敏捷流程的管理工具（有付費的、有免費的），總之找到一款適合自己團隊的就行，但在購買付費版前，最好將公司的流程能完全跑通和讓團隊接受，否則你買了也只會浪費錢財。

二、敏捷實戰

原計劃是不在本文中討論敏捷具體的實施步驟，因為關于敏捷的文章在網上一搜一大把，而且網上還有很多專業的敏捷教練可咨詢，但不分享一點干貨又感覺內容太水（哈哈哈~），由于本人之前一直實踐的是敏捷Scrum模式，所以本次簡單的分享一下敏捷Scrum實施經驗。

首先，介紹一下敏捷Scrum的“334”基本框架，即3個角色、3個工件和4個事件。

1. 【3個角色】

① 產品負責人- Product Owner（簡稱PO）：一般由產品經理/產品總監擔任此角色，PO是產品待辦列表的唯一負責人，其職責是將團隊開發的產品價值最大化，將產品待辦列表中的史詩故事拆解為Sprint中可開發的用戶故事，以及隨時解答團隊對用戶故事的疑問。

② 敏捷教練 – Scrum Master（簡稱SM）：一般由專業的敏捷教練擔任此角色，但大多數由公司比較有聲望和懂敏捷開發的人員擔任此角色，SM的職責是幫助團隊理解Scrum的理論和實踐，保障Scrum中的事件能按時完成以及幫助團隊移除工作進展中的障礙。

③ 開發團隊 – Team（簡稱：Team）：Team由各種跨職業人員組成，包含前端、后端、測試、架構等……，在Team中所有人平等，沒有頭銜之分，都屬于團隊成員，其職責是將產品待辦列表中的需求轉換為可交付的產品增量。

2. 【3個工件】

① 產品待辦列表：該列表由PO全權負責，該列表項應具有這些屬性：描述、次序、估算和價值，產品待辦列表是動態的，需要持續更新以反映出產品需要什么來保持其適用性和競爭力。

② Sprint待辦列表：該列表由團隊全權負責，Sprint待辦列表是由產品待辦列表中選出的一組優先級最高的用戶故事列表，Sprint待辦列表是高度可見的，是團隊在當前Sprint內工作完成情況的實時反映。

③ 產品增量列表：產品增量是一個Sprint中完成的所有產品待辦列表項的總和，以及之前所有Sprint所產生增量的價值總和，無論產品負責人是否決定發布它，增量都必須可用。

3. 【4個事件】

① Sprint 計劃會：該事件由PO在Sprint的第一天主持召開，會議時長視迭代周期而定（周期為2周的一般不超過4小時；周期為4周的一般不超過8小時），參會人員包含PO、SM、團隊所有成員，會議內容由PO向開發團隊講解當前Sprint需要完成的用戶故事，PO講解完當前Sprint用戶故事后，由團隊成員一起將用戶故事拆解為具體的開發任務，同時計劃會也標志著一個新Sprint的開始。

② 每日立會：該事件由團隊成員在一個Sprint周期中每天自行組織召開，會議時長建議不超過15分鐘，參會人員包含SM和團隊所有成員（PO為非必要參加），會議內容由所有團隊成員以“我昨天做了什么……”、“我昨天遇到了什么問題……需要什么幫助……”、“我今天準備做什么……”3個為話題依次發言，發言完畢后現場領取任務（即承諾今天要完成的任務），該事件的召開時間點可自由選擇，根據本人之前的實踐情況，建議固定在每天早上9點10分進行。

③ Sprint 評審會：該事件由團隊成員在一個Sprint的最后一天召開，會議時長視迭代周期而定（周期為2周的一般不超過2小時；周期為4周的一般不超過4小時），參會人員包含PO、SM、團隊所有成員、需求干系人等，會議內容由團隊向需求干系人演示Sprint中完成的功能以及解答干系人在會議上提出的問題，同時評審會也作為一個Sprint的結束標志。

④ Sprint 回顧會：該事件由團隊成員自行組織召開（建議在Sprint的最后一天執行），會議時長視迭代周期而定，回顧會一般不超過3小時，參會人員包含PO、SM、團隊全體成員、視情況邀請/拒絕領導參會，會議內容由團隊成員回顧當前Sprint中遇到的問題并針對上述問題討論解決方案，以便于下個Sprint改進；同時還需要檢視上個Sprint中問題的改進情況。（注：此會議為非正式會議，團隊成員可自由發言，甚至可以購買一些零食邊吃邊聊。此會議的目的為：使團隊能不斷回顧自身不足之處，找到可改進的地方，讓團隊像產品一樣自我迭代更新，從而變的更強。）

介紹完敏捷Scrum基本框架后，其次就是框架的具體運用了，在開始實施敏捷流程前，我們需要先制定一個Sprint的周期。通常一個Sprint周期為2~4周（當然也可以超過4周，根據企業自身情況而定），根據本人之前的實踐情況來看，最終認為2周為一個Sprint是最佳的，所以附上一個Sprint周期為2周的“Sprint事件周期圖”：

在理解了Scrum框架后，再套上這個Sprint事件周期圖執行，我相信你的團隊已經走在真正的敏捷道路上了，可能一開始團隊會有各種水土不服，各種不適，但這些不適之處，正是團隊可改進之處。

當然，也不用按部就班的去執行Sprint事件圖中的每一個流程事件，核心是掌握敏捷思想，企業可根據自身的情況靈活調整運用，以上Sprint事件周期圖就是我們團隊根據敏捷官方指南多年迭代后產出的內容，這里面其實也去掉了一些官方指南中的內容。

三、敏捷的定義

最后，我在梳理這篇文章時產生了一個疑問：我們常掛在嘴邊的敏捷到底是什么？而敏捷的定義又是什么呢？

為了想明白這個問題，我咨詢了身邊多個有接觸過敏捷的朋友們，聽到最多的回答是：敏捷是一種開發方法、是一種開發模式；也有說敏捷是一種觀點的，是以小步快跑、快速迭代、擁抱變化、持續改進等為核心。

我還查閱了一下敏捷官方指南的描述，官方指南給出的定義是：敏捷是一種通過創造變化和響應變化在不確定和混亂的環境中取得成功的能力。

在思考許久后，我認為敏捷是一種思想、是一種文化，它以人為本，尊重團隊每一位成員，以開放透明化的管理方式使團隊可以更專注和更高效的運作。

所以我相信天下沒有不適合敏捷的團隊，因為敏捷是有章可循，從方法流程入手，以團隊為核心，自我迭代更新，從而轉變為一種思想，甚至成為一個團隊的文化或企業文化。

因此“敏捷到底是什么？”這個問題也許沒有標準答案，只是我們每個人對敏捷理解的深度不一致而已。

各位看官，您認為呢？