15 days ago

最近幾次上課同學都有問到 !? 的問題。因為已經回答三次了,覺得應該足夠做懶人包。

Ruby 中的 ! 與 ?

加在 method 後面,如 empty? 或 gsub!

在 Ruby 中,method 的命名,是允許後面加一個 !? 結尾。

一般的慣例是,如果

  • 設計一個 method 後面有 ?,如 empty?,表示回傳值「預期」會是 (boolean) true / false
  • 如果一個 method 後面有 !,如 gsub!,表示此 method 執行,「預期」會改變原物件裡面的值。

(如果你自己設計的 method,加 ? 其實不會自動轉 true / false,這只是一個「大家認為」「預期」應該的慣例)

2.0.0-p195 :001 > string = "ABC"
 => "ABC"
2.0.0-p195 :002 > string.gsub("A","a")
 => "aBC"
2.0.0-p195 :003 > string
 => "ABC"
2.0.0-p195 :004 > string.gsub!("A","a")
 => "aBC"
2.0.0-p195 :005 > string
 => "aBC"

加在變數前面,如 !current_user

! 前面表示相反值。

if !current_user:若 current_user 不存在

! 與 = 放在一起,如 !=

!= :就是 不等於

( current_user ) ? current_user.name : "Anonymous"

三元判斷式:上面這一段等於

if current_user
   current_user.name
else
  "Anonymous"
end

!!

!! 把該物件轉成 truefalse

2.0.0-p195 :008 > a = "a string"
 => "a string"
2.0.0-p195 :009 > !!a
 => true
2.0.0-p195 :010 > b = nil
 => nil
2.0.0-p195 :011 > !!b
 => false

Rails 中的 ! 與 ?

save 與 save! / create 與 create!

Rails 中的這兩組 save 與 create 與行為與 Ruby 的不太一樣。

其中 save / create,遇到過 validation 時,只會回傳 truefalse。但有時候我們要 debug 一個表單,有時候一直不知道為何表單為何沒成功一直 false,有時候會使用 save!create! 去 debug。這兩個 method 會 throw ActiveRecord::RecordInvalid exception 中斷程式。明確的告訴你壞在哪邊。

Rails 4.0 以前的 method?

在 Rails 4.0 以前的版本。若你有一個 boolean attribute 叫 is_admin。你可以直接在程式碼裡面呼叫 is_admin? (不需另外包裝)就會回傳 true / false

Rails 4.1 + 這個版本的 ! 與 ?

Rails 4.1+ 內建了方便實作類 state machine 的 enum 。!? 會自動幫你變更狀態和查詢狀態。

class Conversation < ActiveRecord::Base
  enum status: [ :active, :archived ]
end

# conversation.update! status: 0

conversation.active!
conversation.active? # => true

conversation.status  # => "active"


# conversation.update! status: 1

conversation.archived!
conversation.archived? # => true

conversation.status    # => "archived"


# conversation.update! status: 1

conversation.status = "archived"

# conversation.update! status: nil

conversation.status = nil
conversation.status.nil? # => true

conversation.status      # => nil


可以看到一些微妙的差別。


廣告:歡迎參加 亞洲首次的 Ruby on Rails 年會 - Rails Pacific 9/26-9/27。有亞洲全明星及講師以及多場實用 Workshop。 7/31 前報名早鳥票台幣 5000 元。請速搶購。

 
20 days ago

og-image.jpg

首先,要很高興的跟大家宣布,亞洲首次的 Ruby on Rails 年會 - Rails Pacific 要在台灣籌辦了!

時間會是在 9/26-9/27 (五、六)。在 RubyKaigi 的後一週。請大家幫忙宣傳這個活動。

這個 Conf 會是一天 Workshop、一天 Conf 的形式。我們邀請了幾乎是亞洲全明星級的 Speaker 來台灣做演講和工作坊。此次機會十分難得。敬請把握。

票價是台幣 5000 元。學生票是 3500 元(需附有效學生證,限碩士以下)。

大會網址:http://railspacific.com/

為什麼要有這個 Ruby on Rails 年會?

東南亞幾個國家的主要幾個明星級講者,甚至是 Conf 主辦方,其實都是互相認識的。大家聊天的想法,都是亞洲各國除了要有自己的 RubyConference 外,也應該要有一個共同的 RailsConference。

(美國有自己的 Rails Conference ,歐洲有 RailsBerry,北歐有 Frozen Rails ,就是亞洲沒有)

而各國的 Ruby Conference 當中其實非常矛盾的是:明明很多人職業是 Rails Developer,很多講題也是針對 Rails 為主,卻只能塞在不到一半的 Session 席次。我們希望有一個專門只談 Rails 的 Conference。

為什麼辦在台灣

  • 台灣在東南亞島鏈上是中心點,大家飛來這邊機票費用不容易爆炸。
  • 台灣的 Rails Developer (想學,其實正在用)的人,其實在東南亞比起來算很高的。

我常常參加世界各地的 Ruby / Rails Conference,常跟世界各國 Rails、與國外想找 Rails Developer 的公司打交道之後。我發現幾件事:

  • Ruby on Rails 的需求量,永遠都處於大量缺乏人才的狀況。
  • Ruby on Rails Developer 薪水非常的高。
  • 台灣 Rails Meetup 的參與人數,在世界上比起來是非常高 active 的社群 ( 20-40 / per week, 40-100 per speech )

但問題是,即便台灣有這麼多想學且正在用的 Rails Developer,卻不知道「世界上哪裡有 Rails 工作」,哪裡有外國公司要找 Rails Developer,只能被動的等其他公司來台灣找人。

所以我們想辦一個 RailsPacific,把這個線牽起來,讓台灣成為 Rails 社群在亞洲的 Community Hub。

Conference 內容

亞洲的 Ruby Conference 多半集中在當地 Ruby 的應用(一半),以及一些 General 的 Rails 設計技巧(一半)。講題數量被壓縮,且整體 Rails 的 track 相對於 RailsConf(美國談論)的主題和水準是有差距的。

我們希望要辦就辦一點轟轟烈烈的,在亞洲就把水準拉上去。而且讓大家不必花大錢機票飛到美國去,在亞洲就能能吸收到這些經驗,學到這些技巧。

因此 Conf 的內容我們會集中在以下相關議題:各國的大型 Rails 網站的維運技巧。Rails Developer 如何自我成長。各國的社群籌組交流。學習 Rails 的進階的議題:如 Rails Internal 架構解析,如何 follow edge Rails,網站架構設計實戰等等...

這些一般很難在亞洲 Ruby Conference 出現的議題。

關於講者

Rais Pacific 這次請到全為亞洲全明星的陣容。為各位介紹一下陣容:

三位 Rails Commiter ( All times #21, #27, #34 )
  • Ryan Bigg : (大洋洲:澳洲)知名 Rails 書籍:Rails in Action 3 的作者,2011 Ruby Hero Award,Rails core commiter #21。
  • Akira matsuda : (亞洲:日本)知名的日本 Rails core commiter #27 ,Asakusa.rb 的創辦人。曾在 RailsConf 演講 Rails Internal 的主題。
  • Prem Sichanugrist : (亞洲:泰國)知名的泰國 Rails core commiter #34,在 thougtbot 工作,曾在多個 RubyConf 演講 Rails Internal 的主題。
六位明星級講者
  • ihower: (亞洲:台灣)台灣 RubyConf 創辦人,Rails Best Practices 作者
  • Shibata Hiroshi:(亞洲:日本)日本的 Ruby Commiter,在 Paperboy 公司任職,擅長大型網站運營經驗,且對設計架構、調校、追 Edge Rails 相當在行。
  • Richard Lee : (亞洲:台灣)iCook 創辦人兼 CTO,iCook 有多威大家都知道了
  • Christopher Rigor (亞洲:菲律賓)Engineyard 亞洲區 Application Support Team 的頭,Rubyconf PH 的主辦人
  • Nick Sutterer (德國,現居澳洲)知名 Gem : Cells, Reform 的作者
  • Ding Ding Ye (亞洲:中國)RubyConf 2013 籌組人,敏捷項目管理工具「風車」的創辦人。知名 Podcast:Teahour 的創辦人與主持人。

為什麼一天是 Workshop

我們去過一些 Conference,發現若「只」舉辦 Conference 其實是對聽眾較不足的。

  • 不會所有議題都有興趣聽,有時候會跳過
  • 動手比較能記住東西

所以有時候去一個 Conference,記都記不得這次聽過什麼

而這次我去 RailsConf,有一軌就是單純只開 Workshop。而大家對於這屆 Workshop 的水準讚不絕口(甚至有從來沒在市面上出現過的整天 Elixir Workshop,教得超經典超贊的,光這個 Workshop 就值得那張門票了...)

我們做過調查,發現大家在日常工作,或是來聽 Conference,有幾個議題是在亞洲大家都想學,也比較弱的:

  • TDD
  • Refactoring
  • Object-Oriented Design
  • Performance Tuning

這些議題很難用一兩個 session 講完,而且這些投稿 session 通常也是一些 tips 的集合,聽完也缺乏實作機會,不知所以然。而國外有這些的實戰 Workshop,但學習這些技巧,不僅要自費飛去,而且門票也不便宜(約 700-1500 USD)(還要加上機票約 1200 USD)。

在實際運作社群的時候,我們發現 Workshop 才是有效能夠提升 Developer 技能的活動。因此也希望在這個活動,舉辦 Advanced 級的 Workshop。一舉能拉昇提升亞洲地區普遍的 Rails 實力。

為什麼門票這麼貴?要 5000 NTD

其實,世界各國的 Ruby/ Rails Conference 價格都是都是大概介於 150-750 USD 左右的價格。比如說

  • RailsConf 22500 台幣
  • Reddot Ruby Conf 5000-9000 台幣(按照購買時間)
  • RubyConf PH 6000 台幣
  • RubyConf AU 14000 台幣

我們希望在台灣辦一個讓國際認可的高品質國際研討會。同時藉著這個 Conference 能夠打開台灣的 Rails 國際知名度以及同時提升亞洲地區的開發實力。所以邀請了很多亞洲頂尖的高手來台灣參加這個盛會,想辦好這種等級的 Conf 經費就容易墊高。

而這個價格:含了一天的 Workshop 以及一天的明星級講者演講。說實在 5000 這個價格也並非算高(一個 Workshop 就值回票價了)。

通常如果你要參加這種等級這種講者的活動。往往需要的費用會是: 15000+ (機票),10000+ (住宿),5000+ (Conf 門票 )。

在 7/31 前門票會是 5000, 8/31 前門票會是 6000,之後是 7500。

你們在 Conf 期間還會有什麼活動?

  • 我們會廣邀美國以及亞洲對 Hiring Rails Developer 有興趣的的公司進行 Recruiting 的 Event
  • 期間應該也會有初階的 Workshop 會舉辦

請用力轉帖

希望大家踴躍參與 Rails Pacific 這個年度盛事,以及轉貼給對 Rails 有興趣的 Developer 知道有這個活動,這個講者陣容以及演講內容非常的難得。在亞洲其他國家也幾乎沒有出現過,請把握機會。

 
about 1 month ago

這是剛上過這個 Workshop 的學員心得與筆記。

如果你很需要這方面的專案滅火訓練,歡迎報名七月班,早鳥報名(折扣 NTD 1500) 到 7/10 晚上截止。

若有五人以上的公司團報需求。請來信洽 hello@rocodev.com

 
about 1 month ago

為什麼我覺得 User Story 是學會專案控制很重要的一環。是因為我發現長久以來,很多開發者 do project management the wrong way。

事情做不完的根本原因是很難分清楚:手頭上的東西是「異想天開的想法」「也許改天再做也可以的想法」「真正對專案有重大貢獻的想法」還是「完全不需要實作的想法」。

在不把「真正對貢獻的想法」以及「真正對專案有重大貢獻的想法」梳理出來之前,你不可能知道在給定時間內,有多少資源讓自己能夠準時交付對專案有貢獻的 code。更不可能知道,在時間緊迫之下,哪些「想法」是可以被無情地刪除的。

因此專案延遲是相當正常的。

在最近上課後跟學員交流之後,我更從互動中發現,為什麼有些公司導入 Scrum 會失敗,是因為到 RD 手上的時候,其實 Ticket 都已經被切好。而這些 RD 是在「完全不知道原始故事長什麼樣的狀況」的情境去實作這些 Ticket 的。所以就容易做出歪掉的產品,而因為歪掉,就會在 Acceptence Test 被打回去。

許多 delay 或做歪的專案,問題都在原始 requirement 或 goal 並沒有被專案中負責執行的人好好理解,然後再化之為能夠執行的 Tickets。

而 Issue Tracking System 也淪為「掛想做的任務的工具」,而不是「管控」「應該被做」的「管理任務工具」。

在此前提下,更不可能將專案所收斂。

把該做的事情分離出來

所以如果要真正貫徹 Agile。第一件事情就是要把「該做的事情」好好的分出來。

以此為出發點。再去學如何做 Story Valuation,Velocity,Priority 管控。

在這過程中,後續使用更多的 communication tool 、collaboration tool、continuous delivery tool 排除協作中所會遇到的障礙。

然後,你才會開始看得懂: 那些敏捷開發的書到底在講什麼。哪些你可以用,哪些你不需要用。為什麼 scrum 某些方法 work,哪些方法不 work。

為什麼你花時間讀完一本 scrum 教科書,你的團隊卻還是敏捷不起來。

我想真正的關鍵在這裡。

 
about 1 month ago

這是剛剛在社群頻道上閒聊的結論。

因為我最近在教 Rails 進階班,都用 Github Pull Request 在收學生作業。

作業進度無所遁形

這個方法非常有效率,因為:

  1. 有效掌握學生何時交作業,避免理由伯。
  2. 可以讓助教線上共同批改。
  3. 學生可在 pull-request 直接發問。
  4. 可互相參考解答。

容易檢驗抄襲

所以我想大學資工系其實應該也可以比照辦理才是?比起之前用 FTP 上傳,這個方法實在有效率太多了,而且也可以驗證學生是不是自己寫的。

  • 如果是自己寫的必有 commit log
  • 就算參考其他人的解法也沒關係,起碼 (1) 他有辦法學到怎寫作業 (2) 抄襲者還是可以用 CI Server 做批改魔挑出來打 0 分。
  • 容易設定死線

逼迫大家共同作業

更進一步的用法我還想到,可以用 Gitbook 寫課程共筆或共同寫期末報告。

這樣同組誰偷懶就一目了然。而且還可以訓練用 git co-work 的能力。

培養未來競爭力

而且 Git 現在幾乎是軟體開發界、寫作電子書界、參與開源專案必備的技能。

讓學生直接贏在起跑點上,應該是可以稍微扭轉一下台灣軟實力的劣勢。

學習資源:

至於哪裡可以學使用 Git?教 Git 會很難嗎?

Code School 已經寫了一份免費的 Git 教材 Try Git 。老師連準備教材的時間都省下來了...XD

update: 密西根大學有老師今年也這樣收作業:http://ivory.idyll.org/blog/2014-teaching-undergrads-with-github.html

 
about 2 months ago

因為在編教材,覺得這很基本也很重要。所以特別來出來寫。

helper_method

在 controller 裡面的 method 不能在 view 裡面用。

也就是在

class ProductsController
  def find_cart
    @cart = Cart.find(session[:cart_id])
  end
end

View 裡面不能用

   <%= find_cart.items %>

拉這個 cart 出來直接用。

如果你要在 controller 和 view 都能拉現在的購物車,必須要用 helper_method 宣告這是一個 controller 級的 helper。

class ApplicationController
  helper_method :current_cart
  def current_cart
    cart = Cart.find(session[:cart_id])
    return cart
  end
end

這樣你就能在 View 裡面用 current_cart。

   <%= current_cart.items %>

或者是 Controller 裡面也能用 current_cart。

class ProductsController
  def add_to_cart
    find_cart.items << @product
  end
end

view_context

在 helper 裡面的 method 不能在 controller 裡面用。
也就是在

class ProductsController
  def show
    @page_description = truncate(@product.desc, :lenght => 50 )
  end
end

是不會動的。

如果要在 controller 裡面取用系統內建的 Rails View Helper,或自定義的 View Helper。
必須要用 view_context 去調用。

class ProductsController
  def show
    @page_description =  view_context.truncate(@product.desc, :lenght => 50 )
  end
end

小結

但基本上還是建議在 View Helper 與 Controller 的 code 不要互相混來呼叫來呼叫去。讓 View 歸 View,Controller 歸 Controller。若真有業務上的需求需要「到處都可以用」。建議寫 Module 掛在 lib 用 mixin 技巧混入。

 
about 2 months ago

這是剛上過這個 Workshop 的學員心得與筆記。

如果你很需要這方面的專案滅火訓練,歡迎報名六月班,早鳥報名(折扣 NTD 1500) 到 6/10 晚上截止。

(五月班)

 
about 2 months ago

Intro to Rails Workshop X COSCUP BOF ( Taipei #02)

首先,我要先宣布 Intro to Rails Workshop Taipei #2 會將在 7/19(六)舉辦!

報名網址在:http://tw-rails.kktix.cc/events/rails-outreach-taipei-02-coscup

時間地點在 7/19 (六)COSCUP 的 BOF 時段與場地 ( 18:30-22:00),這次我們開放名額為 60 人

因為上次 #1 的 workshop 有人抱怨說臨時宣布結果名額報不到,因此這次報名時間是從 6/4 (三)10:30 開始,請大家明天早上準備好開始搶票...。這次也一樣需要地方的教練支援,教練報名網址在此

Building Rails Workshop ( COSCUP 演講)

另外不管你是 Ruby on Rails 社群的朋友,或者是別的語言社群想辦 Workshop 的朋友,我在 COSCUP 7/20 (日)14:10 - 14:50 會有一場 Talk,分享辦 Rails Workshop 與推廣 Ruby on Rails 的經驗與技巧,歡迎各位參加!


RailsP2P program

第二件事就是這個令人興奮的 RailsP2P program: http://railsp2p.tw 。(學習機會與教練媒合平台)

10419933_306479536178221_881628148_n.jpg

在籌辦過三場 Workshop (北中南)之後,我們發現 Ruby on Rails 在台灣教學的需求非常非常的猛烈。從社群幾次 Workshop 報名的速度以及我的著作 Rails101 的銷售數字。我們估出了大概全台灣現在有興趣入門學習轉職成 Rails Developer 的人大概有 1000-2000 人左右。

學習 Rails 並順利轉職目前有三個階段:

  1. Intro to Rails (了解 Rails 基本架構與環境)
  2. Basic Rails Development ( Rails 基礎開發技巧與結合 Gem 開發功能、簡單的 deploy, see Rails101 as example )
  3. Intermediate Rails ( Rails 程式實戰開發 / 軟體規劃能力 )← 求職標準

我們發現一個殘酷的現實:即便再怎麼努力辦免費的入門 Workshop,一場以 40 人為計。我們就算一年辦 20 場,都消化不完這個需求(且每辦一次 workshop ,主辦單位都要至少招募 10 個以上的助教)。

如果要能有效地推廣 Rails,那我們應該要做的不是把開 Rails Workshop 的責任攬在主辦單位身上,而是把機會開放給每一個社群開發者:

最後,我們想出了一個遍地開花計劃:

RailsP2P: http://railsp2p.tw 。(學習機會媒合平台)

教練資格

如果要讓大家能夠更快更容易的得到學習 Ruby on Rails 的學習機會,社群不應該把 Rails 的教學資格壟斷在某些人手上,取而代之的應該是的創造點對點遍地開花的教學架構。

經過評估測試過,目前的 Workshop 教練需求條件:

  1. 學習 Rails 超過三個月的時間有能力教 Intro to Rails
  2. 學習 Rails 超過一年的時間有能力 Rails101

透過 RailsP2P,人人可以上網找 Rails 教練,不管你住在台灣的哪裡,都有辦法得到 Ruby on Rails 的現場指導機會。

讓想學 Rails 的開發者,指定想學習的教材與時段,刊登需求聘請私人 Rails 教練一對一的教你(各地都可以)。

刊登學習步驟:

螢幕快照 2014-06-03 上午8.38.50.png

  1. 上網填寫你的學習需求
  2. 登記所在地 (在台灣的哪裡)及有空的時段
  3. 有興趣的教練實際聯絡進行教學

目前我們建議課程所學習的時間以及學費是 Intro to Rails : 4 hr (NTD 2000-4000)。Rails 101 : 8-10hr ( NTD 5000-9000 )

教練聯絡學員步驟:

  1. 上網看到有興趣的 case,進行應徵
  2. 登入 Github 帳號填寫簡單自我介紹以及背景
  3. 學員若對您感到興趣會寄信聯絡
  4. 雙方交換聯絡方式以及教學模式 / 地點 / 時段

人人都可以加入 Rails 教學的行列

這個需求刊登平台,從一開始就是為了解決各地的學習與教學需求而生,現在不會收仲介費,未來也不會收費。而且我們社群希望利用這個平台創作出新的職業契機:

很多 Rails 開發者在抱怨想回鄉工作,但家鄉卻沒有好的工作機會。有了這個平台,在家鄉教 Rails 也可以是一種職業機會。我們的台南社群朋友就開玩笑說:太爽了,這樣台南區的教學機會就都是他的了,藍海市場,幾乎沒人跟他搶 XDDDDD

想賺外快嗎?你可以嘗試一個月晚上教幾場 Rails,一個月下來的學費也有幾萬塊,不無小補。

希望 RailsP2P 可以創造一個人人有功練,人人有錢賺的正向學習環境,歡迎各位加入 Rails 學習 / 教學的行列

 
about 2 months ago

首先,感謝各位三年以來的支持。

為了讓更多人能夠學習 Ruby on Rails,加速 Ruby on Rails 推廣教育地進行。我決定將 Rails 101 的價格調降到 0。

螢幕快照 2014-06-03 上午7.16.38.png

購買連結還是以下這兩個網址

但從今天開始,你可以在 leanpub 上把價格調為 0 元,免費取得這本書

當然,練習完畢如果你覺得這本書有用,可以再重新付費給我。

Github Repo 在此:https://github.com/xdite/rails-101

 
2 months ago

眼尖的朋友看到,最近我開的兩堂課: Deliver Project on Time 敏捷專案管理實務 - 六月班Intermediate Rails - Rails 實戰就業班(六月),都加入了 User Story 撰寫的教學部分。紛紛偷問我為什麼要加這個東西進去?

Rails Meetup 三年多來,在輔導培訓過非常多 Rails Developer 之後,我開始發現當今的網站開發教育中漏掉了很重要的一環,就是「規劃 Application 開發的技術」。

線上教育什麼技術都有教:基本的 Ruby on Rails,基本的 jQuery,基本的 CSS。看起來好像你上了這些基礎班,就可以開始寫一個網站,找到一份工作。但這卻跟現實有一段相當大的差距。我訪問過很多徵才廠商和初級開發者,開始了解到問題出在哪裡。

具備網站簡單的開發能力只是必備的基礎,僱主最看重且會決定錄取的能力,卻是「把 Idea 變成實際 Application 的能力」。就是今天老闆開一個需求,員工要能做出規劃,並且在時間內執行完畢。

很多成長為 Senior Developer 的前輩沒有意識到這也是一門技術,所以面對「如何培養規劃實做能力」的問題,因此往往會覺得,你多寫習題就可以練成了,或找到一份工作被多操一下就會了。但這又回到雞生蛋、蛋生雞的問題,沒有能力寫出中小型 Application,又怎麼容易找到可以成長的工作。

打破雞生蛋、蛋生雞的循環:User Story as Architecure

我後來一直思考如何解決這個問題。才發現其實很久以前我已經解決了這個問題,只是我一直沒有意識到..,就是:「透過撰寫 User Story 的訓練,練習出如何設計架構的能力。」(這個技術四年來也一直在我部門/公司中施行訓練)

什麼是 User Story

User Story,是 Scrum 這個敏捷框架會用到的一個開發方法。具體解釋可以看ihower 曾經寫個的這份整理,寫的很棒。

傳統開發流程是 PM 花上很多的時間進行訪談寫成規格,RD 再轉成 Application。不過往往這個轉換過程中,卻容易出現相當大的風險。

當中的問題出在於 PM 的「規格」有很大的機會天馬行空,即使不天馬行空,也有可能不貼近使用情境,或者是根本脫離真實使用情境。RD 自然拿到規格和畫面 Workflow 進行「轉換」時,萬分痛苦。

當然,更多時候, RD 根本不知道要怎麼「轉換」。這就是為什麼每個專案都花了很多時間進行了需求訪談,也可能寫了詳細的規格,專案卻始終容易出包,都是在「轉換過程」中出現了問題。

User Story 強調透過一份簡單的情境規格,具體的描述出軟體在「使用者」的手上,是怎麼樣被「操作」的。能夠讓 RD 在開發時,能夠盡可能地貼近真實被需要的 Application。而不需要的功能,或者無法被實作的功能,將在一個一個循環之中,被捨棄。

初學的範本是:作為一個 (某個角色) 使用者,我可以做 (某個功能) 事情,如此可以有 (某個商業價值) 的好處。

幾個 User Stories 的範例如下:

  • 使用者可以在網站上張貼履歷
  • 使用者可以搜尋有哪些工作
  • 公司可以張貼新工作
  • 使用者可以限制誰可以看到他的履歷

為什麼 User Story 可以幫助培養開發能力

透過把冰冷的規格轉成具體的小情境,RD 可以更知道要怎麼將架構切分成較小且可以單次就開發完畢的小元件。利用一個一個小的故事,開發出一個一個的小功能,再堆疊成一個完成的網站。同時透過 User Story 的內容對比,RD 能夠開始有辦法排出輕重緩急,甚至估算出正確時程。

我發現很多入門的 Rails 開發者,在學完基礎的 Rails( 比如說學完 Intro to RailsRails turtorial。這些從 CRUD run 到 deploy 到 Heroku 的簡單一日課程之後。就無法再進行下去了....

根本原因是初學者不知道下一步如何進行自己點子的實作。

許多的書籍都有具體給定步驟與架構,因此在自行練習的時候沒有問題,但在自己自由設計題目時,卻不知道如何開展。或者是自己有了一點基礎想法,拍了某些網站的 screenshot & workflow。拿回家時卻不知道怎麼 breakdown。

這就是為什麼我在

都加入了 User Story 的教學部分。因為 breakdown to application, simple project management 就是新手進階成職業的一大瓶頸門檻。

為什麼非程式設計師也需要學習撰寫 User Story

在 Deliver Project on Time 敏捷專案管理實務 的五月班,有一位很有意思的報名者,他報名是因為長期參與 NGO 的活動,但卻覺得 NGO 的專案規劃以及執行專案能力不佳。因此想要透過上這個班,實際學習專案管理能力。

其實不只是 NGO,通常非程式設計師出寫出的規格通常都較脫離現實,是因為誤以為了軟體開發只要提供了「欄位」「畫面」「流程」「仿照知名網站的 Workflow),這樣就是完成專案的規劃。

事實不然,程式設計師往往希望你提供的是軟體使用「需求」,以及軟體「使用情境」,這樣他們才容易設計出好的軟體。很多規格書滿滿的 screenshot,或者是標注模仿某知名網站 Workflow。其實都不是程式設計師想要且需要的東西,他們希望你有辦法簡單敘述你要什麼,你想要的流程是什麼,你背後的生意邏輯是什麼。(a.k.a. 你真的知道自己在幹什麼)

好方便「程式設計師」後續「規劃」「軟體架構」。

User Story 可以很容易的協助雙方達成一致性的目標,因為User Story的書寫語言並不是什麼技術文字,而是一個又一個的情境。可以作為一個相當好,雙方又容易接受的橋樑。同時透過撰寫 User Story,自己也可以越來越釐清這個網站真正需要的東西是什麼,不需要真的實際寫程式,不懂程式也可以設計出合理的網站架構。

這就是我建議為什麼非程式設計師也需要學習撰寫 User Story 的原因。

學習資源

要學習撰寫 User Story 以及學習進行簡單的小專案管理。你可以購買 Scrum 系列的書,或者是以下幾本我覺得不錯的書:

當然,如果你想偷懶,最快的方式,還是報名我以下的這兩個講座 / Workshop。我有直接整理好的講義以及結合 Project Management 的實戰技巧。

希望以上這些學習資源能夠幫助到你。

( 如果你有相關的疑問,歡迎透過這個表單 聯絡我)

 

My Books

  1. #1 Rails 101

    Buy Rails 101
  2. #2 Maintainable Rails View

    Buy Maintainable Rails View
  3. #3 Lean SaaS

    Buy Lean SaaS