敏捷估算方法
無論是團隊研發一款產品或者開發某乙個專案，我們都需要回答「我們大概什麼時間能夠完成？」， 或者到某乙個時間點，我們能夠做到什麼程度， 因此和傳統的開發模式一樣，我們在故事拆分之後需要對我們需要做的事情進行工作量的估算。相對於傳統的工作量估算方式，敏捷估算有如下幾個特點：
1. 團隊集體估算
在scrum的開發過程中，團隊共擔責任，集體承諾每個sprint的工作，因此對於工作量的估算敏捷團隊採用集體估算的方式。集體估算，通常採用估算撲克作為工具，團隊通過玩估算遊戲進行集體估算。一般採用估算撲克來做工作量估算（常見的還有t-shirt size估算），估算撲克的使用方法：
• 每個團隊成員拿一組卡片，包括0,0.5,1,2,3,5,8,13,20,40,?,∞,共計12張。
• 當團隊理解了這個條目之後，每個團隊成員按照自己的想法給出估算結果，並選擇對應的撲克出牌，估算結果不能告訴其他人，出牌時數字朝下扣在桌面上。
• 團隊評估不同的估算結果。我們是否想法一致？我們是否存在分歧？有沒有什麼是我沒有考慮到的？討論之後可以再估算一輪，最終團隊需要達成一致。
2. 估算大小，而不是估算時間週期，使用相對估算，而不是絕對估算
一瓶礦泉水，讓乙個3歲的小妹妹把它喝完所花的時間和乙個成年人把它喝完所花的時間肯定不一樣，因此同一項工作，不同能力的人完成它花費的時間顯然是不一樣的。如果我們要估算從家到公司的絕對距離是多少公里，您可能不知道，但是如果您是做地鐵上班，從家裡到公司有多少站，你一定很容易知道，當知道有多少站之後，我們就可以大概清楚路上需要花多長時間了。敏捷估算時，我們不會估算絕對時間和週期，我們估算大小，和相對值，也就是倍數。敏捷估算時，我們使用故事點作為計量單位，它是乙個倍數，我們會先找乙個我們認為最小的乙個功能的大小作為參考基準，定義為1個故事點，把其它的故事和它做比較，如果是2倍大小，就是2個故事點，如果是5倍大小，就是5個故事點。
3. 記錄每個sprint的團隊速度
團隊速率是乙個scrum團隊在乙個sprint中實際完成的故事點數，通過團隊速率可以知道團隊做的有多快。新開始的專案或產品開發，或者是新團隊，沒有初始速度，我們可以做1-2個sprint測算乙個速度，作為初始速度。在sprint執行過程中，我們要記錄每個sprint的速度，為以後的計畫做參考。
我們估算了產品backlog的故事點總數，然後又知道了每個sprint團隊的平均速度，那麼我們就可以推算我們大概需要多少個sprint可以做完，這樣我們就得到了週期。
敏捷開發每日一貼 敏捷開發 例項化需求常見問題
例項化需求常見問題 推動例項化需求，講到這個例子時，經常會碰到這些問題 6 件可配嗎？例子中提到6件免運費，顯然這個在系統中要可配的，不能在產品中硬編碼 hard code 但是這個需要在例子中講清楚嗎？否者我的開發團隊又要說我需求沒講清楚，不過我總覺得這點意識他們應該有的？乙個有著很多痛苦經歷的p...
敏捷開發每日一貼 自組織敏捷團隊的特點
自組織敏捷團隊的特點 敏捷常提到自組織團隊，通俗的講它是乙個由外部建立，然後給與授權，自行決定行動綱領的乙個團隊。這個團隊接受外部給與的任務和約束條件，自行決定如何完成任務。在這個團隊中，團隊成員自己決定做什麼，以及如何做，是 民主 還是 集權 團隊說了算。橄欖球 籃球 足球等體育團隊，就是非 敏捷...
敏捷開發精準估算
估算並非易事。對軟體開發人員來說，估算堪稱是最難的工作之一。估算必須考慮所有能幫助產品負責人做出影響整個團隊和業務決策的因素。因此，從開發到高管都為它焦頭爛額也不足為奇，但這種做法是錯誤的。敏捷估算並不是什麼性命攸關的大事，就只是估算而已，事實就這麼簡單。我們不用要求團隊週末加班加點來彌補一項被低估...