專案管理和軟體開發的邊界
引言
程式設計師的人生就是和一個個的軟體專案打交道的人生。
不能管理好專案過程的程式設計師不是好的開發人員。
專案管理是對成功地完成一整個軟體專案過程中地一系列目標相關地活動（譬如任務）的整體監測和管控，軟體開發是軟體專案過程中最重要的一個組成部分之一。
在網際網路公司做專案，一邊強調要敏捷開發，一邊要交付成果。所以如何區分好專案管理和軟體開發的邊界，統籌好二者才是一個好的網際網路專案管理和軟體開發過程。
最簡單的專案管理
每週都要寫週報
週報裡面應該寫點什麼？最簡單地要寫當前我要關注哪幾個專案，各個專案是處在什麼開發模式中，對應的開發進度分別進入到了哪個層面，進度和進展分別是怎樣的。有哪些風險。難於解決的問題在哪裡。
每天都要寫日報
那怎樣來監控和衡量專案的進度的問題呢，專案管理和專案開發的邊界在哪裡？
很大程度上取決於所選擇的軟體開發模式。
對於瀑布型的軟體開發模式，進度比較好衡量。需求分析、設計、編碼、整合、測試、維護每個階段都有對應的產出。
迭代型開發：主體框架穩定的情況下，加功能就是迭代型開發。每一個迭代週期裡面，就是一個小的專案開發，這個時候的專案開發進度應該也比較好衡量，對於專案開發的進度管控有些孰能生巧了，有時候就會忽略掉一些步驟，比如設計文件、測試case、單元測試相關的交付。
螺旋開發：如果面對未知的風險，每次專案都要評估風險，每次結束後都需要重新提出修正建議，制定下一步計劃，更像是再搞研究。每一次迭代對應效果的衡量其實是不那麼確定的，以成果認英雄式的進度略微不好衡量。
敏捷開發：頻繁交付新的軟體版本，這個邊界比較模糊，適合於需求非常不確定型，經常需要調整的專案，強調大家齊心協力把事情做好，需求經常可能調整，進度相對不大好衡量，敏捷管理對專案管理和軟體開發人員的要求最高。
瀑布型開發：
需求分析、設計、編碼、整合、測試、維護，強調每一個階段都需要有相應的產出。
迭代型開發：
整個開發工作被組織成為一系列短小地、固定長度（如3周）地小專案，被稱為一系列地迭代。每一次迭代都包括了需求分析、設計、實現語測試。
迭代式開發的優點：
1、降低風險
2、得到早期使用者反饋
3、持續的測試和整合
4、使用變更
5、提高複用性
螺旋開發：
快速原型
1、制定計劃：確定軟體目標、選定實施方案，弄清專案開發的限制條件；
2、風險分析：分析評估所選方案，考慮如何識別和消除風險；
3、實施工程：實施軟體開發和驗證
4、客戶評估：評價開發工作，提出修正建議，制定下一步計劃。
螺旋模型由風險驅動，強調可選方案和約束條件從而支援軟體的重用，有助將軟體質量作為特殊目標融入產品開發之中。但是，螺旋模型也有一定的限制條件，具體如下：
1、 螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，並做出相關反應是不容易的，因此，這種模型往往適應於內部的大規模軟體開發。
2、如果執行風險分析將大大影響專案的利潤，那麼進行風險分析毫無意義，因此，螺旋模型只適合於大規模軟體專案。
3、軟體開發人員應該擅長尋找可能的風險，準確地分析風險，否則將會帶來更大的風險
4、一個階段首先是確定該階段的目標，完成這些目標的選擇方案及其約束條件，然後從風險角度分析方案的開發策略，努力排除各種潛在的風險，有時需要通過建造原型來完成。如果某些風險不能排除，該方案立即終止，否則啟動下一個開發步驟。最後，評價該階段的結果，並設計下一個階段
敏捷開發：
測試驅動開發
scrum
強調程式設計師團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文件更有效）、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的程式碼編寫和團隊組織方法，也更注重軟體開發中人的作用。
1、人和互動 重於過程和工具。
2、可以工作的軟體 重於求全而完備的文件。
3、客戶協作重於合同談判。
4、隨時應對變化重於循規蹈矩
實際工作中，除了瀑布型開發流程很好區分，另外幾種開發模型比如迭代型和螺旋型和敏捷開發都不是很好區分。於是發現了下面這個對比文章，其中明確地把敏捷開發和其它開發流程區分開來，說敏捷開發就是用來做網際網路專案的管理的，迭代模型是敏捷開發的一個組成部分。看起來要靠譜得多。
其中有一段如下： 迭代開發是 一種 軟體開發的 生命週期模型 ,與其對應的還有瀑布模型、螺旋模型等等 敏捷開發是 多種軟體開發 專案管理方法的集合,其中 包括了XP、Scrum等十幾種開發模式,這些開發方法有些共同點,比如重視響應變更,重視實現客戶的價值,重視開發人員的自身發展等等,其核心體現在他們著名的四句原則中.這些開發方法基本都傾向於採用迭代的軟體開發生命週期模型. 簡單來說, 迭代模型是敏捷開發普遍使用的軟體生命週期模型, 敏捷開發所包含的內容比迭代模型寬泛的多.明白自己所處的開發模式下面，可以更好地知曉專案管理和軟體開發的邊界，以及預期自己的產出對於管理者會是什麼。
所以，有的時候軟體開發人員覺得自己做了很多事情，但是個人的成果不那麼被認可，不一定是個人沒做好，也可能是因為個人落在了敏捷開發這個區間，而且關注點在軟體專案的實現上。這個時候可以選擇放慢進度，適度補充一些相對穩定的流程產出和文件產出。這個時候的開發成果和瀑布型開發的成果也是不大一樣的，這個也需要知曉
回想過去兩個月的工作，最後要交付的時候有點狼狽：
原因當然有很多：
比如：中間插進來的專案打斷了原有計劃，快速原型的追求的同時，失去了更詳細的需求分析。
另外就是因為沒有清楚地明確自己手頭上有哪幾個任務、每個任務的時間點和優先順序是怎樣的。這個永遠是top piority。
當然時間的預算也不夠準，最近一直在調整自己的狀態、沒加班，這下預算時間人天數偏少，以及中間的其它意外。
越往敏捷上靠，管理越不那麼精確可控，越容易在交付成果上容易被人詬病，也是正常情況，所以也不用太自責。
軟體開發路漫漫其修遠，專案管理顯階段性成果。