討論區主頁 成熟度模型 CMMI-Dev V1.3中,運用Agile作法時,CMMI的解讀~~ | 無發表權 |
樹狀顯示 | 新的在前 | 前一個主題 | 下一個主題 | 頁尾 |
發表者 | 討論內容 |
---|---|
tyrone | 發表時間: 2010-11-24 00:01 |
網站管理員 註冊日: 2003-04-19 來自: CSQA 發表數: 342 |
CMMI-Dev V1.3中,運用Agile作法時,CMMI的解讀~~ 由於稍早就聽說CMMI會在v1.3提到對於Agile作法的解讀,因此拿到CMMI-Dev-v1.3技術報告,首先就看了有關於Agile的部分。讀的的感覺是,這些似乎是SEI被強迫為Agile approaches而寫,寫出來的內容,SEI自己也認為是僅供參考,可有可無。
另外,想用Agile然後去規避文件作業,在CMMI的框架之下,還是行不通的,而且文件修改可能更加頻繁,尤其是PP、PMC、與PPQA...,因為結合了每日的活動...所以可能變成天天改。一個專案下來,計畫可能跟發展的產品一樣,是一天一個版本.... 有關於CMMI-Dev v1.3中,對於Aigle環境,使用CMMI的解讀,相關素材,謹翻譯供參考。原文請自行參閱CMMI v1.3技術報告。 ----------------------------------------------------------------------------------------------------------- 於運用Agile作法時,解讀CMMI Interpreting CMMI When Using Agile Approaches CMMI常規設計的目的是在各種不同情況下提供價值,並且以通用的用語來陳述。由於CMMI並不對所有特定的發展背書,只提供作法特有之少量資訊。因此,對於沒有在類似其目前所處環境中實作CMMI先前經驗的人員,可能認為解讀並不夠直覺。 為了協助該等使用Agile方法的人員,於其所處環境解讀CMMI,已在選定的過程領域中增加了註解。這些加入的註解,通常是列於CMMI-DEV中的下列過程領域的簡介註解中: CM, PI, PMC, PP, PPQA, RD, REQM, RSKM, TS, 及VER。 這些註解均以“In Agile environments (在Agile環境中)“為開頭,並列於範例框中,以協助您可以輕易地辨識它們,並提醒您,這些註解乃是如何解讀常規的範例,因此,它們對於過程領域,既不需要也不充分。 目前有多種的Agile作法。 “Agile環境(Agile environment)” 與 “Agile 方法(Agile method)”只是所有忠於Manifesto for Agile Development 之發展或管理作法的略示式[Beck 2001] 。 這類的作法由以下的各點所具體描述: --客戶在產品發展的直接參與 --多重發展疊代的使用,以知悉並演進產品 --客戶願意分擔決策與風險的責任 許多發展與管理作法能分具這些特性的一項或更多,但還不能稱為“Agile”。例如,有些團隊可以論證是屬“Agile”,就算未使用用語Agile。就算你未使用Agile作法,你還是能在這些註解中找到一些價值。 在使用這些註解的時候,請務必謹慎。你對於過程領域的終極解讀,應與你所處情況的特殊性配適,包括當面全符合CMMI過程領域目標與常規的時候,你組織的業務、專案、工作群組、或團隊目標。就如稍早所提到的,這些註解應被看做是例子,而且對於過程領域的實作,既非必要亦不充分。 在Agile發展作法上,所給定之指導的通用背景與動機,可於SEI技術短文CMMI or Agile: Why Not Embrace Both! [Glazer 2008]中找到。 ----------------------------------------------- 以下是各PA於Agile環境中作法的解讀... CM: 在Agile環境中,由於要支援經常性變更、經常性構築(通常是每日)、多重基準、以及多重CM支援工作場所(例如,對個人、團隊、甚至是成對程式編寫),組態管理(CM)是屬重要。如果組織做不到下列各項,則Agile團隊可能陷入泥沼:1) 自動化CM (例如,構築腳本(build scripts)、狀態記述、完整性檢查),以及2)將CM當成單一標準服務集來實作。在啟動的時候,Agile團隊應識別將負責CM正確實作的個人。在每一個疊代開始的時候,CM支援的需要,要再次確定。CM以最小化團隊的分心,使工作完成為重點,謹慎地整合到每一個團隊的節奏中。(參閱Part I中“於運用捷式作法時,解讀CMMI。”) PI: 在agile環境中,產品整合是一經常性、通常是每日的活動。例如,對於軟體,工作程式碼持續地以稱為“持續整合”的過程,加入到程式碼庫中。除了進行持續整合之外,產品整合策略能說明,供應者所提供的組件,將如何融入其中,功能性將如何構築(以分層vs.“縱切片”),以及在何時要“重構(refactor)”。應於專案早期即訂定該策略,並予以修訂,以反映組件介面、外部饋送、資料交換、以及應用程式介面的演化與浮現。(參閱Part I中“於運用捷式作法時,解讀CMMI。”) PMC: SP 1.5 Monitor Stakeholder Involvement 在Agile環境中,專案產品發展活動中,受到支持之客戶及潛在終端使用者的參與,對於專案成功極其重要;因此,專案活動中,客戶與終端使用者的參與,應受到監視。(參閱Part I中“於運用捷式作法時,解讀CMMI。”) PP: 對於產品線,多種的工作活動集,能自本過程領域的常規中獲益。這些工作活動包括核心資產的產生與維護、將以該核心資產構築之產品的發展、以及調和整體的產品線努力,以支援與協調交互關聯之工作群組及其活動的運作。在Agile環境中,增量式發展的履行,涉及較傳統之發展環境中,更為頻繁實施的規劃、監視、控制、與重新規劃。雖然整體專案或工作投入的高階規畫通常都會建立,但是團隊還是要估算、規劃、並以一次一個增量或是疊代,實行實際的工作。團隊通常不對專案或疊代未知的部分做預測,除了預判的風險、重大事件、以及大規模的影響與限制條件。估算值反映出影響完成該疊代之時間、投入、資源、以及風險之疊代與團隊特定的因素。於每一疊代期間,經常性地實施(例如,每日)團隊規劃、監視、以及調整計畫。計畫的承諾,會在每個疊代規劃期間,工作指派與接受、使用者故事情節細述或估算、以及工作從受到維護之工作積存中,移至疊代等時候展現出來。(參閱Part I中“於運用捷式作法時,解讀CMMI。”) PPQA: 在Agile環境中,團隊傾向於將焦點聚集在疊代的立即需要上,而非較長期的且更廣泛的組織需要。為了確保抓住客觀評估的真意,使之具有價值,並且有效率,要儘早討論下列事項:(1)客觀評估如何完成,(2)要評估哪些過程與工作產品,(3)評估的結果要如何整合到團隊的節奏中(例如,做為每日例行會議、檢核表、同儕審查、工具、持續整合、回顧等等的一部分)。(參閱Part I中“於運用捷式作法時,解讀CMMI。”) QPM SP 1.1 Establish the Project’s Objectives 專案品質與過程績效目標的例子包括: --將變更請求積存的規模,維持在標的值之下。 --以標的日期,改善Agile環境中的速度至標的值。 --以標的日期,將閒置時間降低x%。 --時程落後維持在指定的百分比之下。 --以標的日期,降低總生命週期成本為指定的百分比。 --在不影響成本下,降低交付給客戶之產品的缺陷至10%。 RD: 在Agile環境中,客戶需要與想法,會反覆地徵詢、詳述、分析、以及確認。需求以諸如使用者故事情節、情境、使用案例、產品積存(product backlogs)、以及疊代結果(在軟體情況下為工作程式碼)的形式記錄。哪項需求會在給定的疊代中予以處理,是以風險評鑑、以及其在產品積存中相關的優先權來驅動的。那些需求(及其他工作物)的細節要予記錄,是由協調(團隊成員間、團隊間、以及後續的疊代)之需要,以及已知事物遺失之風險來驅動的。當客戶參與團隊之中時,仍然會有分離客戶與產品文件,以容許多種解決方案之探索的需要。當解決方案出現的時候,導出需求的職責,會分配給適當的團隊。(參閱Part I中“於運用捷式作法時,解讀CMMI。”) REQM: 在Agile環境中,需求透過諸如產品積存、故事卡、螢幕實體模型之類機制予以溝通與追蹤。對需求的承諾,若非以團隊集體式做出,即是由獲授權的領隊做出。工作指派是定期式(例如,每日、每週)根據進度調整,並成為需求與解決方案顯現的改善理解。需求與工作產品之全面性的追蹤性與一致性,是經由已經提及的機制,以及諸如“回顧”與“展示日”之類的疊代啟始或疊代結束活動等處理的。(參閱Part I中“於運用捷式作法時,解讀CMMI。”) RSKM: 在agile環境中,某些風險管理活動是原本就嵌在所使用之Agile方法中的。例如,某些技術性風險可透過鼓勵實驗(早期“失效”)或執行例行疊代之外的“大釘子”來處理。然而,風險管理過程領域鼓勵採取更為系統化作法,以管理風險,包括技術性與非技術性風險。這樣的作法能整合到Agile的典型疊代中,並符合節奏;特別是,在疊代規劃、工作估算、以及工作驗收的期間。(參閱Part I中“於運用捷式作法時,解讀CMMI。”) TS: 在Agile環境中,焦點置於早期的解決方案探索上。透過使選擇與折中決策更為明顯的方式,技術解決方案過程領域,既採各別方式,亦隨時間的推移,協助改善該等決策的品質。解決方案可從功能、特徵集、或其他能促進產品發展之組件的角度來定義。當團隊外的某個人會在未來憑藉該產品來工作、釋出資訊、維護日誌、以及其他資料,通常會含括於該已安裝的產品中。為了支持產品的未來更新,(折中結果、介面、以及採購的部件之)理由闡述要予以捕捉,以使產品存在的理由,能夠有更清楚的了解。若獲選的解決方案屬於低風險,則正式捕捉決策的需要,就會大大地降低。(參閱Part I中“於運用捷式作法時,解讀CMMI。”) VER: 在Agile環境中,由於客戶參與經常性釋出,驗證與確認相互支援。例如,缺陷能引發雛型或早期釋出版本,早產而未能通過確認。相反地,儘早且持續地確認,協助確保驗證適用至對的產品上。驗證與確認過程領域,協助確保受審與受測工作產品、使用之方法與產品、以及納管介面等選擇的系統作法,驗證與確認協助確保缺陷的儘早識別與處理。產品愈複雜,則就愈需要系統化的作法,以確保需求與解決方案間的相容性,以及需求和產品使用方法的一致性。(參閱Part I中“於運用捷式作法時,解讀CMMI。”) SP 1.1 Select Work Products for Verification 驗證方法的例子包括下列各項: --軟體架構評估與實作符合性評估 --路徑涵蓋測試 --負載、壓力、以及效能測試 --基於決策表的測試 --基於功能解構的測試 --測試個案再用 --驗收測試 --持續整合(亦即,儘早識別整合議題的Agile作法)
凡所有相皆是虛妄。見諸相非相。即見如來。 |
womwom | 發表時間: 2010-11-25 09:29 |
Just popping in 註冊日: 2003-09-29 來自: 資拓宏宇國際(股)公司' 發表數: 4 |
Re: CMMI-Dev V1.3中,運用Agile作法時,CMMI的解讀~~ 看完林兄所提供之資訊,小弟仍無法清楚了解,Agile之開發模式下,如何符合CMMI各流程目標。
是故,若專案以Agile模式開發時,現階段似乎不容易符合CMMI各流程領域(PA)之目標與要求~ |
tyrone | 發表時間: 2010-11-25 09:57 |
網站管理員 註冊日: 2003-04-19 來自: CSQA 發表數: 342 |
Re: CMMI-Dev V1.3中,運用Agile作法時,CMMI的解讀~~ 這個部分,您應該可以請教一下貴公司的LA,她們可以判斷。
其實能不能符合CMMI要求,就是看CMMI的架構要什麼,而不是Agile要什麼。而個人也說了,這些各PA的Agile環境註解,看來是SEI不得已之作。否則SEI不需要強調"that these notes are examples of how to interpret practices and therefore are neither necessary nor sufficient for implementing the process area. (這些註解乃是如何解讀常規的範例,因此,它們對於過程領域的實作,既不需要也不充分。)"而且這段話,還提了兩次(就是在"強調"的意思)。 既然要實作CMMI、要符合CMMI的要求,以取得CMMI的評鑑通過,當然是要從CMMI的角度來看,而不是Agile的角度來看,更何況,CMMI所描述的是組織的成熟度,而不是軟體。所以根本也沒有所謂"現階段似乎不容易...云云"。除非SEI願意把CMMI的架構的鬆緊度降級吧,但是,如果那麼做,是否能夠支持美國國防部的專案,就不得而知了。 又,以SEI所提出來的註解來看,也顯示出,SEI希望,Agile環境能夠注重文件(管理計畫、需求、設計之類的文件)、真正地去重視與掌控風險,要有序地工作,所有的變更,都能立刻真正有效地反映出來(例如,在文件中)。
凡所有相皆是虛妄。見諸相非相。即見如來。 |
tyrone | 發表時間: 2010-12-22 11:52 |
網站管理員 註冊日: 2003-04-19 來自: CSQA 發表數: 342 |
Re: CMMI-Dev V1.3中,運用Agile作法時,CMMI的解讀~~ 有關於Configuration Management,FCA/PCA在CMMI v1.1一個字也沒提,在CMMI v1.2,列於系統工程的環境部分,在CMMI v1.3系統工程與軟體工程都要做,有趣的是,所謂的提到,都只是一段描述性的文字而已。不論是for Dev或是for ACQ通通都一樣。照說,ACQ是獲取者角度,這兩者應該談更多才對,可惜CMMI-ACQ裡沒有強調,也沒有提詳細做法。在美軍的軍規與軍方手冊中,認為不論是系統工程或是軟體工程,此兩項稽核是design-based acquisition一定要做,而performance-based acquisition只做FCA。
業主/獲取者如果同意開發者(廠商)使用Agile Engineering開發軟體系統,那麼,在軟體驗收測試之後,在交付之前,就一定要做好FCA與PCA,並訂定產品基準,免得弄到最後又說,廠商給的不是業主要的,給的產品與需求不相符,產品與文件不一致。
凡所有相皆是虛妄。見諸相非相。即見如來。 |
樹狀顯示 | 新的在前 | 前一個主題 | 下一個主題 | 頁首 |
無發表權 | |