什麼是敏捷中的故事點以及如何估算?
已發表: 2021-06-17目錄
敏捷中的故事點是什麼?
故事點是一種衡量通過實施敏捷框架(如 Scrum 和極限編程)執行的工作的度量。
用戶故事的實現是一項艱鉅的任務。 團隊可能面臨風險; 開發過程中的複雜性等。 這個難度級別是由開發團隊通過使用稱為故事點的抽象度量來衡量的。 因此,敏捷中的故事點被用作敏捷開發中的度量。 它告訴團隊故事的實施有多困難。
產品待辦事項梳理會議執行對故事點的估計,然後由產品開發和測試團隊進行評估。 這樣做是為了提高衝刺計劃的效率。 產品積壓梳理是檢查的粗略估計:
- 衝刺計劃是否準備好有效執行。
- 信息是否足以完成事項。
- 基於用戶故事的 sprint 計劃是否合理。
敏捷故事點估計有三個主要組成部分:
- 風險:對於一個特定的項目,與之相關的風險是模糊的需求、過程中的變化以及對第三方的依賴。
- 複雜性:它代表開發功能的難度級別。
- 接待:它決定了團隊成員對該功能的熟悉程度以及開發中某些任務的單調程度。
結合這三點可以準確規劃衝刺,包括對不確定性的緩衝、與更好估計相關的問題以及避免在時間承諾上過度學習。
敏捷中的故事點估計
估計敏捷故事點的步驟
在估算敏捷故事點時,開發人員、設計師、測試人員等的參與被認為是關鍵因素。 由於每個團隊成員對推進工作和交付產品都有不同的看法,因此有效的協作很重要。 例如,任何設計的變更不僅需要設計團隊的努力,還需要開發部門和 QA 部門的參與。
從敏捷中的故事點估計開始,團隊應該有一個基線故事,不一定要求很小,但可以在團隊中很好地引起共鳴。 接下來是基於基線故事的故事大小。 在參考故事的幫助下,應該給故事打分。 每個故事都分配了一個點值。
上漿的好處
敏捷交付團隊執行更容易估算的規模調整過程。 通過上漿
- 可以查看工作範圍的概述。
- 工作的大小可以通過多個角度來確定。
- 任何錯誤的假設都可以糾正。
- 不能準確的東西都被清除了。
大小調整考慮以下因素:
- 要做的工作量
- 工作的複雜性
- 工作中的風險或不確定性
- 時間/持續時間
通過遵循列出的過程,可以更準確地計劃衝刺:
估計故事點的三步過程是:
- 使用斐波那契數列。
- 傳統的人日評估已被替換為通過斐波那契數來估計故事點,即 1、2、3、5、8……
- 不使用線性標度,因為它提供的項目差異不足以定義估計值。 然而,斐波那契數列可以估計問題中的微小跳躍。
- 斐波那契數列表示一個數字序列,其中序列中的下一個數字是前兩個數字的總和。 為了估計敏捷中的故事點,斐波那契數列被修改為 0.5, 1, 2, 3, 5, 8, 13, ...
- 矩陣的確定
- 確定每個故事點的基線。
- 基線作為值 1 包含在矩陣中。這被設置為最小風險、重複等的標準。
- 規劃撲克
通過計劃撲克,團隊同意每個項目的正確故事點近似值。
計劃撲克的工作是
- 在 sprint 計劃期間,每個開發人員和測試人員都會收到一組卡片。 這些卡片描繪了一個斐波那契數列。
- 從積壓表中選出一個項目進行質疑和澄清項目的特徵。
- 在討論結束時,由測試人員和開發人員私下選出一張反映項目評估的卡片。
- 卡片然後由估算器顯示。 如果達成共識,他們將繼續進行淨項目。 對於不同的卡片,由領導人進行討論,直到達成共識。
一個完整的矩陣對於估計者在規劃撲剋期間用作參考是有用的。 這允許在任務之間實現更大的一致性。 此外,估計的最大限制是 13,如果超過 13,那麼將任務分解為更小的項目是有效的。 此外,如果估計任務小於 1,則建議將其合併到另一個任務中。
敏捷中成功估計故事點的另外 8 個步驟估計是:
- 確定基礎故事
- 在敏捷中估計故事點的重要步驟之一是確定一個基本故事,該故事用作積壓工作的相對規模的參考。
- 基線故事是從開發團隊執行的早期故事或當前產品積壓中挑選的。
- 每個團隊成員對基線故事的理解應該是相同的。 換句話說,團隊應該對基線故事充滿信心。
- 討論要求
- 故事的細節必須討論,與用戶故事相關的解釋將由產品負責人或業務分析師提供。
- 記下重要的事情
- 任何重要的事情都應該記下來。
- 在正在進行的討論中,Scrum Master 最好地完成這項工作。
- 要問的重要問題
有幾個問題太重要了,開發團隊不得不問自己。
- 在開始設計之前,團隊成員需要學習什麼?
- 故事的代碼要求是什麼? 需要多少長度,開發團隊之前有沒有寫過類似的代碼。
- 為了讓客戶接受,涉及多少工作?
- 故事是否有任何外部依賴關係?
- 團隊中是否有人有任何專業知識或經驗在同一個故事中工作?
- 無論是從業務邏輯的角度還是從技術的角度來看,這個故事是否有任何簡單性或相關的複雜性?
- 及時獲得依賴關係的確定性有多大?
- 相對比較的點
- 比較的相對點應該分配給故事。
- 應該為故事分配相同數量的點,即 1,對於具有與已調整大小的故事相同數量的工作的故事。
- 對於更困難的故事,應分配相應的更高值。
- 如果故事由於從前一個故事中可獲得的學習而不太複雜,但與該故事幾乎相似,則分配較低的值。
- 根據故事的大小,在整個團隊中達成共識。
- 應該驗證故事之間存在內部一致性的事實。
- 應確保在重複的時間間隔內所有 1 相同或所有 2 匹配等。
敏捷故事點估計的好處
將估計應用於敏捷中的故事點可為開發人員和產品所有者帶來好處。
為開發人員提供的好處是:
- 估算的應用使開發人員可以知道沖刺需要多少計劃,因此可以以可持續的速度推進工作。
- 避免過度規劃衝刺。
- 通過討論和闡述,可以很好地理解產品所需的實施策略和要求。
為產品所有者提供的好處是:
- 可以專注於產品的長期交付。
- 可以評估項目的“物有所值”或“投資回報”。
- 大項目的技術風險對產品所有者來說是可見的。
從世界頂級大學在線學習軟件課程。 獲得行政 PG 課程、高級證書課程或碩士課程,以加快您的職業生涯。
概括
就像敏捷方法涉及實踐一樣,估計本身也是一種隨著時間的推移會變得更好的實踐。 估計敏捷點的實施對開發人員和所有者都有好處,最終會產生有效的解決方案。
如果您想掌握軟件開發方面的知識,請前來查看 upGrad 提供的軟件開發中的執行 PG 計劃 - 全棧開發專業化課程。
專業化課程將有助於將任何入門級專業人員的隱藏創造力轉變為他們未來的軟件開發。 如果需要任何幫助,您可以聯繫我們的幫助團隊。
敏捷中的故事點是什麼?
你如何估計正確的故事點?
如果故事是關於六個月後舉行的貿易展,那麼你可以給 2 分,因為要求不會改變。 如果您正在開髮用戶界面,故事點可以是其中之一。 如果您正在編寫服務器,您可以將一個點放在兩個小時內。 有時團隊無法估計一個需求,所以最好放大量的點來表明你不知道它需要付出多少努力。 另一方面,如果您有一個簡單的故事,您只是在表單上添加一個新按鈕,您可以說這一點是一個。 有一些工具可用於計算故事點的時間。
什麼是敏捷開發?
敏捷開發是一種軟件開發方法。 在敏捷開發中,需求和解決方案通過自組織跨職能團隊之間的持續溝通、反饋和協作而發展。 它是幾種迭代和增量方法的總稱,例如 Scrum 和極限編程 (XP)。 與其等到項目結束才看它是否好用,不如創建敏捷開發方法,以便在整個項目中定期交付工作軟件。 這是通過建立具有特定目標的小型團隊並在每次迭代結束時交付完整且有效的軟件來完成的。