作者有兩次印象非常深刻的小團隊合作經歷，有幾點關於磨合的思考想分享出來。
前期可能比專案本身更加重要。
前期是個不太具體的說法，這裡想指的是，包括專案發掘，成員招募，團隊組建等內容。總之一切開始真正走入軟體工程生命週期的階段都歸屬於前期。
1.1 專案內涵如何表述？
專案分一二三等，這是個流傳挺廣的說法。但這裡想說的其實是，當已經確定了乙個專案的實際方向，想開始籌畫的時候，如何真正發掘這個專案的內涵，並且能夠充分地展示出來。
在西二旗地鐵站有很多在發放傳單的創業專案，多少有一些吸引人的地方。但共同的問題在於餅很大，也很空。直接地講，最吸引人的說法並不是描繪偉大的藍圖，而是精緻的拼圖已經初見雛形，我作為路人，可以放在裡面做乙個支撐的模組。
1.2 我們都是什麼樣的人？
經歷的團隊，我們有大牛，我們也有小白。但是不論大牛還是小白，需要的都是能夠合作在一起的人，每個人合理的自我定位都很重要。每個人都是在有條件地獲得進步，一定的克制，加上成熟的相處技巧，才能共同進步。
更多的經驗是，專案的學習曲線不是很獨特的情況下，團隊成員能夠跟上較快的節奏，走入快速迭代的高速路，能夠更好地推進專案。不需要的是團隊成員之間互相等待，並且看到的更多的是自己曾經做過的事情。
1.3 我們需要溝通哪些事情？
作為前期來講，更多的是：當專案遇到阻力，我們應該有什麼樣的心態；當有成員之間磨合不周，應該以什麼樣的方式保持溝通；出來問題時，以怎麼樣的語言表達出意見和建議。提前商量好溝通的方式和規則，能夠有效減少摩擦的產生。
通常來說，專案管理者具有相對豐富的經驗，需要針對系統架構和人員管理做許多任務作。但更重要的是，專案管理者那豐富的人際技巧。有的團隊看起來很不錯，但是由於成員在細節上處理不好，而專案管理者也不是很能解決摩擦，導致專案後期乏力；而有的團隊可能只有乙個獅子性格的領導，下面一群綿羊，反而能夠在最後勝出。
從另一方面來說，專案管理者要有一定的魄力。小的團隊的外在環境和自身方向都是不停在變的，成員由於各種原因有著各種觀點，而管理者需要能夠自主決定方向性問題，並承擔與之俱來的後果。當然，歷史總是相似的，管理者的角色最終結局是什麼，和扮演的方式非常相關，而已有的扮演模式和教訓網羅皆是。
團隊走到專案結尾，或者說進入下乙個迭代之前，往往同歷史一樣，東方興盛西方衰敗異軍突起，有的模組已經被砍掉，有的正在不斷擴張，每個人可能都處於了不同的狀態。
這時候需要團隊比前期更加用心於團隊的平衡與和諧。經過乙個迭代的摩擦，很可能氣氛有些急躁，也有可能有一些埋下的隱患。這時候需要略顯密集地溝通，首先評估階段性的工作成果，記好功勞簿；然後重新平衡下每個人的工作，並計畫好下乙個迭代；最後是記錄下暫時沒有辦法解決的問題，比如框架有哪些漏洞，或者有哪些功能實現非常弱，會影響整個專案的效率等等。
及時地溝通，使壓力快速釋放出來，才不致於發生小規模大破壞作用的**。
小團隊協作，磨合日誌
在 開始之前我們進行了詳細的需求分析，包括對老師課題的分析，理解思考老師課題中包含的需求資訊，畫出自己不太理解的或者有疑問的需求部分，然後統一的向老師諮詢，理解好需求，當然這不可能一下子理清楚需求，一有需求上的疑問，要自己理清思路，向老師問出自己的疑問。理清需求的同時，要分模組記錄要實現的功能模組，...
Unity有間隔的UI經驗條自適應與載入
今天遇到製作上圖這樣的進度條，自適應和載入都需要用 實現，所以記錄一下這個小技巧，首先吧進度條製作一下，建立乙個背景把錨點放在最下方，然後建立空物體 背景是父物體 然後製作十個 根據自己需求 小進度條 空物體是父物體 給空物體掛載gridlayoutgroup元件，間隔為10，cell size的x...
小團隊的管理
明確自己的職責 何謂主管？首先我們必須對主管的本質進行定義。如果定義模稜兩可，每個人對主管的理解各有不同，大家就會不知道自己應該做些什麼。在本書中，我將主管定義為 通過下屬實現經營者的目標的人 下面的四象限圖，有四種角色。縱向從 做什麼工作 的角度，將工作分為 實現經營者的目標 和 完成具體業務 兩...