中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

BugBash，即，缺陷大掃蕩。產品版本發布前，團隊全員集中起來、共同找Bug。是軟件工程、互聯網產品開發過程中，驗證環節很重要的一個活動。

什么是Bug Bash？

Bug Bash，顧名思義就是缺陷大掃蕩，讓大家在產品版本發布前，一起集中精力來找缺陷。是軟件工程、互聯網產品開發過程中，產品驗證很重要的一個活動。通常可以由項目經理或QA主導發起。

什么時候做？

建議是在上線前，QA第二輪測試結束通過后，確保線上沒有重大bug影響試用、服務是穩定的狀態下，可以舉行Bug Bash。

但這邊有個兩難是：確實等到前面描述的狀態完成后，bug bash比較正規，團隊不會因為重大bug而block各環節的試用，而且是比較接近上線后用戶的使用狀態；但壞處是通常開發時間是很緊湊的，當到第二輪測試結束后，通常離上線也沒幾天，如果BugBash提出很多需求類的bug、新需求、大改動的部份，其實已經來不及在本版本實現，就會放入需求池或之后版本實現。經常最后BugBash很多提出的問題或需求都會越積越多，修復之日路漫漫。

當然解決方式，可以在提測后，就邀請產品策劃、交互、視覺針對產品做個驗收，確認產品是否跟設計符合，以及是否有些需求bug、新需求、改進提出，可以減少Bug Bash時的需求類bug的數量，及早讓團隊因應。

跟QA做的測試區別是什么？

有同學會問：那是不是我們可以只做Bug Bash，不需要QA了？其實QA是有更專業、更全面、更完整的測試計劃與策略，Bug Bash則可以補充QA的工作，發現一些QA可能沒發現的問題?；蛘弋擰A人力不足時，眾人一起找bug的效率也較高。

加上Bug Bash參與者多，更能發現兼容性或用戶登入、權限差異等問題， 事先就可以約定好哪些人分別使用不同瀏覽器、手機、作業系統來找問題。而且一樣米養百樣人，大家對於產品操作的理解，也會差距十萬八千里；加上多人同時協作來使用系統，這個操作的復雜度就會呈現指數級的差異，可能會發現在測試環節不容易找出的復雜bug。QA在設計測試用例只能針對功能點來測，但許多新功能點交叉加上老的功能點，復雜度也會增加，這就需要眾人齊力發現復雜性bug，使得質量更有保障。

有QA同學做測試，不做Bug Bash是可以的；但是只做Bug Bash，沒有QA則是很大問題。

為什么做Bug Bash？

團隊集體試用，發現需求

可能有人覺得Bug Bash都提需求會不會走偏？其實提新需求也是很重要的，因為Bug Bash中，我們的角色就不只是研發團隊，也是以用戶的角度來看產品。如果內部團隊自己都有覺得很多需要添加的需求，那產品經理或策劃也該好好考慮調整產品的設計。網易教育產品的項目經理也針對這問題做過問卷，團隊原本都是對於在Bug Bash提建議有疑慮，問卷統計出來，大部分人還是支持在Bug Bash提需求與bug都可以。

此外在Bug Bash前，開發都只是專注在自己的部份，可能都沒有完整真正試用過整個產品，要促使團隊自己主動去試用比較難。當測試第一二輪結束后，Bug Bash是一個強制的活動，促使大家真正把自己做的產品用一遍。很多之前只是在設計、交互稿看到的都只是紙上談兵，真正用起來，才會發現問題或需求，也是看交互與文案是否容易被大家理解。所以我負責的兩個項目，經常是新需求以及需求類的bug多過開發產生的bug數。

及時梳理，發布前的剩余事項

用戶手冊、環境、帳號等等，由于大家要開始使用，會促使團隊思考上線還缺什么。由于開發與測試同學對于產品操作、環境都很熟，但在BugBash時，視覺、交互、策劃、項目管理都可能第一次看到成品，應該思考：用戶手冊看的懂嗎？數據庫資料有沒有準備好？等問題，讓產品上線前準備更完善。

游戲化激勵團隊

如果光只是宣導：「大家要注意質量喔」、「QA要盡量找出bug喔」，或者要求大家工作職責，可能團隊成員執行的動力就比較薄弱。但藉著bug bash，其實就是一種工作游戲化，透過大家聚集一起參與，然后加一些比賽的元素，會讓大家有個沖勁要努力找出bug，比誰找的bug數最多。這邊有一點要注意，主持人項目經理或QA不用只是在旁邊觀看或加油，也應該積極參與，一馬當先多找一些bug出來，來提升大家參與度。當然最后可以利用統計工具，計算一下大家的排名與bug數給予獎勵。

團隊平時自己可能會做團建，有些團隊不一定常搞活動。在這種類似游戲化的活動中，會促進團隊間彼此的溝通、良性競爭，對于整體團隊建設也是很有幫助的。如果項目經理要辦Bug Bash，其實可以弄的熱鬧一點，變成一種團建。

如何做BugBash？

1. 說明規則：準備一份ppt可以在周會上，跟團隊宣導說明：什么是bug bash、宗旨跟目的是什么、時間地點是什么、準備工作確認、游戲規則等，方便大家可以隨時查閱Bug Bash規則。
2. 問題記錄的工具：如果有用jira，先確認大家都有jira 6的權限、并可以建立一個叫Bug Bash的模塊（也可以是標簽，只要方便篩選、統計）。沒有jira也可以用云協作、Google doc、Wiki工具來代替，甚至每人發一張紙筆也一樣可行，只要方便大家紀錄，結束好統計即可。
3. 提醒大家做好準備：包括用戶手冊、環境是否都準備好、權限都開了沒、測試是否確保重大bug修復并驗證完畢。如果有經費，準備一些點心、水果、獎品，更有助于提到大家參與的興致。
4. 會議場地：項目組如果人少且都有筆記本電腦，可以借一間大會議室，方便隨時討論、合作、排除問題，讓大家能更集中投入這活動，氣氛也會更熱烈。但是如果沒有辦法借到大會議室或者大家都是臺式機不方便移動也沒關系，只要座位距離不遠、使用即時通訊軟件溝通，也一樣可以把BugBash做的有聲有色。
5. 統計工作：Bug Bash結束后，項目經理要統計全部issue數、有效bug數、需求數（案例見下圖）。并檢查是否有重復提交的問題，若有重復可以按照提交時間的先后順序，決定這題算是誰的，或是各得一半的分數。然后再把bug跟需求區分開來。另外有些團隊也可以根據提bug的價值與重要程度，給予不同獎勵。當然bug bash如果經費允許，可根據不同表現，給予對應同學一些獎勵，促進大家積極參與。
6. 最后也最重要的是，Bug Bash活動之后的問題落實。團隊要開個會，大家一起整理所有提出issue的優先級：判斷到產品上線前，哪些bug是要修好的、哪些是可以留到未來修。因為Bug Bash到產品上線時間可能已經很接近，除非是很嚴重的bug，或者是工作量小、效果大的（性價比高），可以考慮處理；其余都不應該做，這樣才能保障代碼的穩定性，以及準時交付。當然這版本不修的bug、不能實現的需求，可以標示重要性為minor放到需求池，在未來版本去實現。

BugBash問題反思

每迭代都做，容易失去新鮮感

我在幾個項目內推動，第一次一定是大家非常有新鮮感，參與度高。但是每個月迭代下來，大家逐漸對於這活動會失去激情。項目經理這時候就要好好反思一下，該如何改善與調整。我自己的經驗有兩個思路：

不一定每個迭代都搞，可以在大版本或者累積好幾個小迭代認認真真做一次大的Bug Bash、發發獎品，這樣可以保持大家的新鮮感。

另一個是，真的覺得有必要的時候，才做Bug Bash。團隊如果平常會主動走查、用戶反饋也很積極，到也就不必特別做Bug Bash，我們不用為了做而做，真的是發現有價值有需求，再推動效果反而更好。像是我網易有數的項目，就是QA同學與開發負責人感覺測試時間緊張，需要調動大家一起來Bug Bash，反而這樣大家自己提出來積極性更高，最后也認真準備小禮物，大家玩的也很high。

Bug Bash的限制?

有人會問BugBash是不是什麼功能都要測？其實也有限制。例如支付功能、跟實際時間相關的功能（教育產品的學期）、還有權限類等功能，會比較難在一兩個小時內眾人來做測試，對於團隊來說，要真的充值、還是要弄虛擬金錢、調整權限等，會比較麻煩，反而會阻礙其他功能的試用。建議這類功能，盡量讓專業QA來做測試。當然如果項目組事前準備工作妥善，當然BugBash能覆蓋這類功能是最棒。

總結與建議

Bug Bash不是一定要舉行的活動，如果有時間舉行，是對于團隊、產品等多方面都有好處的活動。其實不是只能讓內部團隊參與Bug Bash，例如二次元這個項目也曾經邀請用戶參與Bug Bash，效果也是很不錯的。讓我們一起提高產品質量，打擊小強！

作者：張孫恩，網易杭研項目經理，CSM、PMP。土生土長的臺灣人，臺灣大學MBA畢業。曾服務于美商默沙東藥廠、頂新集團。在網易擔任猛犸大數據平臺、網易有數敏捷數據分析平臺的項目經理，并服務過感知與智能中心（AI、AR）、ColorTouch、搜索算法等項目。關注大數據項目集的敏捷實踐，與企業級產品的戰略規劃、項目管理?！毒W易一千零一夜》主要作者之一。

本文由@網易杭研項目管理（微信公眾號：NetEasePM）原創發布于人人都是產品經理。未經許可，禁止轉載。