自2001年“敏捷宣言”誕生以來,敏捷就有很多嗡嗡聲。事實上,敏捷方法只是一種思維方式,可以使團隊和組織進行創新,快速響應不斷變化的需求,同時降低風險。組織可以靈活地使用許多可用的框架,如Scrum,看板,精益,XP等等。
所有敏捷方法的特點是反覆運算和增量開發。這些方法與傳統瀑布方法完全相反,在傳統瀑布方法中,在開發開始之前,所有需求都被分析、記錄和充實。對於敏捷,需求是隨著每個短反覆運算中的實際軟體發展進展而開發和發展的。
這樣做的優點是能够靈活地快速回應需求的變化和業務的優先順序。敏捷解决了在開發開始之前等待很長時間的問題。它還解决了當不可避免的變化到來時調整大型開發計畫和預算的問題。
那麼,通過介紹,Scrum與其他敏捷方法的區別是什麼?Scrum是一種特別簡單和靈活的敏捷方法。實際上,Scrum可以用作生產任何產品的方法,並且已經用於製造過程以及軟體發展。
簡單性、靈活性以及緊密的通信和合作是Scrum的主要特徵。
Scrum是橄欖球比賽中重啟比賽的方法的名字。兩隊在場上處於緊密相連的小組中, 然後球被拋入這個緊密相連的小組的中間。然後雙方必須密切合作, 將球移動到球門上。
scrum 團隊在軟體發展方面也是如此。這是一個混亂的組合和協作, 但如果每個人都努力工作, 齊心協力, 每個衝刺都可以把球移到離目標更近的地方。
還有其他的輔助角色 (stakeholders)(稱為“雞” i.e. manager, end users and etc. ),但是這是Scrum中的三個“承諾”角色,稱為“pigs”(來自“Chicken and Pig”的故事——對於早餐,雞“參與”,但是猪“承諾”)。
產品負責人代表客戶或企業對產品或系統的要求和優先順序。這是最具權威和責任的角色。
Scrum Master是這個項目的促進者。他不像傳統的專案經理那樣管理團隊。他的主要工作是激勵團隊並消除阻礙開發團隊實現其目標的任何障礙。
開發團隊或團隊成員是最後一個被承諾的角色。這個團隊是自我管理的。對於軟體發展項目,團隊由開發人員、架構師、分析人員、QA分析人員和測試人員以及UX/ UI設計人員組成。團隊一起確定每個開發衝刺將交付什麼,然後他們負責交付他們的承諾。
發展就是衝刺 (Sprint)。這些短跑的長度是1-4周。團隊承諾在衝刺期間完成一定數量的工作。由於他們致力於在當前的衝刺階段一起工作並完成一定數量的工作,他們期望實現他們的承諾。
與在瀑布方法 (waterfall approach) 中記錄和詳細描述業務 (business) 和技術需求 (technical requirements) 時看似無窮無盡的文檔不同,_用戶故事 (user stories)用於描述Scrum方法中要開發的功能。這些用戶故事使用 Scrum Process Canvas存儲在**待辦事項中 (Project Backlog),将积压 (Backlog) 工作中的任何User stories 存储到优先项列表中。
如果企業決定_更改或添加_故事到積壓工作 (Backlog items) 並優先考慮列表頂部,團隊可以在下一個衝刺階段 (Sprint Period) 進行調整分解为较小的user stories,而不是最初計劃的巨形故事。這使得企業可以改變主意,讓團隊隨時調整以適應不斷變化的業務需求和願望。
歡迎和接受改變的能力是Scrum方法最強大的特性之一。業務就是變化,如果您的軟件無法快速更改,那麼您的方法和流程的變更就已經過時了。在當前的業務環境中,您的開發團隊必須具有靈活性。您必須能夠快速有效地更改軟件系統。
老實說,我不知道為什麼我們根據瀑布方法開發軟件。我們花了幾個月的時間與業務用戶會面,記錄需求,然後我們離開,並開發軟件3-9個月,然後再與業務用戶交談。我們在想什麼!?結果總是這樣,“不,這不是我們想要的。你能改變...... X,Y,哦......和Z?“
相反,我們現在每天和每週與企業用戶進行溝通,每2-3週,根據衝刺計劃 Sprint Planning),所有這些。這種密切的_*溝通和協作 (Communication and Collaboration)*_是使這種方法成功的主要因素。這完全是關於溝通。即使您決定改變Scrum方法的嚴格原則,然而密切的溝通和協作也會使您的開發工作取得成功。
通過在一頁內完全自動化 scrum 過程來管理您的敏捷專案
https://www.youtube.com/watch?v=aeiYZGhCj2M