2. 管理開發團隊
(1) 組建團隊
按照工作任務與項目時間的前提條件建立團隊，按團隊職責分配人員，一般團隊人數應該控制在8~12人之間。當團隊人數超過15人時，應該考慮把團隊分解成2個獨立團隊，負責不同的開發任務。
(2) 分配開發任務
在每個迭代周期內（一般是15~30個工作日），應該把每個工作包進一步細分為多個開發任務，再開發任務分配給組員各自負責，開發時間應該控制在15個工作小時以內。如果開發任務的開發時間超出15個工作小時，應該考慮把任務再度細化。而開發任務應該以自由選擇的方式分配給每個組員。
(3) 監督開發進度
在迭代的前期舉行一次會議，讓組員了解開發的進展及流程，并以自主選擇的方式分配開發任務。期間可使用Microsoft Project等工具記錄開發流程的進展，在每個工作包完成開發后應該進行性功能的測試，并以文本方式記錄測試結果。
每天舉行一次15分鐘的站立會議，讓組員交待昨天已完成的開發任務，當天將要做的任務，與開發過程中所遇到的問題。并在每舉行一次例行會議，交待總體進程。
在迭代末期舉行一次沖刺會議，總結項目的進展，交行已完成的任務，回顧該迭代周期內所遇到的問題，為下一個迭代做好準備。
(4) 系統測試
對每個已完成的工作包進行適時的測試，保證系統質量與性能。對測試結果進行文本的記錄，并把測試結果與績效工資收入掛鉤，并以真實數據計算組員的績效收入。
(5) 解決開發中所遇到的問題
對開發人員進行前期培訓，可適當按工作能力分配任務，指導組員的開發。當遇到問題時應該在當天的站立會議時即時提出，并在15個工作小時內解決所遇到的問題以防止問題進一步擴大。
3. 監管產品質量
(1) 質量需要的是計劃、設計而并非審查的。在產品建立的初級，必須與“質量保證”（QA）的部門進行協商，以正式文檔的方式，決定恰當的質量策略和標準。
(2) 在開發過程中使用TDD（測試驅動開發）的模式，提高開發質量。測試人員應該以文本方式記錄bug，并與開發人員共同工作的，把突出的缺陷演示給開發人員，以提高修改的效率。
(3) 在每個迭代的結束時進行一次產品效果的演示，從客戶、使用者、高層領導中收集反饋信息。在團隊內部舉行評審會議，分析測試結果，了解產品性能，為下次迭代所需要做的改進做好計劃。
4. 修改項目計劃
(1) 在產品需要識別階段，應該以文檔形式記錄產品功能與開發流程，在開發計劃需要修改時，應該與客戶共同探討，讓客戶了解計劃修改對項目進度所造成的影響。
(2) 項目計劃的修改應該由統一的負責人提出，并且由用戶需求的審核認可。需求變更的提出應該是定期而不是隨時的。
(3) 計劃的變更應該做好詳細的文本記錄，讓客戶了解需求變更的實際情況和開發方為之所付出的成本代價。
七、 產品交付
1. 項目的后期審核
在項目開發終完成后，對開發人員來說可算是放下工作的重擔，但對項目經理來說這往往是項目的關鍵時刻。前期的風險評估、成本預算、需求分析、軟件設計都是為了引導項目走向這一時刻，此時所有的目光都將投向項目管理人員。你可能發現大量而瑣碎的工作將要在幾個小時內完成，此刻項目經理更需要保持清醒與鎮定，把后的工作視為微型項目來對待。細致地對項目進行后期的審核，分析項目成果、項目團隊的效率、可交付產品的價值，以此審核結果可作為項目管理經驗總結的一部分。
