9天封閉式開發(fā),敏捷開發(fā)的實踐經(jīng)歷
敏捷開發(fā)是一種以人為核心、迭代、循序漸進(jìn)的開發(fā)方法,通過快速、高效的反應(yīng)速度,積極、高頻的溝通為客戶提供一條暢通的指揮通道。而作者經(jīng)歷了九天的封閉式開發(fā),在文中跟大家分享這次敏捷開發(fā)的實踐經(jīng)歷。
這是一次一個面向老板出產(chǎn)品的經(jīng)歷,一個傳統(tǒng)互聯(lián)網(wǎng)公司想要轉(zhuǎn)型成移動互聯(lián)網(wǎng)公司的關(guān)鍵節(jié)點上,當(dāng)時經(jīng)過很長一段時間的產(chǎn)品調(diào)研和業(yè)務(wù)流程的梳理,每次會上都會有近十個總監(jiān)級別的各個部門老大。
由于每次意見不統(tǒng)一,僵持不下,導(dǎo)致產(chǎn)品一拖再拖。最后老板迫于壓力,在4月1日給出了一個命令,必須在4月20號做出來一個能看的產(chǎn)品。
迫于無奈,在4月10日進(jìn)行封閉式開發(fā),9天的時間完成了一個電商類型的小程序,已經(jīng)面向酒店和公司的兩個后臺系統(tǒng)。
正是在這樣的情況下,才能夠體會到敏捷開發(fā)小而快思想的精髓。
第一點,我們遇到的問題
盡管,前期我們有進(jìn)行一個相對比較長的研究,但是并沒有梳理形成一個完整體系。在整個研討會上,也沒有形成一個明確的產(chǎn)品目標(biāo)以及產(chǎn)品的形態(tài)。以至于一直停留在梳理業(yè)務(wù)流程上,沒有一個比較實質(zhì)的進(jìn)展,即產(chǎn)品原型、產(chǎn)品架構(gòu)幾乎空白。
面向老總出產(chǎn)品最尷尬的是他們不在意后臺系統(tǒng),也就是他們往往會忽略后臺系統(tǒng)的工作量。公司又面臨了資金緊張裁員、UI團(tuán)隊需要多方共用,一些系列問題。
總結(jié)一下我們遇到的問題:
- 產(chǎn)品設(shè)計幾乎需要從0開始;
- 大量的后臺系統(tǒng)開發(fā)工作量沒有被正確評估;
- 研發(fā)團(tuán)隊人數(shù)不過;
- UI團(tuán)隊無法All In。
以上的問題,當(dāng)我們一起討論分析,如果想要快速滿足老板的需求,必須進(jìn)行封閉式開發(fā),而且整個團(tuán)隊需要嚴(yán)格的控制和監(jiān)管,降低風(fēng)險,那么就必須要有一個更高效的協(xié)作方式來完成目標(biāo)。
所以,我們選擇使用敏捷開發(fā)的團(tuán)隊協(xié)作方式。
第二點,什么是敏捷開發(fā)
敏捷開發(fā)(Agile Development)是一種以人為核心、迭代、循序漸進(jìn)的開發(fā)方法,通過快速、高效的反應(yīng)速度,積極、高頻的溝通為客戶提供一條暢通的指揮通道。
開發(fā)方式一般分為:Scrum 和 XP。
Scrum: 團(tuán)隊最佳人數(shù)控制在5~9人,一個迭代為四周時間,不允許需求的變更。
XP:更側(cè)重于測試驅(qū)動開發(fā),一般迭代為1到2個星期,允許等量工作量的需求替換。
在整個開發(fā)過程中,因為技術(shù)團(tuán)隊、產(chǎn)品團(tuán)隊的成熟度還不高,無法提供完整的XP模式開發(fā)方式,而項目有偏向于使用XP模式。
綜合考慮,我們在Scrum和XP模式下吸取各自的優(yōu)點:
- 允許中途變更等量的需求,因為在整個過程中,很有可能面臨老板的新需求,必須做到快速響應(yīng);
- 嚴(yán)格按照優(yōu)先級進(jìn)行開發(fā),因為時間短,User Story之間很有可能存在依賴關(guān)系,如果沒有按照優(yōu)先級進(jìn)行開發(fā)很容易導(dǎo)致團(tuán)隊有些成員很忙,有些成員符合無法達(dá)到飽和;
- 采用產(chǎn)品經(jīng)理驅(qū)動項目進(jìn)度,而不是使用TDD模式,主要原因是因為整個技術(shù)團(tuán)隊在TDD模式上未實踐過無法做到自我管理的程度,只能通過產(chǎn)品經(jīng)理人肉測試和項目跟進(jìn);
第三點,我們怎么選定工具
敏捷開發(fā)是一種快速響應(yīng)需求的開發(fā)方式,不同于傳統(tǒng)的瀑布式開發(fā),在管理流程上也就不同。產(chǎn)品經(jīng)理通過采集需求,整理出產(chǎn)品需求池(Product Backlog),然后輸出到研發(fā)團(tuán)隊進(jìn)行工作量評估、實現(xiàn)可行性,最后根據(jù)優(yōu)先級進(jìn)入到迭代需求池(Sprint Backlog)進(jìn)行一輪迭代。
再通過每天的站立會進(jìn)行對需求完成情況的審核,控制風(fēng)險。
以下是一個完整的產(chǎn)品迭代的過程:
通過什么會議進(jìn)行管理?
通常情況下,一個敏捷開發(fā)需要以下的會議來把控研發(fā)的進(jìn)度:
- Sprint 需求規(guī)劃會議
- 項目立項需求同步會
- Sprint 功能規(guī)劃會議
- 估算會議——根據(jù)項目情況合并到 Sprint功能規(guī)劃會議
- 每日立會
- Sprint 評審會議(Review Meeting)——根據(jù)項目需要舉行
- 項目復(fù)盤會議
當(dāng)然,我們根據(jù)當(dāng)時時間緊迫,在盡可能表達(dá)清楚需求的情況下,降低溝通的時間,這也導(dǎo)致了后續(xù)出現(xiàn)了一些問題。比如:整個團(tuán)隊對項目的理解不夠深入,在開發(fā)過程中會存在一些偏差,導(dǎo)致需求返工的情況出現(xiàn)。
敏捷開發(fā)需要依靠什么工具進(jìn)行管理?
在高強度的開發(fā)中,如果沒有一系列工具進(jìn)行管理,將會讓整個項目失去控制。
敏捷開發(fā)的工具主要有:
- Excel 需求池,用于管理需求,一般分為產(chǎn)品需求(Product Backlog)和迭代需求(Sprint Backlog);
- 任務(wù)看板,主要用于管理需求狀態(tài),跟蹤延誤的需求,查找成員是否成為絆腳石;
- 燃盡圖,查看用戶用例(User Story)是否按照計劃如期完成;
- 計劃撲克牌,防止研發(fā)因為考慮不全導(dǎo)致預(yù)估工期不準(zhǔn)確。
第四點,敏捷開發(fā)實踐過程及結(jié)果
成員組成:一個產(chǎn)品經(jīng)理、一個交互設(shè)計師、一個后勤、3個后端工程師、3個前端工程師、機動UI設(shè)計團(tuán)隊。
成果:完成一個小程序、兩個系統(tǒng)后臺。
實踐過程:
整個TAPD工作流設(shè)計:
產(chǎn)品規(guī)劃 => 交互設(shè)計 => UI設(shè)計 => 實現(xiàn)中 => 產(chǎn)品體驗 => 缺陷
缺陷的處理流程:
新 => 已接受 => 處理中 => 待驗收 => 已驗收 => 已關(guān)閉
我們在整個過程中,嚴(yán)格遵循以下幾個原則:
- 產(chǎn)品設(shè)計需要拆分高內(nèi)聚低耦合的模塊,設(shè)計并且及時輸出最小可用單元,保證項目不會產(chǎn)生類似瀑布流開發(fā)的模式。
- 每日完成手頭上的需求才算完成當(dāng)天的工作,確保每個人的需求能夠完成保證進(jìn)度。
- 每日晚上十點進(jìn)行審核,事實上,為了讓大家能夠繼續(xù)加班到凌晨的小技巧,也確保缺陷不過日。
- 每個模塊需要完整的走過工作流,也就包括缺陷,出現(xiàn)問題及時調(diào)整。
實踐遇到的問題:
- 剛開始團(tuán)隊磨合工具,沒有及時變更工作狀態(tài)。
- 預(yù)留給產(chǎn)品設(shè)計的時間太少,導(dǎo)致產(chǎn)品設(shè)計并沒有太全面,邊界條件未充分考慮。
- 需求排優(yōu)先級出現(xiàn)錯誤。
- 需求會沒有被重視,導(dǎo)致開發(fā)過程中需求重新開發(fā)。
- 測試環(huán)節(jié)節(jié)奏比較混亂,沒有從頭到尾測試聯(lián)調(diào)。
- 產(chǎn)品更新原型,缺少比較好的同步工具,讓所有人一直都是使用最新的文檔。
通過9天時間封閉式開發(fā)產(chǎn)生的數(shù)據(jù):
由于離開上家公司的時候沒有整理出來這些資料,大致上,我們通過9天的時間完成了:
- 需求點大致上有300+個,采用前后端分開提需求點;
- 測試并且修復(fù)400條bug,基本上做到日清。
最后,注意事項
并不是所有的項目都適合用敏捷開發(fā),在項目沒有特別明確的目標(biāo),團(tuán)隊技術(shù)水平太弱、需要工期本身比較長無法細(xì)化顆粒度的情況下,使用敏捷開發(fā)會存在很多問題。
比如:
- 響應(yīng)無法做到及時;
- 對工具的使用無法快速適應(yīng);
- 沒有明確目標(biāo),缺乏緊迫感。
等等一系列問題,都會讓整個敏捷開發(fā)變得不敏捷。
導(dǎo)致整個項目的燃盡圖呈現(xiàn)下圖這樣:
而正常的燃盡圖應(yīng)該未關(guān)閉的線段貼合基線:
不過,嘗試使用敏捷開發(fā)小而快的開發(fā)思想在自己的項目管理過程中也是不錯的。
參考資料
- 敏捷開發(fā)之Scrum掃盲篇
- 敏捷開發(fā)(agile)中story
- 讀書筆記Scrum 總結(jié)
- 瀑布式開發(fā)、迭代開發(fā)、敏捷開發(fā)、XP與SCRUM的區(qū)別
本文由 @UShow Jack 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議
敏捷更適合2c,2b不是很適合
每晚10點評審,加班到凌晨,現(xiàn)在上班都這樣了?
不是的,這個是封閉開發(fā)的情況,事實上敏捷開發(fā)一般是早上站立會,明確今天必須完成的任務(wù)
互聯(lián)網(wǎng)的世界里,時間變的越來越是金錢的道理都清楚,以快打忙。敏捷開發(fā)實現(xiàn)小步快跑,不斷迭代試錯,是適合目前形勢發(fā)展的,反而以前的MIS系統(tǒng)年代的瀑布式開發(fā):周期長,過程需求不可控,風(fēng)險無法及時傳達(dá),不可取。
贊。確實如此,敏捷開發(fā)就是要小步快速迭代,不斷試探用戶需求。
敏捷開發(fā)的關(guān)鍵在于團(tuán)隊間的默契與凝聚力。技術(shù)團(tuán)隊才是重中之重。
是的,需要團(tuán)隊成員有比較高的主動性,PM也需要激發(fā)團(tuán)隊的激情
這種開發(fā)真的好嗎?會不會造成當(dāng)時為了趕工后期填坑?
這樣的開發(fā)確實不好,而且應(yīng)該批判對待。但是,在整個開發(fā)進(jìn)度上,敏捷開發(fā)的控制力度是很有優(yōu)勢的
敏捷開發(fā)原則–允許帶著BUG上線的,試錯嘛,MVP不可能十全十美,萬一用戶不喜歡,那產(chǎn)品就被拋棄,BUG也不用解決了,哈哈哈。
贊