it行業最常見的玩笑之一就是產品和開發之間的相愛相殺了。在很多公司兩者似乎成了「仇家」，從一定程度上也說明了產品和開發之間確實有不少矛盾。主要體現在如下幾個方面：
經常出現的是說產品突然某個時候出現，通知開發要在某個時間點之前完成某項feature，然後開發就暴走了。在乙個scrum團隊裡面不會出現這種突然襲擊的意外。團隊關於在某個sprint（衝刺）裡面做什麼，在sprint plan meeting上已經充分溝通並確定了，這個內容在本次衝刺內是不能修改的。如果有新的東西要做，對不起你等下個衝刺再安排。
至於在乙個sprint裡面做哪些，這也不是由產品來指定的。產品只負責按照優先順序（從產品角度）從大到小列出一系列features，每列一條feature，都由開發對feature進行分解並評估任務耗時。每個sprint時間是固定的，人員也是固定的，那麼可用的工時也是固定的。當工時用完，會議就停止。
關於工時的估計，實際上沒有哪個公司能100%的使用。比如每個程式設計師每週工作時間是5*8=40小時，但實際上我們是按照12小時來計算，你每看錯，是30%的生產率。實際上我們總結在這個生產率上，是可以保證時間和質量的。當然具體團隊具體分析，生產率多少要經過幾次嘗試後才能確定。
需求不可避免會發生變更，scrum要求是擁抱變化。畢竟，首要目的是開發使用者需要的東西，而不是遵循以前的計畫開發乙個使用者不需要的東西。不過如果發生較大變更，產品需要接受某個衝刺任務不能完成的情況，不能發生了變化，計畫還維持不變，這不科學。如果產品不能接受這點，team是有權否決變更的。從產品角度，做出使用者需要的東西，比按時完成計畫更為重要。
在scrum中，產品需要和開發坐在一起，經常**開發中的細節。沒有人能在一開始就想好所有細節，產品也不能，開發不能指望產品丟過來乙個完整的spec然後按部就班地做。產品開發中充滿談判和討論，大家目的都一樣：做出使用者需要的東西。在這個過程中，開發每完成乙個feature，產品就可以立即進行驗收測試，如果有問題立即進行改動，保證做出來的東西，符合產品的期望。這樣不會到了衝刺末期，產品突然跳出來說開發做的東西不是他想要的。
產品經理與開發人員的矛盾
1 是不是只要沒有技術上的實現問題，開發者就不應該對產品經理提出質疑？2 需求文件 功能文件 最新而最全的原型設計文件，這些要求過時了嗎？3 產品經理高階建議。軟體工程領域，本著分工合作高效進行的管理方式，每個人只要做好自己的分內事就行。當產品經理召集開發人員進行各種評審會的時候，其實是想讓開發人員...
Scrum 乙個用於開發和維持複雜產品的框架
scrum 是乙個用於開發和維持複雜產品的框架 是乙個增量的 迭代的開發過程。在這個框架中，整個開發過程由若干個短的迭代週期組成，乙個短的迭代週期稱為乙個sprint，每個sprint的建議長度是2到4周 網際網路產品研發可以使用1周的sprint 在scrum中，使用產品backlog來管理產品的...
敏捷開發（一）敏捷開發和Scrum
工作的軟體是首要 進度度量標準。敏捷過程 提倡可持續的開發速度。責任人 開發者和使用者應該能夠保持乙個長期的 恆定的開發速度。不斷地關注 優秀的技能和好的設計會增強敏捷能力 簡單 盡最大可能減少不必要的工作 是根本的。最好的構架 需求和設計出自與 自組織的團隊。每隔一定時間，團隊會在如何才能更有效地...