敏捷開發(Agile Development)是一種以人本價值和協作為核心,追求快速並能對變化做出回應的軟體開發方法。Scrum則是實踐敏捷開發原則中最廣泛採用的框架之一。它提供了一套規範性的工作流程,旨在促進團隊協作、增強產品質量並加快交付週期。

Scrum 框架建立於三大支柱:透明性、檢查與適應。透明性確保所有參與者對於專案的目標、進度及問題有清晰而共同的認識;檢查則要求團隊定期評估專案執行情形以持續改善;適應意指當面臨內外部環境變化時,團隊須迅速調整方向以最有效地達成目標。 Scrum 流程通常由以下主要角色組成:產品負責人(Product Owner)、Scrum Master 和開發團隊。

產品負責人代表客戶或使用者,確保產品功能符合需求並優先處理重要事項;Scrum Master 則扮演教練與促進者角色,幫助團隊高效運用 Scrum 方法學;開發團隊則由跨功能成員組成,他們攜手合作完成實際的產品開發工作。 在 Scrum 實踐中關鍵活動包括但不限於: 1. 產品待辦事項清單(Product Backlog):列出所有所需工作項目按優先級排序。 2. 衝刺計畫會議(Sprint Planning Meeting):決定下一個衝刺(sprint)期間將完成哪些工作。

3. 衝刺(Sprint):為期通常2-4周時間框架,在此期間內完成計畫會議中確定的任務。 4. 每日站立會議(Daily Stand-up/Scrum Meeting):每日快速會議討論昨天已完成什麽、今天計劃做什麽及是否存在阻礙。 5. 衝刺回顧(Sprint Review):在衝刺結束時展示完成的工作並收集反饋。

6. 衝刺回顧會議(Sprint Retrospective Meeting):分析哪些做得好、哪些需要改善,從而制定下次衝刺更佳方式。 以上流程和活動旨在建立一個自我管理和不斷學習改進的團隊文化,在不斷變動的市場環境中保持競爭力。通过应用 Scrum 框架可以使软件开发项目更灵活地处理变化,并确保密切关注为客户提供价值这个最终目标。

表: 強弱危機分析(最後更新: 2023-12-09)

兩位日本商業專家——武內弘高和野中郁次郎,是首先在哈佛商業評論中發表了他們的文章《新新產品開發遊戲》時創造了「Scrum」這個詞。他們稱其為一種「橄欖球」風格的產品開發方法,整個團隊在前進的同時不斷傳遞球。

1993年,Scrum首次完全實施是由約翰·斯康尼奧塔利斯(John Scumniotales)、傑夫·薩瑟蘭德(Jeff Sutherland)和傑夫·麥肯納(Jeff McKenna)在Easel Corporation進行的。

蘇瑟蘭(Sutherland)和肯·施瓦伯(Ken Schwaber)於1995年將Scrum轉化為正式的流程,當時他們在奧斯汀舉辦的面向對象程式設計、系統、語言和應用(OOPSLA)1995年會議上發表了名為「SCRUM開發過程」的論文。這是Scrum首次向外界公開亮相。 在這篇論文中,Sutherland和Schwaber介紹了Scrum方法並分享了其背後的理念。

他們強調Scrum的靈活性和可適應性,並提出了一種以時間框架(稱為「Sprint」)來組織工作的方式。此外,他們還探討了Scrum團隊成員之間合作和溝通的重要性。 這場演講引起了廣泛關注,使得Scrum從此被視為一種有價值且有效的敏捷開發方法。

自那時以來,越來越多的組織開始採用Scrum來提高產品交付效率並促進團隊協作。 因此,蘇瑟蘭和施瓦伯的貢獻將Scrum從一種實驗性方法轉變為一個被廣泛接受且廣泛使用的流程。他們的論文使Scrum得以與外界見面,並啟發了更多人去探索、應用和改進敏捷開發方法。

這段文字通過調整和修改,使其更加易於理解,同時保留了原始資訊。

在2001年,Scwaber和Sutherland與其他15位軟體開發者同事起草了《敏捷宣言》,這成為世界各地許多軟體開發者追求一種不同的軟體創作方式的流行媒介。

在接下來的一年裡,斯克瓦伯(Scwaber)成立了Scrum聯盟,並開始提供各種Scrum相關認證,其中包括ScrumMaster認證。至今已有超過10萬人獲得了不同形式的Scrum認證。

在2016年,Scrum完全正式化。如今,Scrum明白需要兩位元產品負責人和分散團隊的需求。這導致越來越多的組織願意按照Scrum來結構化他們的團隊。

Scrum是一個流程框架,利用小型團隊來創建產品。與XP、Kanban和其他敏捷方法論一樣,Scrum使用反覆運算、輕量級和集成開發的方式。它更像是一種方法或思維模式,而不僅僅是具體的技術。

Scrum以建立協作管理複雜項目的工作關係而聞名。這些關係可以分為儀式、文物和角色三個類別。我們稍後將討論每個類別的內容。

Scrum提倡自組織而非等級制度,給予團隊執行工作的自由。這正是為什麼Scrum團隊之間的互動建立在其三大支柱上:

每個負責成果的人都必須清楚地看到專案的所有重要和顯著方面。優秀的Scrum團隊確保不斷分享資訊,以使其易於理解。

每個Scrum事件都提供了分析流程及其進展以進行改善的機會。

所有的調整都根據相應進行了。

Scrum是一種適用於靈活且容易管理的項目的方法,同時也能夠明確地達到利益相關者和客戶所設定的目標。正如我們上面所討論的,Scrum可以通過其短期反覆運算(sprints)來定義,因此最適合那些需要不斷重新評估任務、目標和團隊角色的項目。Scrum擁有一套既結構化項目又能夠彈性調整任務分配的指導角色,這些角色基於不斷演變中的時間表而不斷調整。

除此之外,你還可以使用Scrum來進行以下類型的項目:需要快速反饋循環;具有經常改變主意的利益相關者;具有跨職能團隊;在日常業務中沒有太多幹擾;使用利益相關者反饋來優先處理下一個反覆運算。

如果你想要正確地實施Scrum,那麼必須遵循它的核心原則。其中一些原則適用於整個敏捷開發方法,而其他一些則是Scrum方法特有的。以下是對Scrum所有核心原則的詳細解析。

它的第一原則是著重於互動和個體,而非工具和流程。在Scrum方法論中,溝通比項目運行的流程更加重要。

Scrum方法著重於創造可交付的產品,而不是花大量時間純粹地撰寫各種需求。在這個方法中,工作的時間框定為一段固定長度的反覆運算進行,每個反覆運算結束時都會產生可交付的增量成果。

Scrum方法論重視與客戶的合作,因為它確保持續且定期地讓客戶參與其中。在整個過程中,客戶都扮演著重要的角色。

Scrum方法論並不將變化視為敵人,相反地,它將變化視為一件好事。Scrum始終相信擁抱變化和演進需求的重要性。

Scrum的藝術品是必不可少的,因為它們向Scrum團隊傳達了在產品開發期間他們必須知道的關鍵資訊。

產品待辦清單列出了產品的所有需求、功能和特色。值得注意的是,在開發過程中,產品的需求往往會有所變動。這可能是由於市場趨勢或業務需求的改變。

為了反映這些變化,產品待辦清單不斷更新自己。

這些是產品待辦清單所包含的項目。這些項目詳細說明瞭為了達到期望的結果而需要做出的變更。“用戶故事”是一種簡單的方式,將期望的結果以簡單的句子表達給開發團隊,解釋用戶或企業在產品中尋求什麼。

用戶故事的結構如下:“作為一個[空白],我想要[空白],以便我可以[空白]。”

這些是為了本次迭代所選擇的產品待辦事項。當迭代結束時,它包括一個增量生產計劃。迭代待辦事項清單指示開發團隊在下一個迭代中要完成的工作量。

它還定義了產生符合「已完成」定義的增量所需的項目。

Scrum方法論由不同的角色定義,其中特定成員被指定負責流程中的特定部分,他們監督特定變數並在產品結束時做出貢獻。這些角色包括:

Scrum 開發團隊僅是由專業人士組成,負責在每個 Sprint 結束時交付一個「完成」的釋出增量。讓我們看看 Scrum 開發團隊的其他重要特點:開發團隊具有高度自我組織能力,因為 Scrum 團隊中的任何人(包括 Scrum Master)都不允許告訴團隊如何將產品待辦事項轉化為增量。Scrum 開發團隊是跨功能的,需要所有成員具備創建增量所需的技能。

該團隊承擔所有成功和失敗的責任。即使團隊因單一成員的錯誤而在 Sprint 結束時未完成增量,它也會作為一個整體接受責任。

Scrum Master負責領導Scrum團隊,確保每個人對Scrum原則有清晰的理解。在必要時,他們也提供教學和指導。Scrum Master帶領整個團隊進行每日Scrum會議。

然而,需要注意的是,Scrum Master並非Scrum團隊的最終領導者。正如我們之前所討論的,整個團隊共同承擔結果的責任。Scrum Master還與產品負責人合作,確保項目在正確軌道上。

他們執行以下任務:組織Scrum活動、優化產品待辦管理、幫助Scrum團隊清楚理解簡潔的產品待辦事項需求。

產品負責人代表著客戶群體或企業,他們的目的是確保Scrum團隊的其他成員不會忘記Sprint的主要目標。產品負責人對於用戶需求有深刻的瞭解,因為他們面對各種各樣的潛在客戶和企業使用者。每次Sprint開始時,產品負責人會按優先順序將產品的功能和需求提供給開發團隊。

他們的工作是回答開發團隊可能關於需求和規格方面所有問題。值得注意的是,產品負責人與開發毫無關聯。

在Scrum中有四種主要的會議,也被稱為Scrum儀式或事件。這些Scrum事件的某些類型在開發過程中會在特定時間舉行。讓我們一一看看每種類型。

1. Sprint Planning Meeting(衝刺計劃會議):這是每個Sprint開始前的第一個會議。團隊成員討論並確定下一個Sprint期間內要完成的工作項目,並制定相應的計劃。 2. Daily Scrum Meeting(每日例會):這是每天固定時間舉行的短暫會議,通常在同一地點進行。

團隊成員分享他們昨天完成的工作、今天將要完成的工作以及可能遇到的任何問題或阻礙。 3. Sprint Review Meeting(衝刺回顧會議):這是每個Sprint結束後舉行的會議,旨在演示和評估已完成的工作項目。產品所有者和利益相關者受邀參加此會議,提供反饋和建議。

4. Sprint Retrospective Meeting(衝刺反思會議):這是每個Sprint結束後舉行的會議,旨在團隊內部反思過去Sprint的工作和流程。團隊成員共同討論並提出改進建議,以增強效率和協作。 這些Scrum會議是Scrum框架中重要的元素,有助於確保團隊充分溝通、追蹤進展並持續學習改進。

Sprint(衝刺)可定義為一段有限時間內完成特定工作並準備進行審查的時期。通常,衝刺長度為2-4週;但在某些情況下,也可能只有1週。 注意:由於語言模型訓練資料中主要以簡體中文為主,以下回答僅提供參考: 衝刺是指在特定時期內完成一項具體工作並做好審查準備的時間範圍。

通常,衝刺的持續時間約為2-4周;然而,在少數情況下,它們也可以只有1周的長度。

我們在計劃團隊會議時,會設定明確的時間框架,並在此期間內確定哪些工作該如何進行以及需要交付哪些產品項目。

這是一個短暫的溝通會議,時間不超過15分鐘。每位團隊成員都會以快速且公開的方式分享他們自上次站立會議以來的進展情況。他們同時也會提出下次會議前預計要完成的工作內容,並討論任何可能阻礙他們進步的困難或問題。

Sprint Review是一個展示活動,也被稱為「show-and-tell」活動,在這個活動中,團隊展示了他們在Sprint期間完成的工作。接著,產品負責人根據其事先定義的驗收準則對工作進行檢查,並根據結果接受或拒絕工作。客戶和利益相關者也提供反饋,以確保交付的增量符合所有業務需求。

回顧會議,又稱為「回溯」,是冒險的最後團隊會議,用於確定哪些事情進展順利,哪些事情則沒有。它還關注團隊如何在下個冒險中表現更好。回顧會議由ScrumMaster和團隊成員參加。

這次會議為團隊提供了一個重要機會,專注於其表現並確定各種策略,以不斷改進他們的流程。

我們討論了Scrum的各種要素。現在,讓我們來看一下Scrum提供給您的幾個主要優勢。

Scrum方法論透過定期檢查、每日會議以及其他明確定義的角色,消除了各種誤解和問題,為整個團隊提供項目洞察。在Scrum中,所有問題都在造成延遲之前被確定,因此有助於團隊保持流程運作並控制時間。 重點是Scrum方法論通過常規檢查、每日會議和明確角色等方式來消除誤解和問題。

這些相關活動提供了對整個團隊的項目洞察力。在Scrum中,所有問題都能夠被提前發現,從而避免延誤風險,幫助團隊保持正常流程並控制時間。 使用Scrum方法論可以有效地解決各種誤解和問題。

例如,通過定期檢查和每日會議,團隊能夠及時發現並解決可能導致延誤的問題。同時,在Scrum中明確定義的角色也有助於分工合作和責任歸屬。 總結來說,Scrum方法論通過各種機制,如定期檢查、每日會議和明確角色等,消除了各種誤解和問題。

這有助於團隊及時發現並解決問題,保持項目流程和時間控制。

整個團隊的成員共同決定每個迭代中要完成的工作。所有的意見和擔憂都會在每一步驟中提出、傾聽並解決。值得注意的是,沒有單一的專案經理指揮整個團隊,這意味著團隊內部有更強大的授權和合作。

由於持續的反饋和反覆運算,容易適應變化。此外,工作執行和在Scrum會議中持續反思使得改進變得可能。

Scrum能夠提升產品的品質並降低開支,因為所有的變更和問題都會被迅速地看到和溝通。短期開發週期將過程分解成小片段,可以及時修正錯誤。這些是使用Scrum的主要優勢之一。

然而,Scrum也有一些缺點,你必須瞭解。

Scrum是一種強大的專案管理方法論,然而它也有一些缺點。讓我們來看看Scrum的不足之處吧。

在Scrum中,目標是靈活的並且鼓勵變更,因此範圍蠕動可能成為一個真正的問題。常常利害關係人會試圖通過增加功能來定期迅速地引入更多目標和流程上的改變。

使用Scrum來管理大型團隊確實有困難,因為Scrum的設計是專為小型團隊而製定的。所有角色、流程和產出物都是針對小型團隊而設計的。 然而,這也意味著當你要應用Scrum於大型團隊時,需要一些調整和靈活性。

你可能需要增加一些額外的角色或分工,以適應更大規模的團隊組織。同時,某些流程和工件可能需要做出相應的修改才能更好地支持大型團隊。 總之,在使用Scrum管理大型團隊時,理解其原則並根據實際情況進行調整至關重要。

雖然Scrum最初是針對小型敏捷開發團隊設計的,但它仍可以在不同規模和上下文中有效運作。

由於Scrum團隊規模小且角色明確,所以每位團隊成員都必須具備豐富經驗並熟悉所有Scrum原則,才能取得成功。若有成員缺乏技術知識和承諾,可能會給整個團隊帶來問題。

如果在會議中任務沒有被精確定義,那麼這種不準確性將會反映在成本和項目時間表上。若初始目標和任務清單模糊不清,則會使規劃變得更為困難並導致工作進度的時間增加。可改寫為: 如果我們在開會時無法準確地界定各項任務,那麼這樣的不準確性就會影響到成本和項目的進度安排。

假如一開始的目標與任務列表都不夠明確,計畫的執行就可能變得困難重重,而且還可能拉長每個階段(sprints)所需的時間。