PingCode與Jira 敏捷開發管理能力的對比
阿新 • • 發佈：2022-02-19
敏捷開發是一種以擁抱使用者需求為核心、採用不斷迭代的方式進行的軟體開發模式，依靠自組織的跨職能小團隊，在短週期內通過快速、頻繁的迭代，迅速的獲取反饋，進而不斷的完善產品，給使用者帶來更大的價值。
雖然敏捷誕生只有20年的時間，但卻幫助了許多企業取得了成功，在這期間也湧現出來各種敏捷方法論和思想體系，最常用的兩種敏捷實踐分別為 Scrum 和 Kanban，採用合適的敏捷開發工具能夠幫助團隊更好的邏輯敏捷實踐，本文我們就來對比一下國產化的智慧研發管理工具PingCode和海外對標產品Jira在敏捷開發方面的支援差異。
1. 敏捷實踐支援
一套合適的敏捷開發工具，可以使得每個團隊獨立自主工作，並與企業中的其他團隊協作，每個團隊都可以採用適合他們的敏捷實踐，並對工具進行個性化的配置2. Scrum 支援對比
在敏捷開發流程 Scrum 標準定義中，有兩個關鍵性的產物：Product Backlog 和 Sprint Backlog，以及四個關鍵的時間：計劃會議、每日立會、評審會議和回顧會議。 下面我們來考察一下 PingCode 和 Jira 這兩個敏捷開發工具在 Scrum 這些關鍵性活動中的支援。2.1 路線圖規劃
在一個 Scrum 型別的專案中，PingCode 和 Jira 都支援通過甘特圖視覺化的方式進行路線圖的規劃，以便很方便的檢視每個工作項的開始/截止時間。但是由於二者在需求管理邏輯上的不同，導致路線圖的規劃方式也有細微的差別。 PingCode 中的 Scrum 專案內建採用Epic / Feature / User Story 三級需求管理：- Epic：史詩，表示比較大的特性，開發週期一般是1-3月
- Feature：特性，表示相對小一些的特性，開發週期一般是1-3周
- User Story：使用者故事，表示最小的使用者場景，開發週期一般是1-3天
而 Jira 中的 Scrum 專案預設提供的是 Epic / User Story 兩級需求管理：
2.2 Product Backlog 管理
在 Scrum 開發中，Product Backlog作為一個具有優先順序的需求列表，包括了所有預知的需要完成的產品工作，如產品規劃的需求、使用者提出的改進、技術升級優化等。 PingCode 中包括需求和缺陷兩類 Product Backlog，在一個特定的專案中使用兩個獨立的元件展示： Jira 中具有一個單獨的 Backlog 元件，所有的待辦事項都在此列表中展示：
2.3 Sprint Backlog 規劃
在一個Scrum迭代開始前的計劃會議上，團隊成員會一起從Product Backlog中根據確定的優先順序，挑選出當前迭代需要完成的工作項，並對這些工作項進行故事點估算，並進行任務拆解。從而形成Sprint Backlog，對於Sprint Backlog的規劃是Scrum迭代中計劃會議的一個重要的工具。 在PingCode迭代中，有獨立的規劃功能，可以非常方便的從需求、缺陷列表中挑選合適的工作項，進行迭代規劃。而在Jira中的Sprint Backlog規劃與Product Backlog管理在同一個頁面，在做迭代規劃時不夠直觀。
2.4 任務板/故事牆支援
任務板是以開發者的視角檢視當前迭代中待辦事項的進展情況，而故事牆則以產品經理的視覺檢視當前迭代中使用者故事的進展情況，任務板/故事牆都是Scrum開發中的重要工具，在每日立會中可以方便的通過任務板/故事牆回顧前一天的工作完成情況。 PingCode中原生支援任務板和故事牆，可以方便團隊成員通過不同維度關注迭代進展。在Jira中迭代的預設展示是看板，並不會明確區分任務板和故事牆，所有的使用者故事和開發任務在同一個看板中展現，不利於團隊成員從不同視角檢視迭代進展。
2.5 迭代回顧板
迭代結束時召開評審會議，在評審會議上每個人基於產品向團度其他成員展示自己在這個迭代中所完成的成果，團隊成員可以針對完成的事項提一些建議和反饋。在評審會議結束後，團隊成員會一起召開迭代回顧會，迭代回顧會是 Scrum 實踐中的最後一環，也是最重要的一環，迭代回顧會將整個迭代形成了閉環，並且基於會議上的成員之間的反饋可以幫助團隊持續改進。 在 PingCode 中則在迭代管理中開發了迭代回顧板，通過做的好的/需要改進/改進計劃三欄清晰的幫助團隊成員更好的記錄和追蹤迭代回顧內容； 而在 Jira 中迭代回顧會議只能通過 Confluence 中的Wiki頁面來記錄，這樣的方式導致迭代回顧會的記錄與實際工作中的迭代產生脫節，不利於回溯。2.6 版本管理
在敏捷開發 Scrum 實踐中，大部分團隊都會忽視版本管理，迭代是針對 Scrum 團隊的活動行為，而版本管理是針對產品的，它定義的是一個批量的概念，用於版本進度管理和交付風險管理，明確在一個版本中的最終交付物。 嚴格意義上說，迭代管理和版本管理是敏捷開發中的兩個並行的管理單元，因為在 Scrum 標準中並不強調版本管理的概念，導致很多團隊不重視版本管理，最終導致轉型敏捷的失敗。 現實敏捷開發中，迭代管理和版本管理的關係比較複雜，頗有剪不斷理還亂的趨勢：- 1個迭代對應1個版本：理想狀態下單一的小型研發團隊使用 Scrum，單個團隊負責單個系統，一個迭代釋出一個版本。
- 1個迭代對應N個版本：同時負責多個系統的小團隊，如負責底層基礎框架建設，在一個迭代釋出多個版本是常見的情況。
- N個迭代對應N個版本：在稍微大型一點的研發組織中，多個團隊同時負責多個系統，並行進行多個迭代，需要釋出多個版本。
2.7 Scrum 支援彙總
在下表中我們對 PingCode 和 Jira 在敏捷開發 Scrum 上的支援，做一個簡單的彙總
3. Kanban 支援對比
Kanban 方法作為另一種敏捷開發實踐，一個團隊採用Kanban方法來管理是否能夠成功，取決於使用Kanban後能否為你的團隊帶來以下幾點改進：- 幫助團隊視覺化整個鏈條的價值流動
- 幫助團隊識別價值流動中的風險點
- 幫助團隊度量價值流動中的各種浪費，並加以消除
3.1 視覺化看板
看板是一個具備約束條件，使用拉動方式來改變工作任務狀態的流程視覺化系統，選擇一個功能完備的視覺化看板系統，能讓團隊在推行Kanban 方法作為敏捷開發實踐時，起到事半功倍的效果。 PingCode中的看板，支援根據團隊業務需要在看板上顯示不同的工作項型別，同時可以自定義看板欄，在工作項狀態和看板欄之間配置對應關係，同時可以定義某個看板欄拆分為Doing/Done兩個子欄，在同一個專案中可以同時建立多個看板，便於根據業務場景的不同，或者團隊角色的不同定義多個看板，並針對每個看板的需要進行個性化的配置。Jira 中的看板也是支援定義看板欄，但無法定義欄和狀態之間的對應關係，預設每個工作項狀態都有一個看板欄與之對應，同時每個看板欄無法再拆分為Doing/Done子欄。每個專案中只支援預設提供的一個看板，無法根據業務場景不同，定義多個不同的看板。
3.2 WIP Limit支援
在敏捷開發中，WIP限制決定了每種情況下的工作流中可以存續的最大工作量。限制進行中的工作數量可以更容易辨識團隊工作流中的無效工作。在情況變得更糟前，一個團隊在持續交付通道中的瓶頸是非常容易辨別的。WIP Limit 旨在讓團隊專注於在開始新工作之前完成專案，雖然一開始具有反直觀性，但許多團隊發現 WIP Limit 可以極大的幫助他們提高工作效率並提高軟體質量。 PingCode和Jira中都支援對於每個欄定義WIP Limit，當超過最大限制時看板欄的背景色將會高亮顯示，WIP Limit 對欄中允許的工作項數量設定軟約束，實際上並不會阻止將更多工作項移動到欄中並超出限制。下圖是PingCode中的WIP Limit顯示：下圖是Jira中的WIP Limit顯示：
3.3 多泳道支援
看板可以幫助天對在工作流從定義移動到完成時視覺化工作流，而泳道還可以視覺化支援不同服務級別類的工作項狀態，如可以建立一個泳道來表示支援跟蹤需求的其他任何維度， 例如可以建立三個泳道（"加速"、"標準"和"Parked"）來跟蹤當前阻止的高優先順序工作項、標準工作項和一般工作項。 在PingCode中支援團隊根據自己的實際業務場景需要，自定義不同的泳道，泳道的命名和用途完全由開發團隊自行決定，可以更好的幫助團隊實踐Kanban方法，在設定泳道後，可以將工作項拖動到泳道中，還可以在泳道中重新排序。Jira 中並不支援團隊自定義泳道，只可以通過系統提供的兩種方式劃分泳道：即通過工作項負責人和工作項型別進行分泳道展示。這樣的泳道本質上只是工作項的另一種分組展示形式，並不能為團隊實踐Kanban方法帶來很大的幫助，團隊無法根據自身的業務場景進行自定義泳道。
3.4 完成定義支援
完成定義可以使團隊在從一個階段到下一個階段時更新工作項狀態時，有助於團隊成員就完成的含義達成一致的共識。 通過為每個看板列指定完成定義的條件，幫助團隊明確完成的概念，完成定義有助於確定在將工作項移動到下游階段之前要完成的基本任務。 此外還可以幫助團隊實現核心看板原則之一： 使程序和策略明確。 PingCode 中原生支援對於看板列的完成定義：在確定後完成的定義後，團隊成員可以在看板中直觀的看到完成定義：
Jira 看板中並不支援完成定義，團隊成員只能通過其他手段就完成的定義進行共識。3.5 流程自動化
在視覺化看板中，流程自動化可以極大程度上減少團隊成員手工操作的時間，根據確定好的業務規則進行一些自動化的工作。 PingCode 中對於視覺化看板系統的流程自動化支援通過兩個方面支援：- 一是PingCode中有獨立的流程自動化的產品Flow，通過在規則中配置相應的觸發器、條件和動作，可以非常輕鬆的實現流程自動化；
- 二是採用看板中的輕量級觸發器實現流程自動化。
PingCode 看板中內建的輕量級觸發器：
Jira 中的流程自動化通過內建的Automation功能實現：
3.6 Kanban 支援彙總
在下表中我們對 PingCode 和 Jira 在敏捷開發 Kanban 上的支援，做一個簡單的彙總。4. 總結
我們從敏捷開發的Scrum和Kanban的功能支援完整性方面，分別對比了國產化研發管理工具PingCode和海外對標產品Jira，從功能支援的完整性方面看，PingCode支援的更加完善和標準化，不管你的團隊是採用Scrum還是Kanban，都可以使用PingCode進行非常方便的管理。最後簡單說一下兩款產品在非功能性方面的差異。- 子產品之間的互通性：PingCode 中所有的子產品都是構建在統一的資料模型，最大程度上實現了各個子產品之間的資料互通與關聯，與使用者故事與測試用例之間連線，團隊目標和具體工作項之間連線，Wiki頁面和工作項之間連線。Jira各個產品之間更加獨立，都是作為單獨的產品使用，各產品之間的資料互通性並不好。
- 產品的易用性：PingCode 作為國產化的新一代智慧化研發管理工具，從產品構建之初就十分重要產品的使用者體驗，整個PingCode的子產品矩陣都構建於統一的使用者體驗之上，符合國內研發團隊的使用習慣。Jira 因為發展歷史比較長，揹負很大的歷史包袱，再加上非常繁雜的配置工作，產品的易用性相對較差。