前言：中文期刊網精心挑選了敏捷的項目管理范文供你參考和學習，希望我們的參考范文能激發你的文章創作靈感，歡迎閱讀。
敏捷的項目管理范文1
【關鍵詞】 敏捷 Scrum
1 引言
在20世紀80年代，敏捷化產品開發方法在日本汽車制造公司興起，緊接著這一年年底敏捷概念傳播到北美汽車制造商和IT部門，然后敏捷方法作為軟件開發方法被其他行業迅速采納。在傳統方法中，產品開發過程中的需求變更很容易導致項目產生混亂，而敏捷方法不僅能接受項目中的任何變更，并且能以一定方式控制項目中的變更帶來的風險。
2 不確定需求的項目管理
在項目開發的過程中，應對不斷變化的客戶需求對開發人員來說是一個很大的挑戰，這使得開發人員在開發過程中把項目分成很多個小步驟，可以接受不斷變化的需求。根據2000年議會科學與技術辦公室的報告中的內容，其中提到把項目分解成為小模塊能靈活應對項目中產生的需求變更，分解出來的一部分包含明確的需求和固定的價格，另一部分用來應對變更的需求和價格，從而確保項目能夠更安全和容易地進行。同時，軟件公司在與政府IT部門工作時應該提供優秀的領導能力，更廣泛的部門目標，與供應商良好的關系，適當的風險管理以及考慮到盡可能多的用戶標準。
賽迪監理通過對眾多大型項目的管理研究發現，6到12個月短時間的項目比一年以上的項目成功率要高。持續時間長的項目失敗原因是由于過時的技術導致用戶需求變化。軟件公司把時間為一年以上的項目分解為小模塊來應對項目中的變更。在20世紀90年代后期，敏捷方法就有能力應對客戶的需求變更和不斷變化的技術。目前，有一種常用稱之極限編程（XP）的敏捷方法，它與傳統方法相比較可以應付不斷變化的客戶需求和技術，在客戶有系統需求時，給予及時滿意的可執行程序。這些要求不一定需要在項目的初始階段實施，但隨著項目的發展這些要求是被包括在哪一個階段要取決于項目的環境，客戶的需求可以通過原型法來確定。
E-type模塊在實施過程中通常存在不穩定的需求。這些模塊必須在整個項目中經常使用，以適應不斷變化的環境獲得更好的效果來提高客戶滿意度，軟件公司更新管理技術來適應需求的新變化。由于需求是經常發生變化的，開發人員往往對敏捷過程要進行不斷的驗證，確保整個項目是以正確的方式在進行在每一個開發周期，開發人員通過檢測測試結果，如果有錯誤，則對項目文件進行修正。客戶和開發團隊之間的有效溝通，能夠在不破壞計劃的前提下應對各種變更，并盡快在指定時間內完成項目。此外，開發人員應該對任何可能會影響項目的風險提高警惕。
Scrum是軟件公司用來應對不確定需求的另一種敏捷開發過程。Scrum過程中產生的產品backlog對需求變更具有重要的作用，產品backlog包含了項目中的各類要求和問題，在開發過程中，產品backlog中的要求可以在任何時候做出改變且不會影響該項目。產品負責人確定客戶需求的優先級，然后將確定優先級的需求分配給沖刺backlog。只有是客戶提出的需求才可以對產品backlog進行更改，這避免了軟件公司在項目發生變更時發生混亂。
軟件公司也常使用一些需求管理工具，一般來說，分為兩大類，一類是面向內容的需求管理被稱作為以文檔為中心的工具；另一類是面向過程的管理工具，用來解決結構化信息項目的需求。這些工具能夠與其它系統工程、軟件工具、分類需求，以及其它查詢和搜索關鍵字設備進行接口集成。HERMES是一種可以對需求進行概括的需求管理軟件，它自帶的XML技術可以把需求從文本轉化為對象，而且可以供其它模塊共享。這種管理系統一般應用于需求編制易修改的項目，此系統會檢測需求概括后的關鍵字，有助于開發團隊和設計者把需求考慮到系統及其開發過程中。
3 Scrum方法
Scrum是一種迭代式增量軟件開發過程。整個開發周期包括若干個小的跌代周期，每個小的跌代周期稱為一個Sprint，每個Sprint周期一般為30天。每天有15分鐘的Scrum站會，團隊的成員在會議中輪流回答以下3個問題：昨天我完成了哪些工作？今天我將完成哪些工作？我在工作中遇到了什么困難？團隊成員從產品backlog中自已挑選任務創建沖刺backlog，每天項目的沖刺backlog會提交給管理者，將客戶需求確定優先級順序經過分析得到沖刺任務列表，同時團隊中產生的任何問題或進一步發展的需求管理者都能夠快速提出來。Scrum適用于不確定需求產品的開發，只要使用Scrum在開發過程中發生的任何問題都可以得到快速解決，項目開發中的需求變更會在產品訂單中得到即時更改。每個Sprint周期的產品訂單和團隊人員在一個周期30天內是不變的，以確保迭代結束時能獲得預期的結果。
Scrum Master主持Scrum會議，管理每日Scrum流程，負責為成員解決障礙和問題。在每個迭代周期結束時那些未完成工作量的需求將移到下個月的產品backlog中，下個月團隊成員參考第一個Scrum過程的反饋內容。回顧會議由開發團隊與Scrum負責人共同討論這個迭代過程中哪些地方做得好，哪些需要改進，使團隊持續成長。下圖詳細說明Scrum過程。（圖1）
敏捷開發是一種開發方法學，可以快速應對客戶變更的需求。它強調以人為本，采用迭代的方式，循序漸進地開發軟件。一般來說，迭代周期為1到4周，短期迭代允許項目需求頻繁的變更，產品是在每個迭代周期結束時被逐步交付使用的。在應對不斷變更的需求問題上敏捷開發是最適用的方法，所有由需求變更導致的困難和風險都會在迭代周期中得到有利的控制，并使得客戶利益最大化，團隊成員面對面的交流使得制定決策計劃比通過文檔交流要快速得多。圖2表示了整個敏捷開發過程。
從上論討論中我們可以得出Scrum過程方法和敏捷開發的優缺點比較如下：
1）短期迭代：Scrum過程的短期迭代周期為30天，每天15分鐘的Scrum例會，每個迭代過程必須在30天期限內交付。敏捷開發的迭代周期為1到4周。這兩種短期迭代都適應于需求更改頻繁的項目開發。
2）增量式開發：Scrum過程的迭代周期結束時新增了交付功能，交付的需求進入下個月的迭代周期訂單進行解決，每個Scrum迭代過程的結果可以看作是項目開發中的增量開發。同樣的，敏捷開發也在每個迭代周期產生一個已通過測試的交付軟件。
3）管理團隊：scrum Master管理整個scrum流程，主持scrum每日例會，并幫助團隊成員解決在項目開發中遇到的問題，這樣避免了迭代結束時的交付延遲的問題。敏捷方法中的團隊成員都擁有解決問題的專業知識。兩種方法都有助于項目在開發過程中避免出現混亂。
4）降低風險：短期迭代使得scrum方法和敏捷過程降低了需求變更帶來的風險。在迭代周期結束時產生的需求變更可能會導致混亂，在下一個迭代周期中會改變技術以及規則來進行調整，使得項目沒有風險的進行最終交付。這樣會使整個項目處于正確的進程上。
5）改進控制：Scrum的每日例會允許利益相關方（一般指產品負責人）參加并對項目開發提出意見，項目開發者在下一步的開發過程中參考客戶提出的意見確認更明確的用戶需求，有益于項目的發展。敏捷開發是由管理者進行控制，它的改進有以下幾種機制：（a）敏捷方法的設計，開發，測試迭代周期為企業帶來了有商業價值的小幅增量。（b）在每次迭代結束時，利益相關者審查項目已完成的工作，如果有任何變化或問題可以直接反饋到下一周期的計劃安排中。（c）越早反饋有助于項目越順利正常進行。（d）每次迭代的測試確保開發商在項目中的贏利。
6）有益的交流：Scrum和敏捷方法都提倡面對面的交流方式，每個成員都對整個項目有很好的了解，這有益于他們進行下一步工作。
7）及時交付：Scrum和敏捷方法都按時交付項目增量，這樣能保證整個項目的最終按時交付。
Scrum和敏捷開發的缺點列舉如下：
1）只適合6至12個月周期的項目。
2）開發人員40以上不適用于此類方法，因為它是否適用于40以上人員是還值得商榷。
3）這兩種方法合適于軟件開發項目，核心是人而不是過程。
4）采用Scrum是昂貴的。
5）Scrum需要培訓。
4 SCRUM和PRINCE2
受控環境中的項目（Prince2）是一種廣泛應用于公共和私人部門的項目管理方法，它是英國項目管理的標準，英國政府項目都實施此方法。 PRINCE2是基于過程的結構化的項目管理方法，在賽迪監理的四控三管一協調理論中也有所體現，它一般包括：項目準備（SU），項目啟動（IP），控制階段（CS），產品交付物管理（MP），階段邊界管理（SB），項目收尾（CP），項目指導（DP）和項目計劃（PL）的過程。由項目委員會來控制項目系統是否值得，計劃是否合理等要點，項目經理來確認項目如何來進行，小組經理來進行工作具體實施。PRINCE2的項目計劃是以產品導向的，也就是說項目計劃強調項目按預期交付結果，而不是簡簡單單計劃在何時該做何事。換句話說，PRINCE2使用產品分解結構。
小組經理和項目經理都與產品交付物管理（MP）過程相關聯。小組經理負責受理，執行及分派工作包，而項目經理授權，評估取得的進展，并回顧已完成的工作包。這一過程包括小組經理和項目經理分別管理的三個子項目。左邊的每個子項目直接與右邊相連，用于通知子項目結束時的進度、質量和其他問題的子項目。圖3顯示了在Prince2產品交付管理的步驟。（圖3）
從上面的圖可以看出，MP1，MP2，MP3是由小組經理完成，而CS1，CS2，CS9過程是由項目經理完成。這整個過程可以在交付工作包的時候與Scrum相結合，Scrum可以在MP2階段幫助團隊進行項目控制，從而在這個過程結束的時候交付一個高質量的工作包。Scrum過程的產品backlog相當于這里的CS1過程中從DP過程中由項目委員會編制的計劃單，Scrum過程的需求優先級排序特征和Prince2中的將工作包授權分配類似。Scrum和MP在團隊中都是交付項目的成品。MP2過程中的工作包都要執行Scrum過程的每一個工作包，在每個驗收點報告給項目經理。同時，小組經理更新質量記錄和時間表給項目經理，不同的是，在Scrum過程中這些情況會在Scrum主管主持的Scrum例會中被反饋。在Scrum過程結束時的潛在的交付增量可以比作MP3過程，雙方都提供一個完成的工作包。Scrum與Prince2的整合是由圖4表示。
同樣的，Scrum可以結合到CS過程中。Scrum可以結合到Prince2的每個工作過程中，并且將每個過程結束時的已完成工作包交付到下一個過程。在結合Scrum之前Prince2過程中的需求是可以進行任意更改的，而一旦結合了Scrum就得對需求變更提高警惕，因為Scrum過程中需求只允許在產品backlog中進行變更，只要產品backlog發展成為沖刺backlog就不再容許任何改變，這也就是為什么要根據客戶需求來對產品訂單進行需求優化級排序，最重要的需求將在第一個迭代周期解決。（圖4）
綜上所述，我們可以得到Scrum和Prince2的相同點與不同點表格如下：（如表1）
5 結語
敏捷方法是一種適用于短期的、需求變更頻繁的項目管理方法，同時，敏捷項目管理對軟件項目開發有著不同的方法，每種方法都有自己的優點和缺點，Scrum和敏捷方法的優缺點也在上文中有進行討論。每個項目團隊要針對不同的項目自身的特點來選擇合適的項目管理方法，給項目提供合適的方法是項目成功的必要前提。
參考文獻：
[1]Reed.K，Damiani.E，Gianini.G and Colombo.A（2004）Agile management of uncertain requirements via generalizations：a case study，in：Proceedings of the 2004 workshop on Quantitative techniques for software agile process，ACM Press，NY，USA，pp40-45.
[2]Parliamentary Office of Science and Technology（2000） Government IT projects，Report 200 - [Blackboard Material].
[3]Taylor.A（2001）IT projects sink or swim，British Computer Society-[Blackboard Material].
[4]Mahnic.V and Drnovscek.S（2004）Agile Software Project Management with Scrum，at http：///scrum/FirstScrum2004.pdf/[accessed 05/05/2007].
[5]Mikneus.S and Akinde.A （2003） SCRUM an agile software development methodology，at http：//facweb.cti.depaul.edu/jnowotarski/se470/akinde-mikneus pres scrum.ppt/ [accessed 10/05/2007].
敏捷的項目管理范文2
“敏捷”是時下的IT圈子里一個非常吸引眼球的詞匯。很多人誤認為敏捷就是一種軟件開發的流程或者實踐，而其實敏捷是一組開發流程和實踐的方法論。這種方法論的背后是2001年由17位資深軟件開發專家在美國猶他州的一個會議上總結出的敏捷思想。時至今日，敏捷思想激活逐漸成為了軟件開發業的主流。全球不同規模、模式的IT組織已經從實施敏捷開發流程及實踐中取得了巨大的成功。而我國不少的IT組織也開始了解、學習敏捷思想，希望自己的組織能從實施敏捷中獲益。
然而，一個組織要接受一種新的開發模式并不容易。筆者對近期參與的一些敏捷項目進行了總結，在此與大家分享組織實施敏捷的方法以及組織實施敏捷過程中需要注意的一些問題。
為幫助大家理解，文中使用的敏捷詞匯簡單解釋如下。
故事: 描述一個有價值的需求的文檔。
迭代: 一個開發周期，往往是一組故事完成的周期。
XP: 敏捷倡導者Kent Beck提出的一組軟件開發的方法。
Scrum: 一種敏捷項目管理方法
組織保證
在談論怎樣在一個IT組織、企業實施敏捷之前，首先從組織架構上予以保證。那么，什么樣的組織架構最適合敏捷？
很多IT企業采用矩陣式組織結構，其中既有按職能劃分的垂直領導系統，又有按產品（項目）劃分的橫向領導關系。一個項目團隊的成員來自不同部門，隸屬關系仍在原單位。很多時候一人同時參加數個項目，其中尤以質量管理人員（質量分析師、測試員等）最為普遍。這樣的組織結構下，每個項目成員一般受雙重管理（所在項目及隸屬部門），這種組織結構存在的問題是明顯的: 首先，雙重管理容易破壞項目團隊的整體性，部門領導和項目管理者容易產生步調上的不一致; 其次，由于團隊管理的復雜化，項目透明度不高，很少有融入客戶（業務部門）的機制，其后果是不能圍繞客戶和市場的真實需求來展開開發工作。
對比上面提到的矩陣式組織結構，敏捷組織需要弱化職能部門的劃分，更多由跨職能、面向價值交付的團隊構成。大家可能會立刻問: 這樣的組織結構價值在哪里？下面我們就從三個方面來分析其價值。
敏捷組織價值一:
統一的團隊
在傳統結構下，團隊采取“會戰”方式組成，人員之間很容易因職能隔離，導致團隊內垂直劃分，從而不能成為一個統一團隊。各職能成員容易各自為政、目標不一。一個典型的現象是，開發人員常常在內心抵觸質量管理人員提出的要求，而質量管理人員又總是對開發的系統缺乏信心，項目管理者很多時候感到力不從心，不能激勵團隊成員，更無法談到融入客戶、擁抱變化了。
由于敏捷組織弱化了職能部門，敏捷團隊成員全職投入到項目組中，增加了每人的團隊歸屬感。原來一個人同時被分派多個項目的做法顯然是不利于團隊建設的，與之相反，敏捷組織要求員工積極參加到自己團隊的日?；顒又?，鼓勵員工參與不同職能的工作。
圖1簡單展示了一個迭代過程中業務分析人員、開發人員、質量管理人員及項目管理人員的日常工作。我們可以看到，除了每個職能例行的工作之外（如質量管理人員要完成上個迭代的故事測試，然后投入到這個迭代新故事的測試工作中），作為一個團隊，大家要共同參與如“迭代開題”、“上迭代回顧”等集體活動。以“下個迭代計劃”為例，項目管理人員需要安排組織會議、控制會議時間; 業務分析人員要解釋下一個迭代故事的選擇; 開發人員及質量管理人員則要了解相關需求，同時提出可能要進一步細化或要求重新評估的故事。通過這樣一系列的活動，項目管理達到了高度的透明。同時我們可以看到客戶（客戶代表）被融入到團隊中。遠離客戶的團隊不可能是一個敏捷的團隊，客戶的參與是保證最終價值交付的關鍵。
從上面的討論中，不難想象如果不是具有高度自組織能力、統一的團隊，是無法貫徹敏捷開發思想的。這樣的參與度，也讓每一個團隊成員很快擁有項目的主人翁精神。一言以蔽之，敏捷組織通過強調集體共有及發揮每個成員主觀能動性來打造統一團隊。
敏捷組織價值二:
價值驅動
談到價值，首先就要明確什么是價值。對于軟件開發項目而言，答案其實就在下面這個問題里。
假設在兩個項目開發過程中市場都在不停變化: 項目A按時、按預算交付所有計劃功能，不幸的是項目本身未能給客戶帶來任何幫助; 項目B因為響應變化，所以延時、超出預算交付了部分功能，但卻幫助客戶取得了盈利。傳統項目管理方式下我們說項目A是成功的，項目組完成了計劃?，F實卻恰恰相反，項目A沒有帶來任何的價值，因為它對使用者沒有幫助。在現今IT市場需求快速變化的時代，按時、按預算交付已經不能成為衡量項目成敗的唯一標準。
然而，要用價值作為驅動力就必須先有感知價值變化的能力。一個團隊要有感知價值變化的能力就必須是一個有高度協作精神、步調統一的團隊。正如GE前總裁韋爾奇所說: “如果我們穿著四件毛衣，那么我們就感覺不到寒冷了。”傳統組織下的團隊就像穿上了一件件“職能”的“毛衣”，很難感受到價值的所在。更無從談起將客戶（或業務部門）的需求轉換為團隊共識的價值、擁抱需求的變化了。
敏捷團隊在項目管理上的高度透明及全程的客戶融入實際是將最終的客戶需求植入到了每一個成員的心里，讓不同職能的團隊成員都能用價值來衡量自己的工作，從而使價值成為我們各種開發活動的驅動力。
敏捷組織價值三:
減少浪費
時下很流行把敏捷與精益制造相對比，這里我們無意討論精益，但精益的一個重要原則“減少浪費”在敏捷的組織結構里卻得到了體現。
韋爾奇在20世紀80年代曾經用“零管理層”、“無邊界行動”等理念將GE打造成美國最偉大的公司之一。在GE一個8000名員工的航空發動機工廠，只有一個廠長和全廠職工兩個階層，沒有任何中間管理層。一般工廠常見的車間、工段、班組、工會、人事、財務、計劃、技術、材料、供銷等所有部門全部取消。在生產過程中所必需的管理職務由工人輪流擔任。而一些臨時性的工作，如招收新工人，就由各崗位老工人臨時組成人事部門，完成之后即解散。這種扁平組織的思想與敏捷組織結構不謀而合！當我們弱化職能劃分的時候，相應地那些為職能部門設立的各種煩瑣的管理細節也被同時精簡; 當我們打造一個統一的敏捷團隊時，相應地按職能來管理人員的機制也就不再需要了。
在參與的敏捷項目中，我們經常聽到傳統組織團隊中資深開發領導者這樣說: “我很喜歡技術，真想跟大家一起開發?？上粘５纳舷聟R報、文檔郵件占去了我所有的時間。根本沒法參與開發！”我們不由得慨嘆這種人員上的雙重浪費。由于煩瑣的管理細節，扼殺了團隊寶貴技術資源的使用，同時也扼殺了資深人員進一步學習的可能。要消除煩瑣的管理工作就必須打造有自組織能力的統一團隊，這正是敏捷思想所追求的。
敏捷實施路線圖
實施敏捷是一個組織長期自我改善的過程。根據實際情況往往可以分為三個階段來幫助一個組織實施敏捷（參見圖2）。
實施敏捷的過程中，組織管理者往往非常關心怎樣去評估一個組織的敏捷程度。由于IT企業的多樣性，評估一個組織的“敏捷成熟度”不能用一刀切的標準。圖3展示了我們評估一個企業敏捷實施情況的一系列維度。紅條為現狀，藍條為設定的目標。每一個維度實際又從不同的角度來考查。比如“測試質量”，我們考查使用測試的種類、測試環境、自動化程度、測試運行頻率及測試用戶。到達尺標5則要求各種層級的測試（單元、功能、集成等）都被分級自動化，并且融入到一個故事的開發周期中由不同人員（開發、測試、客戶等）實施。
這里值得提起大家注意的是: 我們的目標是不是要所有維度都達到最優化（即到達尺度5）？或者說是不是只有各個維度最優化才能說敏捷實施成功了？答案是否定的。首先，要提高一個維度的指標必然需要一定的投入，比如想要更多地自動化測試，就會涉及選用或購買新工具，對相關人員進行培訓。運用敏捷思想，衡量是否需要的標準就是價值，如果我們開發一個簡單的網絡應用，自動化所有測試帶來的質量提高也許就遠遠小于我們的投入。所以，評估一個組織的敏捷程度絕對不能一概而論，一定要結合開發項目的實際情況。
下面讓我們看看這三個階段實施過程中需要做些什么。
敏捷激活第一步:
讓大家了解敏捷
敏捷在軟件開發業界已經成為主流。我們經常聽到不少組織說我們用Scrum了，我們“敏捷”了。事實上Scrum也僅僅是敏捷思想下的一種比較流行的采用迭代式開發方式的管理實踐。這樣的說法暴露出不少人對敏捷的誤解。敏捷是一種思想，有著很強的包容性。如何定義敏捷是一個比較困難的問題。筆者傾向于用敏捷宣言及原則來衡量一個流程、一個實踐是否敏捷。
第一步是要爭取組織領導者對實施敏捷的支持，我們必須認識到敏捷的全面實施是會涉及到部分組織變革的，而組織變革要求上下一心方能成功。
在了解過程中，我們希望給組織的成員傳達正確的敏捷思想，讓大家了解敏捷的思維方式，學會用價值來衡量日常開發工作。當思想得到統一后，即進入分角色培訓階段，一般情況會分為三組: 項目管理人員、業務分析人員組; 開發人員組; 質量管理人員組。項目管理和業務分析在敏捷中其實是分開的兩個職能，但很多時候我們發現傳統IT企業或小型開發團隊中一般業務分析是由項目經理來完成的，項目經理因此對這兩類活動負責。
培訓過程中我們常展示一張“敏捷生態圖”（見圖4），它包含了敏捷常見的一些實踐。生態圖大致按三圈（即個人、團隊、組織）來繪制。個人實踐主要還是面向開發人員，吸取了XP的精華。團隊和組織實踐結合了不少Scrum的實踐，并且強調了客戶及統一團隊的重要性。
敏捷激活第二步:
讓大家相信敏捷
支持是建立在了解的基礎上的。怎樣讓組織的成員相信敏捷的應用能夠幫助大家提高工作效率、保證工作質量是這個階段的重點。比較成熟的實踐是由一個較為資深的敏捷組織和準備實施敏捷的組織共同組建一個項目團隊，并且拿出一個試點的項目由這個聯合團隊開發。聯合團隊將采用結對的工作方式，即每個團隊角色都由資深敏捷組織出人與新實施敏捷組織中同職能人員一起工作。試點項目一般要求是一個全新或相對獨立的系統以避免遺留系統帶來的技術難題分散了我們實施敏捷的主題。試點項目的選取一般會有兩種形式: 假想一個相關系統或一個真實的項目系統。
使用假想的系統好處是可以方便地隔離很多外部干擾，比如對其他沒有實施敏捷團隊的依賴。缺點是真實性不足，不是很容易讓人員全身心投入，而且不能充分暴露出真實開發過程中可能出現的問題。另一方面，采用真實項目團隊很可能要承受交付壓力，對一個在學習敏捷實施的團隊，壓力會產生很多負面作用。
聯合團隊開發過程中我們一般會采用各種物理手段來增加項目的可視性。這里最值得一提的是故事墻（在一面墻上以一些小紙條展示各個部分的進度及相關問題）。通過使用故事墻，我們可以很好地達到統一團隊的目的。人員的日常工作通過故事墻展現出來，項目管理者及客戶可以通過故事墻來了解一個團隊的進度及表現。圍繞故事墻，還可以使用各種輔助圖表來跟蹤整個項目、一個迭代或一個功能的進度并快速發現可能的問題。
敏捷激活第三步:
讓大家用敏捷思考
通過試點項目，整個團隊應該對敏捷開發過程有了實際的理解。這個時候需要用敏捷思想來總結項目中的各個環節，找出適合組織、團隊的敏捷實踐。這個階段大家往往會希望回顧一下試點項目是否是成功的。這時一個不可避免的問題就是怎樣來衡量成功呢？
本文開始我們探討價值時對比了兩個項目，那么試點項目的價值是什么？項目按時、高質量交付固然是有價值的，然而，更重要的應該是試點的目的: 我們希望通過實際操作來找到適合組織、團隊的開發方式，我們希望學會用敏捷的方式來思考和判斷問題。一般在提高軟件質量和提高團隊凝聚力上，大家都能達成共識。但常見的結論中也有敏捷開發方法加大了工作量，開發中的結對編程增加了人力成本，或是拖長了開發周期等。這些結論的得出很大程度上忘記了我們試點的目的。工作量的加大是必然的，因為團隊在學習新的流程、新的方法。結對實際是最有效的學習手段，在2008年全球網上發起的開發人員就測試驅動開發學習方法有效性的投票中，與有經驗的開發者結對學習被選為最有效的學習手段。在我們推行“結對”的過程中，也驚喜地發現不少組織成員已經開始將“結對”靈活使用到日常工作中，比如兩個團隊人員共同的技術問題很快就由雙方的技術人員結對進行了統一解決。因此，衡量試點項目的成功更多的是要從團隊成員能否通過項目實戰學會從用敏捷思想考慮問題入手。
這個階段很多的組織會嘗試推廣敏捷，各個組織的做法更多的是根據自己的實際情況出發。值得一提的是，敏捷的組織應該向一個知識型、自組織型的組織努力。打造這樣的組織我們需要提供多方面的支持，比如，對相關人員，特別是各項目管理者的培訓; 盡量讓項目組能夠集中辦公，增強人員的團隊意識; 成立敏捷學習興趣小組，鼓勵大家互相學習分享經驗等等。
敏捷的項目管理范文3
軟件項目開發通常會遇到這樣的困難：即使寫入了合同，客戶的需求總在變化，尤其是項目后期，使開發一再陷入被動；設計一再修改，跟最初的想法相去萬里；加班加點終于完成可卻不是客戶想要的；歷盡千辛萬苦，軟件最終通過驗收，客戶卻把它束之高閣，根本沒有實際上線運行……
如果你深受這些情形的困擾，而且想走出這些困境，敏捷就是最好的工具。
通過一系列獨立而又相互聯系的實踐，敏捷可改善代碼質量，提高軟件交付的成功率。然而敏捷并非“拿來就用，用之就行”的萬能工具。對敏捷的錯誤認識、不正確的實施方法，都會造成實施的失敗。
面對敏捷，應該持一種什么樣的心態?你覺得這是領導向你壓下來的任務，你不過是完成任務而已?或者你認為敏捷只不過是另外一種形式的CMMI?抱有這種敷衍了事、甚至反對的心態，敏捷成功的可能性很低。
敏捷，讓我們起步
你可能對敏捷的基礎知識有所了解。不過在實施前，還有一些問題你可能會遇到。錯誤的選擇，會使你遇到更大的阻力，帶來高風險。
自上而下還是自下而上?顧名思義，自上而下指的是由公司高層發起，逐步向下推進實施敏捷的過程。因為能夠得到公司高層各種資源的支持，你對團隊所做的各種改革遇到的阻力會較小，成功的幾率也較高。
而自下而上是指由員工發起，再逐漸影響上層實施敏捷的一種方法。這種方法只能從一些小的實踐開始，收到良好的效果之后，再逐漸說服上級實施更廣范圍的敏捷。我們強烈建議您采用自上而下的方法，所以，先說服你的領導吧。
小團隊開始還是大團隊開始?初次實施敏捷，我們建議從小團隊開始。因為小團隊的交流更簡單，更容易在許多問題上取得一致。而且敏捷中的許多實踐，都曾經強調了自己合適于小型團隊。所以首先在小團隊嘗試敏捷，讓每個人都熟悉了敏捷實踐，讓每個敏捷實踐都成為習慣之后，再考慮大型團隊、甚至分布式團隊的敏捷實施。大型團隊和分布式團隊的敏捷，會遇到跨小組交流不便、時差問題、甚至語言不同等多個問題，這也是敏捷領域研究的活躍課題。
全面還是逐步改進?你可能很想立即把所有的敏捷實踐用到團隊中去，但一旦這么做，你會不斷受到團隊成員的質疑，為什么要這樣呢?或有人直接反對：原來的方法已經很好了，為什么非要推倒重來呢?這給敏捷實施帶來了很大的阻力。
敏捷強調自己是一種適應性的方法，你可以根據自己團隊的實際情況，找出哪些方面的問題最嚴重，使用敏捷的方式替代。收到一定效果之后，再逐步采取其它的實踐。這種逐漸改善、小步前進的方式，更容易受到團隊成員的支持。
我們需要培訓嗎?關于培訓，有兩種截然不同的觀點，一些人認為培訓搞定一切。比如參加Scrum認證，通過2天的培訓，拿到ScrumMaster證書，我們就可以敏捷了。這是部分初學者的誤區，源于對敏捷的認識太少。事實上，敏捷社區對于Scrum認證也多有詬病。正確的實施來自于不斷的實踐。
另外一種觀點認為培訓毫無作用。其實這種觀點也不正確。根據經驗，一個新人加入到敏捷團隊，在很短的時間內就可以適應敏捷的方法；而對敏捷一無所知的團隊，實施敏捷困難最大。有了一定的實踐經驗，難免會遇到種種困難和疑惑，帶著這些疑惑參加相關的培訓，或在團隊中引入經驗豐富的敏捷實施專家，效果非常顯著。
敏捷，在路上
你的團隊已經開始實施敏捷，已經在采用每日站立會議、回顧會議這樣的敏捷實踐，也把需求劃分解成用戶故事，根據故事的業務價值迭代開發，但這其中仍然充滿了種種陷阱，及時發現這些陷阱可以避免許多不必要的損失。
不要讓敏捷實踐成為形式。拿每日站立會議來說，這是一個簡單易學的敏捷實踐。但曾有人提出，我們的團隊每天早晨開站立會議，但不久大家感覺無聊且煩人，因為成了每天向PM報告工作的例行公事，這種形式為上的實踐，還需要嗎?
每日站立會議的主要目的是使每個人知曉項目的最新進展，分享已有的成就，提出自己遇到的困難以尋求解決。如果覺得形式重復無聊，可以想一些點子使每日站立會議更有趣味。曾有一個團隊是這樣做的：不要講那些重復、無趣的話題，如果有人覺得內容無聊，可以隨時舉手。超過3個人舉手，發言者必須轉換話題或干脆取消發言。其實敏捷有個重要的實踐，回顧會議。大家可以在回顧會議上把這個問題提出來，沒準能找到更好的解決辦法。
依賴整個團隊而不是一兩個關鍵人。在估計用戶故事點數時，找一兩個技術骨干估計就行了嗎?或者有些問題需要決定，PM或者團隊負責人直接拍板?敏捷強調發揮每個人的主觀能動性。估計用戶故事點數時，讓所有開發人員參加。一些需要決策的問題，也讓團隊成員一塊參與。這些看似不起眼的地方，能讓團隊成員感覺到自己參與其中而不是被置之不理，并逐漸形成正向的激勵，能進一步激發每個團隊成員更大的潛能。
Scrum和極限編程并重。Serum是最近敏捷社區討論的熱點，很多團隊使用敏捷時就是在使用Serum。造成這種問題的原因在于Scrum是項目管理相關的，很容易被負責人接受，而極限編程相關的實踐是與編程相關的實踐，容易遭到忽視。
極限編程的實踐如結對編程、測試驅動開發、持續集成等，可以大大提高代碼質量，減少項目集成的風險?？紤]到Scrum支持迭代開發，不同迭代逐漸增加功能，同時敏捷擁抱變化，功能變化務必會修改代碼。如果沒有自動化的測試做保障，難免會對已有的功能造成影響。所以極限編程是敏捷實踐中必不可少的部分。
如何堅持測試驅動開發等比較難的實踐?與每日站立會議相比，測試驅動開發這樣的實踐并不是很好堅持，很多團隊實行了一段時間就放棄了。
根據調查，造成難以堅持的原因有不少：沒人指導，靠自己摸索比較困難；即使有了相關培訓，培訓的例子與實際應用差別很大，項目進度有壓力，必須抓緊時間寫代碼……面對這樣的困難，測試驅動開發仍然需要堅持?？梢詮钠渌鼒F隊找一些經驗豐富的人指導，團隊內部也必須不斷提醒堅持。
充分發揮BA和客戶的作用。與傳統軟件開發的瀑布模型相比，BA或客戶不再是寫完需求說明書就萬事大吉，開發人員也不是只拿需求說明書照本宣科。
BA或客戶應該與開發人員時刻保持聯系：開發人員從backlog中拿到一個新的故事時，先閱讀故事描述和驗收條件，最好能讓BA或者客戶進行講解。因為BA或客戶對項目的整體理解更為深刻，開發人員一旦理解有所偏差，可以立即發現。
用戶故事開發完成，要先讓BA或客戶現場驗收。現場驗收，不需專門部署驗收環境，也不需準備復雜的測試用例，可以就在開發現場簡單快速的進行。一旦發現沒有完成的驗收條件，開發人員立即修改。這種驗收的時間很短，一般5到15分鐘之內就能解決。把它與QA的測試結合起來，具有良好的效果。
另外每個sprint迭代周期結束后要向用戶演示，現場聽取客戶最直接的意見，看做出來的軟件是否他們真正需要的，及哪些需要做出修改。此時的反饋可以盡早發現問題，避免你在岔路上越走越遠。
敏捷，我們成功了嗎
你已經使用敏捷開發了―個項目，怎樣判斷是否成功了?除了軟件成功交付這樣的指標，還有什么其它條件嗎?你需要看你的團隊是否成長為了一個成功的敏捷團隊。
一個成功的敏捷團隊，是一個可持續發展的有自管理能力的團隊，具有很高的項目交付能力。
敏捷的項目管理范文4
從上世紀50年代軟件出現開始至今，軟件開發方法先后經歷了無規則的編碼和測試、結構化方法、面向對象的方法、能力成熟度模型CMM和輕量級開發方法等各個階段?？v觀軟件開發的發展史，軟件開發方法的演變是有規律可循的，遵循著一條從“計劃和預測”到“反饋和適應”的歷程。造成這一演變過程的原因如下：
1）軟件使用者的主體從大型尖端領域逐漸向廣泛的企業應用領域轉變；
2）人們對軟件系統需求的認識提高；
3）市場經濟的發展，以及市場需求的頻繁變化；
4）面向對象技術的應用和普及。
而今，企業面對的是快速變化的市場，在這樣的市場環境下，收集用戶完整的、穩定不變的系統需求是不可能的。面對無法預知和不斷變化的需求，傳統的軟件開發流程明顯已無法適應，而敏捷過程將程序代碼和系統需求緊密的聯系在一起，將系統需求視作流動和變化的需求的思想，則正符合現今軟件開發的現狀。
1 敏捷開發的興起
敏捷方法誕生于2001年，由J.Highsmith和R.C.Martin發起，由一批業界專家參與成立了敏捷聯盟，并概括出了一系列讓軟件開發團隊具有快速工作、相應變化能力的價值觀和原則。
在敏捷聯盟的官方網站上，可看到敏捷宣言的完整內容：
1）個人與溝通勝過過程與工具；
2）可工作的軟件勝過面面俱到的文檔；
3）客戶協作勝過合同談判；
4）相應變化勝過遵循計劃。
具體來說，傳統的順序開發模型（瀑布模型、V模型、W模型）的一個重要的特點就是所有的活動都是有順序的。順序開發模型成功使用的一個前提是軟件系統具備完善和明確的需求。如果在項目開始階段無法進行完善的需求分析和設計，則順序開發模型就很難被成功的使用。為了解決順序模型的不足，出現了增量迭代模型。從本質上說，敏捷開發就是一種迭代的增量的開發模型。這種模型的優點如下：能很好的適應需求的變化；早期的迭代可以降低風險；集成是持續的而不是在項目后期進行的“大動作”；在每次迭代中發現和更正缺陷并能不斷反饋并改進開發過程[1]。
如果要用一句話來描述敏捷開發，那么敏捷開發應該是：以人為本、輕載、基于時間、just Enough、并行并基于構件的迭代和增量的軟件開發過程。
2 敏捷開發的原則
敏捷聯盟成立后，又陸續形成了敏捷的十二項原則（本文不在詳細展開，詳細描述見敏捷聯盟官方網站），其主旨思想大體如下：敏捷開發中需求是逐漸展開的，在項目初期不提倡過渡的需求分析，對需求變化的響應是動態的；敏捷項目應該分成從幾周到幾個月間隔的迭代周期，每一個迭代周期盡量產出潛在可交付的軟件產品，用戶的反饋作為下次迭代的基礎；可工作的軟件是衡量項目進展的主要依據；敏捷開發整個過程是持續的，帶有反饋的和自我完善的輕量級的過程。
基于敏捷指導思想，形成了不少敏捷軟件開發方法(例如XP、scrum等)，它們大都強調適應性而非預測性、強調以人為中心，而不以流程為中心，以及對變化的適應和對人性的關注。以XP（extreme programming）方法為例，它消除了大多數重量型過程的不必要產物，建立了一個漸進型開發過程。該方法將開發階段的4個活動（分析、設計、編碼和測試）混合在一起，在全過程中采用迭代增量開發、反饋修正和反復測試。并且它作為一種面向客戶的開發模型，開發過程中對需求改變的適應能力較高，即使在開發的后期，也可較高程度地適應用戶的改變。XP開發模型與傳統模型最大的不同是其核心思想是交流（Communication）、簡單（Simplicity）、反饋（Feedback）和進取（Aggressiveness）[2]。這種開發模型的主要優點如下：
1）采用簡單計劃策略，不需要長期計劃和復雜模型，開發周期短；
2）在全過程采用迭代增量開發、反饋修正和反復測試的方法，軟件質量有保證；
3）能夠適應用戶經常變化的需求，提供用戶滿意的高質量軟件。
縱觀所有敏捷開發方法，其基本都具備輕載、基于時間、Just Enough、并行并基于構件的迭代和增量的特點，而且具有類似的敏捷項目交付模型。
3 敏捷項目交付模型
敏捷項目交付模型是一種敏捷軟件項目管理的生命周期模型，它是基于敏捷開發迭代和增量特點的過程模型[3]。該模型把敏捷軟件項目的生命周期大體可分成項目規劃、項目啟動、迭代開發與三個階段。各個階段分別介紹如下：
1）項目規劃階段
敏捷開發中的項目規劃階段類似于傳統開發過程中的項目可行性分析和早期的需求收集階段，該階段的主要工作如下：
（1）就要開發系統的戰略目標、業務愿景和初始項目需求等與關鍵涉眾達成共識；
（2）根據收集到的資料，設計與決策系統開發的關鍵技術架構問題；
（3）評估項目的工作量與成本，輔助客戶決策項目的可行性；
（4）進行項目的初始計劃制定。
2）項目啟動階段
該階段是一過度階段，處于項目規劃后正式開發前，主要工作是為項目開啟準備各種所需資源，包括開發場地布置、軟硬件環境的準備和項目團隊的組建等。另外，通常為了使此后的迭代開發階段能夠順利進行，還有為第一次迭代進行詳細的需求分析工作。
3）迭代開發與階段
該階段是敏捷項目交付模型的核心部分，基本上所有的開發工作都在該階段展開與實現。在迭代開發與階段，項目組會根據目標系統的正式版本將該階段分解成多個重復的過程，并且每次過程基本上都是一次目標系統的增量在開發環境中實現，并從開發環境到生產環境的遷移。每次迭代開發與又可細分為迭代開發、用戶驗收測試（UAT）和三個小階段。各階段的介紹如下：
（1）迭代開發是一個有固定時間周期的、在開發和測試環境上完成系統增量的過程，增量流程大體由需求分析活動、設計實現活動、集成測試活動、客戶測試活動組成。每次迭代都會產生潛在可交付的產品；
（2）多次迭代開發對應一次，多次迭代后每次前，會根據項目需要進行用戶驗收測試。目標是讓客戶代表從系統最終運營的角度測試系統行為，另外，該階段也可作為項目團隊完成目標的緩沖區；
（3） 過程在敏捷開發中有里程碑的作用，其業務意義大于技術意義。使用敏捷軟件交付模型，第一次會在較早的時間發生，這對于提升客戶投資收益，根據市場反饋調整項目走向都有幫助。
4 敏捷開發中的測試
對于敏捷的理解，一般認為最為關鍵的是需要注意兩個方面，即“高速迭代”和“持續不斷的客戶反饋”[4]。而要達到這樣的要求，傳統的注重流程的規范，文檔的齊備，走完整的bug處理流程的測試過程，明顯已不符合敏捷的初衷。
那么敏捷開發中測試有何特點？，簡要來說，如下所述：
首先，就測試的階段來說，敏捷開發中的測試貫穿于整個軟件開發生命周期中（傳統軟件開發模型中，測試只是作為編碼后的一個獨立階段出現）。其次，敏捷開發是迭代和增量的過程，這就意味著測試人員在每個代碼增量完成時，都要測試它，測試工作也是迭代的展開，并且時間更緊，壓力更大。開發和測試是并行進行的，程序員從來不超前于測試人員（在傳統軟件開發模型中，編碼和測試過程是串行的，先編碼后測試）。再次，敏捷開發中，測試人員需要緊密的與客戶合作來定義每一個需求的接收標準；而且測試過程還可以向項目組隨時反饋開發中遇到的問題。而不像傳統測試中，測試由詳細的需求驅動，并且發生在編碼之后。最后，敏捷測試中，提倡持續集成和構建，集成的頻率較高，并且可為開發提供持續的反饋。
5 結論
其實，不管正在使用的是哪種開發模式，都會經歷幾乎同樣的軟件開發生命周期元素。敏捷的不同之處在于時間段明顯變短，而且活動同步進行。因此，參與者、測試和工具都需要適應這一變化。同時，也應該看到沒有哪種開發模式可以放之四海而皆準，只有不斷的被實踐和驗證才能持續完善[5]。目前，敏捷還在不斷發展，更多的項目在實踐敏捷，應用的普及和成功的案例正在不斷擴大。
參考文獻
[1]鄭文強，馬均飛.軟件測試管理[M].電子工業出版社，2010.
[2]張友生，李雄.常用軟件開發模型比較分析.中國系統分析員，2005(1).
[3]桑大勇，王英，吳麗華.敏捷軟件開發方法與實踐[M].西安：西安電子科技大學出版社，2010，5.
敏捷的項目管理范文5
關鍵詞 跨國企業 采購 多項目管理
中圖分類號：F275 文獻標識碼：A
隨著全球經濟一體化之風日盛，其中一種應運而生的商業活動就是“全球采購”。 全球采購是指利用全球的資源，在全世界范圍內去尋找供應商，尋找質量最好，價格合理的產品（貨物與服務）。自從亞當?斯密發現分工能夠提升工作效率之后，產業組織內的企業一直在不斷擴展著分工的范圍，但是長期以來，分工都是在一個國家的內部進行的，直到經濟發展出現全球化的趨勢，跨國企業才紛紛制定了全球發展戰略，也正是在這種戰略的指導之下，成功實現跨國范圍的產業分工，并且由于具備了先發優勢，跨國公司已經成為當前全球產業分工價值鏈的核心，通過這些跨國巨頭，成功的將散布在世界各地的企業聯系起來，并最終為一種產品生產各個所需的零配件，并隨著分工的不斷細化，已經形成了圍繞跨 國公司的高速運轉的企業網絡。也正是因為這種趨勢的不斷深化，跨國公司之間的競爭也由單體之間轉變為企業網絡和供應鏈的競爭。
一、跨國企業采購中的特點
隨著經濟全球化的發展，跨國公司紛紛制定了全球發展戰略。在這樣的競爭方式轉變的背景下，跨國公司才愈發的有動力去整和全球范圍的優質資源，積極構建范圍更廣、成本更低的采購環節就是其中重要的一個組成部分，從某種程度上來說，跨國企業的全球采購策略成功與否直接影響著其競爭優勢的得失。采購活動作為生產的第一道環節，是大多數企業成本中比例最高的部分，原材料的好壞及價格高低直接決定了企業最終品的市場競爭力，因此，如今的跨國公司都將采購供應鏈的全球化整合作為非常重要的戰略組成 。
二、在跨國企業采購中多項目管理手段的應用
關于跨國企業采購中的多項目管理手段應用，國內學者的研究也主要集中在項目組合管理和項目群管理，但還不夠深入細致，尚未完全形成體系。黃有亮等認為，多項目管理的重要工作是如何有效協調多項目之間的沖突、優化調配多項目間的資源，并指出多項目管理需要建立管理信息系統，有效加強多項目參建主體之間的信息傳遞、共享，避免項目之間、部門之間信息孤立，提高多項目組合的價值。白思從多項目管理的概念、特點等方面系統地介紹了多項目管理，并分析了多項目管理的類型。程鐵信對項目組合管理、項目群管理、項目群的形式、項目群的生命周期進行了系統的總結和分析，認為多項目管理的核心是多項目之間利益的均衡、多項目的目標與組織戰略目標的協調、項目之間的資源的優化調配三方面。
跨國企業對于中間投入品的來源可使用內部生產和外部收購的方法。20世紀90年代以來，因貿易與和投資自由化的發展，多數國家市場聯系日益密切，企業間的競爭更為激烈，為了更好的生存和發展，歐美的跨國企業做了大規模的業務調整，將資源集中在業務領域的競爭優勢和聯系上，將一些做的不佳的業務剝離去除。此外，技術的進步，特別是信息技術和通訊網絡等的高度發展，大大降低了交易成本。最終，業務外包與資源外取的優勢更加突出，成為跨國公司生產策略改變的重要趨勢。目前一些跨國企業已不做最基本的生產活動，而是專注在新品的研發、設計與銷售上。
隨著全球采購這一大趨勢的推進，一些跨國企業開始尋找新的管理模式，即當地化策略。這種策略也是全球化采購的一部分，是跨國企業隨著目前的總體趨勢做出的選擇，這是一種權衡多方利弊后的選擇。因為即使不存在貿易障礙，本土化采購仍然具優勢。在上述行業，產品的生命周期短，呈現出多元化的市場環境，消費者對產品的個性化需求的追求，要求生產過程不僅要有高度的靈敏性和調節性，還需要有敏捷的供貨體系，對訂貨到最終交貨的時間、生產商與供應商的距離也同樣有很高要求。具有高效率的采購供貨體系是美國Dell公司成功的關鍵因素，它們根據客戶的需求向供應商下訂單，對供應商的供貨時間有更細化的要求，有些是一兩天以內，更有甚者為幾個小時，這種情況下供應商必須要調整相關產品的生產情況才能滿足這一變化?？鐕髽I的業務重組與采購策略的優化，為國內公司提供了更多參與國際分工的契機，國內企業將會有更多的機會與跨國企業進行合作，這種合作主要是以成為中間投入品的全球供應商的形式出現；但隨著國內貿易保護的取消，跨國企業會重新選擇，選擇的條件主要是看價格是否合理、技術是否先進以及產品的質量是不是過硬，只有以上條件都滿足的才會入選。這種篩選是對國內企業配套能力的一次嚴格檢閱。行業因素、產品的特點、東道國經營環境條件以及政策因素等多個方面會影響跨國企業在華的采購策略。這其中行業因素主要指市場結構、中間投入品的貿易性等，而產品的特點則指所需投入品的重要性和標準化程度等。在此我們需要重視當地的配套能力，是否能夠提供符合要求、質優的零部件或中間服務至關重要，如果國內供應商在交貨期和產品質量方面存在瑕疵，或國內供應商的零部件產品達不到跨國企業的采購標準，那么即使市場競爭性大的跨國企業也會繞道選擇國外同類產品。
（作者：蘇州大學東吳商學院工商管理專業2011春季班，戰略采購方向）
參考文獻：
[1]王長峰，林則夫，馬蒙蒙.現代項目管理前沿[M].北京：機械工業出版社，2008：23-25.
敏捷的項目管理范文6
多元化教材
任課教師除了《軟件工程》以外，選用《UML基礎、案例與應用》和《輕松SCRUM之旅》為教輔材料，《UML基礎、案例與應用》系統的講授了UML基本知識和應用技術，培養學生軟件開發和設計建模的能力?！遁p松SCRUM之旅》將復雜的項目知識寫成有趣的故事，可讀性強，能吸引學生興趣，作為課外讀物，能夠加深學生對于敏捷的思想、Scrum的概念和Scrum的實施方法的理解。教學內容整合了UML建模語言，SCRUM敏捷軟件開發工程，EA建模工具的使用，Project軟件工具的使用等，豐富了教學內容，加深了教學的深度，突出了實踐的重要性。
面向對象案例教學
課程采用案例式、討論式、團隊式的授課方法。教學案例以面形對象為主。團隊合作，教師層面負責相關的決策、技術方案的決定；在實驗環節以教學團隊為中心，按照企業的實際開發環境和要求開設實驗課。用SCRUM理論為指導，熟練使用軟件建模工具EA，以團隊協作的方式進行軟件項目開發和管理。案例式：課程開始之前：由教學團隊收集、編寫案例，包括軟件項目中若干成功和失敗的案例、以及軟件項目過程中的若干實際的項目文檔，建立課程的資產庫。討論式：課程教學過程中：由任課老師提供給學生，在學生中以頭腦風暴、群體創新和群體決策等技術方式進行案例的討論和分析。團隊式：教師層面，以課程負責人為中心，教研室其他專業能力強的老師和企業資深項目管理人員作為該課程的專家小組，是該課程教學的人力資源庫，負責相關的決策、技術方案的決定；學生層面：根據學生的專業能力，成立若干能力相當的團隊。所有的案例討論、項目活動以團隊為單位執行和績效。傳統團隊中成員往往分為項目經理，程序員，測試員等角色，在實踐中，我們發現這種分組方式下，學生往往會繞開自己的弱點選擇角色，達不到課程的目的，同時軟件工程的實驗課時為16個學時，只適合一些輕量級項目的開發，因此，目前團隊采用SCRUM的方式進行。教師作為產品負責人ProductOwner：負責維護產品訂單。每組學生作為一個Team選出一人作為ScrumMaster。一個沖刺Sprint通常在2周左右，開發團隊會在此期間內完成所承諾的一組訂單項的開發。在項目的進行中，每日站會，任務看板，計劃撲克牌等都引起了學生的極大興趣，使得軟件工程不再停留在書本上，而是內化在真實的項目中。
結構化考核方式
在課程的考核過程中，結合課程理論與實踐的特性，制定詳細的課程教學和考核里程碑計劃，在各里程碑以不同考核形式進行驗收。不同里程碑根據課程內容性質采用不同的考核形式，采用理論研究、技術運用、實踐應用、論文寫作四種形式對學生進行考核?？己擞媱潱?.理論研究部分：通過案例材料分析，提交ppt和相關材料。2.技術應用部分：通過期末閉卷考試，對核心的技術和工具進行筆試考核。3.實踐應用部分：通過三性實驗的驗收進行考核。成績積分計劃：總成績=平時績效積分+理論研究積分+技術應用積分+實踐應用積分說明：1.平時績效積分（30分）：出勤抽樣10次、每次1分；實驗抽樣驗收5次，每次2分。分數從第一周至第十二周累計產生。2.理論研究積分（20分）：根據任課教師提供的SCRUN材料，撰寫ppt。3.技術應用積分（40分）：對課程的主要工具和技術進行卷面考核，即期末考試。分數在期末考試結束后一周之內產生。4.實踐應用積分（10分）：對課程第二個實驗“需求分析”，即綜合實驗以三性實驗驗收標準進行考核，評估學生建模工具實際應用的能力。分數在課程結束之后兩周之內產生。
成果
