敏捷web設計與其說是一個過程，不如說是一種哲學。但在我們開始之前，這裏有一個小的曆史教訓。

　　2001年冬天，在猶他州，一群軟件開發人員聚集在一起，創建了一份關于開發的最具啓發性的文檔：敏捷宣言。該宣言将繼續激發一種全新的軟件開發方法，這反過來又将成爲設計師和開發人員用來處理各種不同項目的方法。

　　今天，敏捷項目開發是一種流行的、高效的網站設計方法。讓我們看看它是如何工作的。

　　分解宣言

　　根據敏捷宣言，這個過程并不是關于構思一個項目，然後讓它實現傳統意義上的成果——也就是說，完成它，然後再調整。相反，敏捷項目管理側重于一個持續的、靈活的過程，它依賴于一組人在項目的整個過程中輸入想法。

　　當然，這種思想背後的開發者也相信，全面的文檔、工具、合同談判和遵循計劃都有真正的價值。然而，敏捷開發的原則與這些方法是對立的。因此，敏捷開發将價值放在個人及其交互、工作軟件、客戶協作和對變化的持續響應之上。

　　敏捷與瀑布：區别

　　根據敏捷開發背後的原則，傳統的“瀑布式”設計和開發網站的方法可能會非常低效，使網站無法在合理的時間内充分發揮其潛力。但有什麽區别呢?

　　瀑布法有其優點。以下是它的工作原理，從一個項目計劃開始。在任何類型的web開發可以開始之前，設計者必須有一個清晰的願景和一個明确的目标。規劃階段是預先準備的，而且相當廣泛。因此，瀑布式web開發人員通常可以準确地估計項目的時間表和預算。開發人員通常可以在項目上提供極快的周轉時間，但隻有在計劃完成之後。

　　然而，瀑布法失敗的地方在于它的剛性。如果項目設計需要在整個過程中的任何時候進行更改，則該過程将完全停止。開發人員必須重寫計劃，重新考慮整個項目。

　　如果項目的一個已完成的步驟需要更改，那麽在不中斷項目其餘部分的情況下進行必要的更改幾乎是不可能的。因此，在項目接近完成之前，開發人員很少可以要求對項目進行反饋。一旦出現問題，很難做出回應，而且如果有必要進行修改，可能會很耗時，而且可能會很昂貴。

　　另一方面，作爲一種方法論，敏捷是非常靈活的。一些開發人員将其描述爲“自由形式”的項目設計。使用适應性計劃，敏捷的web設計師一次隻處理項目的一小部分。客戶有固定的輸入，并且設計不斷地被測試。

　　如果需求經常發生變化，或者客戶心中沒有明确的最終目标，那麽敏捷web開發将是一個巨大的福音。因此，設計師可以很容易地适應和融入新的想法。當項目使用敏捷方法開發時，客戶将緩慢但肯定地開始澄清他們的需求。如果你在做一個實驗性的設計，敏捷開發是一個完美的方法。事實上，它甚至可以将設計項目的時間線縮短一半。

　　Scrum方法

　　對于許多使用敏捷項目開發的設計師來說，scrum方法是過程中不可或缺的一部分。這個短語是從橄榄球中借來的;在一個scrum中(scrummage的縮寫)，所有團隊成員聚在一起制定計劃，然後各奔東西。他們仍然是一個有凝聚力的團隊，但每個人都履行自己的職責。任何時候，當球出界，或者比賽被打斷時，團隊會回到一起參加下一個scrum——快速讨論他們下一步需要做什麽，以及需要對策略做出什麽改變。

　　敏捷web設計師和其他項目開發人員在項目的每個階段都使用相同的持續通信，通常是一天一次或多次。使用敏捷，團隊是自組織和高度協作的，因爲沒有人是團隊的領導者;相反，團隊成員集體決定如何處理問題。客戶是團隊的積極參與者和成員，被稱爲項目的“所有者”。項目業主提供指導和指導。

　　Scrum檢查可以讓客戶了解(并滿意)進展情況，同時也可以讓設計師實時适應變化。由于最初的溝通不暢，沒有人必須争先恐後地撤銷或重做大量的工作。

　　最後的想法：你會變得敏捷嗎?

　　如果你——無論你是客戶還是網頁設計師——有興趣與一個聰明而有興趣的團隊進行協作和動态的合作，也許是時候考慮一下敏捷方法，讓你的下一個項目變得生動起來。一旦你開始敏捷，你可能就不想回去了。