軟件工程之美40講——最佳實踐：小團隊如何應用軟件工程？
小團隊在軟件開發中存在的常見問題
- 小團隊成本敏感
首先，小團隊對成本都很敏感，成本是小團隊很多問題的根源，對成本的控制也衍生出一系列大公司可能感受不到的問題。
2. 小團隊人少活多
從分工上來說，通常在大廠前端後端幾個人合作完成的事，在小團隊就得一個人從前端寫到後端了，可能甚至都不會有專業的產品設計和功能測試人員，都是開發兼任。從人員構成來說，大廠在組建技術團隊時會注意梯隊的搭配，整個團隊像金字塔的結構，頂部有幾個特別資深的開發人員，中間有一些經驗豐富的，底部的是有潛力但經驗比較少的。而小團隊就算是運氣好，也可能只有一兩個技術大牛，更多的是水平一般、經驗比較少的。這樣的分工協作和人員構成，導致的問題就是大家每天都很忙，但是感覺技術上積累有限。
3. 小團隊缺少流程規範
項目開發比較隨意，拿到需求可能就開始直接寫代碼了，沒有嚴格的需求分析、架構設計，寫完了後簡單測試一下就上線了，上線後再修修補補；需求變更是家常便飯；多個項目並行的時候，每個項目的負責人都覺得自己的項目是最重要的，希望你能把他的項目進度往前趕一趕；老闆權力很大、想法多變，經常會直接干預項目。這樣不規範的開發流程，導致的結果通常就是開發效率低下，軟件產品質量不高，項目計劃難以遵守甚至沒有計劃。
小團隊怎麼使用軟件工程
小團隊如何招人
比較現實的方法就是招有潛力的程序員培養。也不能一味節約成本，還要注意梯隊的建設，中間要有幾個有經驗的技術骨幹幫助把控好代碼質量。
小團隊如何培養人
-
師傅帶新人的機制其實對小團隊一樣適用，對新人來說可以快速融入，及時獲得指導，對於師傅來說，通過帶人，也能促進自身的成長。除了有師傅帶，新人的技術成長，
-
工作過程中不斷實踐和總結，在這個過程中，及時準確的反饋很重要。軟件工程中，像代碼審查、自動化測試、持續集成都可以幫助對工作結果進行及時反饋。
-
在小團隊推行這樣好的開發實踐，讓團隊獲得及時準確的反饋，有助於整個團隊的成長。
-
內部的技術分享也是很好的共同提升的方式，對於聽的人來說可以學習到一些新鮮的知識，對於分享的人來說，準備一個技術分享，本身就是最好的學習總結方式。
-
還有在分工方面，最好是讓“大牛”一半的精力負責一些重要的像架構設計、框架開發的工作任務，同時還要有一半的精力在代碼審查、帶新人等方面，幫助其他人一起成長，整個團隊的發展才能更健康。
小團隊如何管理人
- 小團隊的管理，核心在於營造好的氛圍，鼓勵成員自我驅動去做事。
- 還要注意的就是遇到線上故障、進度延遲這些不太順利的情況，更多的是提供幫助，一起總結覆盤，而不是甩鍋問責。
有關開除人
在應用軟件工程的時候，團隊中可能有些人會成爲障礙，要麼是能力不足無法落實，要麼是態度有問題牴觸軟件工程的實施。在這種情況下，首先對於有問題的成員肯定是要努力挽救，如果是能力不足，就給予幫助，給時間成長，對於態度有問題的，明確指出其問題，限期改正。但如果最終結果還是達不到預期的話，那就必須要果斷地將這些成員淘汰。
流程建設
選擇適合你的軟件開發模型
首先在開發週期上，應該縮短交付的時間，使用快速迭代的開發模型。因爲小團隊的一個特點是需求變化快，要求交付的速度快，那麼快速迭代或敏捷開發就是一個合適的開發方式。具體在實施上，可以縮短並固定開發週期，比如說每 2～4 周可以發佈一個版本。在做迭代的規劃時，優先選擇當前最核心最重要的功能；在一個版本內，不輕易接受新的需求變更，有需求變更放到下一個迭代中；在迭代時間結束了，無論新功能是否開發完成，都按時發佈新版本，沒完成的放入下一個迭代。另外在會議上，敏捷 Scrum 的幾個會議也可以借鑑，像每日站立會議，可以幫助團隊及時瞭解項目進展，解決進度上的障礙；每個迭代的計劃會議，可以讓大家一起參與到計劃的制定中；每個迭代的驗收會議，可以讓業務部門、老闆及時的驗收工作成果，看到大家的工作進展；每個迭代的回顧會議，可以幫助階段性覆盤總結，不斷優化開發流程。還有基於看板的任務可視化，也可以幫助團隊直觀的看到當前迭代中的任務進度，可以主動選取任務，而不需要去問項目經理下一步該做什麼。
構建基於源代碼管理工具的開發流程
很多小團隊開發質量低，開發混亂的一個原因就是沒有使用源代碼管理，也沒有一套基於源代碼管理的開發流程。在專欄文章《26 | 持續交付：如何做到隨時發佈新版本到生產環境？》和《30 | 用好源代碼管理工具，讓你的協作更高效》中，對於如何基於源代碼管理工具構建和開發已經有了非常詳細的介紹，這些開發流程一樣適用於小型團隊。有一點要注意的是，小型團隊完全沒有必要自己去從頭搭建自己的源代碼管理工具、持續集成工具，應該儘可能採用在線託管的服務，這樣可以節約大量搭建、維護工具的人力和時間成本。類似的策略也應體現在技術選型上，小團隊應該儘可能使用現成的工具、框架，而避免自己造輪子，把主要精力放在業務功能的開發上面。
建立外部提交需求和任務的流程
小團隊在流程規範上混亂的一個體現是，業務部門包括老闆對於提交開發任務非常隨意，可能直接找某個開發人員私下讓改一個需求，增加一個功能，導致開發人員不能專注於任務開發，經常被打斷。如果一個業務團隊的開發任務特別緊急要插隊，那麼意味着其他業務團隊的任務就必須要受影響，那麼就需要大家一起去協調。對於提交需求和任務的人，也能通過任務跟蹤系統，及時的瞭解到任務的進展。在團隊之外推行這樣的流程是會有一定阻力的，最好是能事先去找幾個關鍵的業務負責人私下溝通，取得理解和支持，讓他們知道這樣做對他們的好處，比如說可以更好地跟蹤任務的進展，讓開發效率更高，更好地爲他們完成任務。