敏捷開發在大型軟件項目管理中的應用探討一、敏捷開發概述Scrum是一種迭代式增量軟件開發過程，通常用于敏捷軟件開發。Scrum在英語的意思是橄欖球里的爭球。雖然Scrum是為管理軟件開發項目而開發的，它同樣可以用于運行軟件維護團隊，或者作為計劃管理方法。Scrum是迭代的、增量型的流程，其流程如REF_Ref5808\h1所示。Scrum構造的產品迭代周期為Sprints,工作的迭代時間一般為一到四周，并且是相互銜接的。Sprints是有固定的周期，結束于固定明確的日期，無論該工作完成與否，從不延長。在每一Sprint的起始階段，一個多職能的團隊從已優先化的要求列表（下文中稱ProductBacklog）中挑選若干項目，并承諾在Sprint的末期完成這些項目。在Sprint中，任務的內容不會變化。每一工作日，團隊成員互相通告工作進度，并更新簡易的剩余工作量直觀表示圖表。在Sprint的末期，團隊將對這一階段工作結果作一展示并取得相關的反饋，為下一Sprint做好準備。Scrum強調生產可以使用的產品，意指在Sprint的末期產品的“完成”；在軟件方面，是指編碼已經被檢測并可以隨時交付使用。圖SEQ圖\*ARABIC1Scrum周期圖在Scrum中有三個基本的角色：產品所有者(ProductOwner)，開發團隊和ScrumMaster。1.產品所有者（ProductOwner）產品所有者（ProductOwner）負責取得產品最大的商業價值，收集相關于產品的所有信息。從客戶或產品的終端使用者，開發團隊成員和項目管理者中獲取并將信息轉化為優先權項目列表。在一些情況下，產品所有者(ProductOwner)正是客戶本人；在另一些情況下，客戶可能是有不同需求的成百上千的人。產品所有者(ProductOwner)這一角色在許多企業中是由產品經理或產品市場經理擔任。2.開發團隊開發團隊構建客戶將會購買的產品：比如報表或軟件。Scrum團隊是“多功能”的。它包括交付每一Sprint中的隨2.團隊的構建關于團隊的規模，傳統Scrum一直認為5-9人是一個最佳范圍，團隊過小，管理成本會過高，團隊過大，則不利于團隊的溝通，降低團隊工作效率。在40人團隊規模下如果要繼續有效的使用Scrum方法，唯一的辦法就是分拆團隊，采用ScrumofScrum的方法。相對來說，拆分團隊并不難，當團隊擴大以后，自然就形成了一個分割，人數控制在5-10人左右，在這個組內再任命一名技術、管理能力均衡的成員作為這個小組的ScrumMaster管理所在的子團隊，同時聽命于項目經理。但是，在拆分團隊過程中，也要注意一些問題。（1）跨智能團隊最容易發生的問題是按照工作職能劃分子團隊，如：用戶界面程序員一組，中間層程序員一組，數據庫員一組，這樣的架構其效率很低。應當淡化團隊分工，按照業務功能形成跨職能團隊。這樣，團隊里面的人仍然干差不多相同的活，但是現在能夠關注整個功能，而不是某一層上功能的一部分，雖然會引起團隊間一些集成的問題，但是會使端到端的功能實現得更快。（2）團隊技術共享由于采用迭代開發，團隊遵守自然設計（emergentdesign）的原則。這意味著團隊編寫高質量的代碼，但是只有必要的時候才會增加功能或者設計結構。團隊A可能寫了一個加密模塊，因為只有一個地方在用，他們就沒有使用接口。團隊B可能后來也需要一個加密模塊，但與團隊A的稍微不同。這是，最好的辦法是讓團隊A修改代碼，使用接口這是就需要為團隊A賦予新的任務，即對加密模塊的開發與維護任務，并對團隊B進行支持。這時這個加密模塊的需求，就應該由產品負責人加入到非功能需求中，同時，團隊A的ScrumMaster也要負責這個需求的協調與溝通。（3）拆出一個只關注架構的團隊大型軟件項目通常都是整個應用系統中一部分，需要和已有的IT基礎架構無縫掛接。雖然產品負責人對核心功能需求非常熟悉，但是在安全、日志、可用性、性能等方面就所知甚少了。要從用戶的組織中了解這些需求難度很大，因為這得跟不同部門中的許多人溝通討論。這種調查工作給Scrum的迭代節奏拖了后腿。為了解決這個問題，可以創建一個只關注架構方面的內容的獨立團隊。他們的工作就是弄清楚非功能性需求，并把它