打造Worktile敏捷開發管理工具的思與惑

從2019年初，咱們團隊準備開發一款適合研發團隊使用的敏捷開發管理工具，那時候咱們也在思考，到底什麼樣的工具纔算是優秀的研發管理工具，研發管理的場景、方法和流派有不少，市面上關於研發管理工具的產品也是層出不窮，咱們從哪裏入手才能真正幫助研發團隊提升研發效能？基於如下兩點考慮，咱們選擇了從敏捷開發管理進入：

1. 敏捷開發自1999年以來，通過20多年的發展，已經被大多數開發團隊所接受，近幾年DevOps的流行，更是把敏捷推向了更高的位置，國內太多的團隊須要作敏捷轉型。
2. 敏捷開發在中國落地的專業度還不夠，以致於出現了「中華田園敏捷」的說法，中國的開發者須要一款簡單易上手的、專業的敏捷開發管理工具，來幫助他們在團隊中更好的落地敏捷。雖然只靠一款敏捷開發工具並不能幫助企業在敏捷轉型中成功，但好的工具卻能讓企業敏捷轉型事半功倍。

專業的Scrum流程管理

在Scrum Guide中已經對於Scrum過程當中的活動、事件、產出等定義的很是清晰，這裏再也不重複，只想重點解釋一下在落地Scrum過程當中常常被忽視的兩個問題。

一、絕大部分團隊在實施Scrum過程當中只重視迭代管理，不重視版本管理，固然這已經超出了Scrum自己的範疇，可是好的研發管理中應該是迭代管理和版本管理並存，他們之間是一個互相依賴的關係。

迭代管理是針對Scrum團隊的，它定義的是一個時間盒的概念，用於團隊容量管理和進度管理，對於不一樣的團隊來講，明確在一個迭代的時間盒內的產出，這個產出最終以迭代Review爲標準，經過了Review並不意味着必定發佈出去。

版本管理是針對產品的，它定義的是一個批量的概念，用於版本進度管理和交付風險管理，明確在一個版本中最終的交付物。目前市面上大部分敏捷開發管理工具，都可以很好的支持迭代管理，卻忽視了版本管理。

圖1 Worktile Agile中的版本管理

二、在Scrum Guid中定義一個迭代中的四個活動，即迭代計劃會議、每日立會、迭代評審會和迭代回顧會，咱們發如今大部分敏捷團隊中其實只有前三個活動，而自動忽略迭代回顧會議，偏偏相反，迭代回顧會是Scrum迭代實踐中的最後一環，也是最重要的一環，迭代回顧會將整個迭代造成了閉環。Scrum小組都是自組織的，只有經過迭代回顧會不斷的總結問題，提出改進項，才能幫助團隊不斷精進。

圖2 Worktile Agile中的迭代回顧面板

什麼纔是真正的Kanban

Kanban理論已經存在了很長的時間，其適用範圍也從最初的車間管理，到如今的硬件製造、軟件開發。在軟件開發領域內，不少團隊都在使用Kanban管理本身的團隊，有的使用電子看板，有的使用物理看板。Worktile團隊在作電子看板上已經有了7年的經驗，一直以來咱們也在探索，到底什麼樣的看板纔是真正的Kanban。在我看來，一個真正意義上的電子看板系統，要可以幫助團隊達到如下三點：

• 幫助團隊可視化整個鏈條的價值流動
• 幫助團隊識別價值流動中的風險點
• 幫助團隊度量價值流動中的各類浪費，並加以消除

基於以上考慮，在一個可視化的電子看板系統中，至少要具有如下一些能力：

• 可以清晰定義在製品WIP
• 可以清晰定義在製品限制WIP Limit
• 明肯定義DoD
• 支持多泳道分割
• 在製品流轉中某些操做自動化
• 達到某些風險點時，在製品可以高亮顯示

圖3 Worktile Agile中的Kanban管理

需求管理如何作

不論是採用哪一種敏捷方法實踐，需求管理都是敏捷開發中很是重要的一環。Scrum中定義了兩個重要的概念： 產品待辦事項Product Backlog 和 迭代待辦事項Sprint Backlog ；Kanban中通常採用在製品WIP的概念。

在Worktile Agile中，咱們決定採用業界你們共識的三級需求管理體系，這種表示方式並無一個真正意義上的標準：

• Epic：史詩，表示比較大的特性，開發週期通常是1-3月，用於產品路線圖的規劃
• Feature：特性，表示相對小一些的特性，開發週期通常是1-3周，用於產品版本的規劃
• User Story：用戶故事，最小的開發粒度，開發週期通常是1-3天，在Scrum中用User Story來做爲Backlog，在Kanban中能夠用User Story做爲WIP。

圖4 Worktile Agile中的Epic、Feature、User Story三級需求管理

聯動起來纔有價值

在研發場景下，對於團隊成員來講常常整理需求/缺陷是個常態，另外在基於單個工做項溝通時，每每會說起另外一個工做項，做爲高效的研發管理工具，要可以清晰的定義工做項之間各類可能的關係。Worktile Agile中咱們定義了超過10種工做項之間的關係：

• parent：定義工做項之間的父子關係
• duplicates：表示兩個工做項之間的重複關係
• blocks：表示兩個工做項之間的阻塞關係
• 其餘的如mention、clone、causes關係等

只可以定義關係還不夠，Worktile Agile還作到了在發生某些操做的狀況下，自動生成他們之間的關係，若是團隊成員在某個工做項評論中提到了另一個工做項，則會在他們之間自動創建一條mention關係。

圖5 Worktile Agile中定義工做項之間的關係

工程化不可或缺

在研發管理過程當中，項目管理是很重要的一塊，但項目管理自己並不會關注工程化的過程，在我看來，項目管理和工程化實踐是確保研發順利的兩個支柱，缺乏哪個都會形成不可預知的影響，把工程化數據與管理過程結合起來，將會極大的減少管理成本，提高研發效率。

工程化的過程環節衆多，涉及到的工具數量龐大，如代碼託管、單元測試、代碼掃描、流水線、打包、製品、部署等等，在Worktile Agile中能夠經過REST API的方式，把工程化數據發送到工做項上面並與之關聯，這樣對於開發人員能夠清晰的看到每一次提交涉及到的工做項是哪一個，觸發了哪些構建，構建的結果如何，以及當前工做項部署在了哪些個環境。（注：REST API正在內測中，目前還未對外正式發佈。）

圖6 Worktile Agile中接入DevOps數據

讓一切皆可測試

在User Story的INVEST原則中，明確表示一個好的用戶故事要必須是可測試的Testable。敏捷開發過程自己是頻繁迭代、週期性強而且可以及時、持續地響應客戶的反饋，如何正確創建測試策略，確認客戶的需求能得以實現而且確保及時的交付最終產品是值得思考的一件事。

在Worktile Testhub中，測試人員能夠輕鬆編寫測試用例而且制定相應的測試計劃，同時每一個測試用例也能夠用Worktile Agile中的User Story關聯，讓開發人員和產品經理知道這個User Story會如何測試，同時測試的結果也會及時的與Worktile Agile同步。

圖7 Worktile Testhub自動生成的測試報告

關於將來的一點想法

最後，簡單的談談對於將來的一些想法。對於當下來講最重要的事情把現有的產品進一步打磨好，關於將來咱們也在探索如下幾個可能的思路：

1. 簡化手工操做，將來必定是智能的世界，在研發管理工具中，要儘量的簡化手工操做，讓工做自動化起來，對於開發人員來講更是如此，他們寧肯編寫一段自動化腳本，也不肯一遍一遍的執行重複性的操做。
2. 擴大人員覆蓋，目前Worktile研發產品矩陣已經覆蓋了需求人員、產品、設計、研發和測試等人員，將來咱們還會進一步加大人員的覆蓋面，讓更多的團隊角色能夠在Worktile中完成他們的工做，好比對於中高層管理人員、PMO等。
3. 擴大場景覆蓋，當下咱們的關注點在於如何作好敏捷項目管理和測試管理這兩個場景上，將來不排除還會延伸到別的場景，好比多項目組合管理等。

Worktile 官網：worktile.com

本文做者：Worktile CT0 Terry

文章首發於「Worktile官方博客」，轉載請註明出處。