敏捷開發總結

注：這篇隨筆將會持續更新

前情提要：

　　爲期 10 個工做日爲一個迭代。第一，次日故事會與任務分解會，其後一天一故事，第五天交付少許故事，第十天完整交付，演示及總結。

相關環節的必要性：

　　大部分環節的設置其目的都但願解耦，持續，並提升效率，此外：

　　故事會是但願在持續的開發中減小溝通成本，首先開發者構思軟件最終形態，設置分配具備完整性功能且有價值的故事內容，配合樣圖框架，讓在場的每一個開發者瞭解每一個故事的核心，樣圖，並使思想造成統一。因爲用戶的需求不斷改變，每次迭代都是進行一次形態的初生，重建與思想統一，最後開發者們權衡取捨。

參與：

　　用戶表明，開發者等。

細節：

　　故事會須要提早準備規劃，計時，邀請用戶表明等。

　　軟件首重價值，能夠根據測試用例進行開發，因此故事的交付側重功能，在有效的模塊之間，採用 mock 造成聯繫，安全性校驗等能夠以負債形式記錄留置下個迭代完善。

　　美工與開發者之間能夠以「需求，限定與規格」文件形式，分開進行獨立做業。

　　如何作到一天一故事：接口的定義要簡單，參數少，但功能強大，多端統一。如有新的需求，儘可能原接口不變更，經過增長新的接口，或二次接口進行操做。

　　固然一個新的迭代避免不了新的負債和不斷的填坑。

　　在設計軟件時，要考慮不一樣端的複雜與簡單的權衡，以及後期發佈版本對使用者的培訓成本和難度。

　　演示，總結時遇到用戶的異議，能夠反駁或提出解決方案。

真實演進：

　　1.以上略有形式主義，因爲迭代故事與考覈掛鉤，致使後來體系漸崩。

　　每一個團隊的故事會，演示會，表明們再也不提出異議及促進點，團隊自我封閉，缺乏交流，價值「分子」小，任務「分母」大，是考覈等因素致使。

　　給領導洗腦是不存在的，推翻制度，暫時也不可能。

　　惟有團隊打開封閉，促進交流，任務化爲體現價值的大點，值才更有意義。

　　故事須要快速迭代並演示，技術不是問題，快速的演示纔能有效的促進故事的演進，及時調整任務。

　　演示前交代背景，將故事的每一個場景列出來，而不是列出任務。

 

　　2.交付演示總結變化：咱們在研發軟件時，可能遇到用戶反饋不及時或用戶量較少的狀況。

　　一般咱們會借鑑市場上好的產品功能做爲設計參考，然而殊不知產品爲什麼如此設計。

　　好比開發票：是選擇已消費的開，仍是充值未消費的開？二者都有試用場合，當多用途，或多公司報帳時，選擇已消費的開具發票。

　　敏捷開發中，每每須要快速的完成故事，並提供給用戶使用起來，重點在用戶的使用。

　　及早的投入使用，方能及早的獲得反饋與新的迭代故事。

　　這樣開發者就無需閉門造車，最後鼓搗出一個花樣繁多卻讓用戶難以理解，難以使用的產品。