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. 項目的后期審核
在項目開發終完成后,對開發人員來說可算是放下工作的重擔,但對項目經理來說這往往是項目的關鍵時刻。前期的風險評估、成本預算、需求分析、軟件設計都是為了引導項目走向這一時刻,此時所有的目光都將投向項目管理人員。你可能發現大量而瑣碎的工作將要在幾個小時內完成,此刻項目經理更需要保持清醒與鎮定,把后的工作視為微型項目來對待。細致地對項目進行后期的審核,分析項目成果、項目團隊的效率、可交付產品的價值,以此審核結果可作為項目管理經驗總結的一部分。