我們一直在探討能否採納《以社交活動的方式做計劃-樂高公司的規模化敏捷》（對此文有興趣的朋友請點擊“閱讀原文”）的方法。
目前，我們交付團隊人員的分配依然主要以項目預算作爲依據，但這樣會陷入以項目爲邊界的局部優先級迷思，缺乏全局視角。同時，不同業務部門存在無序競爭有限的交付團隊人員的情況，也有大量的在製品堆積，人都很忙，但價值卻不明確。
我們希望：
每個月組織業務干係人形成“議會”對我們部門來自不同項目的所求需求進行排序；
根據交付團隊人員的情況，限制在製品，確定本月應該交付哪些需求，實現全局的價值驅動交付；
然而要實現這個想法，首先要整理一個Backlog，方能組織業務干係人進行討論和排序。這看似容易的事情卻讓我們卡了殼。
目前我們面對的項目類型有：
有明確交付期限的大項目
監管需求項目
接入新客戶和業務流程優化的小項目
對現有系統的運維
這些項目需求來自不同的業務部門，總體上來說，按照項目的重要程度以及預算，我們的人員大部分都分配在那些大項目上，或者說，當我們問優先級時，總是被告知那些大項目的優先級最高，但這樣的回答並沒有解決問題，因爲不時冒出的監管需求，接入新客戶和業務流程優化的小項目也在爭奪有限的資源，導致人員分配陷入無序狀態，需要不斷調劑人員安排。簡單來說，以項目爲粒度的優先級排序沒有意義，除非優先級低的項目一律不做，但這並不會發生。這也會導致由於沒有跨項目的全局視角，我們大部分人員因爲項目切割，實際可能在做一些在當前全局看來價值並不是最高的交付，造成巨大的資源浪費。
那麼我們希望用來排序的Backlog是以用戶故事爲粒度的。但是從JIRA把現有的用戶故事拉出來就傻眼了。我們一共有上千來自不同項目的用戶故事在Backlog中，這樣的Backlog擺在業務干係人面前是沒有意義的，迷失在細節中，也是無法排序的。
所以我們需要一個在用戶故事到項目之間一個合適粒度的東西，業務能看懂，對全局意義明確，讓業務干係人一眼就能確認這個是否應該在本月做，對交付團隊又是可執行的。我也曾經考慮過Epic是不是一個選項，但是Epic的粒度還是太大，它必然包含必須的和增值的用戶故事，而且這也要求不同團隊Epic的粒度要統一，這又是一個難點。
目前，這對我來說還是一個沒有答案的問題，歡迎大家留言給建議。
關於作者
就職於世界500強銀行，負責基金服務業務軟件開發與交付
敏捷、精益、DevOps專家
精通極限編程、Scrum、看板方法、測試驅動開發、持續集成、行爲驅動開發、DevOps工具棧
曾在GDevOps、DevOpsDays Meetup、中國軟件技術大會等論壇發表主題演講
著有《獵豹行動：硝煙中的敏捷轉型之旅》一書
購書通道
—
紙質書、電子書在京東、噹噹、亞馬遜等渠道已全面上架，搜索“獵豹行動 硝煙中的敏捷轉型之旅”。
噹噹自營購書碼：
京東自營購書碼：
關注公衆號看其他原創作品
