當敏捷來敲門：你深陷的“敏捷式加班”，并不是真正的敏捷

干貨分享

原創(chuàng)2019-07-04小艾老師

抱怨的聲音

在互聯(lián)網(wǎng)公司工作的各位應(yīng)該或多或少都應(yīng)該聽過敏捷，目前，敏捷(Agile)的概念應(yīng)該已經(jīng)相當?shù)钠占埃绕涫窃谝恍┐蠊緝?nèi)部，搞敏捷已經(jīng)成了項目相關(guān)人員的日?；顒印?019年由Scrum.org和Age of Product出版的Scrum Master趨勢報告明確表示敏捷變革將會是未來企業(yè)項目管理的大勢所趨。

運用敏捷方法進行項目的部分企業(yè)

然而，并不是每個人都喜歡敏捷。艾威小編和學員聊天的時候總能收到不少關(guān)于敏捷的抱怨：什么效率低下啦，工時增長啦，士氣低迷呀，浪費時間什么的，等等。

那么敏捷真就如此不堪，除了折騰員工外什么用都沒有嗎？

其實并不然。讓我們從埃森哲講起……

不敏捷的下場

可能從事IT相關(guān)工作的朋友都還有印象，在本年4月底左右的時候朋友圈里曾經(jīng)有一篇講埃森哲的文章刷過屏……

耗費2個多億，耗時2年多，連一個可用的網(wǎng)站或者APP都沒有交付出來。
想要完工？那就再交1000萬美元。
……
因為項目要再進行下去，還需要發(fā)現(xiàn)并糾正埃森哲工作中的缺陷，以及開發(fā)埃森哲本應(yīng)交付但未能交付的功能。
美國汽車租賃公司赫茲(Hertz)終于忍無可忍，一紙訴狀將埃森哲告上法庭。

把事情拖成這樣似乎是大組織的通病。無獨有偶，2016年俄勒岡州政府起訴Oracle，1億美金不能如約履行醫(yī)療網(wǎng)站交付；2017年濱州政府起訴IBM，1.7億美金不能履行稅務(wù)系統(tǒng)交付。

可能有人會問，埃森哲難道不用敏捷方法嗎？難道Hertz的IT部門不知道敏捷嗎？要是他們用了，事情還會變成這樣？

別笑人家，其實說不定覺得自己已經(jīng)對敏捷流程了然于心的你都不知道敏捷真正的樣子。大部分人提到敏捷可能_時間想到的還是“上午出案子，下午就測試，跑通就上線，一周一版本”“每天早上開個晨會就拉倒”這種流于表象的內(nèi)容，項目內(nèi)容不多還好，一多了就容易變成“加班三重奏”。別忘了，敏捷有著自己的價值觀：

個體和互動高于流程和工具
工作的軟件高于詳盡的文檔
客服合作高于?合同談判
響應(yīng)變化高于遵循計劃

敏捷的“敗因”

敏捷缺少了價值觀引導(dǎo)會變成什么樣子呢？

1.項目團隊缺乏對敏捷的正確認識，單純的認為敏捷就是快，就是追趕進度,就可以不受任何制度約束。大家可能聽說過這樣的對聯(lián)，“這個功能很簡單，怎么實現(xiàn)我不管?！睓M批：“明天上線”。也曾聽說有些公司要開發(fā)一個新功能，因為實施了scrum，于是要求項目團隊加班加點，將2周甚至3周以上的開發(fā)任務(wù)在一周內(nèi)就發(fā)布上線。實施Scrum意味著項目團隊“漫無天日”的加班，這導(dǎo)致了項目團隊對敏捷有一種“恐懼”感；
2. PO不能勝任工作，無法拆分有效的用戶故事，或者用戶故事拆分的不合理，無法實現(xiàn)迭代增量開發(fā)；
3.Scrum對于自組織的團隊要求很高，但許多同學認為自己達不到自組織的標準；
4.Scrum倡導(dǎo)工作透明化，項目實時完成情況和每個人的任務(wù)認領(lǐng)情況通過項目看板和項目燃盡圖一覽無余，許多人對此不太適應(yīng)；
5.在迭代的過程中無法及時發(fā)現(xiàn)問題，或者發(fā)現(xiàn)問題，無法有效解決問題，使項目團隊有一種挫敗感。等等。

這其中的每一點，都可能成為企業(yè)在推行敏捷化管理的“敗因”。

真正的敏捷

既然如此，“真正的敏捷”是什么樣子呢？

以Scrum為例子，當我們學習Scrum的時候，首先要明確Scrum 是一個用于開發(fā)和維護復(fù)雜產(chǎn)品的框架，是一個增量的、迭代的開發(fā)過程。

而為了_這個開發(fā)過程時刻處于可視、可集成和可運行狀態(tài)，就需要項目在一個穩(wěn)定的敏捷流程中運轉(zhuǎn)，它包括：

產(chǎn)品分析用戶需求，按照商業(yè)價值依次排序估算，輸出計劃產(chǎn)品功能列表。
經(jīng)過計劃會議討論，按照計劃面板梳理功能列表，輸出產(chǎn)品版本迭代任務(wù)。
進入開發(fā)迭代周期，按照任務(wù)面板增量迭代開發(fā)，輸出可交付的迭代版本。
進入評審驗收環(huán)節(jié)，按照發(fā)布面板匯總問題原因，輸出迭代周期報表數(shù)據(jù)。

不難發(fā)現(xiàn)該流程中存在4個輸出/輸入，3個關(guān)鍵圖表，3個相關(guān)會議，具體的流程細節(jié)這里就不細表了，已經(jīng)給出了圖片說明，而且……

敏捷開發(fā)作為一種團隊協(xié)作方法論，高效與清晰是兩個特別明顯的特點，保持敏捷開發(fā)的理念開始Sprint工作的團隊，一定有正向的開發(fā)BUFF加成，我們需要面對的是如何將敏捷開發(fā)的流程執(zhí)行到位，_大化的獲取加成收益。

小編很認同一些學員對敏捷開發(fā)對于精英團隊的加成是_大化的觀點，因為大家目標清晰，技術(shù)能力完善，執(zhí)行力強，這是_理想的工作模型。但對于現(xiàn)實中的非理想工作模型，特別是在國內(nèi)的“非典型項目環(huán)境下”，我們可以從以下幾個方面去試著加強這種團隊加成效果：

首先，產(chǎn)品BACKLOG的來源一定要盡可能的準確，_好是有明確的數(shù)據(jù)分析結(jié)果作為支持依據(jù)，Sprint BACKALOG的任務(wù)細化盡可能細致，_在后續(xù)的Sprint迭代過程中，團隊的工作目標清晰明確。因為沒有人會希望自己的工作量_后轉(zhuǎn)化為無用功，而不是KPI，這對于團隊士氣是一種相當沉重的打擊。如果還是出現(xiàn)了這種情況，Sprint負責人也要積極轉(zhuǎn)移大家的情緒，勸慰大家盡快投入下一個更加正確的Sprint周期中去。

值得注意的是，為了_開發(fā)過程中靈活性，敏捷開發(fā)往往為了高效而不會過多的對成員做工作流程上的束縛，需求在迭代過程隨時可發(fā)生變動，開發(fā)任務(wù)清單可由團隊成員自主選擇，任務(wù)面板由成員自主更新，是一種以溝通為主的工作模式。所以在這個過程中，團隊成員之間要盡可能形成積極溝通的氛圍，以_各職能團隊之間的信息溝通準確對稱(其實無論是在什么管理中，_溝通準確都是_項目成功的關(guān)鍵點之一)。

再一個，以國內(nèi)大家比較習慣的情況來看，項目團隊成員在工作分配上更傾向于被動接受。所以開發(fā)經(jīng)理在安排工作任務(wù)清單的時候需要根據(jù)項目團隊成員的能力維度進行合理安排，盡_大可能避免團隊成員因為能力方面的原因?qū)е逻M度延期、工作效率低下、士氣低落等不利于團隊建設(shè)的情況出現(xiàn)。

Sprint周期內(nèi)團隊成員的組成結(jié)構(gòu)盡量_不變動，尤其是處于核心的主導(dǎo)成員。因為在這個周期內(nèi)，需要高度集中團隊整體的開發(fā)關(guān)注力，如果這時團隊的頭部成員發(fā)生更換，一定會存在溝通成本損耗，影響整體迭代效率。

還有一點務(wù)必注意，Sprint開發(fā)過程中，會議的頻次與時長是需要進行適當?shù)陌芽氐摹，F(xiàn)在很多人抱怨敏捷瞎開會的原因之一就是有些會議的RIO并不成正比，耗時且沒有正向的工作計劃輸出。所以每次開會_好由負責人主導(dǎo)會議，做好會議相關(guān)數(shù)據(jù)報表的輸入輸出，階段性的展示成果，給予團隊積極的正向會議反饋。

本次分享就到此為止，祝愿還在各種特色敏捷中各種糟心的同志們早日脫離苦海，走向真正的敏捷。

贊