l

2017年3月28日 星期二

Fail Fast不是這樣用的吧?!

March 28 09:12~10:53

屏幕截图 2017-03-28 10.34.39

▲畫面節錄自Google搜尋結果

 

認識Teddy的人都知道Teddy是一個講話非常不中聽的人,也因此在有意、無意中經常得罪人。記得有一年Teddy去拜訪一位朋友,朋友說他們正在跟某公司合作,該公司已經跑Scrum三年多了,成效斐然。聽到台灣有這麼棒的團隊,Teddy很好奇的問:「請問他們的自動化測試和持續整合做到怎樣的程度?」聽到這個問題朋友突然顧左右而言他,快速轉到其他話題上。

文化上的改變先不談,一個跑了三年多的Scrum團隊自動化測試和持續整合都做不好,你說這個團隊好棒棒實在很沒說服力。

***

有位鄉民和Teddy聊BDD(Behavior Driven Development,行為驅動開發),他說他們導入BDD已經一年多了,Teddy非常有興趣,想多了解對方這一年多來實踐BDD的經驗。但聊來聊去都聊不出個所以然,問他如何在BDD中落實DDD(Domain Driven Design)他說從來沒聽過DDD,再問他開發團隊如何和PO或stakeholder協作討論規格與範例,他說他們的規格是「別人」給的。講到最後才發現原來這個朋友口中的BDD是「功能做好之後用Selenium補寫(錄製?)自動化驗收測試」。

這是九二共識的軟體版嗎?

一個BDD各自表述。

***

某位鄉民和Teddy聊到User Story Mapping(使用者故事對照,USM),對方說他參加公司內部的讀書會,把書讀過一遍之後的感想就是使用者故事對照只適合用來管理循序(有單一時間操作順序)的功能,對於多重路徑(有選擇條件)或時間順序不一定的功能無法用使用者故事對照來表示。Teddy第一次讀這本書的時候也是有同樣的疑惑,把使用者的歷程依據時間軸展開,這不是把真實世界中,系統平行、重複或多重選擇路徑硬簡化成單一時序的使用情境嗎?這種方法有用嗎?要表達時間順序不是用UML裡面的sequence diagram (循序圖)就好了,何必再學另一種工具呢?

經過更仔細的閱讀之後,才發現自己一開始只看到使用者故事對照的形,根本沒看懂它的精髓。時間順序只是一種讓你講故事的方法,因為從時間順序來思考最直覺也簡單。有了故事之後,引發團隊討論,驗證大家腦袋中的想法,最後獲得共識,這才是背後的目的。試想,一個產品或服務,你說它時間順序不明顯,無法說故事,那你產品做好之後要怎麼賣?最後還不是要用說故事的方式賣給客戶,總不能把所有規格一條、一條列出來就要客戶買單吧:

4個USB Type C、15” 2K螢幕、觸感不佳的二代鍵盤、超大觸控板、無三小路用Touch Bar、16GB RAM、512GB SSD

如果只看規格,誰想買「貴森森」的MacBook Pro(MBP),類似規格價格便宜的產品選擇很多。相信很多人是因為被產品背後的「故事」—以及故事所帶來的用戶體驗,不管是真實體驗還是自行腦補後的想像體驗—給吸引。功能不是不重要,相反地功能很重要,但必須能夠串起來幫助使用者達成任務(解決問題)才可以傳遞價值。

如果無法說故事,會不會是因為還沒把產品的價值想清楚,還停留在比規格、比功能數量的思維上面呢?

***

敏捷、敏捷,大家都想要求快,就算這個快是很膚淺的快也無所謂,反正先丟出去再說,先說先贏。敏捷不是說fail fast嗎?人是很奇妙的生物,大家經常抱怨政府推出的政策都在炒短線,口號喊著漫天價響,很少做長遠規劃。但輪到自己做事的時候才發現,原來做長遠規劃這麼辛苦,而且又不能時時刷存在感,這樣子怎麼提高民調數字哩?算了,還是也來學政府開放「現股當沖」,先把交易額炒高再說。

學習原本就沒有說一定要「全學會」才可以,學一點、用一點是很正常的現象。怕就怕「學一點」卻以為全部學會,「守、破、離」三個階段都還沒開始「守」就已經不知道「離」到哪裡去了。學習的「量」(廣度)和「質」(深度)之間應該取得平衡,才不至於淪為口號收集器。

俗話說:「滾石不生苔,轉業不聚財。」學習還沒到守的階段就已經換題目,大概離詐神不遠矣。

***

友藏內心獨白:詐騙手法也是要推陳出新。

沒有留言:

張貼留言