當(dāng)敏捷來(lái)敲門：你深陷的“敏捷式加班”，并不是真正的敏捷

干貨分享

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

抱怨的聲音

在互聯(lián)網(wǎng)公司工作的各位應(yīng)該或多或少都應(yīng)該聽過(guò)敏捷，目前，敏捷(Agile)的概念應(yīng)該已經(jīng)相當(dāng)?shù)钠占?，尤其是在一些大公司?nèi)部，搞敏捷已經(jīng)成了項(xiàng)目相關(guān)人員的日常活動(dòng)。2019年由Scrum.org和Age of Product出版的Scrum Master趨勢(shì)報(bào)告明確表示敏捷變革將會(huì)是未來(lái)企業(yè)項(xiàng)目管理的大勢(shì)所趨。

運(yùn)用敏捷方法進(jìn)行項(xiàng)目的部分企業(yè)

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

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

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

不敏捷的下場(chǎng)

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

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

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

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

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

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

敏捷的“敗因”

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

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

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

真正的敏捷

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

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

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

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

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

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

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

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

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

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

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

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

本次分享就到此為止，祝愿還在各種特色敏捷中各種糟心的同志們?cè)缛彰撾x苦海，走向真正的敏捷。

贊