互聯(lián)網(wǎng)產(chǎn)品的開發(fā)周期短，需求不斷變化，所以敏捷方法是很適合互聯(lián)網(wǎng)產(chǎn)品開發(fā)項目的。但綜觀國內(nèi)，能靈活且高效地使用敏捷方法去進(jìn)行項目管理的成功案例并不多。大的方面在這里就不啰嗦了，如需了解，可以看這里。

公司的一個項目也曾嘗試使用敏捷方法，但實踐中留下了諸多問題。大家都在抱怨根本沒有敏捷可言，最后做得不倫不類。究其原因，主要還是由于公司原有的組織架構(gòu)和業(yè)務(wù)類型造成的。

組織架構(gòu)：公司現(xiàn)有的組織架構(gòu)是矩陣型，QA和developer分別隸屬于不同的Manager。這樣就造成QA在項目中不能全力投入，QA manager有可能會安排別的任務(wù)給QA。敏捷項目則最好是QA和developer隸屬于同一個manager，這樣就便于協(xié)調(diào)QA的任務(wù)分配，保證QA可以全力跟進(jìn)項目；另外，敏捷項目中的人數(shù)為4-7人為宜，其中1-2人為QA。這么小的團(tuán)隊，沒必要再加入一個QA manager的角色，這樣只會增加了溝通的渠道數(shù)，反而影響了進(jìn)度。

項目類型：公司業(yè)務(wù)范圍屬有線電視領(lǐng)域，客戶為有線電視運營商。這類客戶是對產(chǎn)品的穩(wěn)定性和可靠性要求特別高。他們往往會在lab里面試用產(chǎn)品半年至數(shù)年之久，這樣用戶的反饋就非常慢，周期也拉得很長了。用戶的需求很難及時地反饋并反應(yīng)到產(chǎn)品上面來，所以敏捷開發(fā)對這類的產(chǎn)品根本不適合。

采用敏捷方法的項目對項目組成員要求較高，起碼整體是在同一個水平線上，沒有明顯示短板。另外則要求團(tuán)隊的合作意識較強(qiáng)，最好是已經(jīng)進(jìn)行了一段時間的磨合，團(tuán)隊成員之間相互了解，相互信任。敏捷方法非常強(qiáng)調(diào)信任：產(chǎn)品的Owner要信任團(tuán)隊成員；團(tuán)隊成員之間要相互信任；QA和developer之間要相互信任。出現(xiàn)了問題，不需要直接找QA，直接由developer來認(rèn)領(lǐng)； 任務(wù)單也是一樣，由成員自己來主動認(rèn)領(lǐng)。

產(chǎn)品的Owner則負(fù)責(zé)整體工作的協(xié)調(diào)，并負(fù)責(zé)確定項目的范圍。在用戶反饋方面，負(fù)責(zé)匯總和篩選，制定出下一個版本的Feature List。

這里要強(qiáng)調(diào)的是QA需求在需求分析階段就介要入，只有這樣，在測試的過程中才不會有遺漏項沒用測試用例覆蓋到。

另外，團(tuán)隊成員的座位安排也非常重要，他們要集中在某一區(qū)域，這樣非常方便口頭溝通和交流。即節(jié)省時間又可以避免距離較遠(yuǎn)而影響溝通效率的情況。

好的，就這些吧。

文章來源：互聯(lián)網(wǎng)老獵人的牧場

標(biāo)簽： 產(chǎn)品經(jīng)理 PM 互聯(lián)網(wǎng)產(chǎn)品 

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。