最近陸續(xù)出現過好幾次竖配，團隊迭代交付的時候哨鸭，出現的信息不對稱的問題通今，直到迭代評審驗收的時候才發(fā)現粥谬？原來這個迭代我們還被安排了這樣的事情肛根？或者，原來這個事情怎么和我們做的事情是兩個事情漏策？
原因有幾個派哲，迭代的輸入沒有統(tǒng)一起來，類似這樣改進類的任務掺喻，也需要納入到PO Meeting有統(tǒng)一的入口芭届，因為團隊最主要還是要承擔業(yè)務需求，之余才是各種改進task感耙，由統(tǒng)一的PO入口并根據優(yōu)先級排序褂乍，PO會權衡團隊在業(yè)務和改進上的權衡，我們似乎也也樣嘗試了即硼，可為什么會出現改進task和實際團隊做的事情是兩件事情的問題逃片？
原因有二:
- 團隊的BA統(tǒng)一規(guī)劃團隊本迭代要完成的各項任務，包括業(yè)務需求只酥，改進任務褥实。如果改進任務是直接下發(fā)到個人，而不是經統(tǒng)一入口BA下到團隊裂允，當BA根據團隊優(yōu)先級給隊員下發(fā)的任務和項目下發(fā)到個人的任務發(fā)生沖突的時候损离，必然有一方的任務無法完成。
- 改進任務的AC是由項目來寫的绝编，就像業(yè)務需求一樣僻澎，用戶只知道最終想要達到什么效果，卻因為對團隊很多細節(jié)不清楚十饥，無法把握住細節(jié)怎棱，改進類的TASK和STORY的拆分一樣，必須滿足SMART原則绷跑，否則就會出現一個任務很多個迭代都完不成拳恋，外部客戶看來一直進展緩慢，完成風險很大砸捏。這跟需求的跟蹤管理是一個道理谬运。
究竟應該怎么做？
*改進類的任務垦藏，應該和業(yè)務需求走相同的流程梆暖。小妹兒和范范，在TFS上拆分出feature掂骏，寫feature的AC轰驳，PO Meeting上，和PO一起，跟團隊澄清想要團隊承擔哪些改進事項级解，三方一起權衡協(xié)商后冒黑，討論出下迭代要做的事情的范圍。圈定后勤哗，下來由團隊BA拆分task并寫AC抡爹，并在計劃會上就業(yè)務需求和改進TASK和團隊一起澄清，并向PO反饋最終的承諾芒划。這樣一個過程冬竟，才能保證，入和出民逼，以及要做的事情的范圍都是幾方協(xié)定并共同給出的泵殴，且已經被拆分成適合的粒度，更容易在迭代內完成拼苍，也讓外部更容易看到進展袋狞。
圖片發(fā)自簡書App
