小倩倩

這個課題太大了。

個人理解CMMI最重要的是加強項目的組織化，也就是說根據(jù)組織既定模式來推進項目，在項目推進過程中再將經(jīng)驗反饋于組織財富。

而敏捷開發(fā)模式，強調(diào)是保證結(jié)果的前提下精簡資源和流程。比如檢查人員與被檢查人員坐在一起閱讀source，修改程序。這樣就不需要也無法將檢查出的錯誤留在文檔中，用于以后跟蹤。從而也無法統(tǒng)計這種檢查方式的bug率。

所以敏捷開發(fā)模式會大大加大CMMI推進的難度。而CMMI的推進者（QA，EPG）成員與敏捷開發(fā)項目的項目經(jīng)理的摩擦會較普通項目大大增加。

CMMI講究的是組織層面：只要參照組織管理方式，項目就不會有大的偏差。

而敏捷開發(fā)講究的是人的能力層面：能力高的，就不必拘泥于規(guī)定，講究的是效率。

我個人不相信，有個人或者組織能將兩個很好的結(jié)合。（最多就是表面的結(jié)合而已）

紅紅的太陽

這里涉及的第一個問題：自組織是不是敏捷的本質(zhì)特征？有人認為是，如果是的話，第二個問題：什么樣的自組織是敏捷所需要的？

對于第一個問題，我認為并不是那么絕對。

敏捷宣言和原則并沒有清晰的回答這個問題。

第二個問題, 在英文中對應(yīng)到“自組織”有3個詞，分別是self-organizing, self-organized, self-organization. 敏捷中采用的是self-organizing。 所以敏捷并沒有明確要求自組織的程度，而是指出了團隊建設(shè)的大方向。

所以，PM,QA等角色需要不大的變化，就能采用敏捷。

PM和QA秉承向著自組織的目標去，發(fā)動團隊成員的能動性和參與度。

當然，采用Scrum的角色安排來推進敏捷采用，也是可以的。

但不是必須的。

對于大多數(shù)組織和團隊，筆者建議注意發(fā)揮現(xiàn)有PM/QA的技能和團隊中的影響和權(quán)威，來尋求更敏捷的做法。

婉婉

我覺得敏捷可以理解成迭代的一種，也算是一種生命周期模型，QA、PM角色職責應(yīng)該是一樣的，只是他們的工作頻度加快了，可能以前寫周報，改為每日站會。

以上是個人的理解。

展顏

QA/PM的角色會有顯著的變化

首先敏捷開發(fā)都強調(diào)自組織的團隊，也就是說團隊是自我管理的，而不是受制于外部壓力的，團隊內(nèi)部是相互平等的，而不是有人主導其他人配合的。在這樣的團隊文化中，QA、PM的角色就和傳統(tǒng)的角色差異很大了。

以比較流行的Scrum方法為例，這個方法中就不再有PM這個角色，和PM勉強有點像的是ScrumMaster這個角色，ScrumMaster負責在團隊內(nèi)倡導Scrum實踐的應(yīng)用，并守護團隊不受外部不利因素的影響，但他并不是PM，并不負責計劃的制定、任務(wù)的分配和跟蹤，這些傳統(tǒng)的管理工作是由團隊成員自己決定、自己負責的

同樣，QA這個角色傳統(tǒng)上是用于從團隊外部去檢查團隊工作流程并報告給管理層，但由于敏捷方法倡導團隊自我管理、自我改進，團隊的管理制度都是由團隊成員自己制定的，QA就很難再按照統(tǒng)一的過程要求去約束團隊，這時QA要么徹底從監(jiān)督者轉(zhuǎn)換為服務(wù)者，要么就只能從一個相對較高的層級去檢查項目的過程，而不能再從細節(jié)上去約束團隊行為