引論－談下我的軟體和團隊之路

2大傷痛

軟體開發了這麼多年，也帶了很多的團隊，真的沒什麼心得，只能說有點感慨。

軟體開發到底難不難，這真的是一個問題，剛剛畢業的時候，覺得做軟體樂趣很大，困難很很小，結果呢，到現在還沒有一個項目令自己滿意。既然不難做，但為什麼就是做不好，這真的是一個揪心的問題。

軟體團隊到底需要多少人，這已經不能稱為一個問題，而是一處傷痛，初出茅廬的時候也曾經認為一人一機就是軟體，但遙望印度千人團隊，真心不知道他們在幹嘛，為什麼要那麼多人，難道他們都很苯？

如果說有什麼心得，還不如說我心中的2大傷痛，以搏一笑：

1.       軟體只需要開發就可以完成，團隊只需要開發就可以組成。

2.       軟體出了問題是可以改的，而且不難改

 

軟體就是開發

也許大家會笑，當事實上大部分人都會被這2個問題傷到，而且傷了好多年。

軟體只需要開發，這個看上去是一個很淺顯的道理，就像古龍式的大俠那樣，殺人就是用刀划過敵人的身體，就這麼簡單；是的，軟體開發就是把代碼編寫出來，編譯運行，交給客戶，的確就這麼簡單。

細細品位這第一個傷痛，我發現這個問題其實是看似偶然中的必然；軟體的最小組成就是代碼，有了代碼就有了軟體的實體，有了實體就可以認為完成了軟體，這個是非常實際的想法。加上老闆最關注的是項目的成本和時間，那麼為Team Dev增加開發人員看似是最“有效經濟”的方法，一人開發一周，那麼2個人最不濟開發3天應該夠了把――大家都會如此思考。

當然，軟體開發還真的是神奇的所在，它的一個神奇之處就在於，無論如何，軟體的生產過程還是可以完成的，無論如何，在一定的時間和努力之後，軟體還是誕生了，他的誕生時候似乎是必然的，不可阻擋的,那麼我們還在擔心什麼呢。

 

軟體沒有失敗

有人說,軟體完成僅僅是萬裡長征第一步,還差的遠呢,客戶的要求還遠遠沒有結束. 真正的修改還在後面.是的,軟體開發的第二個神奇之處就是,軟體可以通過不斷的修改來彌補以前的錯誤,不管你提交的軟體是100分還是20分,它都可以通過不斷的修改而繼續存活下去,可以這樣說,只要還能修改,軟體就沒有失敗,那我們還擔心什麼呢.

2大神奇法則

這裡,我們引出了軟體開發的2大神奇法則:

1.       軟體只需要開發就能進行,並且基本都能完成.

2.       軟體只要修改就可以存活,而且很少最終失敗.

首先,我們必須感謝這2個神奇的法則,它大大降低了軟體開發的入行門檻,使得很多團隊和個人,即使懵懂幼稚,即使身無長處,亦能昂首踏入這個行業,以各種各樣的姿態開始自己的職業生涯.

其次,這2個法則也深深的傷害了很多團隊和個人,在進入這個行業若干年以後,很多人發現,這2個法則所營造的就是一個迷魂陣,一個無底洞; 軟體總能完成卻從未結束;軟體不會失敗卻從未成功; 困惑與當下的實踐,迷茫於未來的發展.

 

我在擔心什麼

我在擔心什麼,其實我也說不太清楚;

首先,那些必然完成的軟體沒有給我和我的團隊任何美妙的感覺,做的好不好,是否可以算成功,這個問題幾乎沒有人可以回答,那麼自然也就沒有答案了.

其次,永無止境的修改,最終的結果只能是傷痛,日積月累的疲憊感,不斷受挫的成就感,加上毫無希望的未來. 幾乎沒有人會喜歡這種”永不言敗”的感覺,團隊的崩潰和軟體的擺爛,幾乎是必然的結果.

最後, 夢想和發展,幾乎已成奢望,遙望歐美令人羨慕的先進開發方式,展望自己30歲以後的發展空間,總是覺得那麼遙不可及,對職業生涯的希望已經到了破碎的邊緣.

 

尋找突破

如何突破,無非是自身尋求突破和效仿先進模式;自身尋求突破太過理想化,如果自己有這個能力,要突破早突破了,何必等到現在.

效仿他人先進模式是必然的,當也絕不能盲從: 別人的先進模式是大學畢業水平,而我們剛剛走出幼兒園,怎麼學,學什麼,並沒有想象那麼簡單.

這裡就談2個大家都耳熟能詳的模式: CMMI和敏捷開發.

CMMI是一個非常不錯的體系,當我希望大家知道的是,CMMI就是大學畢業水平,給我們這些幼兒園和小學的小朋友來用的確是有點一知半解. CMMI2 就基本要求到20人團隊(一個項目),試問一般中小公司有多少單個Team Dev可以到20人? 更不要說團隊內部的人員素質是否達標這個問題.也有人談到裁剪,這個是沒錯的,但問題是誰來裁剪? 讓我們這些小朋友來裁剪大哥哥的論文? 靠譜嗎? 難上加難. 我也曾寄希望與國內的CMMI培訓團隊來幫我們裁剪,最終也是發現這也是勉為其難. CMMI能用,但全用是邯鄲學步,裁剪是困難重重.

敏捷開發,這個更是一個冷笑話,敏捷開發是什麼,是高中水平嗎,完全錯了,敏捷開發是研究生水平,是參透了大學水平的更高層次的升華,軟體開發沒有”銀彈”,沒有捷徑,如果小學還沒有畢業,就先用研究生的手法來解題,其結果只能是徹底的失敗. 我的看法是,如果CMMI2都覺得遙不可及的團隊,不要輕易嘗試敏捷開發,先打好自己的”內功”根基.

 

我的”銀彈”

l 學習:學習瞭解先進模式和理念

l 自省:認真分析自身團隊和成員的能力

l 定製:尋找最小模式,從零開始,重新組建合理團隊,搭建合理流程.

l 發展:走上不斷積累提高之路

這裡我認為有以下幾點心得:

不去瞭解先進模式是閉門造車,必然失敗.

不根據本身團隊情況是盲目改革,必然失敗.

軟體開發有其規律,最小模式絕對不是”兩把菜刀鬧革命”,沒有辦法獲得最低資源要求,就不要改革.

如果你的改革不能形成有效積累模式,就不要改,改革為的是將來不斷壯大而不是現在解決一時疑難,沒有發展通道的改革還不如不改.

 在下一篇文章裡面,我將會對軟體開發和團隊的最小模式做一個探索.