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版推出的絕佳配置,三個人能讓專案既有足夠的人力,也能保持流暢與敏捷。三個人的角色,可以是一位設計師、一位開發人員,和一位能在兩者之間切換的人。

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


熱門新聞

Advertisement