項目案例分析第四期

　　問題一：該案中Team的溝通平臺建設有問題，沒有建立組間協調的基本準則，和監督手段，這樣會出現沒有完成的工作可以提交甚至是移交給下一個環節。
　　問題二：該案中沒有說是否采用了配置管理工具，但很顯然配置管理規范是沒有做的。
　　問題三：該案中的Team Leader 沒有起到疏通流程，接收反饋，改進過程的作用。
　　問題四：該案中尚沒有建立很權威的軟件質量標準。
　　高質量的工作=過程+管理+技術
　　首先，過程。應該說現在很多軟件公司的工作流程都很不完善，需要過程改進。而且更多的時候需求管理和配置管理是過程改進的關鍵和瓶頸所在。需求管理和配置管理不善就會直接的給開發和測試工作帶來負面影響，尤其給測試和開發人員的溝通增加了障礙。導致效率不高，就如本案中提到的問題點。那么配置管理的過程是什么呢？如下圖
　　
　　當項目組有越多的成員的時候，制定一個規范的流程就顯得越發的重要。
　　第二，管理。所謂“無規矩，無以成方圓”，在做好管理之前制定一套合理的管理規范是必須的，流程有了，但是管理不善也是會功虧一簣的。配置管理，可以說是時間、人、工作內容的全面管理。
1.時間，時間管理主要是及時的向配置管理庫中提交更新的內容，從而避免在Build的新版本的時候有遺漏，而導致本案中提到的，測試人員在回歸的時候發現提交的缺陷根本沒有改的狀況，重新再Build一個版本，那自然是人、時、力的極大的浪費。
2.人，作為所有數據的處理和操作主體，是管理的關鍵，一個誤操作就可能使很多人的工作成果付之流水，所以付給不同角色的人不同的權限是很關鍵的，曾經有一個項目經理給所有的人員只能提交，不能刪除的權限，還謂之約“糖公雞”策略。（意思是不但不拔毛，還粘毛）這不是不信任誰，而是在極大程度上保護大家的勞動成果。
3.工作內容，工作內容可以說是工作質量和工作的主體了，同時也是大家交流的主要對象。對于工作內容的管理主要注意下面幾個方面。
* 注釋，很多程序員再寫代碼的時候，不做注釋，一個程序員一種風格，這就給讀代碼，尤其是交叉檢查代碼帶來了困難，人的記憶能力總是有限的，老人家常說“好記性，不如爛筆頭”相信時間久了，代碼的易讀程度就會受到影響。所以代碼要求注釋。
* 更新說明，在做更新的時候要寫說明，我們都知道，變動的代碼是極有可能跟很多其他開發人員寫的代碼有關聯的，那么代碼的變更勢必需要相關聯的代碼也跟著變更，如果沒有，那當然就會出現，提交的缺陷修改完成了，又引入了新的問題的狀況。關聯復雜的情況下定位問題是很不容易的。由此可見更新的說明對于溝通是多么的重要，當然它也是有幫助記憶的作用的。
* 代碼狀態，這個是內容管理很重要的一部分，這個狀態既能標示一個開發人員的工作里程碑，也能給Build新版本提供一個依據。從而保證Build的每一個新版本是開發人員確認過了的有效的一個版本。
　　第三，技術。開發工程師和測試工程師的技術水平也是決定版本質量的關鍵，甚至決定性的因素，開發人員不比說了，資深開發人員和剛畢業的開發人員會出現的Bug都很大區別。但經驗都是積累出來的。測試人員的水平是很需要提高的，一個同行把測試分為驗證和確認兩種，（CMMI中也有這樣兩個過程域）。驗證，主要來做數據結構，系統架構，邏輯結構的嚴謹的驗證，從而保證算法、邏輯的嚴密和準確。確認，主要來看這個系統是否滿足了客戶的業務需求。我想著不無道理。這樣能更深層次，或者更有依據的來保證軟件的質量，我們直接就做確認了，確認正確的結果可能是一個假象，就像2+2=4,但公式如果寫成2*2=4兩個的結果是一樣的，但是實現確實完全不一樣的。不論是開發人員還是測試人員，在軟件質量保證上的目標是一致的，技術要求也是一致的。
　　技術指標的制定，這個筆者也不能給出什么建議，只知道沒有最好，只有更好，我們需要不斷的提高技術水平。技術提高，不恥下問很重要，一個技術難題很可能其他同事已經解決了，而你不知道，就還需要鉆研很久。一個相同的功能，很可能多少個開發人員就有多少種實現，何不大家溝通一下，選個最好的呢？配置管理也是，如果你有更好的解決辦法，也別忘了跟我們共享一下。
　　說的可能有點遠，但在任何時候做正確的事情，都比堅持錯的效果要好。配置管理，從現在開始吧！