太陽底下無新鮮事，今天是歷史的沿襲，沿襲之後的變革。
軟體的發展經歷了幾個歷史階段：
第乙個階段：個人英雄主義
這是pc的時代，乙個求伯君就可以完成wps，紅透半邊天，這個時代是技術強人的時代，是老虎的時代。這個時代的軟體**量小，開發成本也低，幾個人拿上槍就能上山打游擊。使用者最迫切的需求是從紙質進入計算機。
第二個階段：大魚吃小魚
這個階段的特點是小專案都紛紛向產品積極演化，初期的專案簡單針對某個功能實現，這個階段推出功能更全的版本，試圖通過更多的功能提供占領市場。此時研發團隊也開始走向分工，需求/研發/測試等角色開始誕生。各類小公司被大點的公司整合或者自行滅亡。
第三個階段a：大專案時代
煙囪式發展的眾多專案問題非常明顯，各個專案很多功能重複，比如使用者管理，這個階段開始將煙囪打破，重新整合，乙個專案就做好一塊功能。以我們公司的163專案為例，早期的163是由業務受理，系統管理，認證，計費，webservice後台等組成，後來就負責最核心的認證，計費剝離給了計費團隊做，業務受理剝離給了crm做。
此時的研發已經和以前的研發完全不同，團隊人數眾多，不是乙個兩個，也不是十個八個，各個專案融合為乙個超大的團隊，技術分類繁複，架構眾多，**規模也是百萬行單位了。
繞回來說說軟體危機，乙個專案開工，隨著**越寫越多和人員流動，不被人了解和控制的**越來越多，產品的質量如何保證，困惑。
沿襲大工業時代的經驗，精細分工，重視頂層設計，貫徹執行力度。
用什麼來保證軟體質量呢？過程改進。
什麼是過程改進呢？將人員細分為九大類角色：專案經理/系統架構/開發/測試/整合/資料庫管理員/需求/質量管控/配置管理，定義好每個人在專案的不同階段做不同的事情，完成提前計畫好的任務，並產出相應的工件，也就是產品，這裡的工件主要是**和文件。
大型軟體的模型主要是迭代開發，每個迭代週期都一樣的經歷需求蒐集與分析，目標制定，設計，開發，測試等過程，並對整個過程進行監控和度量，提出改進方案，否則老是犯同樣的錯誤，那不就完蛋了。
cmmi最受人詬病的是狂多的文件，以測試為例，根據專案計畫編寫測試計畫，根據需求編寫方案，細化測試用例，需要寫清楚輸入資料(需要實際資料的例子)，步驟和期望值，然後測試完成要有測試報告，對bug的數量，等級分布等進行統計，提供給質量管控分析。
為什麼要這麼做？乙個人最多可以同時關注七件事，這裡的乙個人是指的那種編寫vi的狂人，普通人最多可以同時關注四五件事，乙個團隊十個八個人的話，每個人跟你說一下他在做什麼，因為你並不需要關心所有人在做什麼，所以大致你聽一遍之後會有印象，但是如果乙個團隊超過十個人以後，每個人都說一遍在做什麼，直接和你相關的可能就會超過四五項了，團隊成員的增長會導致溝通成本成指數級上公升。如此眾多成員的團隊，為了盡可能的避免歧義，只能通過技術文件為主，郵件，面談等方式為輔的溝通方式。可以說，專案的成敗取決於溝通。
cmmi狂多的文件是為了解決幾個問題：
一是團隊的專業溝通，二是強化過程管控，三是為了度量。
如果經歷過大專案時代，就會深深的覺得，地球離了誰都會轉，我是祖國一塊磚，**需要**搬，跟瘋狂旋轉的陀螺一樣，不停忙碌卻是在原地打轉而已。因為過程是第一的，人只是一顆螺絲釘，大兵團作戰，你能力再強也就只能做好你本職崗位的事情。
第三個階段b：網際網路時代
我個人覺得網際網路時代和大專案時代是並存的，同處乙個時代，但是大專案針對的是大客戶，而網際網路更多針對公眾客戶。
以前你可以想象到會在網上購物嗎，以前你可以想象網上相親嗎，現在有電腦有網路就可以。
這個時代的研發體系，和大專案時代互相借鑑，大的規劃，大的頂層設計。但是已經有了太多的不一樣。網際網路時代更多的是公眾客戶，而不是傳統的大客戶，對於使用者體驗更加重視，以前迭代計畫確定後，乙個月內如果沒有重大變故，都會封閉開發完成再發版，而在網際網路時代，這樣的迭代密度是不能滿足使用者要求的。
在這裡cmmi理論是否過時了？其實也不完全是，在這個階段，剪裁了過程控制，對於文件工件的要求降低，對迭代頻度要求增加，大體上還是自頂向下的設計，只不過效率更高，速度更快了。團隊也拆的更小了，角色的劃分，不能再那麼細緻，但是大體角色的職能還在，只是有剪裁，各個成員要求盡可能一專多能，每個團隊都盡可能專注做好一件事。
第四個階段：移動網際網路時代
移動網際網路的精髓是什麼？我以為是個人價值的凸顯，無論是使用者還是研發。
需求來講，以前是二八模式，80%的錢都是從20%的使用者身上賺取的，而現在更加重視沉默的大多數的需求，使用者群定位更加精確，而且不是模糊的一群人，是乙個個具體的人的需求。小公尺為例，成功的最重要的因素是，最大限度的與使用者零距離互動，重視每個人的想法和需求。眾多的公尺粉是小公尺最堅定的後盾和同盟。
研發體系也發生了徹底的顛覆，敏捷開發幾乎一夜就爛大街，雖然大家都未必清楚。但是有件事大家都知道，必須要盡快推出使用者需要的產品，速度比質量更加重要。
移動網際網路是草根生產力的解放，不再是上面說啥我就做啥，而是要徹底解放每個個體的生產力和創造力，要發出小嘍囉自己的聲音。
軟體研發的特點
追本溯源是人類的天性。當面對問題時，人們都會問，為什麼這樣做不行？為什麼那樣做就行？談及軟體研發過程中的問題和改善措施，需要首先分析其問題的本質，究竟是什麼原因造成了軟體研發過程的眾多問題。這樣我們才能說服自己，也說服別人，從根本上做些改變。在分析軟體研發特點之前，讓我們首先討論一下人類另外兩大類主...
軟體專案研發流程
前一點段時間參與了乙個公司的新專案，最近有時間開始總結一下專案的研發流程 研發流程大概分 為 6個部分可研性分析，需求分析，概要設計，詳細設計，程式編碼，測試，發布，下面就分別說一說這個幾個環節具體都幹什麼.可研性分析之後，確定產品，研發 技術leader和主程 測試同學，質量同學，需求方對接人進行...
完整軟體研發流程
軟體產品開發流程 下圖所示的是乙個軟體產品開發大體上所需要經歷的全部流程 1 啟動 在專案啟動階段，主要確定專案的目標及其可行性。我們需要對專案的背景 干係人 解決的問題等等進行了解。並編制專案章程和組建專案團隊，包括 產品經理 架構工程師 ui工程師 開發工程師 測試工程師等。完成以上準備工作之後...