本節書摘來自華章出版社《safe 4.0參考指南：精益軟體與系統工程的規模化靈活架構》一書中的第3章，第3.7節 作者［美］迪恩·萊芬（deanleffingwell），更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。
3.7 團隊待辦事項清單
待辦事項清單的定義：
1. 隐藏在舒适表面下的大型清單
2. 未完成的任務或未處理資料的聚集
上述第一種待辦事項清單的燃盡速度緩慢，而第二種待辦事項清單的燃盡速度迅速。
摘要
團隊待辦事項清單代表了一個團隊為提升系統需要做的所有事情的集合，它包含了使用者故事和使能故事，其中大部分都來自于項目群待辦事項清單，有些則是來自團隊自己的具體場景。團隊待辦事項清單由産品負責人負責，雖然産品負責人是待辦事項清單的“責任人”，但這并不意味着隻有産品負責人可以建立使用者故事，而是需要産品負責人對工作進行優先級排序。
由于使用者故事和使能故事都是待辦事項清單的一部分，是以通過有效配置資源以確定投資可以在需求沖突中得到平衡，這一點顯得尤為重要。資源的配置需要把靈活釋出火車看成一個整體，并根據火車的需要進行協調。
詳述
雖然“待辦事項清單”看起來是一個簡單的概念，然而在其背後卻有許多微妙的影響。
待辦事項清單需要包含所有要做的事情，如果工作項處于清單中，那麼就需要被完成；如果工作項不在清單中，那麼就不會被完成。
待辦事項清單是一個“希望實作工作項”的清單，而不是一個承諾。工作項可被估算（推薦）也可以不用估算，但無論哪種情況都不會包括承諾該項工作的具體完成時間。
待辦事項清單有唯一的責任人——團隊的産品負責人。這樣可以保護團隊免受多方面利益相關者的幹擾，因為每一個利益相關者的關注重點都有所不同。
所有的團隊成員都可以将自己認為重要的使用者故事放入待辦事項清單。
待辦事項清單包含使用者故事、使能故事和“改進故事”，其中“改進故事”是從團隊疊代回顧會議的結果中識别出來的改進内容。
團隊待辦事項清單是一個簡單而統一的形式，但也隐藏了靈活在規模化過程中的複雜性。圖3.7-1說明了團隊待辦事項清單的三個主要來源。
項目群待辦事項清單中包括将要實作的特性，通常會計劃在靈活釋出火車中進行傳遞。在pi計劃會上，計劃在項目群增量（pi）中傳遞的特性會被分解成故事，并且暫時配置設定進入團隊待辦事項清單以便在下一個疊代進行實作。此外，也會計劃一些将來需要開展的工作，在這種情況下，團隊待辦事項清單也可以包含一些尚未拆分成故事的特性。有時需要由多個團隊共同傳遞一個特性，在這種情況下，就需要為相關團隊建立相應的工作，然後對其進行估算，并在團隊待辦事項清單中進行維護。
團隊也需要根據自己的實際情況開展工作。除了需要實作那些來自于特性的故事之外，團隊也會有一些自己建立的故事，比如新功能、重構、缺陷、研究探針，以及技術債等。這些由團隊自己建立的故事也需要加以識别，可以寫成使能故事，進行估算，并排序放入待辦事項清單中。
靈活釋出火車上的團隊并不是孤立存在的，不同團隊的待辦事項清單中的使用者故事可能會互相關聯，進而滿足利益相關者的目标。這些故事可能會包含對特性、能力甚至史詩故事的研究和估算探針，同時也會反映團隊之間的依賴關系，以及對外部的承諾。
通過容量配置設定優化價值傳遞和系統健康
與靈活釋出火車一樣，每個團隊都會面臨待辦事項清單中内部和外部工作項的平衡問題，内部工作項包括維護、重構、技術債等；外部工作項是指立即能傳遞價值的新使用者故事。“永遠保持新功能的開發”在一定程度上比較有效，甚至可以立即滿足市場需要，但是這種效果将是短暫的，因為可能會由于沉重的技術債務而影響傳遞速度。為了避免速度的降低，以及推遲由于技術過時導緻的大量系統更換，團隊需要持續關注解決方案的技術演進，及時修複缺陷和改進提升，進而保證現有客戶的滿意度。
産品負責人對于工作項的排序是一件複雜和極具挑戰的事，他需要在3種不同類型的工作中進行價值比較：1）缺陷；2）重構、重新設計和技術更新；3）新的使用者故事。而且這些工作項按需發生，持續增加。大多數情況下，工作項來自項目群待辦事項清單，然後通過容量配置設定有助于團隊形成一種機制，用于明确在給定時間周期内開展哪些類型的活動，如圖3.7-2所示。
一旦團隊做出決定，他們就可以從每個“切片”中選擇最高優先級的工作項，放入疊代中進行實作。對于那些在項目群中已經承諾的故事，在pi計劃的時候就已經進行了優先級的排定；但是對于團隊自己添加的本地故事，産品負責人需要按照價值/規模大小，或者采用wsjf（權重最短作業優先）進行優先級排序。此外，為了平衡長期的産品健康和價值傳遞，配置設定到各個工作項類型的百分比可能會有所不同（例如，在每個pi中都會有所不同）。
待辦事項清單梳理
在本節的讨論中，可以看出待辦事項清單中的有些故事已經比較完善，并準備就緒可以進行下一步的實作了，這樣的故事不會帶來太大的風險和意外。因為，整個團隊都參與了讨論，大家采取了基于流的方法，通常是每個疊代（或者每周）至少有一個團隊對将要實作的故事（有時也會讨論特性）開展一個工作坊，進行讨論、估算，并且建立初步的接收标準。
對于這個會議，業界沒有标準的術語，在safe 中稱為待辦事項清單梳理會，但是需要指出的一點是，待辦事項清單梳理是一項持續的工作，而不僅僅是一次會議就能解決全部問題的。應用接收測試驅動開發（atdd）的團隊，通常會在前期投入更多的時間用于開發特定的接收測試，有時也會開展一些相關會議，稱為規格說明工作坊（specification workshop）。此外，由于多個團隊都在做待辦事項清單的梳理，可能會出現新的問題、依賴關系和故事。在這種方式中，待辦事項清單梳理的流程會有助于把目前計劃中存在的問題暴露出來，并更新到靈活釋出火車的同步會議中進行更進一步的讨論。
參考資料
[1] leffingwell, dean. agile software
requirements: lean requirements practices for teams, programs, and the
enterprise. addison-wesley, 2011.