今天ipm糾正了乙個我長期的誤解，現把經過記錄下。
在ipm中，我們會對這個迭代要做的user story進行簡單的講解，然後開發人員會對該user story進行估計。現在存在這麼乙個問題：假如我們現在要對story #1: provide rss for latest articles進行估點。但是我發現我們之前曾經做過provide rss for most viewed articles。基於對已有工作的經驗，我認為現在這個story將很容易完成。因為資料來源已經有了，我們只需要借用一下以前那個story裡已經實現的rssformater就可以很容易實現了。那麼按照我原先的想法，我將這個story估計為1個點。
不過今天ipm的時候討論了乙個問題：對當前story的評估，是否必須根據過往story的開發經驗或知識。按照我以前的誤解是需要。
但是今天同事講，對story的估計是為了衡量這個story的大小，是根據該story的複雜度進行評估。比如我們拿以前乙個story #x作為基準點1，看看當前這個story相對於這個作為基準點的story是多大，然後做出評估，而不依賴你對該story中的某些知識的熟悉程度。也就是說給story估的點是一種相對複雜度，而不是工作量（這是我的誤解）。
那麼就可能存在這樣的情況：我們先完成了乙個點數為2的story #1，現在要做乙個點數為4的story #2。可能因為story #2中有部分工作在story #1裡已經準備好了基礎設施，導致這個4點的story比2點的花更少的時間。同事說，這是正常現象，這表示我們對系統的熟悉程度正在逐漸提高。所以一般就會出現這樣的情況：在專案剛剛開始的時候我們完成點的速率會很低，隨著專案的深入速率也就會不斷的提高。比如在剛開始我們每個迭代完成了10個點，後來我們每個迭代可以完成15個點了，這就表示我們對專案越來越熟悉了。後來某個迭代，我們完成點數突然降低了，我們就可以立馬發現這個訊號，然後尋找原因：比如是不是步入了系統裡乙個不熟悉的領域？是不是士氣有問題了？是不是請假的人太多了？等等，這樣就更利於視覺化，更利於我們發現問題所在。
還有一點是，如果我們對story的估計基於以後的知識，那麼問題就來了，可能團隊裡，你比較熟悉這個背景知識，但是別人並不了解。那如果依賴背景知識到底怎麼估計呢？如果按照你的估計方式，那這個story是不是一定要你做呢？這又是另外乙個問題。
那如果不基於過往的經驗我們到底估計這個點呢？
首先就是劃分任務，我們可以讓熟悉這個領域的團隊成員對這個story進行劃分。比如上面這個rss，一種可能的劃分方式：
因為劃分任務後，每個任務都相對很小，也更明確了，我們就可以更好的評估該story的複雜度。
那麼如果碰到乙個大家都不熟悉的領域呢？比如拿到乙個story後，大家都不知道到底該怎麼下手，不知道水兒有多深。那麼一般的建議就是不要對這個story進行估計，我們需要讓乙個人先對這個story spike一下，然後拿到spike結果後再劃分任務，然後再估計。
總結一下
敏捷估計中對story的估計是對story複雜程度的衡量，並不表示完成該story需要的工作量（因為工作量這東西還需要看完成該story的人）。
敏捷中的溝通與故事點
當我讀到 scrum敏捷軟體開發 關於專案經理的討論時，讓我產生了極大的共鳴，使我不得不放下書來閒扯兩句，一方面抒發自己的感受，另一方面也算是一種反思吧。我平時一般要同時帶3 5個專案。作為專案經理，我都要花上大部分時間去分析需求，然後將其拆分成小任務。拆分任務時，我會將任務錄入到我自己設計的專案管...
01 敏捷估計與規劃 前言筆記
00.您的專案進行的怎樣？遇到了令人詛喪的變化？不確定性？還是產品錯過了標誌點和最終期限？mike cohn清晰明了地展示了如何有效地開發具有高商業價值的軟體。通過敏捷估計與規劃，即使環境發生了變化，您仍可以將經理專注於真正需要的地方。01.規劃對任何敏捷開發專案都是不可缺少的組成部分。02.敏捷開...
讀書筆記 敏捷估計和規劃
最近讀完了 敏捷估計和規劃 這本書對於實現敏捷開發具有很強的實戰意義，提供了很多實際的操作方式和工具集，下面就是這本書的核心 敏捷估計和規劃的12條指導原則 1.讓整個小組參與。打撲克牌 特定活動的主要職責可能會落在某個人或者某個分組身上，例如確定需求的優先順序主要是產品所有者的職責。但是，在最求可...