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

前言

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

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

一、問題剖析

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

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

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

這其實是對敏捷不理解的原因，首先擁抱變化指的是整個團(tuán)隊擁抱變化，是公司的整體方向擁抱變化，當(dāng)方向有變動時，可以及時調(diào)整，而不是說產(chǎn)品經(jīng)理可以隨意變更需求，在敏捷模式中產(chǎn)品經(jīng)理變更需求或任務(wù)都是需要和研發(fā)團(tuán)隊商討確認(rèn)的。

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

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

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

2. 看似是推進(jìn)困難重重，實則是沒有上級支持

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

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

3. 看似是團(tuán)隊低效的問題，實則是工具不行的問題

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

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

二、敏捷實戰(zhàn)

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

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

1. 【3個角色】

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

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

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

2. 【3個工件】

① 產(chǎn)品待辦列表：該列表由PO全權(quán)負(fù)責(zé)，該列表項應(yīng)具有這些屬性：描述、次序、估算和價值，產(chǎn)品待辦列表是動態(tài)的，需要持續(xù)更新以反映出產(chǎn)品需要什么來保持其適用性和競爭力。

② Sprint待辦列表：該列表由團(tuán)隊全權(quán)負(fù)責(zé)，Sprint待辦列表是由產(chǎn)品待辦列表中選出的一組優(yōu)先級最高的用戶故事列表，Sprint待辦列表是高度可見的，是團(tuán)隊在當(dāng)前Sprint內(nèi)工作完成情況的實時反映。

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

3. 【4個事件】

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

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

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

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

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

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

當(dāng)然，也不用按部就班的去執(zhí)行Sprint事件圖中的每一個流程事件，核心是掌握敏捷思想，企業(yè)可根據(jù)自身的情況靈活調(diào)整運(yùn)用，以上Sprint事件周期圖就是我們團(tuán)隊根據(jù)敏捷官方指南多年迭代后產(chǎn)出的內(nèi)容，這里面其實也去掉了一些官方指南中的內(nèi)容。

三、敏捷的定義

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

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

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

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

所以我相信天下沒有不適合敏捷的團(tuán)隊，因為敏捷是有章可循，從方法流程入手，以團(tuán)隊為核心，自我迭代更新，從而轉(zhuǎn)變?yōu)橐环N思想，甚至成為一個團(tuán)隊的文化或企業(yè)文化。

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

各位看官，您認(rèn)為呢？