軟體開發中的老問題——溝通
在軟體開發中有這樣的乙個法則（
brook
法則）：向進度落後的專案中增加人手，只會使進度更加落後。我們經常可以聽到「
1+1>2
」的說法，但從這個法則中可以知道，在軟體開發中１加
1是小於２的，甚至是小於
1的，這是為什麼呢？其中主要的原因就是溝通，專案開發人員之間的相互溝通產生了額外的時間開銷，甚至可能會因溝通而產生新的問題，如新加入的開發人員因對問題理解不全面而導致產生設計上的重大缺陷，使得軟體開發變得更加困難。
在《人月神話》中論述了古代巴比倫塔專案建設失敗的原因：缺乏交流，以及交流的結果
—組織。
「因為左手不知道右手在做什麼，從而進度災難、功能的不合理和系統缺陷紛紛出現。
」由於對其他人的各種假設，團隊成員之間的理解開始出現偏差，最後導致的專案的失敗。這裡還提到了「組織」建立的幾個要素，這些都是非常有意義的，其中有一點給我的印象最為深刻：團隊組織的目標是為了減少必要的交流和協作量。當你聯絡到自己的工作中時，你會發現這種描述是多麼的精準，既然溝通會產生額外的代價，那麼首先就需要有乙個較好的組織，乙個較好的組織會減少很多不必要的溝通，減少必要的交流和協作量，也即提高了工作效率。
「溝通，溝通，還是溝通。」每個成熟的程式設計師或軟體專案管理者總會反覆地強調這樣的問題。那麼溝通會有那些形式呢？一般的形式有：非正式、常規專案會議，會上進行簡要的技術陳述、共享的正式專案工作手冊，以及電子郵件。其中關於專案工作手冊我覺得是最為重要的，特別是在大型專案開發中，那是必不可少的，專案工作手冊使得溝通在每個專案開發人員中有形無形地在進行著，專案工作手冊記錄了所有跟開發有關的內容，它保證了專案得以順利有序地開發。
對於溝通，我覺得還有一種形式是最容易被忽略的，那就是培訓，說到培訓，一般認為是對新員工的培訓，我覺得可以把培訓定義得更廣泛些：一種學習上的交流。乙個開發團隊也都有乙個相互磨合過程，乙個促進磨合的方法是定期進行培訓（交流學習），如開發經驗的交流、對新技術的理解、工作方式的討論，把培訓做成一種雙向互動式的，而非灌輸式，應使得大家受益，大家都能夠在培訓中得到進步。
溝通過程中要注意不要陷入互相扯皮推諉的境地，乙個有效的溝通應當是使得開發目標更加明確，開發人員之間的協作更加有效地進行。
最後我們再來看一下進度落後的解決問題，增加新人手，因需要更多的溝通，產生了效率問題，所以在面對這種問題時，我們要適時考慮進度的重新安排，不要把希望寄託在更多的人力上，在增加人手後，最為緊要的問題是如何提高溝通效率，特別是剛開始時應當把溝通列為最為緊要的問題，把因增加人手後產生的負面效應降為最低，我想如果有進行如此地充分周全的考慮和實踐是可以達到1加
1大於或等於
2的效果的，其實，在很多種情況下能夠大於
1就已經是很不錯了。
老菜鳥看軟體開發的管理
作為乙個code了十幾年的老菜鳥，眼睜睜看著國人開發從開始的一鍋爛粥，到後來的cmmi，再到xp tdd，然後火爆了 scrum 概念炒 作之甚，讓人不能不感慨，當年魯迅老先生的拿來主義，實實在在地在 創新 的年代得到了發揚光大。細思思又有些感傷，中國人在用著人家的系統 人家的開發 語言的時候，還不...
軟體開發如何趟過溝通管理的泥潭
幾個月前，公司委派我負責乙個難啃的骨頭式軟體開發專案。公司把我從一線開發設計組調到專案需求組，主要負責客戶需求調研 確認和溝通的管理工作。對於此項工作我原來認為壓力並不大，因為對於軟體開發的需求調研我可謂輕車熟路，加之自己有一線開發和設計的經驗，工作起來應該會是一帆風順的。但沒有想到的是才過了乙個月...
軟體開發中的併發
併發作用 1.在互動式應用中，快速響應使用者的請求，提高感知響應的時間 2.充分利用硬體資源，計算資源 3.簡化應用設計 併發壞處 1.難於測試 2.併發應用執行在複雜的環境下，軟體不確定性增多 3.處理同步，通訊的問題，增加程式設計複雜性 4.併發開銷對效能的影響，包括上下文環境切換，同步等 併發...