jeff sutherland最近提出：使用者故事應該是「有推動作用的需求說明（enabling specification）」，能讓團隊不必跟產品負責人反覆對話，就能高效地往前推進工作。
\
\\要想讓敏捷團隊達到最佳效率，使用者故事必須是有推動作用的需求說明。如果做不到這一點，團隊在sprint中就要不斷跟產品負責人對話，弄清楚使用者故事的真正含義。這會降低故事交付過程的效率，並影響團隊開發速度。
\
「有推動作用的需求說明」已經作為乙個scrum模式公布了。jim coplien點出了產品負責人在交付這些規範說明時的角色。
\
\\產品負責人應該交付有推動作用的需求說明，這是乙個標誌，表明他或者她已經竭盡所能發掘了需求空間。有推動作用的需求說明意味著需求說明足夠豐富，只要負責實現的人有一定的對應技能，他不需要太多後續澄清，就可以實現相應解決方案。
\ 產品負責人要做好自己的功課，這比把需求說明在開發前寫下來這個事實要重要得多。
\
對於不斷改進需求說明質量和產品負責人的積極參與，timothy d korson進一步講述了這兩件事的重要性。
\
\\我在做產品負責人的時候，我的要求是：所有進入sprint的產品backlog條目（product backlog item, 簡稱pbi），必須把對應的驗收條件和測試場景開發任務放到任務板上去。作為產品負責人，我會與負責那個任務的人保持聯絡，而且會在產出的測試場景上簽上名字。其他任何在這個pbi展開工作的團隊成員，他們都會認真地與我們保持聯絡。在田納西州chattanooga的一家公司最近採納了這個方法，他們說這對他們的scrum過程是乙個重大改進，產品負責人在開發過程中能夠更早地參與進來，提供反饋。盡早評審測試場景，這也幫助他們盡早了解情況，從而更快發現問題，減少了返工情形，並提公升了工作效率。
\
在自己撰寫的《specification by example》一書中，gojko adzic建議：將需求說明以可執行測試的形式表述，還要讓非技術背景的利益相關者能弄明白。
\
\\傳統意義上的文件很快就過時了。如果讓程式設計**作為惟一可靠的功能說明**，這又會造就資訊瓶頸和黑洞。此時，帶有示例並且撰寫清晰的需求說明就能發揮作用。這些需求說明通過經常執行的驗收測試得以驗證，我們可以相信：系統完成了測試要求的功能，從另一方面說，這些文件仍然說明了系統的功能。帶有示例並且撰寫清晰的需求說明讀起來也很簡單，易於訪問和理解，因此它們幫我們移除了資訊瓶頸。
\
siddhartha govindraj強調：要定期根據產品的目標驗證工作。
\
\\令人驚訝的是：很多敏捷團隊有自己的sprint的驗收條件和完成定義，卻沒有技術來驗證應用是否符合目標或者方向的變更。實質上，他們還是在玩「需求說明就是上帝」這個遊戲。
\ 如果你是產品負責人，你的工作絕對不是僅僅接受或拒絕使用者故事，而是要不斷驗證正在構建的產品是否符合目標，還要掌控方向。
\
您會撰寫有推動作用的需求說明麼？或是其他形式的使用者故事驗收測試條件？它是否有助於提公升開發團隊效率？
\ 檢視英文原文：product owner should deliver enabling specifications
如何拓展產品負責人的角色
scrum中的產品負責人 product owner 是業務和開發之間的介面。在複雜大型企業中，由於有複雜的產品和需要做很多的決策，使得由一人充當這樣的角色通常並不可行。在這種情況下，就需要擴充產品負責人的角色。u0026 xd n 在benelux 2013 xp days大會上，timo pun...
技術團隊負責人應該具備怎樣的能力
乙個公司的產品和服務，是其自身組織結構和溝通 工作方式的反映 康威定律 人員的架構會改變和影響產品的架構，產品一大，人分組拆開了，專案也跟著拆開了，越多人一起工作就更需要科學的流程和協作方法。所以說人和組織會決定或影響產品。如果說初期目標是打造乙個良好的產品或服務，隨著發展應該慢慢更著力於打造乙個能...
產品上線前，相關負責人需實際體驗成品
解決問題 重點解決己成功下單的客戶被臨時告知缺貨的問題,保證有貨。優化 如圖所示，顯示了很多預警庫存為0的sku。浪費預警資源。很簡單的優化，加個過濾條件，必須是審核通過的預警庫存，並且實際庫存小於等於預警庫存的，才提示給採購部門。並且把實際庫存列字型加粗變紅。so明顯的優化為什麼要等到最後才發現呢...