March 28 09:12~10:53
▲畫面節錄自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嗎？人是很奇妙的生物，大家經常抱怨政府推出的政策都在炒短線，口號喊著漫天價響，很少做長遠規劃。但輪到自己做事的時候才發現，原來做長遠規劃這麼辛苦，而且又不能時時刷存在感，這樣子怎麼提高民調數字哩？算了，還是也來學政府開放「現股當沖」，先把交易額炒高再說。
學習原本就沒有說一定要「全學會」才可以，學一點、用一點是很正常的現象。怕就怕「學一點」卻以為全部學會，「守、破、離」三個階段都還沒開始「守」就已經不知道「離」到哪裡去了。學習的「量」（廣度）和「質」（深度）之間應該取得平衡，才不至於淪為口號收集器。
俗話說：「滾石不生苔，轉業不聚財。」學習還沒到守的階段就已經換題目，大概離詐神不遠矣。
***
友藏內心獨白：詐騙手法也是要推陳出新。
沒有留言:
張貼留言