Web應用程式的敏捷開發方法學

Getting Real
掌握現實情境，掌握Web易變特性，建構快速上線、持續改進的流程
談到國外的Web 2.0代表網站，由37signals打造的幾個線上服務如Basecamp、Campfire、Backpack等，經常被視為經典範例，該公司將專案管理、即時溝通與個人資料管理等軟體Web化，並提供直覺易用的介面。

還有一個響亮的名詞與37signals連結在一起，那就是改變Web開發觀念與生態的Ruby on Rails，這個Web開發框架便是由團隊成員David Heinemeier Hansson在37signals網站開發中累積而來。

由37signals推出的《Getting Real》這本書籍，就是他們開發Web應用程式的經驗集結，這些法則讓他們打造出一個又一個成功的服務，而Ruby on Rails也處處反映著這些開發原則。

事實上，《Getting Real》屬於敏捷開發觀念下的實踐，並且針對Web的特殊性調整。相較於盒裝出品的軟體，總是隔一到兩年推出新版本，Web卻是隨時可以更新版本與改進，因此版號並沒有意義，而Web開發人員更應該善用這個特性，提升Web應用程式的價值。

簡單來說，《Getting Real》主張Web應用程式應該追求小規模、敏捷開發與高品質，因此開發時力求更少的程式碼、更精簡的功能、更少的文件與會議。它的開發流程通常由介面開始著手，因為這是客戶／使用者最容易感受、體會的地方，最容易溝通，因此比起大量的規格書與文件，書中指出，不如展現出一個真實網頁。也由於Web調整容易的特性，因此透過反覆式開發的流程，讓Web可以快速上線、調整與持續改進。

《Getting Real》在精簡一切背後，卻仍然能交付品質極佳的成果。這是因為它的開發方法中直擊真正要處理的問題，而不是關於問題的空想，它迫使開發人員面對當下。

書中直言這些思想並不是由37signals發明的，而是帶領他們成功的一些工作法則與實踐。因此這本書除了陳述了他們的想法，也常常具體談到他們在開發像Basecamp專案中的一些經驗。像是Basecamp在發展過程中如何利有限資源的「優勢」，初期的收費、網站架構規模等，都在書中分享給讀者。文⊙黃天賜

Blank Slate
空白的石板，意指初始介面
在介面設計上，《Getting Real》舉出應該設想三種介面，分別是常規、初始與錯誤介面，而這當中，最容易被開發人員忽略的便是初始畫面。

在開發階段，開發人員經常會用一些測試數據填滿介面，作為常規介面的內容。但是對初來乍到的使用者而言，並沒有太多的資料顯示在初始介面上，而這時介面對使用者夠不夠友善或吸引力，往往決定使用者的去留。

Chore
例行工作
開發人員應該把Web專案控制在可掌握的範圍，去享受開發過程，而不要將它視為例行工作，因為缺少應有的熱情，很容易從最終的產品上看出來，因此不管在選才或面對專案的態度，書中都再三強調熱情的重要性。

《Getting Real》對於熱情的宣揚並非只是一種美麗的口號或信仰，而是從專案應該如何組成、發展，到人員的配置、溝通上，都必須讓具有熱情的開發人員，更容易發揮他們的才能。

Code Speaks
程式碼會說話
對於開發人員而言，《Getting Real》認為要仔細去傾聽程式碼所說的話，它不但會與開發人員互動，也會給出建議，讓開發人員能找出好的解法。

當一個新功能需要花費數周的時間，動用上千行程式碼才能完成，這時程式碼便是在告訴你，也許還有其他不同，甚至更好的解法。因為讓程式碼保持簡單、輕巧，避開無謂的複雜，正是《Getting Real》對撰寫程式碼的建議。

Enthusiasm
熱情
在尋找適合的Web專案成員這個議題上，與其尋找專家，書中給的建議是不如尋找技術水準雖然不是最好，但卻是充滿熱情的人。書中認為熱情是偽裝不來的。

如何檢視一個人是否具有熱情，一個小技巧是讓應試者針對即將加入的專案提問，因為充滿技術熱情的人，往往會想深入問題與細節，並思考如何提供可能的解決方案。這樣的人，對於快速變動的Web專案，才能提供好的戰力。

Have an Enemy
設定敵手
Web專案成形之際，對於最終會發展成什麼樣子，剛開始有時是難以掌握的。《Getting Real》建議，不妨就設定個敵手，提醒自己別犯對方的錯。

Basecamp在著手發展時，便將微軟的專案管理軟體當作對手。面對龐然大物的軟體，開發團隊反其道而行，不讓專案管理軟體只是專案經理的工具，而讓它提供給所有專案成員進行溝通，而成功發展出新的解決方案。

Make Opinionated Software
做堅持己見的軟體
「偉大的軟體要有自己的理想，偉大的軟體必定有所主張」書中強調不要試圖讓軟體去取悅所有的使用者，而是必須有所捨棄，有所不為。書中以wiki的發展為例，它將傳統合寫文章的軟體的許多功能捨棄，像是標示出編寫者是誰，而這種態度與想法，讓wiki有所不同。

因此開發軟體時，不要企圖滿足所有人的喜好，而是讓使用者成為你志同道合的伙伴。

Meetings Are Toxic
會議有害身心
《Getting Real》對會議採取批判的態度，它認為會議會對生產力產生傷害，它不但中斷日常工作流程，讓工作時間變零碎，而且會議的品質要好，與會人士需充分準備，並能對會議主題聚焦討論，才能發揮效果，但這經常在理想狀態中才會發生。

書中建議，會議可以強制在30分鐘內結束，並盡可能地減少參加人數。不需要透過會議解決問題時，就別開會了。

Publicize Your Screwups
公開錯誤
Web的維護與支援，其實也是和Web用戶之間的互動，《Getting Real》認為如果系統發生了什麼錯誤，應該開誠布公地讓用戶知道。

書中指出，也舉了Basecamp曾經在半夜故障了數個小時，幾乎99%的使用者都不知道，但它們還是發了公告，清楚交待原因並致歉。他們認為多數的使用者在資訊透明的情況下，往往更能包容一些搞砸的事情。

Three Musketeers
三個步兵
保持精簡的人力配制是《Getting Real》認為發展彈性Web專案的重要原則。它認為三個人（文章標題比喻為步兵）是1.0版推出的絕佳配置，三個人能讓專案既有足夠的人力，也能保持流暢與敏捷。三個人的角色，可以是一位設計師、一位開發人員，和一位能在兩者之間切換的人。

人數少既可以讓溝通成本降低，而且好的團隊也會因為資源受限，而更能有效面對與解決問題。