Q&A - 敏捷中他說做完了，可是怎還少30%沒做?

【Q&A - 敏捷中他說做完了，可是怎還少30%沒做?】

這也是從別人那裡聽來的困惱，"PO覺得應該是這樣，但實際結果確和自己想的少30%?"

首先，先來理解一下，自己的30%和別人的100%是如何各自解讀的。任務板上通常稱為靜態資訊，是屬於不會變動的。而在每個人的大腦叫作動態資訊，這種會隨著自我預設、假設而產生不同。但理論上，這些會在Planning meeting、Daily中縮短、對齊你我的資訊才對，如果還發生這種情況該怎辦?

通常會這樣說的人，大概都是PO，開發人員一定都是身在其中，認為自己是已經全部完成的。所以，極有可能是某些環節歪掉導致這樣結果，從頭檢視有沒有可以改善調整的地方，

Planning meeting：
●需求描述太大，以至於寫任務時會遺漏，不妨縮小描述，讓開發Team自然而然展開正確需求任務，也能從全部展開的Task中，再次確認跟PO想像的有沒有落差
●SBE (Specification By Examples 實例化需求)，透過關鍵實例的描述再次讓資訊落差縮小

(Specification by Example 中文版：團隊如何交付正確的軟體)

●DoD (Definition of Done 完成的定義)
●AC(Acceptance criteria 驗收標準)

Daily：
●每日的自我檢視，搭配以上的定義，如果有問題的話，會在執行過程中發現，再去找PO確認；當然，如果沒有上面那些定義的話，就只能做到最後才發現
●如果真的是重要項目，PO必要的話也可以在該項目執行中，也加入關心。

Review：
●PO通常在這時候才發現資訊落差的現象，先以產品和利害關係人回饋為優先，觀察、記錄會議過程，也許能從中發現為什麼有落差的原因。

Retrospective：
●好好了解一下，為何發生這種落差。除了避免下次再發生，也稍微討論一下可以如何補救落後進度。

除了這些工具以外，日常生活中也可以訓練這樣的邏輯思維，這樣在才不會又發生你聽你的我說我的冏境。PREP溝通法則，這也是簡報常使用的方式
POINT=結論
REASON=依據
EXAMPLE=具體事例
POINT=強化與重申結論

結論：

如果透過以上的方式還是一直發生，應該就不是工具、流程問題，先了解一下人員狀況與能力，有什麼隱藏或個人因素造成，需要更深入的協助。假如只是能力不足的話，短期間，也許可以考慮傳統的命令方式，以明確的指令替代開放思考，讓他熟悉、成長後再調整方式。

可不要有個錯覺，認為已經跑敏捷了，為何還會有這些事情發生?或者好像披上的超人披風，大家一切都理所當然的變強了，不應該發生。

敏捷中，發生的任何事情都要視為"反應"而非"結果"，如何處理這些反應轉而成長經驗，是大家共同的課題。

拍立得的創立及發明者,蘭德(Ed Land):「每一項錯誤都是一個累積最後成果的事件。」