iT邦幫忙

0

Scrum中的敏捷估計?故事點和計劃撲克

對於軟件開發人員來說,這是工作中最困難的部分,即使不是最困難的部分。它必須考慮一系列因素,幫助產品所有者做出影響整個團隊和業務的決策。

在軟件開發過程中,團隊經常會遇到一個問題:

如何估計工作時間更準確?

對於項目或產品的所有者來說,這是衡量項目資源和時間表的一個非常重要的信息,但實踐這會帶來許多問題。

許多開發人員總覺得PM正在使用最后期限來回推送。他們不關心功能是否可以满足質量。

“首先完成它,然後尋求更好”因此已經在軟件行業中流傳了很長時間。

許多PM總是覺得開發人員在評估他們的工作時最傾向於“誇大”。似乎他們都使用典型的工作估計方法:“估計實際需要時間的三倍作為緩衝”“

事實上,工作時間不能估計為“絕對準確”,但有一些方法可以估算“相對客觀”。由於工作時間和要求的複雜性,通常存在正相關關係。因此,本文將首先解釋響應需求復雜性的常見問題,提出一個解決方案,並解釋解決方案中許多設計的目的。

問題

開發者的地雷

  • “這很簡單。製作它不應該花太長時間嗎?“
  • PM今天對你說:“明天之前我必須把它交給你。“在尋求質量之前,先完成它”
  • PM後天對你說:“為什麼這個程序的質量如此糟糕?”
  • 當它被推遲時,其他同事說:“你怎麼需要花這麼長時間?這有一個現成的代碼供參考。這有一個很好的底層使用。你為什麼不問我?“
  • 其他同事:“我只需要一天,你為什麼要花這麼多天?”
  • “這是常識!需求即使没提,你應該知道該怎麼做。“

PM / PO的地雷

  • “為什麼這麼簡單?花了這麼長時間?“
  • “為什麼看到你正在訪問Facebook,但你沒有時間去做?”
  • “為什麼這些東西質量這麼差了?”
  • “為什麼他上次一天就做出來,你要做這麼多天?”
  • 由於規範或要求沒有明確寫入,因此開發人員被描述為需求變更。

Result

  • 角色敵意:需求單元和開發單元不再提供可以為用戶帶來好處的產品,而是為了自己的目的而相互攻擊,以避免承擔額外的責任。因此,需求單位和開發單位根本不是一個團隊的情況。
  • 責任:團隊認為“我沒有錯,所以延遲不是我的責任”,而不是優先考慮用戶需求。
  • 需求凍結:由於截止日期的壓力,開發人員被迫改變他們的要求,否則他們將被推遲並且責任將由開發人員承擔。因此,要麼需要加班來製作隱藏大量錯誤的東西,要麼製作某種不符合用戶需求的功能; 兩者都會降低用戶滿意度。
  • 低質量:PM的地位通常高於開發人員。因此,為了滿足合同的最後期限或避免處罰等,團隊將被要求“先完成,然後再尋求更好”,但最後通常是“先,沒有時間尋去求好” “技術債務的積累正在增加,結果是現實世界的責任鏈模型,它在最後的鏈條中負有最大的責任和成本。因此團隊就像堆棧流行,開發人員無法一個接一個地維持,這是項目公司工程師經常擁有高流動率的因素之一。
  • 提高代碼的重量:為了優化效率,最熟悉的人的位置總是用於估計工作時間,因此最熟悉模塊和過程的人將始終關注相關要求。最後,只有那些人可以維護自己的代碼,就像潘多拉的盒子一樣,你永遠不會知道哪些牛和鬼會在打開後什麼會突然出現。因為黑匣子經常骯髒,但公司根本不知道如何解決這個問題。你也只有希望他不會離開,否則一些代碼將無法理解。

Solution

這裡提出的解決方案是估算Scrum中需求復雜性的常用方法,但即使它不是Scrum團隊,也建議讀者根據原則和設計目標確定評估團隊的最佳方法。 。

請記住,這個世界沒有靈丹妙藥,其他人的最佳實踐方法並不一定適用於您的團隊,因此首先要了解您的團隊目前遇到的問題,然後找出適合您解決你自己實踐問題的方法。 ,只要它不會引起新問題或新問題的成本風險是可以接受的。

這裡用來估計需求復雜性的單位是故事點(相對單位),而不是工作時間(絕對單位)。這樣做有幾個原因:

1.比較不會因人而異:要求的複雜性通常不會因人而異,實踐所需的時間也許會因人而異。

2.“相對”比“絕對”更容易評估:如果查看工作時間,則需要估算絕對數量,並且需要在估算過程中考慮實施細節。要使用故事點來估計複雜性,您只需要將大小與其他要求進行比較。

例如,很難估計清楚“A塔高幾米”,但更容易指出“A塔比那座建築高約2倍。”

3.估計用戶故事的故事點的壓力小於估計其工作時間:因為關注需求本身,而不必擔心自己的資源和項目資源,只需評估需求的複雜性。在估算過程中,團隊成員壓力較小,並像遊戲一樣參與軟件開發。

接下來,解釋解決方案的各個方面。

When

在決定誰来做之前進行評估:這樣做的好處是最大限度地減少開發人員的個人因素。因為知道由誰做,所以不需要因為您自己的任務或最后期限而故意高估去添加緩衝區。

Who

只有做事情的人一起評價:兩個關鍵點:

  1. 只有那些做事的人才能估計出來。需求單元估計的時間或複雜性不是客觀的,因為它們不是實際工作的人,並且沒有權力根據工作負擔評估影響開發團隊的估算。這也使得更容易避免從截止日期開始評估要求的複雜性。
  2. 一起做事的人估計。因為您不知道將要做什麼,所以每個人一起估計的數字在討論和重新估計後很容易達成共識。每個人都有參與,他們會有參與感,而且因為每個人都有參與,估計結果是由每個人決定的,所以誰將來會這樣做不會抱怨。

What

使用規劃撲克來估計故事點。

Poker and Fibonacci Sequence

估計Scrum 中用戶故事大小的最常用方法是分配故事點。故事點只是從設定大小的數字池中抽取的數字,例如,故事可以具有1,2,3,5,8,13,20,40或100個故事點。

菲舍爾系列有一個有趣的功能,並且每個數字是前兩個數字加。另一方面,數字與下一個數字之間的間隙越大,差異越大。

如上所示,8和13之間的差距是5,而13和20之間的差距是7.但是,這與估計需求的複雜性有何關係?我們不在數學課上。

與Fibonacci序列相關的估計特徵

估計也有一個特徵,即越大越不精確,需求或任務被削減到更精細的粒度,通常估計更準確。就像在杯子中安裝一塊大的不規則石塊一樣,中間會有更多的間隙,這是不對齊或浪費的部分。如果你安裝一個更細和相同的不規則的石頭,間隙將相對較小,並且它易於調整,它可以更方便地填補空隙。

即使先前數字的差異相對較小,也無關緊要,因為數量很小,這意味著搬家靈活且風險低。如果由於某些因素導致時間估計不准確,則前面的小數字的任務是大約20分鐘的加班時間。而不是加班2或5天。

因為大的數字間隙很大(費米系列的兩個前後值的差值接近1.618),所以可以避免估計“這種複雜性是20還是21”。“要麼要想13,要麼20,要麼40。

這種差距可以突出相同要求的估計差異,因為幾乎所有這些差異都要差1.5倍。這個比例很容易讓人們判斷相對大小,因此可以減少許多細微差別和不必要的重新估算過程成本。

撲克牌中的特殊號碼

另外,上面的圖片可以看到一些特殊的數字,分別是0,無窮大和問號。

  • 0可能意味著根本不需要完成此要求,或者它已經完成。
  • 無限意味著需求是明確的,但超過最大數量的需求,表明需求需要細分為多個較小規模的需求。
  • 問號表明需求不明確,需要PO / PM來解釋或澄清。

How

1.首先定義復雜度單位1,例如單表綜合查詢的功能。由於我們的估算過程是基於相對規模,我們首先定義比較基準的單位,並在團隊估算後有比較的基礎。

2.主持人大聲說出要求(例如用戶故事卡),以確保每個人都了解要求,每個人都有自己的估計複雜性。使用計劃撲克的原因是因為您評估的數字可以同時顯示,而不是旋轉您評估的數字。很容易將數字輸出並導致其背後的人的結果受到之前數字的影響。

3.如果團隊中有不同的估計,估計這兩個估計是最小的和最大的,他們將評估它們複雜或簡單的原因。在上面的例子中,在估計過程中,如果一個人估計故事點是13,大多數人估計20和另一個人估計40。13和40差不多3倍,所以基本上必須有一些重要信息沒有同步。

例如,估計13的人認為這種需求幾乎與過去的某個要求相同,而且這個要求並不像想像的那麼複雜。估計40的人可能會感到相對複雜,因為他對這個要求或過程不夠熟悉。

4.最低和最高數字完成評估的原因並進行進一步投票。如果仍然有不同的投票數,並且絕大多數人都達成了共識,並且沒有達成共識,估計的複雜性只是遠離共識複雜性的一個級別,您可以詢問估計不同數字的成員是否他們可以接受您評估的數字。

5.如果數字仍有差距一个级距以上,或者無法達成共識,請重複步驟3到5,直到達成共識。

同樣,只有那些實際執行任務或完成要求的人才能參與投票過程,而PO / PM不能干涉。

Why

這種估算方法有幾個優點:

  1. 合作的人決定合理客觀的估計結果,有參與感,沒有抱怨。
  2. 決定的結果是PO和團隊之間的共識,這將減少未來針鋒相對的情況的發生。
  3. 每個人都能理解這個要求。將來,每個人都可以充當滿足要求的人。當需要支持時,人們也可以互相幫助或互相支持。
  4. 在您這樣做之前,您可以澄清不明確的要求部分和有疑問的部分。
  5. 在您做之前,您可以找到最佳和最有效的團隊合作方式。
  6. 除非整個團隊都是一個不可靠的人,否則這個數字反映了團隊共享估算的事實,而PO可以理解需求與評估之間的差距。
  7. 通過比較需求之間複雜性的相對大小,未來的PO將能夠承諾在迭代中可以完成多少工作,並且將有一個比較的基礎。

結論

通過上述估算過程,這樣的決定是公開,透明,客觀和自願的。對於兩個角色:

對於PO / PM:

  • 不需要擔心某些成員過度估計任務作為緩衝區。
  • 了解在評估過程中實施需求或任務的潛在困難。
  • 了解需求的任何部分是否需要明確說明去除誤解部分。

對於團隊:

  • 開發人員在開始處理任務之前進行知識交換。無論估計數量是增加還是減少,需求都更加明確,估計更客觀。
  • 因為您仍然不知道誰負責這項任務,所以估算過程可以客觀地實現,並且在團隊一致的情況下,您知道誰在這個過程中熟悉這個任務。實際操作時,您可以基於這些資訊配對編程或知道向誰尋求幫助。

本文提出的解決方案是一種常見的解決方案。重點不在於形式,而是在敏捷估計過程中每個環節的設計目的,以解決什麼樣的問題。最後,敏捷估計只是:估計。不是滴血為誓。

Scrum技術中的文章


尚未有邦友留言

立即登入留言