軟件開發之3S方法
作者：駱欣榮
本文的思路多來源于極限編程（xp）
軟件開發項目的幾種頭痛：
1、需求不穩定性�。。^號頭痛殺手）
客戶需求非常不穩定，客戶調研方法也導致獲取需求的有效性，準確性，但是仍然有相對穩定的需求，按照哲學理論，運動是絕對的，靜止是相對的，相對于某一個客戶的某一個階段，這些需求是穩定的，特別是靠近現階段的需求，最容易把握，所以，盡可能的縮短研發周期是避免需求變更的一個很有效的方法。一般一個研發周期不超過2個月，最好在一個月完成一個敏捷周期（比較困難喲~~）。
缺點：對于比較大的項目，如果沒有良好得總體把握（業務框架和技術框架），很可能會增加重構的工作量，甚至從頭再來�。p面刃的選擇�。��；蛟S：整體規劃，分步實施可以緩解該缺點，但是在沒有把握充分信息的項目初期，難度好大（行業專家和技術專家的整合團隊做起來就容易許多~~）？？
所以，我們需要“短周期”，但是對于大型項目，好像不太適用~~
2、知識更新換代非�？欤�！
對于技術的高速更新，在項目的技術選型中也很費思量，原則上：適用就是好，或許這個技術并不先進，但是能很好的解決問題，就好像使用手機，我作為一個普通人（非商業人士），僅僅需要它良好的通話功能就可以了，至于那些上網功能，移動辦公，游戲什么的，好像很優先，但是我會選擇一個很普通的手機---有良好的通話功能，這就是使用了以上原則：適用就是好。
另一方面，技術的領先本身也有其競爭力（有人會說：客戶才不管你用什么技術呢，只要能很好的滿足需求就OK，其實不然，如果你賣給客戶5年以前生產的手機，他會要嗎？當然，除非你送給他�？峙履阋膊粫档阶鲞@樣的買賣），對實現相同功能相同價位的WEB系統和桌面系統，哪一個系統對客戶更有吸引力，我不說你也知道，但這個假設條件往往不成立，WEB系統開發成本相對高，所以他的價位也會適當上浮。
這一段好象不是我的主題喲！~~~
短周期也可以降低項目技術選型的難度。
間接推導出“短周期”
3、人員流動率高��！
軟件研發團隊，由于外界的原因（誘惑太多）和內部原因（缺乏管理方法，沒有凝聚力），團隊呈非穩定結構，人員流動是不得不面對的問題，改善這種狀況的主要做法還是科學的管理方法和有吸引力的企業文化/前景等等。。。，不過短周期也可以很好的避免人員的流動，如果在2個月以內都無法確定其穩定性的人員，你作為項目經理，可能也不會考慮使用，但是時間長了（比如半年），變數就多了，所謂夜長夢多，常理也。
另一方面，短周期的項目一般能很快看到成果（一系列的小版本的誕生），可以讓團隊持續有成就感，有成就感在馬斯洛的需求層次中可是最高層。所以能持續的有這種感覺，研發團隊也就自然有了相當的凝聚力，這不就是團隊建設想要的嗎？但是也會有失敗，那有什么關系，失敗是成功的媽媽 J
可以推導出“短周期”，“小版本”。
對于小版本的說明：一個軟件項目的規模大小是客戶決定的，從總體項目上說，我們必須完成合同上的所有特性，但是在項目管理上，為了回避/減低風險，尊重項目的迭代式清晰的特點，所以可以把項目分成若干個小版本，迭代式完成之。
4、溝通不易：思維性的作品��！
溝通不容易：因為軟件產品是思維的結晶，思維是最變化莫測的，這時我有一個很得意的想法，到了晚上，突然又有一個很有創意的解決方法，我會本能的把精力轉移到新方法上去。。。思維就是這樣很隨意，不可預測的。一個人尚且如此，一個團隊會怎樣，一個團隊很長一段時間又會怎樣，可變性真的很難把握（正是因為思維的無窮創造力，才會讓產品越來越優秀和好用）。團隊中每一個人的想法都很重要，但是要做到團隊無死角的溝通，幾乎不可能（我提出了極限溝通的概念。J ）。從風險管理角度，我們可以改變做法來減低風險的影響，小版本就是一種方法，小版本中不會涉及太多特性，就那么幾個或者更多一點（兩個月，多了也沒法做~~），復雜性/難度就低很多，溝通最不容易的是復雜/難的東西，對于沒有太多特性的一個小版本，溝通起來就減低了好多障礙。小團隊也是另一個解決方法，團隊人數膨脹是溝通的大敵，精銳小分隊（不超過10人，最好5~7人）控制了溝通路徑的膨脹，同時也能做到角色分工配合，高效率的推進項目。
所以我們需要“小團隊”“短周期”“小版本”。
5、。。。
小結：
根據軟件開發過程的特性和以上推導，對于規模不大（中，�。┑捻椖�，使用“小團隊，短周期，小版本”可以提高軟件開發成功率。
文章來源于領測軟件測試網 http://www.kjueaiud.com/