1樓：啊哈時刻產品經理
產品要快速迭代，一般就採用敏捷專案管理。Scrum是迭代式增量軟體開發過程，通常用於敏捷軟體開發。
Scrum是乙個包括了一系列的實踐和預定義角色的過程骨架（是一種流程、計畫、模式，用於有效率地開發軟體）。
在每一次衝刺（乙個15到30 天週期，長度由開發團隊決定），開發團隊建立可用的（可以隨時推出）軟體的乙個增量。每乙個衝刺所要實現的特性來自產品訂單（product backlog，我覺得翻譯成「產品目標」更恰當），產品訂單（產品目標）是指按照優先順序排列的需要完成的工作的概要的需求（目標）。哪些訂單項（目標專案）會被加入一次衝刺，由衝刺計畫會議決定。
在會議中，產品負責人告訴開發團隊他需要完成產品訂單中的哪些訂單項。開發團隊決定在下一次衝刺中他們能夠承諾完成多少訂單項。在衝刺的過程中，沒有人能夠變更衝刺訂單（sprint backlog），這意味著在乙個衝刺中需求是被凍結的。
Scrum一般會搭配使用燃盡圖（burn down chart）來直觀的顯示當前衝刺中未完成的任務數目，或在衝刺訂單上未完成的訂單項的數目。
如果Scrum都無法滿足迭代更新速度的要求，那麼可以採用極限程式設計(XP)來做迭代。
敏捷方法之和 Scrum區別
區別之一： 迭代長度的不同
XP的乙個Sprint的迭代長度大致為1~2周, 而Scrum的迭代長度一般為 2~ 4周。
區別之二: 在迭代中, 是否允許修改需求
XP在乙個迭代中，如果乙個User Story(使用者素材, 也就是乙個需求)還沒有實現，則可以考慮用另外的需求將其替換， 替換的原則是需求實現的時間量是相等的。而Scrum是不允許這樣做的，一旦迭代開工會完畢, 任何需求都不允許新增進來，並有Scrum Master嚴格把關，不允許開發團隊受到干擾。
區別之三: 在迭代中，User Story是否嚴格按照優先級別來實現
XP是務必要遵守優先順序別的。但Scrum在這點做得很靈活，可以不按照優先級別來做，Scrum這樣處理的理由是：如果優先問題的解決者，由於其它事情耽擱，不能認領任務，那麼整個進度就耽誤了。
另外乙個原因是，如果按優先順序排序的User Story #6和#10，雖然#6優先順序高，但是如果#6的實現要依賴於#10，則不得不優先做#10。
區別之四:軟體的實施過程中，是否採用嚴格的工程方法，保證進度或者質量
Scrum沒有對軟體的整個實施過程開出工程實踐的處方，要求開發者自覺保證。但XP對整個流程方法定義非常嚴格，規定需要採用TDD、自動測試、結對程式設計、簡單設計、重構等約束團隊的行為。
極限程式設計
使用者研究如何跟上產品的快速迭代？
UIDX 你弄反了。是產品迭代跟著用研跑，不是用研跟著迭代跑。乙個大用研可以規劃出至少2年內的產品路線圖。使用者研究不是研究 使用者現在喜歡什麼 而是研究 使用者是誰，他們什麼樣，他們會喜歡什麼 這樣我們才能決定 產品要做成什麼樣，向哪個方向迭代 說白了，使用者研究是決定目標的，行動是跟著目標走的。...
產品是快速迭代推動專案上線好還是追求極致沒bug？
阿歡 首先沒有bug是不可能的，其次使用者是需求推動的，如果你的初期產品可以解決使用者的某個痛點，就算bug一堆也不會沒有使用者，反而會在上線後被使用者和資料推動，確定下一步的迭代方向，這時候的方向是真實由市場反饋的，所以可信度還比較高。當前如果在開始推出產品時一點都不能用也是不行的，還是要有取捨，...
如何模擬快速冪實現函式迭代？例如f x a x b迭代n次？
令 我們發現，於是，自然地，我們有。於是，欲求 迭代 次 只需要求矩陣 的 次冪即可，用二分法可以輕鬆把複雜度從 降低到 對於取模的問題，每一步都對向量的每乙個元素取模即可。 所以改改快速指數冪的步驟，每一次乘方的時候記得膜 就行了唄至於其他答案說的那道題，原題等價於求遞迴式的值用數學歸納法可以證得...