項目管理目標
- 減少失敗可能性,提高生產率,降低缺陷率,提高客戶滿意度,讓業務部門滿意
- 儘早的發現和解決各種問題和風險(技術,需求,目標,可用性等),對進度建立合理的預期並完成
- 敏捷的響應用戶的反饋並調整,能持續改進和添加新的工程,使得系統更接近涉衆的真實需求
- 各參與人員能獲取持續的個人提升,包括對業務領域的深入和技術上的成長
項目管理原則
各個項目因按照產品特點選用合適的項目管理流程和相應的管理工具,從瀑布模型,Scrum,極限編程,結對編程,測試驅動開發,看板等各種實踐中選用對自己項目有益部分.下面以敏捷開發爲例
agile development
敏捷宣言
- 個體和迭代,超越過程和工具
- 工作的軟件,超越完整的文檔
- 客戶協作,超越合同談判
- 響應變更,超越履行計劃
敏捷原則
- 優先級最高的是,通過早期和持續交付有價值的軟件來滿足客戶
- 歡迎變更需求,即使在開發的後期提出.敏捷過程爲客戶的競爭優勢而控制變更.
- 以兩週到兩月爲週期,頻繁地交互可運行的軟件,首推較短的時間定量
- 在整個項目過程中,每一天開發人員都要和業務人員合作
- 由個體推動項目的建設,爲個體提供所需的環境,支持和信任
- 在開發團隊中或開發團隊間傳遞信息的最爲有效和高效的方法是面對面交談.
- 衡量進展的重要尺度是可運行的軟件
- 發起人,開發者和用戶應該步調一致
- 不斷地關注技術上優越的設計會提高敏捷性
- 簡潔是最重要的,簡潔就是儘量減少工作量的藝術
- 最佳的架構,需求和設計來自自組織的團隊
- 團隊要定期反省如何使工作更有效,然後相應的調整行爲
項目人員
- 產品經理 & 實施工程師
- 與業務部門溝通,收集整理需求,編寫說明文檔及原型
- 調研競品/近品,持續改進產品設計
- 與研發小組其他人員溝通,確保大家充分理解需求
- 確定需求的重要性和優先級,商定研發計劃並進行上線驗收
- 培訓用戶並收集反饋意見,優化用戶體驗
- 研發經理
- 確定技術框架(必要時進行培訓學習)
- 確定研發計劃並儘量讓項目按計劃進行
- 選擇項目組人員組成並進行合理分工
- 掌握項目具體執行進度並對項目質量,風險進行控制
- 研發工程師
- 充分理解產品經理的需求說明和技術框架
- 按計劃完成工作,對負責的項目進行設計,編碼,單元測試和文檔說明等維護
- 及時響應測試工程師的反饋,確保軟件質量
- 測試工程師
- 充分理解產品經理的需求說明
- 制定測試計劃,設計測試用例
- 準確的定位並跟蹤軟件中的問題,推動問題及時合理解決
- 編寫測試報告
- 運維工程師 & DBA
- 負責運行環境的維護,保證各系統穩定
- 響應發版請求
- 對數據庫進行監控,對數據庫設計進行評審和改進
- 對數據進行備份和修改,確保數據安全,正確
- UI工程師
- 充分理解產品經理的需求說明,重建各個用戶操作的場景
- 負責對軟件從界面風格,操作流程,交互體驗等進行改進
- 負責對改進後的頁面進行驗收
項目流程
總體流程
1 項目立項
2.項目啓動
3.需求整理
4.業務建模
5.架構設計
6.開發實現
7.測試
8.環境搭建
9.部署上線
10,用戶培訓
注意,對於採用Scrum方式的開發而言,上面的部分流程會反覆執行
評審
在軟件開發的各個階段根據重要性都可以進行評審,不必在軟件開發完畢後進行評審.
評審目標
- 發現軟件功能,邏輯或實現方面的錯誤
- 保證代碼與需求文檔,代碼與設計說明文檔等各種文件的一致
- 使得代碼,文檔以一種更容易理解的方式呈現
評審準則
- 評審產品,而不是評審設計者
- 限制會議人數並堅持做準備工作
- 建立議事日程並維護,不能脫離主題
- 儘量使用評審清單,幫助評審人員思考,避免遺漏
- 展示記錄,隨時寫在白板上
- 限制爭論,主要是發現問題而不是解決問題
- 對評審進行評審,持續改進
評審過程
1.召集評審會議,確定評審範圍.參與人員不宜過多,時長不宜操作兩個小時
2.進行評審,結束時必須做出以下幾種決策之一:
- 接受,無需修改
- 暫時接受
- 無法接受,需要修改
3.評審記錄,對於評審中的問題進行記錄,包括最終決策及其理由,以及保留意見.
源碼,SQL,文檔
1.產品所有源碼,數據庫的DDL,文檔都需上傳到版本控制軟件,進行統一管理
2.產品經理應對源碼進行評審或安排他人進行評審,保證代碼質量
3.DBA應對SQL語句進行評審,結合數據庫情況對SQL提出改進意見,保證系統的高效運行