在瀑布模型中, 一旦發生需求變化, 給專案帶來的風險是巨大的. 而如果不變, 那很可能作出來的東西就不是使用者想要的東西, 那這個東西對於使用者而言還有什麼意義? 所以, 在瀑布開發模型中, 不管開發團隊願意不願意接受需求變更, 這種變更的客觀事實已經給專案本身帶來太多的風險.
而敏捷開發呢? 是不是就沒有瀑布模型的那些開發步驟: 需求提出-->需求凍結-->需求實現-->實現評估? 答案是否定的, 敏捷開發當然也會有這些過程, 但是, 敏捷開發對於瀑布模型最大的改進在於: 把瀑布模型中的大版本切成敏捷開發中的乙個個小版本, 從而大大縮短軟體發布小版本的時間週期, 始終堅持盡最快速度向使用者提交乙個最新功能的版本, 讓使用者在體驗中不斷與開發團隊共同完善.
而不是象瀑布開發模型那樣, 使用者提出了需求後, 開發團隊悶頭作一兩年, 發布乙個很大的很全的但可能是不合使用者本意的系統. 敏捷開發的發布週期通常是兩周到兩個月, 它不要求每次都要發布很多的內容, 但它要求最好要向你的終端使用者頻繁發布你的最新版本.
所以, 從這一點來看, 敏捷開發與傳統開發, 最大的不同點正是在於"敏捷"二字, 而其對使用者的具體表現就是: 使用者可以拿到新版本的週期由一兩年大大縮短到了兩周到兩個月。
我心中的敏捷 3 兩種世界觀
在瀑布模型中,一旦發生需求變化,給專案帶來的風險是巨大的.而如果不變,那很可能作出來的東西就不是使用者想要的東西,那這個東西對於使用者而言還有什麼意義?所以,在瀑布開發模型中,不管開發團隊願意不願意接受需求變更,這種變更的客觀事實已經給專案本身帶來太多的風險.而敏捷開發呢?是不是就沒有瀑布模型的那些...
敏捷的世界觀
有一種相當流行的軟體方法學要求對乙個專案分配35種不同的角色，包括架構師 設計人員 編碼人員 文件管理者等。敏捷方法卻背道而馳，只需乙個角色 軟體開發者，也就是你。專案需要什麼你就做什麼，你的任務就是與客戶緊密協作，一起開發軟體。敏捷依賴人，而不是依賴於專案的甘特圖和里程表。這大概是全棧工程師吧，哈...
我的世界觀
我的世界觀 阿爾伯特 愛因斯坦 我們這些總有一死的人的命運多麼奇特！我們每個人在這個世界上都只作乙個短暫的逗留 目的何在，卻無從知道，儘管有時自以為對此若有所感。但是，不必深思，只要從日常生活就可以明白 人是為別人而生存的 首先是為那樣一些人，我們的幸福全部依賴於他們的喜悅和健康 其次是為許多我們所...