LeSS 小型框架 vs 巨型框架 (Basic vs Huge)

Scrum: 大型企業規模化(LeSS框架

LeSS框架是scrum的放大版本,可幫助產品團隊在大規模環境中實施Scrum。LeSS適用於在單個產品上一起工作的多個Scrum團隊。LeSS提供了實驗,指南,框架,原理和要素,以通過案例研究或從早期實施或不同環境中汲取的經驗教訓來幫助團隊實施LeSS框架。它支持多團隊以及(Mulit-Site)多站點敏捷開發。

符合Scrum慣例的LeSS框架提倡使用由單個產品負責人 (Product Owner) 維護的單個產品待辦事項列表 (Backlog),常見的完成定義(DOD)以及導致單個產品增加的同步迭代 (synchronized iterations)。產品負責人提供了優先的待辦事項,並將其分發給跨職能 (Cross-functional) 的Scrum團隊

LeSS通過將整個思維方式從如何執行流程轉移(how to perform) 到爲什麼必須執行 (why the process must be performed) 流程,從而以簡單的經驗方法 (empiracal way) 來解決產品開發問題,從而幫助消除組織的複雜性,專注於意圖 (intent) 而非單純的實踐 (practices)。它有助於實現所完成工作的價值,從而消除了傳統方法中遵循的大多數不需要的過程和方法。該框架還自覺地避免引入其他角色,人工製品和文檔,以避免複雜性,例如流程的數量,團隊傾向於在開發中失去人類的觸覺,這與敏捷的基本原理大相徑庭。當流程輕鬆進行時,團隊將能夠專注於與所有利益相關者的互動和協作,從而實現有效的,基於價值的交付。

LeSS-框架

LeSS提倡兩種類型的敏捷擴展:

  • LeSS Basic:

     最多支持8個團隊(每個團隊八個成員)。最適合於每個團隊的規模爲8到10,且總共有8個或更少團隊的並置團隊。
  • LeSS Huge: 

    支持多達數千個人爲單個產品做出貢獻。它支持同一地點和多地點或多站點團隊,但是建議每個Scrum團隊都位於同一地點。

 

LeSS Basic

當產品的複雜性最小且涉及兩到八個Scrum團隊時,將使用LeSS Small Framework。除Scrum團隊外,LeSS團隊還包括一個負責所有Scrum團隊的產品負責人和一個負責多達三個團隊的Scrum Master。這些團隊是跨職能的,在共享的代碼環境中致力於創建完成的項目。產品負責人維護單個產品待辦事項,並將優先處理的項目級聯到Scrum團隊,

LeSS Huge

當Scrum團隊超過8個時,將採用LeSS Huge。本質上是將多個LeSS框架堆疊在一起。由於總體輸出是單個產品,因此LeSS Huge還提倡單個產品積壓,相同的衝刺持續時間以及所有團隊致力於單個交付。

單個產品待辦事項與各個區域產品負責人分爲多個需求區域。需求區域是以客戶爲中心的類別。區域產品負責人又是各自需求領域的主題專家。區域產品負責人由產品負責人小組組成,將共同負責優先級劃分,儘管範圍和時間表仍將僅由產品負責人決定。產品負責人將功能分爲特定需求區域,如區域積壓,

LeSS中的事件

衝刺計劃 (Sprint Planning):

在LeSS中,Sprint計劃分爲兩個級別。Sprint計劃一集中在Sprint中需要完成哪些項目,而Sprint計劃二則在Scrum團隊級別上進行,並着重於這些選定項目的交付方式。

  • Sprint Planning - Part I(所有團隊共同使用)- 

    在Sprint開始之初,所有團隊的所有成員都參加了Sprint Planning One。但是,隨着sprint的成熟和對團隊的瞭解的提高,只有每個團隊的代表都可以參加Sprint Planning One活動。產品負責人和團隊或每個團隊的代表參加了這次會議,他們從產品積壓中選擇了將要用於下一個衝刺的項目。
  • Sprint計劃 - Part II(每個團隊分別完成)- 

    在團隊(從Sprint計劃一)選擇項目之後,團隊將舉行自己的Sprint計劃二會議。當團隊之間存在強烈的相互依存關係時,這些團隊將執行合併的Sprint計劃二,以識別相互依存關係並弄清楚如何有效地處理它們。在會議結束時,團隊將更加清晰地瞭解每個團隊在該衝刺中要完成的工作,並且每個團隊都將朝着各自的衝刺進行工作。

 

產品待辦事項列表細化 (Product Backlog Refinement):

通常,團隊不遲於Sprint的中間,團隊需要開始爲下一個Sprint計劃項目。這將涉及:

  • 拆分項目 (Splitting Items)

    可以分成單個衝刺的較小塊
  • 詳細說明 (Elaborating the Items)

     以及更詳細的要求和驗收標準詳細信息,直到團隊認爲該項目已“完全”準備好爲即將到來的衝刺而挑選
  • 估算工作量 (Estimating the effort)

     最終使完成的商品“完成”所需的商品

 

待辦事項的提煉分爲三個級別:

  • 總體產品待辦事項列表細化- (Overall Backlog Refinement) 

    在這裏,所有團隊的代表以及產品負責人決定下一個衝刺的項目。該活動旨在對沖刺項目達成共識,並使團隊能夠全面瞭解團隊成員之間的依存關係。然後,團隊深入研究項目,並與產品負責人和主題專家一起闡明要求。
  • 團隊級產品待辦事項細化 (team level Product backlog refinement)- 

    在全面瞭解衝刺需求之後,團隊可以考慮他們的特定積壓,並在下一個衝刺中挑選出更多的物品。團隊的所有成員,不僅是代表,都參加了此活動。這也確保了在整個產品積壓細化練習中獲得的理解被級聯給所有成員。積壓的任何更改都將通知產品所有者,例如項目拆分或新的估算。
  • 多團隊產品待辦事項細化 (Multi-team Product Backlog Refinement) - 

    在團隊與其他團隊相互依賴的情況下,LeSS建議進行多團隊產品待辦事項優化會議。在此會議期間,涉及的多個團隊在同一房間(通常是大大廳)中進行精煉。團隊進行“ Just Talk”交流,對他們的依存關係進行排序,並就如何解決這些項目達成共識,而對每個項目的干擾很小或沒有中斷。

 

衝刺回顧 (Sprint Rview):

在LeSS中,Sprint審查是像“ Bazar”或Fair一樣的盛大活動,每個團隊都被分配一個站來展示他們在該Sprint方面的成就。參加者可以訪問他們感興趣的站點。利益相關者總結交易會的意見將有多個融合週期。

衝刺回顧 (Sprint Retrospective):

與Sprint計劃一樣,Sprint回顧展也分爲兩個階段。在sprint結束時,團隊會定期進行Sprint回顧,在該團隊中,回顧過去的sprint的經驗教訓,並檢查以及需要採取哪些措施才能更快,更好地交付。第二次回顧是在單個團隊回顧之後進行的。通常,這是在下一個衝刺開始時進行的,

 

References

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章