軟體開發之3S方法

本文的思路多來源於極限程式設計（xp） 

軟體開發專案的幾種頭痛：

1、需求不穩定性！！（頭號頭痛殺手）

客戶需求非常不穩定，客戶調研方法也導致獲取需求的有效性，準確性，但是仍然有相對穩定的需求，按照哲學理論，運動是絕對的，靜止是相對的，相對於某一個客戶的某一個階段，這些需求是穩定的，特別是靠近現階段的需求，最容易把握，所以，儘可能的縮短研發週期是避免需求變更的一個很有效的方法。一般一個研發週期不超過2個月，最好在一個月完成一個敏捷週期（比較困難喲~~）。

缺點：對於比較大的專案，如果沒有良好得總體把握（業務框架和技術框架），很可能會增加重構的工作量，甚至從頭再來！（雙面刃的選擇！）。或許：整體規劃，分步實施可以緩解該缺點，但是在沒有把握充分資訊的專案初期，難度好大（行業專家和技術專家的整合團隊做起來就容易許多~~）？？

所以，我們需要“短週期”，但是對於大型專案，好像不太適用~~

2、知識更新換代非常快！！

對於技術的高速更新，在專案的技術選型中也很費思量，原則上：適用就是好，或許這個技術並不先進，但是能很好的解決問題，就好像使用手機，我作為一個普通人（非商業人士），僅僅需要它良好的通話功能就可以了，至於那些上網功能，移動辦公，遊戲什麼的，好像很優先，但是我會選擇一個很普通的手機---有良好的通話功能，這就是使用了以上原則：適用就是好。

另一方面，技術的領先本身也有其競爭力（有人會說：客戶才不管你用什麼技術呢，只要能很好的滿足需求就OK，其實不然，如果你賣給客戶5年以前生產的手機，他會要嗎？當然，除非你送給他。恐怕你也不會傻到做這樣的買賣），對實現相同功能相同價位的WEB系統和桌面系統，哪一個系統對客戶更有吸引力，我不說你也知道，但這個假設條件往往不成立，WEB系統開發成本相對高，所以他的價位也會適當上浮。

這一段好象不是我的主題喲！~~~

短週期也可以降低專案技術選型的難度。

間接推匯出“短週期”

3、人員流動率高！！

軟體研發團隊，由於外界的原因（誘惑太多）和內部原因（缺乏管理方法，沒有凝聚力），團隊呈非穩定結構，人員流動是不得不面對的問題，改善這種狀況的主要做法還是科學的管理方法和有吸引力的企業文化/前景等等。。。，不過短週期也可以很好的避免人員的流動，如果在2個月以內都無法確定其穩定性的人員，你作為專案經理，可能也不會考慮使用，但是時間長了（比如半年），變數就多了，所謂夜長夢多，常理也。

另一方面，短週期的專案一般能很快看到成果（一系列的小版本的誕生），可以讓團隊持續有成就感，有成就感在馬斯洛的需求層次中可是最高層。所以能持續的有這種感覺，研發團隊也就自然有了相當的凝聚力，這不就是團隊建設想要的嗎？但是也會有失敗，那有什麼關係，失敗是成功的媽媽 J

可以推匯出“短週期”，“小版本”。

對於小版本的說明：一個軟體專案的規模大小是客戶決定的，從總體專案上說，我們必須完成合同上的所有特性，但是在專案管理上，為了迴避/減低風險，尊重專案的迭代式清晰的特點，所以可以把專案分成若干個小版本，迭代式完成之。

4、溝通不易：思維性的作品！！

溝通不容易：因為軟體產品是思維的結晶，思維是最變化莫測的，這時我有一個很得意的想法，到了晚上，突然又有一個很有創意的解決方法，我會本能的把精力轉移到新方法上去。。。思維就是這樣很隨意，不可預測的。一個人尚且如此，一個團隊會怎樣，一個團隊很長一段時間又會怎樣，可變性真的很難把握（正是因為思維的無窮創造力，才會讓產品越來越優秀和好用）。團隊中每一個人的想法都很重要，但是要做到團隊無死角的溝通，幾乎不可能（我提出了極限溝通的概念。J ）。從風險管理角度，我們可以改變做法來減低風險的影響，小版本就是一種方法，小版本中不會涉及太多特性，就那麼幾個或者更多一點（兩個月，多了也沒法做~~），複雜性/難度就低很多，溝通最不容易的是複雜/難的東西，對於沒有太多特性的一個小版本，溝通起來就減低了好多障礙。小團隊也是另一個解決方法，團隊人數膨脹是溝通的大敵，精銳小分隊（不超過10人，最好5~7人）控制了溝通路徑的膨脹，同時也能做到角色分工配合，高效率的推進專案。

所以我們需要“小團隊”“短週期”“小版本”。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-582356/，如需轉載，請註明出處，否則將追究法律責任。