斷斷續續工作塊有二十四個月，可以說剛入門了。經歷了三四個完整的專案流程：做過開發，做過調研，做過測試管理，做過諮詢，做過維護。工作很雜所以看到的東西也不少。
工作實踐中，不乏很多問題，引發很多思考。我將逐步從開發模型，管理方面，編碼方面，測試進度、上線準備以及其他相關小的方面，自己的相關想法和感受記錄下來，願與君**亦留作回顧。
希望在將來的某一天可以回過頭來，重新總結和點評這些事兒。文中有許多地方還是很篇虛，可能是因為工作經驗的不足吧，希望各位前輩可以指出。
在沒畢業的時候，一直認為：乙個成功的專案是因為有乙個好的技術模型、好的架構和好的人員。等到今天我才明白，其實成功的專案大部分都是因為有好的開發模型、可以監測進度預估分享，激勵成員等一系列管理上的手段，而非技術上有多麼的出彩。
記得我畢業那年面試，在陸家嘴的某場面試裡曾經和面試官討論過以下的問題：瀑布模型雖然很土，並且無法預估風險、不能承受較大的改動、任何錯誤都會集中在較後的工序中體現出來，例如在需求階段對某個需求點認知比較模糊，因為缺少必要的溝通和修改，導致一直到交付才發現這個問題。但是日本人對瀑布模型加以改進成為v字模型，某個必要的設計工序都會有乙個對應的測試工序，而不是瀑布模型一樣，只有乙個整合的測試工序（換句話說，將這個工序拆分成各細更有針對性的測試週期了）。所以可以說明乙個問題，其實在軟體開發中，編碼和設計的不足大部分是可以靠測試把關，而國內大多數專案組都不看中測試，讓人覺得很納悶……
轉到我的工作中，我的專案組使用的開發模型應該屬於增強型的瀑布模型：
需求收集--需求分析--概要設計--詳細設計--編碼---測試---上線--維護；並且在概要設計和詳細設計階段中均有評審階段；下面我講逐一介紹一下：
輸入：客戶需求
輸出：需求收集文件-通常為rs（需求說明書）
與客戶確認基本的需求，並給出大約的工期作為銷售**的乙個評估引數；
輸入：需求收集階段的rs、客戶需求、現在系統文件；
輸出：功能說明書（fs）
結合現有的工件或系統或構建，進行相應的需求拆分，歸類，給出乙個更更準確的工期引數，作為銷售**的乙個評估引數；
輸入：fs，rs文件
輸出：概要設計說明書、資料庫設計文件、畫面說明書
根據不同德需求點，設計每個業務處理流程，顆粒大寫，多半是根據使用者的一次操作來分割的，比如乙個錄入、一次審核以及之後的系統自動處理流程之類，通常在這個階段已經把前後臺的處理介面定下來了，資料庫的表機構也定下來了，當然畫面也定下來了（不只是畫面原型）
輸入：概要設計說明書、資料庫設計文件、畫面說明說
輸出：詳細設計說明書
根據輸入工件書寫每個處理流程的具體操作，主要包括:其他系統析構介面，必要的判斷分支、資料庫表操作、也可能把**都貼了進來……
應對變化的策略是，如果在編碼階段發現明顯的需求修改，則直接按照正確的理解作，而通常這個動作不會影響需求分析的
輸入：概要設計說明書、詳細設計說明書、資料庫文件、畫面說明書
輸出：應用程式
開發工作大同小異，後台業務處理的開發主要是資料庫和業務操作參考的是詳細設計說明說和資料庫文件；而ui團隊依靠之前概要設計中的介面引數和畫面說明書進行開發。
輸入：幾乎全部文件
輸出：測試報告（後來我提議的……之前幾乎是靠excel來記錄和分派）
測試工作並不出彩……幾乎是沒有的，現在有所改進了……
零零散散說了這麼多，感覺這樣的開發誠然很沒有效率，但是縱觀整個事業部，我專案竟然還處於比價好的管理氛圍中。
今天先寫到這裡，這次是將整個週期都寫了出來，以後會挑乙個兩個點單獨詳細的寫。
如果各位前輩有什麼指教和教誨或者批評都請指出哦！
專案開發遇到的問題（1）
這邊是我乙個人單獨開發整個專案，其實之前在學校學的也不是很好，標準的學渣一枚，這個專案能完成多少我也不確定，盡力而為吧，把現在遇到的一些問題總結一下，乙個 使用哪一門程式語言開發，使用的是什麼資料庫，使用的是哪一種的框架模式這一點太重要了。因為之前在學校對ssh框架比較熟悉，hibernate可以自...
專案開發中的「繞」
專案開發中的 繞 乙個專案在開發過程中，不可避免會遇到一些問題，出現這些問題的時候，該怎麼辦。目前我看到的處理方法無外乎兩種，一種就是找到問題的根源，解決它。另外就是繞開它。就純粹技術開發角度上講，繞 當然是不可接受的，在這之前我對待問題的基本態度也是找到根源，解決它，不然心裡不舒服。但是從專案管理...
專案開發中的反思
接觸ios開發一年多，接觸到的專案也接近10個了，雖然對自己的進步不太滿意，但是還是有必要整理一下自己的經驗，以後可能會用得著。第五個經驗是關於專案中的各個模組。目前我知道幾種專案模組的劃分方式，它們都具有一定的合理性，都完全可以勝任任何ios專案的開發。但是在一位高階工程師進入開發小組後，一切都亂...