關於在完成項目的過程中，很多時候需要團隊內部或者團隊間的合作。
合作分三類，代碼級合作，設計級合作，項目級合作。
首先關於代碼級合作，
其次關於設計級合作，
最後關於項目級合作。
代碼級合作：
根據《人月神話》的推論，當一個項目進行到後期，如果加入新人不僅可能無法縮減開發時間，還有可能增加開發時間。後來網上根據這個也有很多討論，說這個推論有適用的前提。當一個項目的複雜性很高，模塊間耦合性極強，對於一個新人來說，首先就要花費很多時間來理解代碼間的關係。可能這個時間，就需要很長。《人月神話》所提出的應該是針對於這種情況的。所以爲了避免出現《人月神話》討論的情況，我們需要採取措施，儘量避免那種情況。隨着，軟件工程的發展，這些也越來越多受到關注。
功能模塊化，模塊化編程，高內聚，低耦合。這些都是有利於避免後期加入新人，縮減開發時間的情況。當然，代碼的規範性，可讀性，影響到新人理解代碼的時間。
綜上，首先爲了避免中途加人造成的時間開銷，需要在開發代碼的時候，注意：
功能模塊化：將功能分解爲一個一個最小單元。對於每一個最小單元，能夠最快的理解。
模塊化編程：在設計程序結構的時候，將各個功能分模塊化實現，或者分層實現。避免不同模塊間的代碼耦合，這樣只需要專注於一個模塊就可能理解當前所做的事情。減少了需要關注的量，就相應提高了理解代碼的時間。
高內聚，低耦合：對於模塊化編程，需要注意高內聚，低耦合。否則，只是有模塊化編程之名，而無模塊化編程之實。各個模塊間的交叉調用，增加了理解一段代碼需要關注的代碼量，也就增加了理解的複雜度。
變量，函數命名規則統一：對於代碼中，用統一的方式命名變量和函數，能夠便於其他人閱讀時更快的理解代碼，也有利於自己很長一段時間後，回頭修改程序時，更快的理解程序。對於風格熟悉的代碼，能夠提高理解代碼的速度。
使用具名常量：避免程序中出現數字，使用有意義的名字代替這些數字。這樣對於閱讀代碼時，能夠一眼看出代碼的含義，也便於以後修改代碼，只修改具名常量定義的地方，關於這個常量所以使用的地方都會做了修改。避免有遺漏的地方。
一定的代碼縮進方式：代碼縮進統一，對於書寫者是一種好的習慣。對於閱讀者，是一種熟悉的閱讀環境，便於他們更快的進入代碼邏輯的分析，而不是停留在找尋相關代碼。
一定的規範，是人與人之間的協議，這樣便於人與人之間的交流（通信）。這樣，即使加入新人，功能模塊化，模塊化編程，高內聚低耦合，可以儘可能減少新人要做的工作量；代碼的規範性與可讀性，減少了新人熟悉工作內容的時間。這樣，儘可能會做到：增加新人，減少時間。
設計級合作：
一個嵌入式產品的設計涉及到硬件與軟件的雙重設計，以及不同獨立模塊間的設計，而他們之間的協同工作，能夠直接影響最終產品完成的時間。這就是系統設計的重要性所在。從一個整體上考慮他們之間的關係，合理選擇任務分配：由硬件實現OR由軟件實現；由A模塊實現OR由B模塊實現。當多個部分同時進行開發的時候，如何提高並行開發的個數，儘量減少最長時間鏈。 這些需要由系統設計來統籌。
在硬件設計的時候，硬件與軟件之間的交互要和軟件設計協同進行；軟件上對於脫離硬件的部分軟件可以獨立設計。有聯繫獨立模塊之間，通信協議的約定需要協同完成。多個功能可以在不同獨立模塊上實現，需要協同設計，實現每個模塊上均等的開發任務。
上述，各種協同工作的最終目的是，儘可能減少產品開發需要的時間。
硬件與硬件協同：分配好每一個獨立模塊需要完成的功能，在保證符合相應規格要求（標準）的前提下，保證每一塊都有最短的完成時間，以及每塊之間可以獨立工作，這樣便於每個模塊的獨立測試。同時每個模塊間的接口要在開始實現前，在設計的時候定義好，並且在以後的過程中不輕易改動，目的在於：1、實現前後版本的兼容，2、減少在最後時刻，因爲接口問題導致的延期；
硬件與軟件協同：在確定好需求，開始設計時，首先要分清楚，哪些工作軟件實現，哪些工作硬件實現；之後，根據要實現的功能，硬件給出設計接口，並在以後的設計過程中不輕易改動。軟件根據硬件提供的接口，設計底層驅動程序，再設計的過程中，不直接使用特定端口，而是使用宏定義調用這些端口，目的在於如果硬件發生改動，軟件上做到最小改動，規避因硬件改動帶來的程序修改。同時，將硬件相關程序與硬件無關程序獨立開來，最小化硬件相關代碼，方便以後的不同硬件平臺的移植。
軟件與軟件協同：軟件與軟件協同開發時，一部分參見“代碼級合作”。還要注意的是，保持函數接口的穩定不變性，使用面向對象的思想來編程。
接口的設計（硬件與硬件之間的接口，硬件與軟件之間的接口，軟件與軟件之間的接口，函數接口，通信協議），是模塊與模塊之間協議。在確定宏觀功能的前提下，將項目分爲各個部分，分而治之，多個部分同時協同進行，且做到最大能的並行開發，儘可能的縮短開發時間。
項目級合作：
每一個大項目都可以分爲許多個小項目，適當的若干個個小項目組合起來可以構成一個大項目。項目的無所謂大小，小可大，大可小。只有溝通上的難易。一個項目牽扯的人越多，在溝通上需要的時間就越多。而且隨着人員的增加，溝通的難度度會越來越大。以一個大項目中分隔開的若干個小項目而言，如果，要進行設計工作，必須理解各自要承擔的部分，以及評估自身成員的能力，能否及時、按質完成項目；如果中間有難度，需要項目間的相互配合，儘可能做到每一個項目需要時間最短。從而做到，整個大項目的時間最短。
1、根據需求，進行項目間初級任務分配與預估；
2、根據各自項目的預估結果，決定是否接手項目，或者進行項目任務的重新分配，做到每個項目組適其才，盡其用；
3、根據任務分配，做好需要做的事情，保證進度與質量；
結束：
總體而言，現在理解到的是這些。不論是代碼級，設計級，還是項目級，有兩個共性：高效溝通，忽視細節（面向對象）。
代碼級：功能模塊化，模塊化編程，是爲了讓別人忽視實現細節；其他的編碼規範，是爲了做到高效溝通；
設計級：面向接口設計，是爲了做到忽視細節，同時也是溝通的結果。
項目級：任務的分配與評估，是溝通的結果；之間的合作，是爲了讓項目組之間，忽視其他的細節；