軟體開發難，恐怕大家都覺得最難的是搞清楚需求；但是其實更難的是
管理需求。今天在北京.net俱樂部上又有人提出了這樣的問題，主要的難點是他的開發團隊是為了自己的領導們服務的，幾個領導都有自己的想法，而且不停的在開發過程中提各種個樣的問題；開發進度無法保證，開發的結果總是滿足不了要求……
其實這樣的問題大家都遇到過，而對於普通的開發人員來說我們往往不去關心，認為這是專案經理的事情，但是其實不然，這樣的問題涉及軟體開發的各個環節，就算你是出於最底層的開發人員，一樣需要控制專案經理交給你的任務。其實這裡最重需要把握的一點就是：把任務控制在你能控制的範圍之內。總結一下，我的經驗如下：
第一：無論你的客戶是誰，我們永遠需要乙個中介來接受需求；你首先需要和客戶有個協議，需要他們制定某乙個人來提所有的需求，這個人不需要是很高職位的人，而且往往最好的選擇是中層的技術管理人員；使用者的所有需求必須通過這個人的認可，就算是對方老總提出的要求，如果沒有這個人的認可我們也不執行。這點非常重要，可是替我們減少許多麻煩。
第二：無論是什麼樣的軟體開發過程理論現在都承認乙個問題，那就是軟體開發需要迭代。而且我們一定要面對乙個現實，就是軟體開發的過程是在不斷的變化中尋找平衡的過程，我們的需求永遠不會結束，我們的軟體永遠都在被修改；修改不是壞事，但是我們必須要保證在一定的時候可以拿出成果。
所以，控制迭代的增量就是非常重要的。一般我們公司的做法是，以兩周為乙個週期最為乙個release，一旦這個release開始以後，任何使用者的新需求就都需要放到後面的release；我們不會決絕客戶的需求，但是我們必須管理我們可以承受的進度。這樣做的最大好處在於，在兩周的時間內，我們一定可以為客戶提供乙個更好的版本，這可能不是客戶現在心目中的最終結果（因為很多新需求都在後面的release中），但是我們至少完成了我們在兩周前所承諾的結果，客戶得到他們想要的東西（當然不是全部），我們也可以很明確的告訴客戶，我們完成什麼樣的需求。
而且在這樣乙個迭代的過程中，我們會發現很多需求中的不完善之處，每兩周的時間我們都可以針對開發方向作相應調整。最終的結果是保證了客戶的滿意度，同時也保證了產品的按期交付。
在這裡，我們需要明確的區分修改bug的需求和新功能的需求，bug應該是那些對軟體主要功能造成決定性影響的缺陷，這些東西無論是我們開發人員自己發現的還是客戶反饋的，都必須在當前的release處理完；而新需求則必須放到後面的release中去。明確區分這兩種不同需求對軟體專案的成功起到決定性作用。
第三：我們需要學會管理客戶。可能有人覺得我在胡扯，客戶怎麼可能被管理，他們是上帝啊？？！！其實上帝也是人，而且是通事理的人。我們對客戶永遠不應該是100%的服從，正確的方式是控制使用者對開發進度的期望值，盡量使他們一致。當然有些時候我們需要更強硬一點點，比如我就經常很直接的告訴我的老闆，這個需求屬於新功能，必須放到後面的release中去。
有關管理客戶需求的一點見解
軟體開發難，恐怕大家都覺得最難的是搞清楚需求 但是其實更難的是管理需求。今天在北京.net俱樂部上又有人提出了這樣的問題，主要的難點是他的開發團隊是為了自己的領導們服務的，幾個領導都有自己的想法，而且不停的在開發過程中提各種個樣的問題 開發進度無法保證，開發的結果總是滿足不了要求 其實這樣的問題大家...
有關管理客戶需求的一點點見解
軟體開發難，恐怕大家都覺得最難的是搞清楚需求 但是其實更難的是管理需求。今天在北京.net俱樂部上又有人提出了這樣的問題，主要的難點是他的開發團隊是為了自己的領導們服務的，幾個領導都有自己的想法，而且不停的在開發過程中提各種個樣的問題 開發進度無法保證，開發的結果總是滿足不了要求 其實這樣的問題大家...
this的一點見解
執行環境 execution context,有時也成為上下文，有時也稱為 環境 執行環境定義了變數和函式有權訪問那些資料，決定各自的行為。全域性執行環境是最外圍的執行環境。全域性執行環境一直都存在。宿主環境不同執行環境也不同。每乙個環境都有乙個執行環境。當執行流進入乙個函式時，函式的環境就會被推入...