Scrum開發(fā)的失敗經(jīng)歷及心得
本文作者回顧了自己一次失敗的Scrum開發(fā)經(jīng)歷,總結(jié)了如下問題及改進(jìn)方法,望對(duì)后來(lái)者有幫助。
背景
公司是一家初創(chuàng)公司,因?yàn)樾聵I(yè)務(wù)需求:另外兩個(gè)部門需要開發(fā)互聯(lián)網(wǎng)產(chǎn)品,于是成立了IT研發(fā)部。我的崗位是產(chǎn)品,另還有前端3枚、后端1枚、UI1枚、產(chǎn)品總監(jiān)1枚。除產(chǎn)品總監(jiān)外,其余都是萌新。
IT技術(shù)總監(jiān)決定以Scrum敏捷開發(fā)來(lái)進(jìn)行日常開發(fā),由于其比較忙,暫由我擔(dān)任敏捷教練,帶著從沒接觸過敏捷開發(fā)的大家,一起嘗試。
到目前,大家已有1年的磨合了,開發(fā)完了兩個(gè)線上產(chǎn)品。然而,對(duì)于團(tuán)隊(duì)的戰(zhàn)斗力(一個(gè)產(chǎn)品需要多久開發(fā)完?大概幾個(gè)sprint完成?每個(gè)sprint能做多少個(gè)任務(wù)?)還是模糊不清的,可以說(shuō)scrum開發(fā)實(shí)踐的蠻糟糕的。下面就與大家分享下,希望后來(lái)者能避開我走過的坑。
Sprint1:估算埋的坑
我是運(yùn)營(yíng)轉(zhuǎn)的產(chǎn)品,對(duì)技術(shù)上可以說(shuō)是比較白的,只能邊學(xué)邊摸索著推進(jìn)團(tuán)隊(duì)Scrum開發(fā)的進(jìn)程。技術(shù)總監(jiān)傳授了一些技巧讓我組織切割故事點(diǎn),和程序一起估算開發(fā)任務(wù),并組織開站會(huì)。一開始真的是一個(gè)頭兩個(gè)大,我對(duì)如何切割故事點(diǎn)?怎么估算開發(fā)周期?晨會(huì)每個(gè)人說(shuō)完三個(gè)問題后又應(yīng)該如何?這些都都很模糊,隨著業(yè)務(wù)的進(jìn)展,只能硬著頭皮干了。
準(zhǔn)備階段,我把需求和故事點(diǎn)迷迷糊糊屢出來(lái)后,和程序開會(huì),讓他們了解產(chǎn)品的需求。關(guān)于估算,我們采取了每個(gè)程序各自估算的方法。前端負(fù)責(zé)做前端頁(yè)面和管理后臺(tái),后端一個(gè)人做所有的業(yè)務(wù)。需求列表里屬于誰(shuí)的故事,就各自估算,以人天為單位,放到teambition(協(xié)作工具)里。
到了開發(fā)階段,每天早晨會(huì)有站會(huì),我們各自在座位上走一輪。期間,越往后感覺大家越不上心,有點(diǎn)應(yīng)付。我做是主持角色,每天記錄成員工作完成情況。
結(jié)束總結(jié)時(shí),我們發(fā)現(xiàn)了兩個(gè)問題:
- 前端頁(yè)面兩個(gè)人寫的,各自有分配到頁(yè)面,但后期發(fā)現(xiàn)其中有個(gè)頁(yè)面是幾乎一樣的,這個(gè)而我切割故事的時(shí)候也沒有注意,他們各自重復(fù)的寫了,浪費(fèi)了時(shí)間。
- 延期了。我注意到,剛開始他們一天甚至可以完成估算的3天的工作量,但最終結(jié)果延期了3天(前期估算其實(shí)很不合理)。排除程序請(qǐng)假的因素,原因是有些任務(wù)程序不熟悉或開發(fā)期間遇到麻煩了,導(dǎo)致估算1天可以解決的任務(wù),卻做了好多天。站會(huì)也詢問對(duì)方能不能解決,有沒有啥困難,都口頭上說(shuō)沒問題很快能解決,可實(shí)際結(jié)果不是這樣。
失敗分析:
- 沒有大家一起打撲克估算,討論矯正,而是各自單獨(dú)估算,估算的不準(zhǔn)確。
- 需求會(huì)沒有溝通到位,成員沒有對(duì)整體產(chǎn)品做全面的了解,產(chǎn)品也沒點(diǎn)出不同模塊的相同頁(yè)面,減少開發(fā)的浪費(fèi)。
- 站會(huì)溝通不夠,成員遇到問題沒有足夠重視,沒有延期發(fā)生時(shí)的解決方案。
Sprint2:溝而不通,有形無(wú)神
到了第二個(gè)sprint的,遇到了一個(gè)極其嚴(yán)重的問題:由于前期后端接口的任務(wù)沒有估算和切割(我當(dāng)時(shí)也不懂,主要是引導(dǎo)者前端把故事做切割),然后,程序采取的是先寫頁(yè)面后調(diào)聯(lián)的方式(該方式也導(dǎo)致了后面前端程序回過頭調(diào)試時(shí),有些功能都已經(jīng)遺忘了,開發(fā)效率下降),導(dǎo)致前端頁(yè)面樣式都寫完了,卻沒有接口調(diào)試,只能停下來(lái)等后端寫接口。
此外,期間還暴露了很多其他問題,值得引起重視。如:
- 后端程序不太樂于溝通,數(shù)據(jù)庫(kù)進(jìn)度卡在了那里,沒有追蹤;
- 前期切割任務(wù)沒有列入后端的任務(wù),完全沒有發(fā)現(xiàn)這個(gè)問題,期間站會(huì)后端的匯報(bào)總是幫助前端調(diào)接口之類的,就略過了;
- 另,我作為Scrum master臉皮比較薄也沒有尋求技術(shù)總監(jiān)幫助,一般催程序一次兩次,對(duì)方還沒結(jié)束,只能繼續(xù)等著。
各種因素一起,導(dǎo)致了這個(gè)尷尬的局面。
失敗分析:
- 前后端沒有獨(dú)立開,前端實(shí)現(xiàn)依賴后端的接口來(lái)完成工作。
- 前期估算任務(wù),忽略了后端的工作,寫接口寫數(shù)據(jù)庫(kù)表等都應(yīng)該納入。
- 前端采取先寫所有頁(yè)面樣式,再全部統(tǒng)一調(diào)聯(lián)的開發(fā)模式,導(dǎo)致后期接口壓力巨大,回過頭調(diào)聯(lián)可能已經(jīng)忘記前面頁(yè)面的需求。應(yīng)該采取邊寫樣式邊調(diào)聯(lián)的開發(fā)節(jié)奏。
Sprint3:士氣低迷得結(jié)束
受前一個(gè)sprint的影響,后面只能讓后端穿插著配合前端寫接口,前端等待的狀況無(wú)法避免,肯定延期了,大家的目標(biāo)就是盡快交付。
由于前面頁(yè)面與調(diào)試的分離,導(dǎo)致每個(gè)階段都沒法進(jìn)行測(cè)試,后面我測(cè)試發(fā)現(xiàn)很多問題,只能又退回去返工,導(dǎo)致延期時(shí)間延長(zhǎng),拖了快1個(gè)月才上線。
此外,有個(gè)前端是新手,期間也沒代碼檢驗(yàn)的步驟,導(dǎo)致有些頁(yè)面用不了,重新返工。
延期期間每天加班,大家士氣更加低落,協(xié)作得非常糟糕。
失敗分析:
- 沒有階段性的測(cè)試及驗(yàn)收標(biāo)準(zhǔn),開發(fā)模式不規(guī)范,應(yīng)前期約定好并找專家確認(rèn)。
- 團(tuán)隊(duì)氛圍不理想,沒有重視并調(diào)整。
- 產(chǎn)品與程序溝通不到位,對(duì)需求理解不一致。
總結(jié)
最近一段時(shí)間,大家除了日常的開發(fā),還有各種bug修改任務(wù)穿插,Scrum的實(shí)踐處于半停滯狀態(tài),只有站會(huì)跟蹤在延續(xù)了。期間遇到的問題還是老問題,尤其是上線后爆發(fā)的問題,大領(lǐng)導(dǎo)責(zé)問技術(shù)總監(jiān),技術(shù)總監(jiān)追責(zé)我,我看著程序無(wú)辜的眼神和忙碌的身影,也特別委屈無(wú)奈,有決心改但不知道從何開始。
有時(shí)候很迷茫,覺得自己不是在做產(chǎn)品的工作,除了調(diào)研產(chǎn)品、設(shè)計(jì)原型、溝通需求、上線前測(cè)試外,還要兼職生活委員,注冊(cè)各種賬號(hào)、走款審批、整理密碼。最難的就是要做Scrum master,很吃力,對(duì)外溝通難對(duì)內(nèi)催進(jìn)度難,出了事還要背鍋。自己覺得做的不好,估計(jì)領(lǐng)導(dǎo)和團(tuán)隊(duì)成員也覺得我工作的不好吧,心累。期間至少有兩次,我感覺自己的自我被擊碎了。
但又很不甘心,從哪里失敗了,就想從哪里爬起來(lái),或許沒有我想象中那么難,只要再改進(jìn)一點(diǎn)就接近成功了。就像羅胖說(shuō)的,摔倒了并沒有什么大不了的,爬起來(lái),用簸箕把自己的碎片掃一掃,回頭再拼回去。
改進(jìn)思路
針對(duì)這段經(jīng)歷,我有一些改進(jìn)思路想法,也希望過來(lái)人給我提提意見,幫助成長(zhǎng),感恩。
- 先開一次輕松的會(huì),團(tuán)隊(duì)成員集思廣益,說(shuō)說(shuō)自己的改善意見,保持公開透明,下次開發(fā)時(shí)調(diào)整。
- 規(guī)范任務(wù)開發(fā)估算的步驟,以故事點(diǎn)+打撲克牌來(lái)一起打個(gè)樣,看看每次大家能完成多少個(gè)故事點(diǎn),慢慢提升效率。
- 高效溝通,適當(dāng)拍拍程序馬屁,他們也辛苦的,偶爾下午茶激勵(lì)大家。
- 臉皮再厚點(diǎn),只要發(fā)現(xiàn)延期的苗頭,放下手頭的工作,間隔性詢問追蹤,若超過一定時(shí)間則邀請(qǐng)專家?guī)椭鉀Q。
- 確立驗(yàn)收標(biāo)準(zhǔn),每個(gè)sprint結(jié)束了,進(jìn)行階段性測(cè)試,條件合適另邀請(qǐng)外部同事參與演示會(huì)。
- 燃盡圖跟進(jìn)進(jìn)度,發(fā)現(xiàn)問題,及時(shí)發(fā)現(xiàn)并針對(duì)性改進(jìn)。
- 把線上的互動(dòng),全部轉(zhuǎn)移到線下來(lái)(白板、估算撲克),增加參與感與儀式感。
實(shí)踐結(jié)果怎么樣?暫時(shí)未知,有結(jié)果會(huì)與大家分享。
本文由 @季月 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來(lái)自 pexels,基于CC0協(xié)議
Scrum,首先要求SM對(duì)每個(gè)sprint進(jìn)行跟蹤和驗(yàn)收,我們做的時(shí)候嚴(yán)格要求前端和后端分開,各自估算時(shí)間,邊做邊調(diào)接口的這種模式,這里面對(duì)開發(fā)的配合和要求稍微高那么一丟丟,這里面首先對(duì)前端和后端的負(fù)責(zé)人要求高,對(duì)故事的拆分,分配等等相關(guān)要做到心中有數(shù),不能稀里糊涂,delay的原因有很多,不光是程序員對(duì)任務(wù)估算不足,如果估算不足,那就是對(duì)需求評(píng)審的時(shí)候么有做好相關(guān)的流程和系統(tǒng)的理解,產(chǎn)品應(yīng)該是管事不管人,這樣才能很好溝通,尤其不懂技術(shù)的產(chǎn)品,萬(wàn)一流程規(guī)劃的不清晰,那就真的…
嗯,后面盡量拖技術(shù)總監(jiān)和我一起把前期工作做到位,只要能合理分配好,成員不拖延(拖延了,能看出是誰(shuí)導(dǎo)致的,及時(shí)讓其調(diào)整),到我能掌控的產(chǎn)品功能要求及驗(yàn)收標(biāo)準(zhǔn)階段,我能很好的把控住
敏捷不是沒有要求和過程管理,只是這些事情是需要SM進(jìn)行把控,什么做什么不做,所以敏捷的快體現(xiàn)在不做那么多的限制,但是SM本身就是裁判,團(tuán)隊(duì)做的不好的時(shí)候要及時(shí)喊停,但是樓主是萌新,也沒有項(xiàng)目管理經(jīng)驗(yàn)和技術(shù)背景,在判斷規(guī)則和做法的時(shí)候缺少必要的技能和背景的支撐,有些縮手縮腳,不能起到很好的團(tuán)隊(duì)引領(lǐng)作用,失敗在所難免,其實(shí)看了您的文章感覺這是軟件研發(fā)過程管理的常見問題,也起不到太多的借鑒意義,唯一值得警醒的是問題就是貴公司對(duì)敏捷和SM的選擇上稍顯草率
感謝,確實(shí)存在這些問題,后面還是希望能通過我的協(xié)調(diào)和把控,讓流程高效運(yùn)作,沒技術(shù)背景和經(jīng)驗(yàn)支撐,在邊做邊學(xué),最近在研究敏捷開發(fā)的書籍
敏捷開發(fā)的核心就是“人”啊,對(duì)個(gè)人能力要求會(huì)很高
感覺延期的主要原因,是程序碰到難題,過不了關(guān),導(dǎo)致拖期,一是請(qǐng)外部專家協(xié)助解決,另一個(gè)要讓程序知道是他的原因?qū)е峦掀凇?br /> 萌新通常都會(huì)這樣,如果有人偷懶耍滑,堅(jiān)決斃之,不然真整個(gè)團(tuán)隊(duì)都會(huì)。。。
是的,就是實(shí)行起來(lái)為難的,大家都是每天見的同事,哎
scrum,Master是關(guān)鍵啊,需要有團(tuán)隊(duì)中的Keyman都具備足夠的能力才行。如果團(tuán)隊(duì)成員大多是弱雞,建議不要輕易嘗試
??
港真,scrum對(duì)開發(fā)的綜合能力(技術(shù),大局觀等)要求非常高
所以小團(tuán)隊(duì)采用啥方法合適?