Software Development Story 01 - User Story, ATDD and BDD

  1. 1. 軟體開發故事01 - 使用者故事 User Story, 驗收測試動開發 ATDD -Acceptance Test Driven 與 行為驅動開發 BDD - Behavior Driven Design
    1. 1.1. 很久很久以前,軟體開發的形狀是醬子的
    2. 1.2. PM 在做什麼?
    3. 1.3. PM 最重要的是什麼?:
    4. 1.4. 要怎麼訓練大家有相同的溝通方式和基礎呢??
    5. 1.5. Day 1
    6. 1.6. Day 2
    7. 1.7. Day (D-1)早上
    8. 1.8. Day (D-1)晚上
    9. 1.9. Day D
      1. 1.9.1. 從上面的故事中我們觀察到了什麼??
      2. 1.9.2. 你對於這個團隊的感覺是什麼?
      3. 1.9.3. 思考一下,對於這個團隊最有幫助的可能是什麼?
    10. 1.10. 什麼是使用者故事 User Story?
    11. 1.11. 由User Story 衍生出的 ATDD、BDD

軟體開發故事01 - 使用者故事 User Story, 驗收測試動開發 ATDD -Acceptance Test Driven 與 行為驅動開發 BDD - Behavior Driven Design

很久很久以前,軟體開發的形狀是醬子的

在大多數軟體開發的歷程中,當老闆藉由市場資訊以及用戶需求,口述軟體想要什麼樣子的操作,希望得到什麼樣子的結果,甚至對於軟體的細節,像是用辭字句,甚至是顏色等等。

於是,使用者和工程師之間,就會不斷地在開發與驗收的過程中產生溝通的問題。

為了解決使用者與工程師之間溝通(雞同鴨講)的問題,於是乎創造出一個職位叫做PM,擔任團隊的溝通窗口,建立一道防火牆,避免老闆因為專業度的不足,做出難以達成的目標,軟體成果無法交付,或是對於團隊直接指導棋,造成團隊向心力潰散。

PM 在做什麼?

PM的出現是來解決問題的,為了向老闆報告,於是工作開始細分成一包包的工作包,介定要作的範圍、時間以及要花的成本,避免品質落差太大,所以要做品管,對內要做好團隊成員的團隊建立,團隊溝通的方式,管理風險,以及外包、採購的管理。最重要的任何一個可能會影響專案成敗的利害關係人都必須打點好,專案才有可能順利結案,老闆才能拿到如專案計劃所規劃的產出(軟體)。

PM 最重要的是什麼?:

如果PM不懂技術,就會再長出一個System Analysis或是System Architecture的角色,如果PM不懂營運,就會再長出一個Business Analysis的角色,如果專案太大,就會再長出一些小PM,將專案分切成許多小專案。如果專案成本金額太高,財會部門會來幫忙,如果PM不懂時程規劃,就會再長出一個跟催(Expeditor)的角色,PM不懂品質管制,就會長出QA和QC,如果PM不懂任用人事,就會有Functional Manager或HR介入,如果PM不懂工具,MIS會來幫忙,如果PM不懂外包,就會由採購來介入。

一個團隊之所以變得如此偉大(真的要搞到這麼大??),由此可見PM的重要性!!!

一個PM就要練就各式各樣的溝通模式(簡稱:見人說人話)身為一個團隊的窗口,能夠做到將老闆的表達,清楚地轉化為團隊不同成員之間可以正確理解的話語、文件或是其他形式的紀綠。管理團隊成員能夠在時程之內交付產出。

故事從這裡先停一停。反思一下可能存在的問題。

要怎麼訓練大家有相同的溝通方式和基礎呢??

舉個團隊日常的故事當例子吧

出場角色表 職責說明
User 軟體所有權有者
PM 出張嘴的防火牆
軟體工程師1 前端開發者
軟體工程師2 後端開發者
Art UI/UX,出圖都靠他
QA 替User做早期驗收,對程式測試有足夠的了解,避免交付出太糟糕或是問題一堆的軟體,有時候沒有這個角色,大多是不進行測試,責任對內由工程師扛,對外由PM扛
用戶 市場上真正的軟體操作者

Day 1

Scenario 01: 地點-老闆辦公室

  • User: 幫我們的APP做一個登入的功能,當使用者登入後要看到首頁的內容。
  • PM: 好,我請團隊評估一下所需要的時間。應該一個星期可以完成。

Scenario 02: 地點-團隊會議室

  • PM: 老闆說APP要一個登入的功能,使用者登入後要看到首頁的內容。(90%老闆的表達原文轉錄)
  • 工程師1: 只要登入就好?要不要Facebook Login? 要有人上去fb後台設定後,我才能串接哦
  • 工程師2: 要開那些欄位?長度多少? API那記錄那些東西?不要不自動登入?OAuth咧?JWT?
  • Art: 是不是給底圖和色碼就好了?
  • QA: 等你們做完我再測(繼續滑手機)

[email protected]#$%^&[email protected]#$%^& 七嘴八舌分隔線 [email protected]#$%^&[email protected]#$%^&[email protected]#$%^&[email protected]#$%^&

[email protected]#$%^&[email protected]#$%^& 七嘴八舌分隔線 [email protected]#$%^&[email protected]#$%^&[email protected]#$%^&[email protected]#$%^&

[email protected]#$%^&[email protected]#$%^& 七嘴八舌分隔線 [email protected]#$%^&[email protected]#$%^&[email protected]#$%^&[email protected]#$%^&

  • PM: 我再去和 User 確定好了

一天過去了,一天過去了,一天過去了,一天過去了
(除了PM之外,團隊都沒在忙)

Day 2

  • PM: User說登入用帳號+密碼,想要早點拿到,Facebook登入要不要做都可以,自動登入如果有的話是最好的了。User 不懂什麼是OAuth,什麼是JWT,你要用簡單的話說,不然我也不知道怎麼和User解釋
  • 工程師2: 不懂不要做最好了,那帳號欄位長度多少?密碼強度呢?怎麼沒問呢?
  • PM: User才不懂那些東西,你照上次專案怎麼做就copy一份來接著做。
  • 工程師1: 我畫面拉好了,等著後端做好之後,我再來串。以防萬一,我把JWT的code貼一份到程式裡放著,要用的話馬上就有了。(自信滿滿)
  • Art: (好像沒人理我,我自己出個RWD設計好了,以免被人說我沒做事)
  • QA: 等你們做完我再測(繼續滑手機)

Day (D-1)早上

  • PM: QA東西測了沒? 明天要交
  • QA: 東西還沒給我測試,誰知道他們在慢什麼,太晚給我,我又要加班測了,喂!PM,我要登記申請今天的加班。
  • 工程師2: 我也要,如果QA測有問題的話,我也要加班來改。
  • 工程師1: 避免你們改了什麼,要害我修改APP,原本要去約會的,只好改天了。
  • Art: 大家都加班了,我也加班stand by好了。
  • PM: [email protected]#$%^&[email protected]#$%^&…..

Day (D-1)晚上

  • QA: (測試中)
  • 工程師1: (看ptt)
  • 工程師2:(看youtube)
  • Art: (看pinterest)
  • QA: 這裡好像怪怪的,為什麼帳號輸入特殊符號也可以登入,你們在寫程式的時候自己都不測的嗎?
  • 工程師1: 後端要擋一下呀!
  • 工程師2: 前端為什麼不擋?

(各自念個兩句後,就開程式起來改了)

  • QA: (繼讀測試)
  • 工程師1: (看ptt)
  • 工程師2:(看facebook)
  • Art: (看Dcard)
  • PM: (好了沒?)

幾個循環之後,功能完善了,QA也驗完了
  • PM: 大家這麼努力為工作付出,有這麼好的團隊真的太幸福了。大家可以下班了。
  • 眾人: (眼神死)很多東西一開始就講好,如果夠清楚的話,也不用最後再來一直改….

Day D

Scenario 01: 地點-老闆辦公室

  • User: 這..做出來的東西好像和我們一開始說的不一樣…怎麼多了一個驗證碼?
  • PM: 我會開一張ticket,請團隊拿掉。

Scenario 02: 地點-團隊會議室

  • PM: 是誰自動主張把驗證碼加上去的?
  • 工程師2: 我們的網頁專案一直都有驗證碼的功能…
  • 工程師1: (JWT的code這次沒用到,躺著裡面不會被發現吧)
  • ART: (iPad不用測呀?我有做,不過好像沒什麼人關心)

從上面的故事中我們觀察到了什麼??

  1. 溝通很重要
  2. 每個人都覺得自己是個很好溝通的人(尤其是PM)
  3. 當下說好的東西不一定照著做,可能會受到以往的經驗而做出自己的判斷

當然,或許你有其他的觀察,我們留到後面再說。

你對於這個團隊的感覺是什麼?

  1. 還算可以的團隊,至少東西有做出來了
  2. 好像還可以更好?

思考一下,對於這個團隊最有幫助的可能是什麼?

  1. 有效的溝通
  2. 與User確認過的,一份大家都看得懂的好的規格書

什麼是使用者故事 User Story?

回顧一下軟體開發的第一天 User說的話

「幫我們的APP做一個登入的功能,當使用者登入後要看到首頁的內容。」

這句話,其實就是一個典型的User Story。

我們稍微改一下描述。

1
2
3
4
As an User,
I Want a login feature.
When I login,
So That I Can see Main Page.

對於User來說,完整地說出一個故事,就已經是相當盡責的User了。接著呢?PM和團隊要設法將一個個的故事拆解,變成許多工程師可以實作的功能,並且可以滿足故事的測試用例。好讓QA可以測試,一同做出使用者可以驗收的產品。

由User Story 衍生出的 ATDD、BDD

拆解成可測試用例的動作就是所謂的ATDD, Acceptance Test Driven Design

關注於使用者的操作行為所需要的功能拆解就是所謂的BDD, Behavior Driven Design。

以下介紹 Gherkin 語法,用自然語言來定義與描述測試用例

1
2
3
4
5
6
Feature:
在APP實現一個登入的功能
Scenario:
假設(Given),存在有一個可用的帳號與密碼
當(When),使用者開啟APP,輸入帳號,密碼,點選「登入」
然後(Then),要看到首頁的內容。

如此一來,我們就能夠將一個個的使用者故事,轉化成一個個可以讓大家容易理解的測試用例,工程師知道怎麼做,QA知道怎麼驗,使用者在驗收時就一定會買單了。

(美美的畫面如何測試與驗收,留到UI Testing時再來說,一般而言,一定也可以用Gherkin語法來闡述有關UI/UX的測試用例)

(後話):Gherkin語法和企管學裡的 STAR 非常地像,在大公司裡,或多或少都會用STAR語法來寫HR最喜歡的績效評量(Performance Appraisal)或是在面試時用STAR來檢驗應徵者的描述是否完整。
S: Situation, T:Task, A:Action, R:Result

那麼要如何正確地寫出好的Acceptance Test Cases?
要怎麼樣做會更好??

<未完待續>