去年入職公司不久，就趕上了公司“敏捷”開發的改革大潮。從最初的敏捷培訓，到摸著路探索，也有4個月的時間了。

　　現在，對於grooming，planning，daily stand up，demo review retrospective這些Scrum中的活動已經清楚了很多。

　　但從這些活動形式和內容上看，這些活動都很有必要，比如grooming，可以幫助大家理解需求，planning，可以讓大家知道優先在這個sprint做的，和接下來的sprint中要做的……可是隻有這些，不足以讓我們對“敏捷開發”進行瘋狂追求。
　　在這四個月的時間裡，被問的最多的就是敏捷開發有什麼好處，和之前的開發模式有什麼不同？
　　對於瞭解過敏捷開發的人來說，他一定會脫口而出幾個詞：快速交付，快速響應使用者需求……但是，在真正實踐中如何達到這些目標，我覺得這裡面有很多學問要做，當然也和本文這次要分享的內容有關。
　　在一個Sprint完成時，應該保證這個Sprint中的Story已經開發實現並已測試完，部署好，可以交給使用者。這裡的關鍵就是劃分Story。
　　我們知道一個Sprint是兩週的時間，如果一個Story太大，就無法達到上述要求。那麼問題來了，如何拆分它呢？
　　下面的視訊中，闡述了拆分Story的技巧：
　　

　　
　　總之，在拆分Story時，SPIDR是個很好的技巧。但是，實踐當中不用把這些方法都用上，只要能把Story分的小到易於完成就可以了。