相信大家都讀過一千零一夜的故事，接下來，我們來回顧一下這個故事。
故事有兩個主角，乙個男主（主動方），乙個女主（被動方），
互動的方式是： 被動方 講故事， （可以故事裡巢狀另乙個故事，故事也可以有多個分支。。。）
評價體系是這樣的：
a）主動方 接收 某個小故事， 被動方 繼續 （可以見到明天的太陽）
b) 主動方不接收，被動方 被 主動方 kill 掉 （死翹翹）
我們來看看 被動方是怎麼做的。
首先，她需要精心準備第乙個故事，吸引客戶的注意。
（有沒有點「最小可行方案」的感覺？）
女主角學識淵博（技術積累），前期的故事不成問題，準備充分，那麼還有第二個難題。
客戶也有審美疲勞的時候啊，要是哪天男主打了個盹，走了下神，女主就得喀嚓了。
女主講故事的方式很特殊，舉個例子，有些地方，故事巢狀了四五層之多。
這說明，故事是分層的，子故事之間有一定的邏輯關係，客戶對區域性功能不埋單，沒關係。（框架很重要）
最後，整個週期時間很長，將近3年，這點 和 持續交付 有異曲同工的效果。
當然這只個寓言故事，你也可以用自己方式重構它。
最後，我們以《敏捷開發一千另一夜》中104頁的一段文字，作為結尾。
「如果第二天可能被砍頭，沒有時間顧及繁文縟節又不想坐以待斃，當天晚上想出來的方法就是敏捷方法。」
敏捷開發讀後感
經過閱讀這些文章，我對於敏捷開發有了初步的了解。總的來說呢，敏捷開發 是一種以人為核心 迭代 循序漸進的開發方法。就是將乙個大專案進行分割，將其分割成為乙個乙個分別獨立而其中又存在聯絡的小專案，每乙個小專案由不同的小組分別完成。由於這種較為靈活的模式，使得敏捷開發與其他軟體開發型別相比在適應性上有了...
敏捷開發一千零一夜讀書筆記之敏捷初探
最近很忙，有個把月沒讀過書，沒上過這裡，趁著今天專案結題驗收，上來轉轉。我常常想，我這裡應該是沒有讀者的吧，我完全把這裡當成是一些我腦子裡記不住，或者感覺 啊，原來是這樣 的東西集合地。因此，看起來雜亂無章。一晃27歲生日就要到了，裝修已畢，婚期將至，手下的人，也越來越多，最近，總是在思考團隊管理的...
關於敏捷開發的讀後感
完成一項工程時，我們常常會有這樣的感受 我們的解決方案要根據顧客的需求和現實情況的需要，不斷更改。採用傳統意義上的瀑布式開發，往往要花費更多的時間。最重要的原因就在於它相比於極限程式設計 敏捷開發，對於團隊合作的重視程度不夠，自由度也相對較低，導致效率偏低。在實際做專案時，我們應該清楚，我們做工程的...