Specification By Example

  1. 1. 軟體開發故事02 - 實例化需求 Specification by Example
    1. 1.1. 實例化需求 Specification by Example
    2. 1.2. 從上面的表格中我們觀察到「有什麼」??
    3. 1.3. 從上面的表格中我們觀察到「沒有什麼」??
    4. 1.4. 反思一下,這個團隊做了什麼樣子的改變??
    5. 1.5. 什麼樣的例子是好的例子?

軟體開發故事02 - 實例化需求 Specification by Example

前情提要:在驗收的 D Day 當天,User發現了預期之外的驗證碼功能,覺得這項功能在手機上不需要,所以PM只好回過頭來,要求團隊再花時間把多做的功能拿掉。

請大家思考一下,那裡可能出現了問題?

不過是一個小小的使用者登入的功能,User心裡所想的,PM心裡所想的,工程師心裡所想的,QA心裡所想的,Art心裡所想的,都有可能不一樣???

1990年,Elizabeth Newton - 史丹福大學心理學研究生,通過研究一個簡單的遊戲,提出了「知識的詛咒」(curse of knowledge),在遊戲的過程中(註1),會因為每個人的背景不同,教育不同,經驗的不同產生出一種認知的偏差。

以故事之中APP登入的功能為例

  • User認為他對於登入的描述夠清楚了。

  • PM知道其他APP是怎麼登入的而User提出的需求沒有太特別,一定做得出來。

  • 工程師1想的是APP其他型態的登入要不要做

  • 工程師2在意的是資料欄位的檢核,也許還要先開規格給工程師1

  • Art只能憑過去的經驗,把猜測要出的圖出一出

  • QA還沒進入狀況,等開發出來之後再來看

通常,一個團隊裡面,大多數會存在一個意見領袖,抑或是一個脾氣很大的人,或是比較強勢不讓步的人,這裡分別用工程師2的角色代入這個情境來看看。

  • PM: 老闆說不要放驗證碼
  • 工程師2:APP不加驗證碼的話,不就等於裸體上街一樣嗎,駭客知道你的API後一直打,後台掛掉你要負責嗎?
  • 工程師1:沒有人在APP上放驗證碼的。
  • Art: (小聲)UX的確不放驗證碼比較好。
  • QA: 你們決定好就好。

(幾個循環之後)

  • 工程師2:請尊重專業好嗎?資安你不懂啦,每個使用者登入都要檢核,放驗證碼是最簡單最基本的。(怒氣值+10)
  • 工程師2:舊專案的網頁有放驗證碼,後端的檢核機制是一樣的,你要給我2倍的時間把程式拉出來另外寫,當初你沒有說,所以估時間沒算到要加寫的時間。(怒氣值+10)
  • 工程師2:我有其他更重要的ticket,你要把一些ticket拿掉,這個當初是你沒有講清楚的,我不想加班幫你擦屁股。(怒氣值+10)
    (幾個循環又幾個循環之後)
  • 工程師2:改好了。
  • 工程師1(心想):舊的code先不砍好了,我有預感會加回來。
  • Art: 工程師1知道怎麼弄吧,自己砍就好了,設計沒有變,不用問我。
  • QA(心想):終於….

(此時生產線才開始活絡了起來,工程師1才開接後台,好了之後套圖,把之前的元件delete掉,好了QA才開始點個幾下,馬上交付給PM)

於是乎。User過了幾天後才拿到拿掉驗證碼的版本。

Scenario 檢討會議

  • 工程師1: PM 你要問清楚,需求不明確的話下面的人很難做事
  • 工程師2: PM 每次都把問題丟到團隊裡,事後再來說這裡不對、那裡不對
  • Art: (轉筆+發呆)
  • QA: 不要只會說 PM, 配合 PM 本來就是職責
  • PM: (怒氣+100)

Scenario 老闆辦公室

  • PM: 老闆下次可不可以多講一些?
  • User: 我是老闆還是你是老闆?

故事從這裡再停一停。反思一下上述已經發生的問題。

你看到了那些問題?

你覺得這個團隊的氣氛如何?是開心?還是很有凝聚力?

如果BDD、ATDD可行的話,為什麼還有這麼多問題呢?

有什麼方法可以讓這個團隊可以做出符合使用者期望的功能呢?

實例化需求 Specification by Example

我們來回顧一下團隊的需求金字塔

  • User: 我說的算
  • PM: 準時或提早做出符合使用者期望的功能
  • Art: 不要違背UX和美感
  • QA: 做出來的東西要能夠測試
  • 工程師2:在乎的是資料格式,檢核,串接、資安、系統穩定
  • 工程師1:需要知道要的的範圍邊界,登入的方法很多,有無窮多種可能性的登入方法,比方說Facebook Login,指紋登入,人臉辨識登入。

需求愈往下,就愈發散,創造各式各樣的可能性就愈多。

看起來,要讓需求不發散,避免各說各話,甚至是可以聚焦的一份好的規格文件。

然後,我們來看看這份好的文件要有那些優點?

  1. 大家都看得懂(廢話)
  2. 大家看完之後不會衍生出一堆黑人問號
  3. 對要製做的功能與文件的描述能要夠相符,User也可以買單

有人問我,為什麼PM寫的專案需求文件沒有人看?

裡面有scope time cost,quality… 想要找什麼,裡面都有寫了呀?(理論上是醬子沒錯)

實際上,很少有人會去看專案文件,這在軟體業裡算是常態吧,大多數軟體開發細節,或是User Story,很少會落在白紙黑字之上,通常文件寫好之後就束諸高閣,無人問津,最後連更新文件都變得是件苦差事。

一份沒有人看的文件,那怕製作再精美,多麼圖文並荿,也是沒有價值的廢紙。

那,有什麼好的建議呢?「舉個例子吧」

  • OS:什麼? 什麼意思? 你說的是「舉個例子」? 那你舉個例子來看看

我們回到第一次的場景

Scenario 01: 地點-老闆辦公室

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

  • PM: 好,我請團隊評估一下所需要的時間。應該一個星期可以完成。 可以舉個例子嗎?

  • User: (吱吱喳喳…)

  • PM: (吱吱喳喳…)

  • PM:我整理一下,討論的結果是不是如下:

  1. 我用帳號 “aki” 密碼 “qaz” 按「登入」鈕之後,畫面會移轉到「首頁」
  2. 我用帳號 “aki” 密碼 “123” 按「登入」鈕之後,登入失敗,會跳出「帳號密碼錯誤」錯誤訊息

為了方便,我們將它整理成一份表格

1
2
3
4
As an User,
I Want a login feature.
When I enter @account and @password,
So That I Can see Main Page.
account password result
aki qaz success
aki 123 帳號密碼錯誤

Scenario 02: 地點-團隊會議室

  • 工程師1:我想加兩條,沒有輸入帳號,或是沒有輸入密碼的都算是錯誤
account password result
aki 帳號密碼錯誤
qaz 帳號密碼錯誤
  • 工程師2:我想加個兩條,帳號有最短和最長的限制,太短或太長都不能讓使用者打我的api
account password result
ak qaz 帳號長度不符
DaijyoujitaniSaemonzaburo qaz 帳號長度不符
  • 團隊: (吱吱喳喳…)
  • PM: 我們統整一下表格如下:
account password result
aki qaz success
aki 123 帳號密碼錯誤
aki 密碼不得為空
qaz 帳號不得為空
ak qaz 帳號長度不符
DaijyoujitaniSaemonzaburo qaz 帳號長度不符
(註2)
  • QA: 咦,Test Case竟然順便寫好了,那我可以用自動化工具來寫測試了(暗爽中)
  • Art: 只要三個元素呀,兩個輸入框,一個登入鈕,我就先出這幾個元素的圖
  • PM: 大家看一看沒問題的話,我就拿這一張表格再去和User再確認一次

從上面的表格中我們觀察到「有什麼」??

  1. 資料庫裡真的有一個帳號 aki ,密碼為 qaz
  2. 帳密未輸入的防呆有了
  3. 帳號基本的長度檢核有了

從上面的表格中我們觀察到「沒有什麼」??

  1. 沒有驗證碼(當PM拿著例子去和User確認時就會知道了)
  2. 密碼強度? 一般常見的強規則是:密碼最低要求8字元; 必須包含
    至少一個大寫英文字元,至少一個小寫英文字元,至少一個數字字元,至少一個符號字元

    自己試著練習一下,加上一條密碼強度檢核條件,也要順便檢查輸入的值和輸出的結果有沒有需要調整的

反思一下,這個團隊做了什麼樣子的改變??

當有人為了這個流程舉了一個例子之後,所有的人都可以用這個例子放到自己心目中的流程去試一下,有什麼不對的地方,一旦發現了,再多加幾個例子來描述這個流程有什麼不足的地方,例子愈多,流程就愈完整,就愈不容易做出預期之外的功能了

什麼樣的例子是好的例子?

  1. 愈真實的例子愈好
  2. 愈簡單愈好

舉個例子

account password result
test test success

工程師2拿出自己的測試資料當例子時,有沒有可能會測試通過,但是換個帳號就測試失敗了?有沒有可能有個通用密碼為test,不管什麼帳號用test當密碼都能登入。

拿真實的帳號來測,問題就自動消失了

舉第二個例子

account password result
aki qaz success
DaijyoujitaniSaemonzaburo qaz 帳號長度不符
DaijyoujitaniSaemonzabur qaz success

帳號的長度少一個字元後就成功了
在邏輯上,這兩條指的是相同的一件事,就是帳號長度存在一個邊界,且邊界值為24, 第三條就顯得多餘了。

當然,你想要多加幾條測試來增加信心,也不是不行,但是生命就應該花時間在更有價值的事情上不是嗎?

註1:
遊戲有兩個角色,一個人是敲節奏的人(A),一個人是聽到節奏猜歌曲的人(B)。

實驗如下:

選定120首歌曲眾所能詳的歌曲,由A敲節奏,由B聽節奏猜歌曲,分別予以紀錄。

按照伊莉莎白根據實驗得出的結果:

A認為自己敲的節奏能夠讓B猜出來的機率為50%

B聽到A敲打的節奏而正確猜到歌曲的機為只有2.5%

註2:
大正寺谷 左衛門三郎