iT邦幫忙

2017 iT 邦幫忙鐵人賽
DAY 4
2
DevOps

CI 從入門到入坑系列 第 4

先求有,再求好?

  • 分享至 

  • xImage
  •  

相信大家一定常聽到這句「名言」,不管是從老闆、從主管、或同事、甚至是有些開發方法如 MVP ,也提出類似的觀點。

在前三天了解基本概念後,可能有人會覺得奇怪:這句話跟 CI 有什麼關係呢?如果有仔細閱讀並思考前三天內容的話,大家應該猜想得到,魔鬼可能就在這句話的細節裡。這句話在軟體開發的世界裡,絕大多數的場景都沒錯,因為軟體開發在改善流程上,比起其他實體產業是非常快的。因此確實可以考慮早點進入市場,再求改善,甚至是原先沒有的功能都可以在未來改善時加入。咦?沒有的東西未來都可以加入的話,那一開始到底要「有」什麼呢?

這是今天想跟大家一起討論的:什麼才是「有」?

什麼才是「有」?

下面以 MVP 來當範例說明。

一般 MVP 是設計者先做需求假設,再提出解決需求的產品,只要目標使用後需求有被解決,就會持續使用產品。目標使用後,通常會有回饋給設計者,如果回饋跟設計者思考方向一致的話,設計者就能參考回饋再為產品加上更符合需求的功能;反之,代表一開始需求假設是錯誤的,設計者依然可以參考回饋,並思考下一個可行的產品。

舉個例子:假設醫院的病人會想利用網路來線上掛號,因此我們應該要有線上掛號產品來服務病人,病人使用覺得滿意,下次自然會願意繼續使用,或給一些回饋。不滿意的話,就不會繼續使用,甚至連回饋都懶得給。所以對最終使用者來說,毫無疑問地,一個「有」解決需求的產品,才能回饋設計者設計「好」產品。

而對設計者來說,什麼才是「有」?從上面的描述可以大概了解,對設計者而言,一個能解決需求的產品,並能提供回饋資訊的產品,就「有」了!

重點來了!試著思考一下,如果最終使用者所使用的產品,與設計者所預期的不同;或是更白話的:產品有瑕疵的話,會發生什麼事?

常見的就是 bug 回報,如醫院掛號時間與通知時間不符,這代表使用者的思考是符合設計者的概念;可怕的會是使用者用了有問題的產品後,但給予了錯誤回饋,這會讓設計者改善產品的方向錯誤。比方說:原本設計是送出表單前會再次確認,但實際產品沒有實做,使用者回饋也是正向居多,設計者會誤以為這是使用者接受的做法,於是思考改善流程或動線時,可能就會被忽略。

產品有瑕疵,會使團隊無法得到上述「先求有,再求好」的好處,甚至還會讓產品越改越差。

正確的產品才是「有」

「先求有,再求好」,那什麼才是「有」?答案很明顯,正確的產品才是「有」,瑕疵的產品跟沒有一樣。在趕上線時,常會聽到「先求有,再求好」,這句話是對的,但把魔鬼細節加進去會更好:

「先要對,才會有,再求好」

趕上線的時候,要記得檢驗一下產品有沒有「對」。那要如何確保產品有對呢?這時 CI 精神就非常重要了!當團隊有了 CI 精神,團隊會常常對產品做驗證,不正確要立即修正,以確保交付出去是正確的產品,是對的,「才會有」!甚至,不但產品是正確地交付出去,在未來「再求好」的時候,常常驗證也能保護產品原本功能的正確。這才是真的「先求有,再求好」,也是這句名言與 CI 之間的關係!

Agile 的「有」

Agile 有些方法也是確保交付的產品是正確的,如:

  • TDD ,定好程式規格之後,才開始寫程式。
  • BDD ,決定好系統或產品的行為後,才開始實作。
  • ATDD ,在開發前,先決定好驗收規格。
  • DoD ,定義階段完成的條件,如:上線前必須做驗收測試。

很多 Agile 方法的初衷,都是為了要確保產品正確。因此可以發現,其實 Agile 不只在講因應改變,同時也在講如何提升品質。當然, CI 也是!

未來在討論 CI 要領時,也會專注在「確保產品正確」,而上述的 Agile 方法都很適合拿來參考並使用。

非開發人員的 CI

這裡以企劃人員當範例,其他公司類似的職務可能像是 PM 或設計師等。

分工比較明確的公司,通常會分開發人員與企劃人員。開發人員的工作是產出正確的產品;而定義正確的產品,是由企劃人員決定。這會有類似 Dev 與 Ops 之間的衝突,但 See the whole ,從整體產品的角度來看,「確保產品,人人有責」,開發人員本來就需要了解什麼是正確的產品,企劃人員則應該要用各種方法讓開發人員知道,自己心中的正確產品。

所以什麼是非開發者的 CI ?一樣是 Continuous Integration ,持續整合資訊到開發人員上,並確認預上線產品或上線產品是否正確。整合資訊與確認的過程或多或少會有問題,比方說企劃人員沒發現新舊功能衝突,或開發人員誤會企劃人員的意思,但一樣 See the whole ,這都是要一起克服並解決的。更重要的是,這些都是本來就該做的事,不會因為不持續做,就可以不用做。持續做的好處是每次資訊同步與確認的量少,問題會比較明確好解決。

Dropbox 又來了:就像第一次同步 Dropbox 的檔案也會很久。當完成後,同步就會非常快速了。

今日回顧

  • 「先求有,再求好」沒錯,但「先要對,才會有,再求好」會更好!
  • CI 是達成「先要對」的最佳實踐!
  • Agile 也有很多方法在討論如何「先要對」!
  • 非開發人員也要有 CI 的觀念:持續跟開發人員同步資訊!

下一篇:簡單的好習慣,是 CI 的一大步

相關連結


上一篇
Agile 與 CI 之間的火花
下一篇
簡單的好習慣,是 CI 的一大步
系列文
CI 從入門到入坑30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

1 則留言

0
Albert
iT邦高手 1 級 ‧ 2016-12-04 15:41:07

「先求有,再求好」沒錯,但「先要對,才會有,再求好」會更好!
...
很有意思的主題
也是我們目前所使用的方式
"開規格"之前先開"粗規格"後立即寫 Code ,
再用 Code 呈現來驗證"粗規格"
再度 重寫"粗規格"
再用 Code 呈現來後再度驗證"粗規格"
到達滿意後
依據 Code 來寫"最終規格"

Miles iT邦新手 2 級 ‧ 2016-12-05 18:29:11 檢舉

是的,這是規格精鍊的過程,所以非開發人員也必須要一起持續整合規格的資訊。

所以應該是「持續整合,人人有責」XD

我要留言

立即登入留言