個人軟體過程 1

    提到軟體過程,大家首先會想到"傳統的瀑布模型",當然,這個通常作為反面例子,來襯托各家的過程如何實用、先進。然後是CMMI、Rup這些重量級的軟體過程，然後是Xp、Scrum這類敏捷過程。嗯，無論是哪一種軟體過程，一般公司有實施過的，程式員常常會聯想到兩個字：痛苦。
    是的，痛苦。漫長的培訓、沒有必要最後也沒人看的文檔，當然即使是XP的捉對編程也會令一些人感到私人空間收到侵犯，而單元測試這種一部分人尋找快樂的方法，也往往會讓另一部分人感到繁瑣。

    通常叫囂要建立良好的軟體過程的人，是公司裡的技術權威，或者准權威。通常這種叫囂的結果，是所有人的無奈，和叫囂者最後的頹敗。
    所以姑且不論大公司，我所見過的中小企業，即使通過CMM幾級認證之類的，往往也是掛羊頭賣狗肉。為認證而認證，真正的軟體過程仍然是稀爛到不能再稀爛的程度。今天想起來應該這樣，強調一陣子，明天想起來應該那樣，再強調一陣子。強調來強調去，隨著人員頻繁的進出，最後往往是我們每天在努力，然後我們每天都很稀爛。

    這也許和中國人的特質有關，工作如何令人快樂？良好的過程如何長期保持？
    西方人的經驗未必有多少借鑒意義。
    很簡單，在西方，程式員是高薪行業，也是能工作到退休的行業。而在中國，程式員多數是以民工狀態生存的，同時是一碗青春飯。西方尚學尚能，中國唯尚官，在南為橘，在北為枳，大體就是這個道理。哦，那些每月拿到數萬元高薪的傢伙，沒有說你，一邊去吧，這裡講的東西不適合你。

    我長期掙紮在一群程式員中間，維持一間十來人的小型公司多年，慢慢實踐的結果，覺得對中國人，必須有針對中國人的軟體過程。這不是民族主義，我也不憤青；這也不是獨樹一幟，我採納的也都是各類軟體過程中一般的實踐。針對和地球主流不同的人群，中國程式員，當然要有和主流不一樣的方法。
    首要的原則，是簡單，次要的原則，是堅持。當然，不簡單的東西若要堅持，往往也是天方夜譚。

    我想，多數有一定年頭的程式員面臨的問題，往往是需求怎麼採集、怎樣將需求劃分為開發工作單位、如何設計資料庫、如何做類設計、怎樣保證品質、怎樣管理原始碼和項目資料、怎樣監控進度、怎樣權衡進度和工作量的關係、如何判斷哪些程式員貢獻度最大、怎樣積累開發知識、團隊整體水平很差的時候怎麼辦？
    我最後形成的方法，或者是開發習慣，基本上一一對應的解決這些問題。

    從方法論來說，我們必須Crowdsourced Security Testing道為什麼這樣做，才會這麼做。因此，有幾項基本的立論：
    1、每個人都是懶惰的，勤快是因為有所圖：比如需要賺錢養活自己、擔心丟失工作、在團隊中擔心沒有面子、希望將來能夠賺更多錢，這些都是能夠勤快點常見理由。
    2、中國是沒有高手的：嗯，看看作業系統、資料庫、開發環境、主要的優秀產品、最強的公司，這些是不是在中國，看結果就知道。
    3、人的能力是有差異的：雖然整體是中國軟體處於地球上的食物鏈低端，但具體的個體之間還是有強有弱的。
    4、每個人都喜歡聽到誇獎的話，不喜歡被批評。
    5、模仿是最好的學習方法：這個，我們知道英語折磨了很多大學生，學習十年後不會說話的比比皆是，卻很少聽說哪個小孩因為智商問題學不會說漢語，雖然漢語看起來似乎更難一些。
    6、最重要的：如果人的勞動不能帶來有尊嚴的生活，不要指望任何方法可以讓這個人為你拚命工作。這一點是所謂軟體過程能夠實施的前提，假設你準備開一間黑心工廠，或者你準備利用廉價到甚至難以應付生存的勞動力賺錢，任何所謂的管理、架構之類的藥物都不用吃，註定沒有效果的。
   
     所謂最簡化的軟體過程，大體上從這麼六點出發。在公司層面來說，公司的技術負責人、專案經理可能需要真正實用、可操作性強、可持續的Team 專案管理方法；在程式員個人層面來說，形成良好的工作習慣，讓自己更有效率乃至今後逐步勝任團隊的管理，這些知識也是必須掌握的。
     所以，這裡會是一本薄薄的書，從現在開始我會結合一個實際項目，“徹底完成”其中的資料匯入功能，逐步的講解，自己個人的編程習慣、團隊協作最簡易的方式，包括採集和記錄需求、規劃使用者體驗、列出開發工作單位、估算所需時間、類設計、資料庫設計、管理bug、版本控制、知識庫等各方面。
     也希望牢記一個原則，你做的軟體產品，只要多按一個鍵，意味著客戶永遠不會用，這種簡單性，既對軟體產品的使用者來說是必需的，對程式員而言也是這樣：多一分複雜，就不要指望每個人都守規矩。