在人月神話的blog中看到了〈
不管理的軟體開發專案管理-**
〉一文，我不同意其中的一些觀點。看來不少人對極限程式設計等敏捷方法存在一些誤解，例如結對程式設計並不是說兩個人在某段時間內完成乙個功能點，而應該是兩個人在某段時間內完成兩個甚至兩個以上功能點。
專案管理並不只是軟體開發專案管理，而是在各行業的專案管理基礎上綜合提煉出來的學科，並且軟體工程比起建築工程等領域算是比較新的，如何把專案管理的經驗和軟體開發的特點結合起來也是比較新的學科——it專案管理。
專案管理實在是綜合的學科，至少官方聲稱pm由九個知識領域構成，每個知識領域的作用在不同的專案中都發揮著不同的作用，不可以忽視更不可以偏廢。象成為乙個優秀的軍事指揮官那樣，想成為乙個好的專案經理確實不容易，挺累的。
不同的專案，不同的公司，不同的客戶，不同的團隊（程式設計師水平的差異），管理的具體做法都會有所不同。所以不能夠說那一種專案管理方法一定就是好的，另一種方法就一定不好，任何一種專案管理的方法都不是萬能良藥包治百病。每個專案所關心的重點要素不一樣，每種方法適用的範圍也不一樣，只有哪一種方法更適合專案而已。與兵法一樣，專案管理既有一定之規，又必須靈活運用。
就象問oracle和ms server那個更好，linux和windows那個更好？每個人可以有不同的偏愛，但如果想比較好的回答這個問題，必須解答一大套話，因為客觀地評價好和壞是不容易的，只有在乙個具體的事情中，我們可以回答那一種產品/技術更合適。
敏捷和極限方法中並沒有認為程式設計師是機器，相反，我認為她關心了作為「人」的程式設計師的一些在以前的方法中沒有被關注的很多特性。這個方法的文獻中不寫出其他的方法的成功之處，是因為那些經驗和知識其他的文獻中已經充分表達了，沒有必要在這個範疇內再論述了。
這篇文章中的主要觀點都涉及到管理學範疇（不管理的軟體開發專案管理-**
），比如企業文化問題和如何成為合格的領導者這些問題。這些問題是任何管理領域中（不只是軟體開發）都要關注的，是成功專案管理的前提之一。
敏捷和極限方法提醒我們注意到以前沒有的要素和方法，拓展了我們的思路，是乙個不錯的方法，非常值得關注和學習。即使在專案中不能夠完全按照敏捷/極限的方法開發，也能夠讓我們在專案中關注那些要素——例如注重交流和測試等，從而改進我們的專案管理。
在這裡感謝人月神話的**引發了我的思考。
敏捷開發方法的一點思考
2006年05月11日 13 44 00 author 袁琳 msn testwin sohu.com 1 敏捷開發方法與傳統重型開發方法相比較，是一種更加主動的模式。那麼在專案管理過程中，調動每一位專案參與者主動的創造 適應變化，主動的發起 參與 交流和協作就顯得猶為重要。對於專案管理來說，就需要...
對idc的一點思考
先談談反面例子，我們公司的idc，主要精力花在搬機器跑機房上面了上架什麼的。還有各類瑣事，比方說裝置壞了。之前乙個比較大的問題是，機器比較分散，分散就導致我們聯絡重啟的人比較頭痛了，各個機器有不同的 流程，有些還要發郵件進行身份驗證，非常慢。各個機房的頻寬買的也不一樣，看起來也不方便。再乙個就是人員...
敏捷開發的一點認識
敏捷開發是一種以人為核心 迭代 循序漸進的開發方法。在敏捷開發中，軟體專案的構建被切分成多個子專案，各個子專案的成果都經過測試，具備整合和可執行的特徵。換言之，就是把乙個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態 目前大部分公司是敏捷開發，分配合適的...