1樓：敏捷開發
但是人數並不是乙個死規定。具體可以按照自己的團隊實際情況來進行調整。
像LeSS框架，就是將Scrum框架放大，並應用於多團隊管理層級中。
LeSS保留了很多Scrum 中的基本要素，例如：每日站會、產品待辦列表、Sprint計畫會議、Sprint評審會議、回顧會議等。但在Scrum框架的基礎上，LeSS框架又延伸出比之更大的範圍。
同時，LeSS框架是乙個極簡框架，以真正的團隊作為基本構建塊來進行整個組織的架構。對於多團隊來說，規則越少，實踐的門檻就會越低。另外，在建立LeSS的過程中，Bas Vodde 和 Craig Larman 盡可能地減少定義的輸入，更多的是推動團隊憑自身經驗建立適合自己的流程。
LeSS具體細化為兩種框架：一種是適用於8個小團隊進行開發，每組最多8人的「LeSS」；另一種是協調、管理多達上千人的團隊的「LeSS Huge」。不論是哪一種具體的框架，對團隊自身的要求都不會改變。
LeSS Huge框架
規模化敏捷LeSS（Large Scale Scrum）的誕生 ：這篇文章強調了LeSS團隊的幾個特性。
在公司的組織變革轉型、創新業務流程等場景中，經常會遇到以下問題：
不同專案資源分配不均？
複雜專案進度難以監控？
公司戰略無法對齊？
……在這些複雜的業務場景下，單專案管理已不足以支撐現有管理目標的實現。
與傳統專案管理相比，專案集管理可以幫助管理者更好地對公司專案進行整體監控，通過專案集 > 子專案集 > 專案的狀態，來持續驗證專案集與公司戰略之間的一致性。
專案集的成敗將直接關係到公司戰略能否實現，因此無論專案集本身進展如何順利，如果專案集偏離了公司戰略，專案集自身以及專案集管理工作將變得毫無價值。
就比如禪道發布了15版本專案集管理，該版本對原有管理理念做了全新公升級，新增專案集功能，以幫助使用者更好地進行專案集管理。
如圖所示，專案集是多層級管理。其中，專案集的層級最高，在它下面可以管理乙個或多個子專案集、產品和專案。產品只能關聯到頂級專案集下。
對於專案層級的切分問題，也可以按照不同的維度，如時間、部門、產品線等進行劃分。
這樣，專案建立的時候選擇敏捷流程，同樣能夠輕鬆管理多專案、多人員。
下面附送禪道15版本手冊：
2樓：PM網事
敏捷團隊人數受諸多因素影響，組織環境、專案情況、團隊情況等因素都會影響人數，所謂最佳是要根據上述因素判定的，沒有絕對的標準。
3樓：江青山
敏捷管理為什麼要有乙個最佳人數呢 ？ 敏捷管理有乙個很大的誤區，就是說，之有小團隊才會用。！！ 我覺得這是不對的！ 太扯淡了！
在敏捷專案管理中，如何鼓勵團隊成員也去適當地關心整體進度？
大熊圓滾滾 很多人都說這個問題難，那是因為如果你要站在問題裡面看問題。不能跳出來，那當然是難題，乙個本來就不關心專案進度，或者是在這個專案裡，關心進度對與這個員工沒有真正的正向反饋的時候，他為什麼來跟你主動報告呢？當然很難沒有可能了！那我們現在該做的是什麼？先把工作激勵，專案激烈，員工生涯規劃做好！...
敏捷專案管理與傳統專案管理有什麼區別？
敏捷布道師 簡單來講，傳統專案管理是序列模式，先收集需求，搞清楚後，開始設計，之後開發 測試 發布 運維。因此週期一般都很長，那麼問題來了，等最後發布之後，才發現市場環境變掉了，以前的需求現在市場已經不需要了，那怎麼辦？只能再重頭將上面的流程來一遍，既浪費時間，又浪費金錢，還很可能無法避免上面提到的...
scrum敏捷專案管理怎麼樣？
儲茄 Scrum作為一種專案管理方法，已經幫助數百家公司成功走出困境，高質量 快速地成功交付軟體產品。Scrum是管理複雜專案的簡單方法，它的魅力在於規則和實踐方法數量較少，簡單好用，容易上手。但與此同時，Scrum的簡明性往往又使新手在不知不覺中重拾傳統專案管理方法和工具。使產出成果縮減。在實際專...