這個部分的內容由pm具體負責，主要的工作內容如下：
使用者調研、需求分析，確定產品迭代功能，出具產品backlog。決定產品的發布日期與發布內容，給迭代計畫預設目標。根據rio（商業價值/工作量）排序優先順序，考慮必要風險。
優先順序排序：排序的目的，是弄清楚哪些需求最重要因此可能在最近的一兩次迭代中進行開發。參與排序的條目一般足夠接近半年的開發工作量，但多數只有乙個簡短的名稱，只有最高優先順序的需求才會被真正細化，也就是近一兩次迭代要開發的需求列表。在每個sprint結束或者臨時需求變更時，都需要更新優先順序的排列順序。
關鍵物：產品
backlog
如圖：
這個部分的內容主要由開發經理負責，主要工作內容如下：
將產品backlog拆分為在本次sprint中可細化的sprint backlog。sprint backlog中的開發任務以小時估算，預計1-16小時的工作量化。根據開發優先順序管理sprint backlog，隨時更新sprint backlog狀態。每個團隊成員都可以自主挑選任務，修改sprint backlog。
優先順序排序：要完成這個選擇其實不太容易，如果只是盯著產品backlog「重要程度」這個排序依據，極有可能從很多功能模組中各自挑出最重要的需求，而這些需求湊在一起，只能形成乙個四不像的版本。因此常常可以挑選最重要的功能模組中的多個條目，形成整體完整的乙個「故事群」，這樣無論開發、測試和演示環節，都有乙個相對內聚的目標。為了防止大家中途跑偏，常常給每個衝刺要都起乙個簡短的名稱，比如：「本次迭代將發布乙個具有電子節目單的版本。」
關鍵物：sprint backlog
如圖：
這部分內容主要由開發團隊共同推進，主要工作內容如下：
依照sprint backlog，開始開發工作，更新工作任務面板。參加每日例會，圍繞昨日進度、今日安排、所遇困難三個方面快速的梳理一遍任務面板上的工作內容，所遇困難在會後點對點進行討論解決。保證整體開發進度不大幅度的偏離預設的sprint燃盡圖。高度的自我組織管理，保持良好的跨職能團隊溝通，確保實現sprint目標。
優先順序排序：一般在迭代計畫會上使用moscow方法進行這種排序，將要sprint backlog中的條目分為四級（其實只有前3級）：
must：必須做的
shoud：應該做的
could：可以做的
would not：不要做的
要按照這些順序來做，保證product owner所需要的must、should完成，並力爭could能完成；在發生重要變更的時候，犧牲could乃至should保證變更。開發過程中避免在m、s完成前就有人動c。
關鍵物：燃盡圖
如圖：
這部分內容主要由sprint團隊成員共同參與，主要工作內容如下：
產品開發團隊通過操作演示的方式展示sprint中完成的功能與架構。pm根據產品backlog，驗收開發交付的迭代版本，發布產品迭代版本。收集sprint問題反饋，尋找根本原因，討論解決方法，改善sprint過程。
裸機開發步驟簡述
ubuntu應用程式 gcc所遵循的部分約定規則 c為字尾的檔案，c語言源 檔案 a為字尾的檔案，是由目標檔案構成的檔案庫檔案 c，cc或.cxx 為字尾的檔案，是c 源 檔案且必須要經過預處理 h為字尾的檔案，是程式所包含的標頭檔案 i 為字尾的檔案，是c源 檔案且不應該對其執行預處理 ii為字尾...
敏捷開發的實施步驟
這個人必須知道帶領的團隊需要做什麼 製造什麼產品以及取得什麼成果，必須會面考慮到風險與回報 什麼具有可行性 什麼能做以及他們對什麼富有熱情。真正做事的是誰？這個團隊必須能夠落實產品負責人的願景。團隊規模宜小不宜大，一般3 9人較為合適。主管為scrum過程負責，負責培訓團隊其他成員，確保scrum得...
簡述敏捷開發中的測試流程
對敏捷sprint程序中測試任務的簡要描述 需求討論 這個階段測試人員要把自己帶入到使用者角色中，列舉使用者角度的場景需求，協助開發和產品制定技術實現方案 確認驗收標準 為了避免sprint進行中產生的扯皮推諉，應當在需求討論會上就確定驗收標準。形成開發任務tag 形成測試tag，估算測試時間，形成...