絕大部分人用來管理Scrum/敏捷開發的四類工具
阿新 • • 發佈：2021-09-03
目前針對產品研發管理的工具和平臺大致可分為四類，但無論是哪一類，因為敏捷理念的火熱，或多或少的能支援一些Scrum的需求，這也就造成了大家現在選擇Scrum工具時更加迷惑。下面我們就簡單聊聊這四類工具分別是什麼，又適用於什麼樣的環境。
一、基礎的scrum 工具
1、白板 白板是實施Scrum 最簡單直接的方式，用於每天跟蹤彙報，簡明易懂。但是對Product Backlog支援明顯不夠，也沒辦法保留歷史紀錄，而歷史記錄對於回顧還是非常重要的，畢竟Scrum 的核心理念之一就是通過短期回顧,達到持續不斷的改善。 2、Excel Excel相信很多團隊也有嘗試過，也有很多現成的模板可以用，但它主要問題是當成員比較多的時候，同時修改一個共享Excel檔案，會相互衝突，不好同步；同時表格的整理需要花費比較多的時間，以及視覺化管理功能並不滿足等（如燃盡圖）二、平臺類Scrum 工具
平臺類：釘釘，飛書協作類：Worktile，Tower， Trello，Teambition，Asana，Basecamp等
研發類：PingCode，Jira，Tapd，Coding等
平臺類，雖然通過外掛的形式具備了部分Scrum的功能，但總體來說，基本是各種辦公軟體的大雜燴，用於 Scrum 太過於臃腫。在一定程度也存在下架風險，比如外掛廠商與平臺沒談好下架的情況在以往也並不少見。 協作類的軟體的適用的範圍比較廣，一定程度也能滿足了Scrum管理的需求。 但這些協作軟體都有一個共同的特點——以專案的方式來滿足Scrum管理需求，這樣做當然能用，但體驗不好（別問為什麼，誰用誰知道）。三、落地Scrum 需不需要工具？工具該如何選擇？
如果團隊在25人以下，由於規模小資訊差不大，流程簡單，很多事情拉個會議，使用一般的白板或者是線上文件就能滿足需求，這個時候上工具有時候反而會給團隊的效率造成阻礙。 但是當敏捷成為超過百人團隊，或進行大型專案的主流開發方式時，這些自己臨時組織起來的技術團隊，或者是在跨團隊之間，以及日常管理多個團隊，如僅靠白板、電子表格和Wiki 等將難以滿足需求。四、Scrum管理工具的簡單評測
為了避免口水戰，我們這裡僅從Scrum方法論出發，對比這些工具在功能匹配度上的一些不同（僅供參考，體驗深度問題可能有一定程度出入）
從Scrum工具的功能層面角度可以看出，PingCode 這裡做的是比較不錯的，甚至是說完整支援了 Scrum 敏捷開發流程。
當然，功能數量只是表面，我們還做了更深入的測評，由於每個測評篇幅會過長，所以這裡我們就以PingCode為例。
五、Scrum管理工具的深入體驗
1、Scrum角色管理 Scrum 框架下有3種常見角色：產品負責人（Product Owner）、敏捷教練（Scrum Master） 團隊成員（Scrum Team） 在體驗中，PingCode 能以自定義專案角色和許可權的方式對成員進行分組和許可權管理。比如配置不同角色不同的管理和檢視專案、工作項型別等許可權，專案成員亦可擁有多個角色。 2、需求管理 按照Scrum的一般做法，迭代開始前，由產品負責人收集來自各方需要、期望和訴求，評定優先順序，整理出產品 Backlog，通過會議評審形成 Sprint Backlog。 在體驗中，PingCode是以史詩、特性、使用者故事三級方式進行需求管理。可以通過自定義需求狀態、補充各類屬性欄位，編寫完整描述，上傳相關產品文件等方式，形成完整的故事結構。 也可以利用「子工作項」進行復雜需求細化和拆解 當然，值得一提的是需求也可與使用者反饋、研發任務、測試結果、Wiki的文件等工作項相關聯，便於其它成員查詢引用、追溯來源。3、規劃 無論是產品規劃或者是制定產品的里程碑，產品路線圖對於產品團隊來說都是很需要的，我們來看看Pingcode的表現： 用一句話來形容就是：我們一眼就能看到未來三個月甚至一年要做哪些產品功能，而且能知道先做什麼，再做什麼，哪一個功能做完才能做另外一個功能。 是管理層特別喜歡的功能了 4、缺陷管理 這個模組很明確，就是列出我們開發過程中或者通過使用者反饋提交的所有的缺陷，具備優先順序等屬性設定。 5、迭代 這是我們敏捷開發過程中用到的最核心的功能，也是支撐我們 Scrum 流程的靈魂。 就PingCode來說，在Sprint規劃以及資訊豐富度上是做的比較好的。 這裡我最想聊的是工作項（可能這不在Scrum管理之列），這是一個真正體現研發團隊的價值的資料的能力。 比如下面的使用者故事 ：該使用者故事的負責人是誰，子任務如何拆分的，關聯了哪些工作項，關聯的測試用例是什麼，開發過程中提交的開發資料和資訊是怎樣的，工時是怎麼登記的，關聯的 Wiki 頁面是什麼，都上傳了哪些附件，評論中都討論了哪些事情，該工作項的活動軌跡是什麼，狀態是怎麼流轉的等等。 6. 跟蹤迭代進度 迭代開始後，每日站立會議對迭代進行跟蹤。各成員快速任務進度、今天的計劃、遇到的困難等就成為常態，燃盡圖在這裡必不可少。 我們從下圖也能看出，PingCode迭代概覽、燃盡圖基本具備，在直觀反映各成員工作狀況、當前迭代進度的健康程度上並沒有啥毛病。 7、迭代回顧 在迭代完成後，團隊成員對當前迭代所完成的工作成果進行演示覆盤。 這個環節PingCode支援整個迭代情況概覽，以及迭代回顧看板記錄，基本能滿足回顧覆盤的需求。
除以上講的一些之外，我發現PingCode還具備版本、篩選器（全域性搜尋）、工時統計等一些在Scrum管理中比較好用的功能。但這裡就偷個懶，不一一講解。
就體驗來看，PingCod在系列Scrum管理工具中也是特別值得嘗試的一個選擇，當然，需求各有不同，我是以自身團隊的經驗來判斷的，也僅供大家參考。