以我從事設計開發十五年的工作經歷來看，因為自己近十年從事的行業比較特殊，因此，在使用敏捷時，也和常見的敏捷有很大區別。
通常，我從事的行業，對產品概念完整性的要求非常非常高，使用小版本迭代，很大可能第二個版本發現要順利進行，要推翻第乙個迭代的很多東西（第乙個迭代的很多東西需要推翻重寫），而且這種情況隨著開發活動的進展會越來越多，越來越頻繁。
為了解決這樣的問題，會衍生出乙個非常龐大的sprint0。在這個sprint0裡，其實不是敏捷方式來做的（不過這也不怎麼要緊）。
再演變，可能會演變成另外一種場景，產品的第乙個版本，不採用敏捷方式，而是傳統方式來做，最重要的是，澄清和反覆確認產品的最最精髓部分（一般產品的精髓和本質，是一組相互關聯的概念）和架構（相當於人體的骨骼），然後在實現過程中，不斷完善概念和架構。
因為概念的變化實際上是比較緩慢的，架構變化稍多一些，實現隨著形勢的發展，變化最多。所以第乙個版本之後，基本上概念不大會變化了，架構也不大會進行傷筋動骨的改變，大多數時候，是一些實現上的調整，增加功能、功能變化。從此之後，倒是可以使用敏捷開發，來很大程度上提高產品的開發效率，提高產品質量。
或者說，第乙個版本不能圖快，要穩打穩紮，要打下乙個擴充套件和改進的很好的基礎（倒是無需考慮太多，只是打下乙個清楚的底子非常重要）；後續的改進等等可以制定快速反應、快速發布的策略。第乙個版本圖快了，後面的改進勢必變慢，或者把產品變成技術的簡單堆砌，一鍋大雜燴。
關於逐步實踐敏捷開發的想法
由於將會要組織乙個全新的研發團隊，而且可能團隊中講會以年輕人為主，應屆畢業生尤其巨多。我覺得這是乙個嘗試全新的開發模式的好時機，但是當然需要平穩過渡。首先，我們都沒有敏捷開發的經驗，其次，敏捷開發所有的概念也未必完全適合團隊，需要動態的來尋找結合點。1.簡單設計及重構 首先需要較為嚴格的確立工程的概...
敏捷的幾條想法
所有開發流程都有共通的環節，因為軟體產品的生產就像其他產品一樣，不可能實現奇蹟性的產出。敏捷開發解決的是應對變化，本質是縮短週期，增加校對點。幾天 一周 最長乙個月的週期裡，一般至少有一次校對機會，減少實際和預期的偏差。即使採用敏捷方法，應對各種需求變更也只是理想的目標。因為 和測試的調整要遠慢於需...
敏捷開發使用者故事系列之三 使用者建模
這是敏捷開發使用者故事系列的第三篇。之一，之二，之三，之四，之五，之六，之七，之八，之九 使用者建模的目的，是為了更好地分析使用者行為和使用者價值，並因此獲得商機。有一次培訓中，分組建模的時候，一位學員就自言自語地說了一句話 真的啊 我好像不知道誰會使用我的產品 這其實是一種常見的現象。比如前文所說...