同誰，九陰真經不是這樣子練滴

March 23 20:44~22:11

上一篇寫了『Scrum 之逆練九陰真經』，希望鄉民們不要以為 Teddy 鼓勵大家『假 Scrum 之名，行亂搞之實』。上一篇的重點是，就算你是『逆練九陰真經』，好歹練功的內容還是和『九陰真經』相關連，總不能說當年郭靖給歐陽峰一本『瑜伽大全』或是『第一次學有氧舞蹈就上手』然後騙他說這是『九陰真經』，這樣就『騙太大了』。

幾個禮拜前在某個 sprint demo meeting 中，某人用很認真的表情說了一句對 Scrum『大逆不道』的話，令 Teddy 印象深刻：

因為這個 story 太大了，在這個 sprint 中做不完。接下來我打算不要開始下一個新的 sprint，等我繼續把這個 story 做完再說。

這好比你去參加超市所舉辦的 『1 分鐘大搬家』活動，在限時 1 分鐘內隨你搬任何超市內的東西。就在時間截止的時候，你跳出來說『等一下.... 我還沒搬完，等我搬到爽之後你們才可以換下一組人馬』。

***

Teddy 還曾經看過一個類似這樣的 story：

身為程式設計師，我可以設計一個具有擴充性的軟體架構。

不要笑，地球上就是有這種 story，說不定鄉民們不經意也會寫出類似的 story。這種 story 要怎麼施工，要如何 demo？Teddy 也可以舉一反三寫出類似的 stories：

• 身為食神，我可以做出宇宙無敵好吃的飯菜。
• 身為歌神，我可以舉辦場場爆滿的演唱會。
• 身為唬神，我可以寫出超級賣的企劃案。
• 身為員工，我可以月入數十萬。

反正 Scrum 說要把需求寫成 story 啊，好啊，你要 story，我就給你 story，誰怕誰啊，反正吹牛又不用繳稅！於是產生了上述的 stories....Scrum 的『形式』是有了，但是卻沒有抓到重點。這樣的練功方法，不要說『逆練』，就算是學小龍女躺在『寒冰床』上練，甚至是跑到『火星去練』，練的再久都沒用。

***

請問哪個程式設計師不想設計出『具有擴充性的軟體架構』，那個廚師不想做出『宇宙無敵好吃的飯菜』，那個歌手不想『舉辦場場爆滿的演唱會』，那個企劃人員不想『寫出超級賣的企劃案』？問題是，把『幻想 願望』以 story 的形式寫出來不表示這個願望就可以實現。


那麼『具有擴充性的軟體架構』要怎麼達成？很簡單，利用『完成若干個功能性的 story 來達成』。這樣講沒人聽得懂，舉例說明，假設你要開發一個『具有擴充性的會計系統』，stories 可以這樣寫：

• 身為使用者，我可以安裝新的會計模組-->這樣這個 story 又太大了，繼續細分：
• 身為使用者，我可以安裝薪資模組
• 身為使用者，我可以安裝進貨模組
• 身為使用者，我可以安裝 xx 模組

       上面這幾個 stories 完成後，系統就具備了『功能模組擴充性』，接下來

• 身為使用者，我可以設定薪資規則 --> 一樣可以繼續細分：
• 身為使用者，我可以計算全職人員的薪資
• 身為使用者，我可以計算全職人員的國內出差費
• 身為使用者，我可以計算全職人員的國外出差費
• 身為使用者，我可以計算全職人員的加班出差費
• .....
• 身為使用者，我可以計算兼差人員的薪資
• 身為使用者，我可以計算派遣人員的薪資

以此類推，可以一直寫下去。『具有擴充性的軟體架構』是一個很抽象的非功能需求（non-functional requirements or quality attribute），要達到此需求，首先先定義『什麼東西需要被擴充』。藉由將『需要被擴充的功能寫成 stories 』並『逐一完成這些 stories』，一個具有擴充性的軟體架構就完成了。這些 stories 給『具有擴充性的軟體架構』規範了一個 context，在此 context 底下去實現此軟體架構才有意義。有點類似 UP （Unified Process）談的 use case driven 的概念，只是在 Scrum 中改成 story driven。

至於第一個問題，一個 story 如果太大在 sprint 快結尾時才發現做不完該怎麼辦？幾個比較可行的方法包含：

• 將這個 story 移到下一個 sprint 繼續做（在目前的 sprint 中，這個 story 就不算完成，也不用 demo）。
• 如果這個 story 就只有這個 story 那怎麼辦？
• 承認這個 sprint 失敗，並檢討原因，是因為 sprint planning meeting 將 story 估的太大，還是 sprint 進行中發生什麼意外（bugs 太多，員工被抓去開會，支援其他案子等等）...
• 如果這個 story 可以被細分，那麼看看這個 sprint 完成的內容可否完整的自成一個 story，如果可以那麼沒做完的另外寫一個 story 到下一個 sprint 繼續。
• 就算是這個 sprint 有很多 stories，而你認為這個未完成的 story 可以被切割，你還是可以 demo 已經完成的內容，並且將沒做完的需求另外寫一個 story 到下一個 sprint 繼續。

理想上 story 沒做完就是沒做完，應該移到下一個 sprint 繼續做。但是有時候這個 story 已經完成的部份的確是可以被單獨 demo 的，那麼倒不一定要強制整個 story 移到下個 sprint。例如，某個 story 原本要同時支援 Windows 與 Linux 平台，但是 sprint 快結束時 Linux 平台的支援還有一點問題。你可以選擇把整個 story 都不要 demo，也可以選擇把這個 story 切割成 (1) for Windows  平台， (2) for Linux  平台，這個 sprint 就可以先 demo 已經完成的 Windows 平台功能（請不要說為什麼一開始的時候不直接把這個 story 拆成兩個...千金難買早知道啊...）。

***

採用 Scrum 遇到『問題』的時後，不是說『老子（老娘）想怎麼樣，就怎麼樣』，Teddy 建議可以視情況所需偷偷地『逆練九陰真經』，但是不是鼓勵鄉民們『亂練九陰真經』，到時候練壞身體不要怪 Teddy... 只好善用你的健保卡...XD

***

友藏內心獨白：為什麼開會的時候常常想學電視上表演那種『從椅子上跌下來』的橋段。