引言

程序員的人生就是和一個個的軟件項目打交道的人生。

不能管理好項目過程的程序員不是好的開發人員。

項目管理是對成功地完成一整個軟件項目過程中地一系列目標相關地活動（譬如任務）的整體監測和管控，軟件開發是軟件項目過程中最重要的一個組成部分之一。

在互聯網公司做項目，一邊強調要敏捷開發，一邊要交付成果。所以如何區分好項目管理和軟件開發的邊界，統籌好二者才是一個好的互聯網項目管理和軟件開發過程。

最簡單的項目管理

每周都要寫周報

周報里面應該寫點什么？最簡單地要寫當前我要關注哪幾個項目，各個項目是處在什么開發模式中，對應的開發進度分別進入到了哪個層面，進度和進展分別是怎樣的。有哪些風險。難于解決的問題在哪里。

每天都要寫日報

那怎樣來監控和衡量項目的進度的問題呢，項目管理和項目開發的邊界在哪里？

很大程度上取決于所選擇的軟件開發模式。

對于瀑布型的軟件開發模式，進度比較好衡量。需求分析、設計、編碼、集成、測試、維護每個階段都有對應的產出。

迭代型開發：主體框架穩定的情況下，加功能就是迭代型開發。每一個迭代周期里面，就是一個小的項目開發，這個時候的項目開發進度應該也比較好衡量，對于項目開發的進度管控有些孰能生巧了，有時候就會忽略掉一些步驟，比如設計文檔、測試case、單元測試相關的交付。

螺旋開發：如果面對未知的風險，每次項目都要評估風險，每次結束后都需要重新提出修正建議，制定下一步計劃，更像是再搞研究。每一次迭代對應效果的衡量其實是不那么確定的，以成果認英雄式的進度略微不好衡量。

敏捷開發：頻繁交付新的軟件版本，這個邊界比較模糊，適合于需求非常不確定型，經常需要調整的項目，強調大家齊心協力把事情做好，需求經常可能調整，進度相對不大好衡量，敏捷管理對項目管理和軟件開發人員的要求最高。

不同軟件開發模式

瀑布型開發：

需求分析、設計、編碼、集成、測試、維護，強調每一個階段都需要有相應的產出。

迭代型開發：

整個開發工作被組織成為一系列短小地、固定長度（如3周）地小項目，被稱為一系列地迭代。每一次迭代都包括了需求分析、設計、實現語測試。

迭代式開發的優點：

1、降低風險

2、得到早期用戶反饋

3、持續的測試和集成

4、使用變更

5、提高復用性

螺旋開發：

快速原型

1、制定計劃：確定軟件目標、選定實施方案，弄清項目開發的限制條件；

2、風險分析：分析評估所選方案，考慮如何識別和消除風險；

3、實施工程：實施軟件開發和驗證

4、客戶評估：評價開發工作，提出修正建議，制定下一步計劃。

螺旋模型由風險驅動，強調可選方案和約束條件從而支持軟件的重用，有助將軟件質量作為特殊目標融入產品開發之中。但是，螺旋模型也有一定的限制條件，具體如下：

1、 螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，并做出相關反應是不容易的，因此，這種模型往往適應于內部的大規模軟件開發。

2、如果執行風險分析將大大影響項目的利潤，那么進行風險分析毫無意義，因此，螺旋模型只適合于大規模軟件項目。

3、軟件開發人員應該擅長尋找可能的風險，準確地分析風險，否則將會帶來更大的風險

4、一個階段首先是確定該階段的目標，完成這些目標的選擇方案及其約束條件，然后從風險角度分析方案的開發策略，努力排除各種潛在的風險，有時需要通過建造原型來完成。如果某些風險不能排除，該方案立即終止，否則啟動下一個開發步驟。最后，評價該階段的結果，并設計下一個階段

敏捷開發：

測試驅動開發

scrum

強調程序員團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟件開發中人的作用。

1、人和交互?重于過程和工具。

2、可以工作的軟件?重于求全而完備的文檔。

3、客戶協作重于合同談判。

4、隨時應對變化重于循規蹈矩

實際工作中，除了瀑布型開發流程很好區分，另外幾種開發模型比如迭代型和螺旋型和敏捷開發都不是很好區分。于是發現了下面這個對比文章，其中明確地把敏捷開發和其它開發流程區分開來，說敏捷開發就是用來做互聯網項目的管理的，迭代模型是敏捷開發的一個組成部分。看起來要靠譜得多。

不同軟件開發模式的對比

其中有一段如下： 迭代開發是一種軟件開發的生命周期模型,與其對應的還有瀑布模型、螺旋模型等等 敏捷開發是多種軟件開發項目管理方法的集合,其中包括了XP、Scrum等十幾種開發模式,這些開發方法有些共同點,比如重視響應變更,重視實現客戶的價值,重視開發人員的自身發展等等,其核心體現在他們著名的四句原則中.這些開發方法基本都傾向于采用迭代的軟件開發生命周期模型. 簡單來說,迭代模型是敏捷開發普遍使用的軟件生命周期模型,敏捷開發所包含的內容比迭代模型寬泛的多.

明白自己所處的開發模式下面，可以更好地知曉項目管理和軟件開發的邊界，以及預期自己的產出對于管理者會是什么。

所以，有的時候軟件開發人員覺得自己做了很多事情，但是個人的成果不那么被認可，不一定是個人沒做好，也可能是因為個人落在了敏捷開發這個區間，而且關注點在軟件項目的實現上。這個時候可以選擇放慢進度，適度補充一些相對穩定的流程產出和文檔產出。這個時候的開發成果和瀑布型開發的成果也是不大一樣的，這個也需要知曉

回想過去兩個月的工作，最后要交付的時候有點狼狽：

原因當然有很多：

比如：中間插進來的項目打斷了原有計劃，快速原型的追求的同時，失去了更詳細的需求分析。

另外就是因為沒有清楚地明確自己手頭上有哪幾個任務、每個任務的時間點和優先級是怎樣的。這個永遠是top piority。

當然時間的預算也不夠準，最近一直在調整自己的狀態、沒加班，這下預算時間人天數偏少，以及中間的其它意外。

越往敏捷上靠，管理越不那么精確可控，越容易在交付成果上容易被人詬病，也是正常情況，所以也不用太自責。

軟件開發路漫漫其修遠，項目管理顯階段性成果。

總結

以上是生活随笔為你收集整理的项目管理和软件开发的边界的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。