以前還不覺得單人開發和團隊開發的區別有多大，以為頂多就是把一個人的任務分給了多個人而已，但是其實不然。

我也是在經歷過團隊開發之後，才感覺到了單人開發與團隊開發之間的重大區別（大致情況在後面說明），並不僅僅是將任務劃分一下就完了。

而在之前我之所以任務他們之間的區別不大，只要是因為我忽略了一個問題，在團隊中中的每一個人都是一個獨立的個體，每一個獨立的個體都會擁有一種不一樣的思想。

一個獨立的人思想是可以根據自己本身的需求和意向而改變的，但是如果是一個團隊，團隊裡面同時存在著多種獨立的思想，思想與思想之間是會發生碰撞的，有了碰撞之後就極有可能產生爭議，一旦產生爭議，就是問題的開始。

如果沒有一個能夠拍板的人，那麼整個團隊將會伴隨著越來越多的爭議而走向消亡。

特別是如果在一個團隊中，存在著那種非常固執任性的，不服從指揮，堅持我行我素的人，那麼這個團隊消亡的速度就會愈發的快了。

算了，不叨叨這多了，開始正題！

首先先了解一下開發的大致步驟。

▍開發步驟

1、需求分析

2、頁面原型設計

3、資料庫建模

4、架構

5、類設計

6、編碼

7、測試與除錯

8、部署

▍專案前期

第一個也是最重要的：找好領頭羊，不是每個人都適合作為領導者，這個領頭人一定要在團隊中有威信，有公信力和領導力。

另外如果自己自身在團隊中沒有威信，領導力不夠，那麼最好不要當這個領頭人，乖乖的當個小組員，做好自己的本職工作就好。

當一個無法讓眾人信服的組長是一件很頭疼的事情（這個我剛剛吃過虧！！！原以為當個領頭人是個很簡單的事情，結果發現，自己很難在組長中建立威信，佈置的任務總是拖延或是敷衍了事，根本達不到要求，很多時候都想自己把全部的事情給做了算了。弄得我現在頭疼得很）。

團隊互補是很重要的，好的搭配才是精彩的開始，糟糕的人員搭配只會讓事情變得很糟。

組隊的時候不能只看個人能力，還要看個人的溝通表達能力，有時候個人的性格脾氣也會對整個專案的進度產生影響。

人員分工一定要合理，包含兩點：第一好鋼要用在刀刃上（不要讓不熟悉相關工作的人做相關的事情），第二每個人的工作量儘量做到最好的“均分”。

▍需求分析

單人完成！

主要分析這個系統是幹什麼的，需要哪些功能，使用者主要是哪一類人群。

在需求中需要有完整的用例圖和用例表，不只是做到“差不多”，而是要做到用例全覆蓋。以下為單個用例表例項：

在需求中要指出變數、函式、類等的命名規範。

確定頁面快取方式，哪些表格是按照整個表格快取，哪些表格是按照單個欄位快取。

需求文件一定要完整清晰，發現其中有欠缺的地方要及時完善補充。

▍頁面原型設計

單人完成！多人同時提供設計思想會導致頁面始終難以確定。

如果其他人有任何意見，可以在設計完成後提出，如果最後關於某個問題爭執不下，那麼就團隊投票表決或者是組長做決策，不要在一個小問題上糾結太久。

▍資料庫建模

單人完成！

在資料庫表的設計上要保證科學合理，資料表的構建一定要符合3NF正規化。

每張表必須有一個自增id作為主鍵，不做其他用處，只是用來標識資料的數量。

▍架構

架構構建的時候，儘量使用當前流行且成熟的框架，保證架構的實用性與牢固性。

▍類設計

類設計就是要設計出有哪些類，這些類中又分別有哪些方法， 每個方法是做什麼用的，然後這些方法之間又是怎麼連線在一起的。

▍編碼

我個人認為編碼應該分為兩個小的階段：

第一階段前後臺獨立編碼，前臺完成頁面的製作，後臺根據頁面原型圖敲定大體上會用到的函式以及函式以及所涉及到的變數，這段時間內前後臺是互不影響的，可以獨立同時進行的；

然後前後臺獨立工作完成之後，就可以進行整合了，第二階段前後臺整合，前臺在後臺中找到所要請求的函式，如果有並且正確，那麼就直接呼叫這個函式，如果後臺沒有考慮到這個函式，或者函式的引數與返回值不滿足前臺的請求方式，那麼就需要對後臺進行微調，這個時候前後臺人員的交流就要多一些了。

不要想著能一次性寫好，這是不可能的事情，或者說是做夢。。。

如果是前後等後臺完成之後再動工，或者是後臺等前臺完成之後再動工，那樣的話中間等待的時間就會被浪費掉。

我的隊員就犯了這樣一個錯誤，我做前臺，他做後臺，我把前臺頁面做好之後，問他後臺的編碼工作完成沒有，結果他說他在等我前臺的變數名定好之後再動工，我簡直要氣死了。

離提交時間就只有這麼短了，他竟然告訴他還沒有動工！！！

不過要說怪的話，也怪我沒有事先說好程式設計階段的時候怎麼做，沒有把我的看法拿出來跟他們交流（我以為他們應該跟我想的一樣）。

團隊中的每個個體都需要有良好的程式設計規範，多寫註釋。

網站或者軟體在開發過程中，必須要使用版本控制器進行版本控制（小型團隊使用SVN學習||SVN的正確開啟姿勢，大型團隊使用GitGit簡潔教程-本地專案推送到GitHub），否則會做很多無用功。

▍測試與除錯

這一步驟是為了保證程式能夠正常跑起來。測試是為了找出Bug，而除錯是為了找出出現Bug的原因，然後修改程式修復Bug。

團隊之間肯定會存在方式思路不同的時候，除錯過程中，當我們覺得隊友的程式碼或者處理邏輯有所欠缺或不足時，在沒有與原始編碼人員商討的情況下，不得擅自修改，防止出現“交叉版本”。

▍部署

運用不同工具開發的專案，其釋出的方式也可能會有相應的區別。

比如如果是普通的web專案，有兩種方式：第一種在編輯工具中配置伺服器（例如在eclipse中配置tomcat），然後啟動配置在編輯工具中的伺服器，專案就可以跑了；第二種是將web專案打包成war包，然後放在放到伺服器中執行。

▍專案後期

專案完成之後，要看到這些文件：

• 需求分析文件

• 專案總體設計報告

• 專案詳細設計報告

• 專案進度報告

• 專案測試報告

• 專案使用說明書

• 專案風險評估報告

▍注意事項

專案過程中要有定期會議，每次會議要有會議記錄。

▍我是尾巴

這篇總結肯定還有一些不足之處，在後面積累更多的團隊專案經驗後，應該對整個流程會有更深的理解。