譯者：付新圓&柴曉燕
幾乎每個scrum團隊都在使用故事點，但故事點不是官方scrum指南的一部分，就存在很多不同的解釋和使用方法。本文旨在消除圍繞故事點的神秘感，也將分享我在敏捷實踐中遇到的對故事點的誤解。
故事點是用於估計敏捷開發中使用者故事的相對大小和複雜性的度量單位，表示投入pbi (product backlog item產品待辦事項) 所需的工作。每個故事點代表乙個時間的正態分佈。例如：1個故事點可以表示4-12小時的範圍，2個故事點可以表示10-20小時的範圍，依此類推。這個時間分布在預估過程中是未知的。通過參考pbi (product backlog item產品待辦事項) 得到相對估計值，雖然不知道完成任務的具體時間，但可以粗略地知道需要多長時間完成任務。
故事點使團隊能夠：
pbi (product backlog item產品待辦事項)的實現需要複雜的演算法。有些pbi (product backlog item產品待辦事項)很複雜，但並不需要很多時間，團隊之前已經做過了此類的操作，所以他們能快速完成。相反的情況也會存在，比如乙個簡單的pbi需要很多時間，團隊需要重構一小段**，但影響了很多功能，結果許多功能需要進行回歸測試，這將花費大量時間。
預估的不確定性在故事點fibonacci-like序列本身中捕獲：1、2、3、5、8、13、20、40、100。從該序列中選擇特定數字反映了不確定性。當不確定性太大而無法估計時，則可以使用「?」 卡。
故事點提供了乙個粗略的估計，並不能說明pbi的價值。該專案可能非常有價值，或者根本沒有增加任何價值。故事點可以幫助專案確定pbi的roi（投資回報率），您可以考慮將功能與價值一起交付。
故事點與工作相關。 複雜性，不確定性和風險是影響工作量的因素，但它們單獨使用時不足以決定工作量。
通過將故事點數轉換為小時數，您就無法從相對估計的速度中受益。您開始以小時為單位工作，冒著做出承諾的風險。當您將故事點的時間範圍從10-20個小時減少到15個小時時，它提供了一種錯誤的準確性。當您開始在確切的時間範圍內工作時，團隊在預估上達成一致就會非常困難。
在計畫撲克遊戲的過程中，團隊的一半人預估pbi為3個故事點，另一半人預估為5個故事點。只需將4個故事點作為估算值，就可以解決討論。這樣並不是100%準確的，關鍵是要足夠準確，提前做好計畫。團隊不應這樣做，因為它提供了錯誤的準確性。另外，您可能會因為平均而失去一次有價值的討論。也許5個故事點是乙個更好的估計。
當團隊開始處理問題時，即使事實證明他們的預估是不準確的，團隊也不應調整「故事點」。如果預估不正確，則它是最終衝刺速度的一部分。有時預估不正確是正常的。您不會丟失這些資訊，這將成為團隊歷史速度的一部分。
乙個與當前衝刺無關的bug應該只在故事中提到，該bug是團隊需要完成的工作。如果團隊在衝刺期間保留了固定的時間來處理bug，那麼這就不適用。與衝刺中的問題相關的bug不應該用故事描述，因為這是原始評估的一部分。
調查一些關鍵的事情應該有時間限制，這件些關鍵的事情通過經驗可能只需要4個小時來完成，就無需在其中新增任何故事點了。
當乙個團隊調整參考pbi的衝刺時，那麼不同衝刺的速度不再具有可比性。團隊會丟失資訊，您將無法再使用歷史速度來提前計畫。最好使用一系列最新的pbi作為參考。
將未完成的pbi移至下乙個衝刺時，無需重新估計。這個估算可能不準確，但這不成問題。作為衝刺計畫的結果，團隊將了解完成問題所需的所有任務。這些任務的估算以小時為單位。因此，下一次衝刺，團隊將知道完成pbi仍需要多少時間。pbi未完成的將成為速度的一部分。
故事對應的pbi與參考的使用者故事相關，由團隊完成。團隊成員講述了pbi的故事，並在規劃會議中就估算值達成了共識。對於高階開發人員，pbi可能是3個故事點，對於初級開發人員，乙個pbi可能是8個故事點。團隊工作量應達成協議，並將其用於計畫。您不應調整故事點，因為每個pbi都將由特定的人來完成。也許當他們開始處理該問題時，高階開發人員正在處理生產問題。然後，初級開發人員就需要將其剩餘的工作撿起來。
當團隊組成發生變化時，這可能會影響速度和故事點評估。他們倆都依賴於執行工作的團隊。想象一下，當兩個高階開發人員在場時，您就可以從故事中找到問題所在。當您要開始解決這些問題時，他們倆都離開了公司。現在，團隊中有兩個新的初級開發人員。建立乙個新的使用者故事參考是很好的實踐，它需要整個團隊來進行。這樣可以確保每個人在講故事時都在乙個步調上，並給團隊一些時間來建立新的速度。隨著團隊的越來越成熟，估算能力也越來越強，建立新的參考pbi可能是乙個好主意。
在制定衝刺計畫時，團隊可能會與專家保持一致。解決此問題的一種方法是讓專家詳細說明這項工作，然後讓團隊的其他成員在沒有專家的情況下進行評估。積累特定的專業知識是不可避免的，但不要讓這削弱了團隊的估算能力。
每隔一段時間，團隊都會指出故事評估的錯誤問題，討論這些問題並嘗試了解這些問題非常重要的，這樣未來的評估就會更準確。在我的乙個團隊中，我們忘記了在評估時考慮測試資料的建立，因此，我們特別討論了建立測試資料是否適用的每個問題。如果適用，我們會詢問他們是否考慮了測試資料的建立。這大大改善了我們的評估質量。
故事點的概念很簡單，但很難應用，幾乎每個scrum團隊都使用它們，但它不是官方的scrum指南的一部分。正因為如此，人們對如何使用故事點有不同的看法。術語「故事點」本身已經令人困惑，因為您也可以將它用於使用者故事以外的工作型別，在這個「點」字上，說明乙個故事點代表了價值。正如一位同事指出的那樣，或許用「計畫因素」一詞來說故事點會更容易讓人理解。本文旨在幫助大家了解在使用故事點時可能會犯的錯誤，並以正確的方式應用它們。
實踐中使用haproxy 防禦ddos
首先在http 這裡做乙個門防禦 白名單 acl whiteip src f usr local haproxy etc whiteip.lst 標記非法使用者 stick table type ip size 20k expire 2m store gpc0 tcp request connect...
敏捷實踐中的好品質
作者gunjan doshi deborah hartmann譯者喬梁發布於 2007年6月7日 上午1時46分 社群 agile 主題 團隊協作,變更 成功的實踐者會注意到 敏捷更倚重於紀律，而不是幾個天才。因此，實踐的重中之重就是 把 人 放在第一位，聚焦於價值，頻繁地交付高質量的工作成果，通過...
PHP 專案實踐中使用的IOC容器思想
1.容器的意思就是乙個全域性變數,裡面存了很多物件,如果要用到某個物件就從裡面取,前提就是要先把物件放進去 2.控制反轉就是把自己的控制權交給別人 3.這兩個結合就是,把自己的控制權交給別人並且建立的物件放進乙個全域性變數裡 4.好處就是可以靈活的修改乙個物件的屬性,而不需要去修改類本身的 clas...