【從學員練習影片觀察到一個關於 TDD 的有趣現象】
極速開發的課後練習作業,雖說重點是放在極速開發要學習的技巧與刻意練習的模型,但開發的方式、順序也是刻意安排成類似 TDD 的進行方式,來讓生產力最大化(TDD 本來就是幫助開發的,不是幫助測試的)
我從2位第一次上我課的學員(當然就是 #極速開發,代表他們沒上過#單元測試 跟 #TDD與持續重構),雖然他們是照著示範影片、上課教學用 TDD 在寫整個 tennis 的過程,但從他們執行測試的時間點就可以發現:
「他是用測試來驗證 production code 的正確性」,即使他先寫了測試,也不先執行,沒有看到紅燈,每次都等到 production code 寫完了,應該要綠燈時,才執行測試。
而其他上過 TDD 課的同學 ,或是上過單元測試的同學,知道測試是用來描述情境,如果現在「加入的這個情境是新的需求或需求異動,代表目前 production code 還不支援這個情境,執行測試跑出的紅燈,就是等等 production code 要完成的 #目標」
test-frist 從來都只是 TDD 其中一個小小的衍生產物,而不是全貌。TDD, 測試驅動開發 從來都是一種開發方法,而不是測試方法。
總有些人老愛把 TDD 拿來跟測試相提並論,就總是喜歡把 test-first 當作靶子打,覺得違反人性跟直覺,覺得先寫測試在很多情況下是浪費時間或是不 work,可能拿來跟一堆測試的方法論相提並論,或總是只拿回歸測試的效益來當作 TDD 的整體。抑或是陷入 isolation unit test 與 integration test (其實就是非 isolation 等級、有實際依賴的自動測試)之爭。
```
註:TDD 事實上是可以不是單元測試等級的。
```
要比較正確看待 TDD 的角度,首先要知道它是幫助開發的、它是一種開發方式(當然不是唯一一種,甚至也不會是最好的一種,因為根本沒有最好,只有剛好)
接著要了解 TDD 可能用 IPO 模型還比較貼切,input-process-output,在你開發任何功能之前,你總要先想過這件事。而先想這件事,才是 TDD 的最基本精神。
接著是怎麼把你想好的東西,變成可執行的 spec,我們只是用測試程式來「描述」你腦袋中的「IPO模型」,把 process 的過程當作一個黑箱子。
而這個 IPO 模型在結合成「使用情境」,就會帶來「高易用性 API 的好處」,只有在一開始就先想好怎麼給別人用,最後才會好用。所謂的一開始想好,指的不是預先設計一堆 class,而是 input/output 想清楚期待(一般會結合實例化需求,搭配 Given/When/Then 的 gherkin style 來把前置條件、資料、前提想好,當發生什麼事,應該是怎樣的結果),然後描述它。在紅燈定義清楚目標,綠燈完成 input/output 關係且沒弄壞前面的所有情境後,來針對 process 進行重構(事實上 Kent Beck 的 TDD by Example 更多是用 refactor 來 #完成 process。
```
註:所謂的 output 不一定只有回傳值,包含外部依賴狀態、資料的改變,甚至顆粒度小一點,針對物件導向設計的話,物件內部狀態的改變也算,只是物件內部狀態改變,驗證點要嘛是拿得到內部狀態,要嘛就是要驗證物件哪個行為會因這個內部狀態而有所不同。
```
## 戰 TDD 之前該先做好的功課
要戰 TDD,是不是至少要把 Kent Beck 的 TDD by Example 看完?
要戰 TDD,請不要拿它跟測試方法論來比,那只是一下就被人看破手腳。因為它是個開發方法論。
要戰 TDD,請不要把它的好處只限縮在跟回歸測試、自動測試的比較,因為那只是它的衍生好處,當你試過在白海報紙上 TDD 就懂,TDD 是在釐清你的思緒的同時,又可以以終為始,確保你在 production code 的每一個動作都是為了滿足某個期待的情境。
要戰 TDD,請不要去把 單元測試、整合測試捲進來,那是測試的顆粒度,那是測試的分類,TDD 從來都不是只能限於單元測試。
要戰 TDD,請不要在那邊戰他是 bottom-up ,是直接從程式/class 的角度出發,事實上 TDD 既不是 bottom-up, 也不是 top-down, (書裡面就有講這件事咩),實務上的 TDD 結合倫敦派(GOOS)跟芝加哥派(Classic TDD),會更像 Outside-In 的進行方式,先定義好驗收情境,接著從最外部(也就是使用者看得到的部份)一路把依賴往另一邊的系統邊界推,直到推到系統以外的依賴資源(persistence 或 external API/service)
```
註: ATDD by Example 中 ATDD by Example, Kent Beck 寫的序最後的一段話。
Kent Beck:
「就像我曾說過的,TDD的一個缺點是,它可能會退化為一種用來滿足開發人員需求的編程技能。某些開發人員從更廣泛的角度來看待TDD,輕易在他們測試的不同抽象級別間跳躍。然而在ATDD中不存在歧義,這是一種加強與非編程人員溝通的技術。我們之間良好的協作關係,以及作為這種關係基礎的溝通,能夠使軟件開發更有效率。採用ATDD是向著溝通更清晰這個目標邁進的重要一步,而此書是一本全面又平易近人的入門讀物。」
```
要戰 TDD,請不要只關注在 test-frist,因為他只是用 test 來幫助你 think-first,不要邊寫邊想。然後不要過份依賴或相信你腦袋的能力,把你想好的東西具體化出來,最好可以被直接執行,最好除了你以外每個人執行出來的結果都會一樣(不管是對的,還是錯的)
要戰 TDD, 請不要把論點放在見樹不見林,如果你有看 TDD by Example 的 Part 1, Part 2 那兩個加起來共 24 個章節,就知道一開始就得把當下想到的全貌紀錄在一個「紙本」的 backlog (所謂的紙本,只是要講這並不依賴於任何工具)
而這個需求輪廓的全貌,會隨著你逐漸完成一部分一部分的情境,設計逐漸浮現後,而隨時跟著增減調整。
但不代表 TDD 就是先想到一個測試案例,就直接先幹下去了,那根本是亂搞。
以上這些,都還不是在列 TDD 的好處,而是針對那些從來沒搞懂 TDD 但又愛戰 TDD 的人一點提醒,你戰的很可能是「你誤解的 TDD」。
TDD 還有許多實務上的用途,列上我在譯者序中的一小段:
>> 測試驅動開發(Test-Driven Development, TDD)!一種以測試為開發輔助、以測試來描述需求情境、以測試來當作目標、以測試來表達期望、以測試來驗證疑問、以測試來實驗學習、以測試來溝通協作、以測試來協助設計高易用性 API 的「開發方法」。
譯者序有開放給大家看,請見:https://tdd.best/book/tdd-by-example/
拜託,要戰之前去看一下祖師爺 Kent Beck 對 TDD 的原始見解:https://www.tenlong.com.tw/products/9789864345618?list_name=srh
如果你想正確的使用 TDD 來幫助你在實務上產生許多的價值,帶來許多的好處,尤其是需求釐清、持續重構、小步快跑的部份,最好理解的培訓課就在這:https://tdd.best/courses/classic-tdd-by-example-video-training/
最後我想講一段話:
TDD 從來都不該被導入到團隊中,但它是一種很好的自我鍛鍊與學習的方式,也是一種能用很低的成本來帶來很多好處的開發方法(見下方註腳),然而它也不是適用所有的情況,但它可以讓『完美』變成一個動詞,而非不變的形容詞。
```
註:
Kent Beck 在 DHH 靠腰:《TDD is Dead》 之後寫的一篇反串文:《RIP TDD》
https://www.facebook.com/notes/1063422864115918/
我幾年前的簡易翻譯,通常也是 TDD 可以幫助你解決的問題,如下:
- Over-engineering (過度設計)
- API feedback (改善API的設計與可用性)
- Logic errors (想的跟寫的不一樣,寫的跟需求不一樣)
- Documentation (寫跟維護文件是痛苦的)
- Feeling overwhelmed (找不到切入點)
- Separate interface from implementation thinking (抽象設計)
- Agreement (確保已修正問題的證據)
- Anxiety (改東壞西的擔心受怕)
```
很久沒對 TDD 發表這種長篇大論了,因為不理解、不想理解、不同角度理解的人居多,能真的到各自的塔上用不同角度來看原義,以及實務上用它來幫助解決的問題有哪些的人,真的太少。
大部分人只想針對這個詞彙來攻訐以博得流量跟吸引目光,而不是想著「我可以用它來幫助我什麼」
問題跟需求是中性的,解決問題跟滿足需求的手段與方式有千萬種,不會只有一種,也不會有所謂的對錯,多點角度去了解不同的方法、方式,然後融會貫通,發揮綜效,在實務上用最少的成本與風險來產生最大的價值,這才是真正的目標。
導入敏捷不該是目標,導入 TDD 也不該是目標,目標永遠都是在實務上產生價值、解決問題、滿足需求。
敏捷開發缺點 在 Facebook 的精選貼文
《#場景行銷模式》贈書兩本,參加辦法請見部落格文末
「我不喜歡被廣告中斷閱讀,沒有人喜歡。」我在第一天創立部落格的時候就放上這段話,期許自己的部落格文章給讀者一種流暢、乾淨和簡潔的閱讀體驗。雖然大部分的人都討厭看到廣告,但是你有沒有發現,有些廣告看起來並不討厭,甚至給你一種「好慶幸自己能看到這則廣告」的驚喜感?同樣是廣告,為什麼給我們的觀感差這麼多?
部落格圖文版 https://readingoutpost.com/context-marketing/
Podcast 用聽的 https://readingoutpost.soci.vip/
.
【這本書在說什麼?】
.
《場景行銷模式》的作者是世界第一客戶關係管理(CRM)平台 Salesforce 公司的市場研究負責人馬修.史威茲(Mathew Sweezey),他指出了傳統「有限媒體」環境的舊廣告行銷模式已經不再適用,企業該轉型學習「無限媒體」時代的新行銷方式,來突破雜訊、超越演算法、打造自動化的顧客體驗旅程。
以往的有限媒體觀念,認為企業要透過「一對多」的方式把同一種廣告訊息,傳遞給所有人,講求的是曝光和流量。然而,在2009年之後,「個人產出的訊息量」已經正式超越「企業產出的訊息量」,傳統的有限媒體已經完全被淹沒在無限產出的個人雜訊當中。
在這本書裡,作者分享了他的團隊研究全球一萬多家企業之後,發現高績效的成長企業都很擅長打造「場景」,也就是為消費者提供最個人化的體驗,滿足其慾望。這個嶄新的觀念他稱之為「場景行銷」(context marketing),他在這本書裡提供完整的執行步驟,教我們觀念、策略、技巧和工具,一步步達成這個足以顛覆傳統行銷模式的新形態模式。
.
【什麼是場景行銷?】
.
讓我們想像一個場景:你在晚上看電視劇的空檔之間,看到插播的汽車廣告。你想要追最喜歡的劇、讓自己放鬆、而且你現在對汽車一點也不感興趣。但是那個廣告持續了很久,跟你當下想要的事情無關,甚至開始讓你產生反感。這就是「有限媒體」時代的舊廣告方式,如果可以,你一點也不想看到這則廣告,對吧?
再想像另外一個場景:你被老闆指派了一個任務,要你尋找一個專案管理軟體來讓團隊使用。你 Google 「最棒的專案管理軟體」,點擊第一篇介紹五種熱門軟體優缺點比較的文章,找到了其中一個感興趣的軟體,點了文章裡的連結開始免費試用,在你試用的期間,官網持續提供你「如何使用軟體」、「如何寫計畫」、「如何管理派工」的文章,用順手之後便告訴老闆,買這款吧。
上面兩個是我仿照書中內容想出來的場景,起初同樣都充滿了雜訊,但是第一種廣告你只想要忽略他,無論那台車的折扣或贈品有多麼划算;第二種廣告卻一路引導你往前探索,最後還幫你解決了問題。兩種截然不同的場景,第一種行銷很惹人厭,第二種卻是顧客想要的場景行銷。
.
【如何創造顧客想要的場景?】
.
無論廣告的內容是文字、影像、聲音,都屬於廣告的「內容」。作者強調,並非內容不重要,而是:「內容只是在特定時刻用來實現目標的中介,回答消費者的問題,娛樂他們,驗證他們的身分。消費者渴望的是那些體驗,而不是內容。」我們要注意的是,顧客渴望的是「體驗」。
作者設計了一套完整的架構,來幫我們創造出顧客想要的場景,進而達到體驗的效果。這五個步驟分別是:可得即用、顧客許可、全個人化、真誠同理、價值目標。這樣的步驟,能夠創造場景化的體驗,更能夠以顧客當下預期、渴望的方式吸引他們參與。
在這本書裡,作者在每個架構之下,除了說明原理之外,還引用了許多商業上的實際案例,加上他在 Salesforce 公司的實務經驗,讓這些內容讀來十分紮實。創造專屬顧客的場景行銷,不能只依賴傳統的媒體工具,更重要的是「自動化數位平台」和「敏捷開發」的相輔相成,許多成功轉型的高績效公司會把場景行銷跟 IT 團隊整合在一起,場景行銷不只是廣告行銷的轉型,更是公司數位資訊的轉型。
以下,我想挑其中三個讓我有所感觸、有所收穫的步驟來和你分享,分別是:可得即用、顧客許可、和真誠同理。
.
【1.可得即用】
.
你的好友分享的貼文可能會出現在你的動態牆上,媒體花大錢打的廣告卻不一定會出現。為什麼個人能夠突破重圍,媒體巨擎卻做不到呢?理論上,答案相當簡單:在這種新環境中,消費者位居主導地位。在無線媒體時代,並不是一次向所有人傳遞一條相同的訊息,而是使用演算法,即時地把恰當的人以恰當的內容連結在一起。
因此,「可得即用」這個法則在場景行銷的最終目標,就是幫助顧客完成手頭上的任務,或是獲得當下尋求的價值。場景行銷的目的是在最適合的時機,建立人際聯繫,而非單純接觸大眾。知名行銷平台 HubSpot 的行銷長曾經說過:「我們的目標不是把內容塞進消費者的收件夾,而是提供一些值得閱讀的東西。」
HubSpot 迎接新的電子報訂閱者過程中,會先介紹他們閱讀三篇點閱率最高的部落格文章,然後提供顧客訂閱時勾選感興趣類別的文章,最後才按一般的步調寄送最新的部落格文章。在這個旅途當中,當顧客依據不同需求點擊不同內容的時候,網站也會做出對應的反應,提供當下最適合的內容。那些引導的電子信所創造的用戶參與度,是其他電子信的整整兩倍。
.
【2.顧客許可】
.
知名的行銷專家賽斯.高汀(Seth Godin)曾在暢銷書《願者上鉤》中提到「許可」的力量:「許可能夠促進消費者參與,因為消費者更願意參與他們主動要求的東西。」傳統無差別式的廣告行銷,就像是看電視時的汽車廣告,並沒獲得顧客許可。顧客主動索取當下想要的體驗,就像是提供試用版的軟體服務,則取得了顧客的許可。
因此,在「無限媒體」時代,顧客擁有一種權力,誰可以直接接觸他們的權力。任何違反這種許可的接觸方式,很可能都會有意無意之間惹怒顧客。當企業取得了顧客許可之後,才能再以更加個人化的方式,提供顧客真正想要的體驗。在我讀這本書的時候,剛好遇到了一件事,我犯了「取得許可」的錯誤。以下分享這個實際的案例。
近期我把抽獎贈書的活動,轉到部落格上面進行,卻在「沒有取得許可」的情況下,把參加者的 Email 直接加入了電子信訂閱者的名單內,這引起了參加者的不滿和不信任。隨即,我在網頁上做出了改善,也發了封道歉信和改善說明給參加者們。
這個事件提醒了我「取得許可」的重要性,「顧客的信任」就藏在細節裡。以下是我致參加者的完整道歉信,也給有在經營社群和品牌的讀者參考看看。
.
【信件標題】 致曾參加「閱讀前哨站」抽獎贈書的你
嗨,我是瓦基,會寫這封信給你,是因為我犯了一個錯誤,以及我做出的改善措施。
你會收到這封信,是因為你填寫 Email 參加過《創造與漫想》、《極度吸睛》、《思考的框架》其中一本書的抽獎活動。但由於我在介面設定的不熟悉,把曾經參加抽獎的讀者,在沒有取得你同意的前提下,都直接加入了「電子報訂閱者」的名單內。
有一位參加抽獎者在「取消訂閱」時回覆給我的建議,讓我留意到這件事情可能對參加抽獎者們造成的困擾。這個抽獎網頁(plug-in套件)是我近期新添加的元素,對於 Email 自動串接訂閱的設定,我原本只採用了預設值,因此造成了參加抽獎者的困擾。
收到他的回訊後,我跟 plug-in 客服請教該如何調整設定,現在我把新的設定方式寫了上去,提供「勾選」的選項來決定是否訂閱(預設否)。這個設定起初並不好寫,但很開心我還是學會了。附圖在底下給你參考,對往後的參加抽獎者都會是更好的選項。
再度跟你說聲抱歉,也非常感謝你的參加,你們的回饋讓我找到改善的方向和細節。如果你不希望再收到「閱讀前哨站」的讀書心得、好書推薦電子信,你可以直接點擊〈取消訂閱〉這個連結來取消。無論你是否繼續訂閱,你的參與和關注,我都感念於心,謝謝。
.
【3.真誠同理】
.
在書中有一個很有趣的商業案例,賓士汽車把大規模的廣告視為主要的成長模式,特斯拉則是加倍關注整個顧客旅程的場景。賓士汽車在電視、網路媒體上的廣告威力,想必大家一定領教過了,我就不再多說。讓我們來看一下特斯拉怎麼做行銷的?
特斯拉傳達給顧客的共同目標:讓世界擺脫化石燃料、透過徹底創新、專注於永續生活。他們把汽車發射到外太空,而不只是關注汽車本身。特斯拉也提供流暢的網站預約體驗,在評估階段還能嘗試各種個人化的設定,他們的業務員懂得關注顧客的選擇和需求,而不是一昧強調汽車的規格。特斯拉也深諳推薦的力量,向朋友引介買車的車主還能獲得現金獎勵。開放顧客預購 Model 3 的預售模式,除了讓顧客有參與和期待感之外,還挹注了100億美元的年度營收。
每輛特斯拉汽車的平均廣告費是6美元,賓士汽車則是926美元。
還有一個有趣的故事,是最近我讀到 Podcast 股癌的著作《灰階思考》,作者謝孟恭分享他曾經去應徵特斯拉業務員的經過。面試官對著台下一票的面試者說:「試著賣給我一台特斯拉。」面試者們每個都努力背誦出特斯拉優異的規格、漂亮設計、節能特色。但顯然這些答案,面試官沒有一個滿意。
特斯拉的面試官後來反問大家:「怎麼沒人問我是誰?我家裡有幾個人、有幾個小孩?我有小孩的話,會在意加速嗎?你們連『我』是誰都沒搞清楚,怎麼賣車給我?」當一家企業的行銷不再是冰冷冷的廣告訊息,而是能夠真誠同理地,認識你的需求、對齊你的目標、滿足你的渴望,你怎麼能不愛?到頭來,惹人厭的不是廣告,而是不貼心的廣告。
.
【後記:不要成為討人厭的廣告】
.
由於我自己有在經營部落格和社群,因此閱讀《場景行銷模式》的過程中,感受到很多的觀念衝擊。目前市面上的行銷教戰守則,大多數還是偏向於有限媒體的行銷概念。然而時代正在改變,資訊超載和爆炸多的雜訊正在淹沒著我們,該如何接觸到目標受眾、有效提供對受眾的價值,就是一門不斷學習和精進的學問。
這本書除了提供非常顛覆性的行銷觀念之外,後半部的「自動化流程」的設計方式,我認為更是未來優秀企業和普通企業的分水點。自動化並不容易,但值得投資金錢和時間,因為這是一個能夠推動企業成長的永續循環。我最近在練習的自動化工具是 Integrately(跟 Zapier 比起來便宜許多),如果你對這類型工具也有興趣,可以用我的連結免費註冊帳戶試用,獲得額外 500 task/month 的額度。
總結來說,作者以三個方法貫穿本書的內容,讓我們知道場景行銷的操作方式:
1. 找出顧客旅程中的關鍵點,確保你出現在那些關鍵點中,並善用那些時機。
2. 與受眾合作,積極參與社群會想辦法和受眾一起創造產品,或者兩者都做。
3. 每一步都為顧客創造良好的體驗,想辦法把它變成推薦者,維持場景循環。
一個事業如果能夠融入上述的要素越多,事業發展就越可靠、越持久。在這個訊息多到爆的時代,如何突圍觸及顧客?演算法當道的現在,讓顧客買單的關鍵在哪裡?體驗取代內容,什麼是推動顧客旅程的關鍵?無論你任職於行銷業務、社群小編、內容創作者,這本書都值得推薦給你體驗。
敏捷開發缺點 在 台灣物聯網實驗室 IOT Labs Facebook 的最佳解答
迎接終端AI新時代:讓運算更靠近資料所在
作者 : Andrew Brown,Strategy Analytics
2021-03-03
資料/數據(data)成長的速度越來越快。據估計,人類目前每秒產出1.7Mb的資料。智慧與個人裝置如智慧型手機、平板電腦與穿戴式裝置不但快速成長,現在我們也真正目睹物聯網(IoT)的成長,未來連網的裝置數量將遠遠超越地球的人口。
這包括種類繁多的不同裝置,像是智慧感測器與致動器,它們可以監控從震動、語音到視覺等所有的東西,以及幾乎大家可以想像到的所有東西。這些裝置無所不在,從工廠所在位置到監控攝影機、智慧手錶、智慧家庭以及自主性越來越高的車輛。隨著我們企圖測量生活週遭數位世界中更多的事物,它們的數量將持續爆炸性成長。
資料爆量成長,讓許多企業把資料從內部部署運作移到雲端。儘管集中到雲端運算的性質,在成本與資源效率、彈性與便利性有它的優點,但也有一些缺點。由於運算與儲存在遠端進行,來自終端、也就是那些在網路最邊緣裝置的資料,需要從起始點經過網際網路或其他網路,來到集中式的資料中心(例如雲端),然後在這裡處理與儲存,最後再傳回給用戶。
對於一些傳統的應用,這種方式雖然還可以接受,但越來越多的使用場景就是無法承受終端與雲端之間,資訊被接力傳遞產生的延遲。我們必須即時做出決策,網路延遲要越小越好。基於這些原因,開始有人轉向終端運算;越來越多人轉而使用智慧終端,而去中心化的程度也越來越高。此外,在這些即時應用中產生的龐大資料量,意味著處理與智慧必須在本地以分散的方式進行。
與資料成長連袂而來的,是人工智慧與機器學習(ML)也朝終端移動,並且越來越朝終端本身移動。大量來自真實世界的資訊,需要用ML的方式來進行詮釋與採取行動。透過AI與ML,是以最小的延遲分析影像、動作、影片或數量龐大的資料,唯一可行且合乎成本效益的方式。運用AI與ML的演算法與應用將在邊緣運作,在未來還將會直接在終端裝置上進行。
資料正在帶動從集中化到分散化的轉變
隨著資訊科技市場逐漸發展與成熟,網路的設計以及在其運作的所有裝置,也都跟著進化。全盛時期從服務數千個小型客戶端的主機,一直到客戶端伺服器模型中使用的越來越本地化的個人電腦運算效能,基礎架構持續重組與最佳化,以便更貼近網路上的裝置以及符合運作應用的需求。這些需求包含檔案存取與資料儲存,以及資料處理的需求。
智慧型手機與其他行動裝置的爆炸性成長,加上物聯網的快速成長,促使我們需要為如何讓資產進行最佳的部署與安排進行評估。而影響這個評估的因素,包括網路的可用性、安全性、裝置的運算力,以及把資料從終端傳送到儲存設備的相關費用,近來也已轉向使用分散式的運算模型。
從邊緣到終端:AI與ML改變終端典範
在成本、資源效率、彈性與便利性等方面,雲端有它的優點,裝置數量的急遽增加(如圖2),將導致資料產出量大幅增加。這些資料大部份都相當複雜且非結構化的,這也是為何企業只會分析1%~12% 的資料的原因之一。把大量非結構化的資料送到雲端的費用相當高、容易形成瓶頸,而且從能源、頻寬與運算力角度來看,相當沒有效率。
在終端執行進階處理與分析的能力,可協助為關鍵應用降低延遲、減少對雲端的依賴,並且更好地管理物聯網產出的巨量資料。
終端AI:感測、推論與行動
在終端部署更多智慧的主要原因之一,是為了創造更大的敏捷性。終端裝置處於網路的最邊緣與資料產生的地方,可以更快與更準確地做出回應,同時免除不必要的資料傳輸、延遲與資料移動中的安全風險,可以節省費用。
處理能力與神經網路的重大進展,正協助帶動終端裝置的新能力,另一股驅動力則是對即時資訊、效率(傳送較少的資訊到雲端)、自動化與在多數情況下,對近乎即時回應的需求。這是一個三道步驟的程序:傳送資料、資料推論(例如依據機器學習辨識影像、聲音或動作),以及採取行動(如物件是披薩,冰箱的壓縮機發出正常範圍外的聲音,因此發出警告)。
感測
處理器、微控制器與感測器產生的資料量相當龐大。例如,自駕車每小時要搜集25GB的資料。智慧家庭裝置、智慧牙刷、健身追蹤器或智慧手錶持續進化,並且與以往相比,會搜集更多的資料。
它們搜集到的資料極具價值,但每次都從各個終端節點把資料推回給雲端,數量又會過多。因此必須在終端進行處理。倘若部份的作業負載能在終端本身進行,就可以大幅提升效率。
推論
終端搜集到的資料是非結構性的。當機器學習從資料擷取到關聯性時,就是在進行推論。這表示使用AI與ML工具來幫忙訓練裝置辨識物件。拜神經網路的進展之賜,機器學習工具越來越能訓練物件以高度的精準度辨識影像、聲音與動作,這對體積越來越小的裝置,極為關鍵。
例如,圖4顯示使用像ONNX、PyTorch、Caffe2、Arm NN或 Tensorflow Lite 等神經網路工具,訓練高效能的意法半導體(ST)微控制器(MCU),以轉換成最佳化的程式碼,讓MCU進行物件辨識(這個的情況辨識對象是影像、聲音或動作)。更高效能的MCU越來越常利用這些ML工具來辨識動作、音訊或影像,而且準確度相當高,而我們接下來馬上就要對此進行檢視。這些動作越來越頻繁地從邊緣,轉移到在終端運作的MCU本身。
行動
資料一旦完成感測與推論後,結果就是行動。這有可能是回饋簡單的回應(裝置是開啟或關閉),或針對應用情況進行最佳化(戴耳機的人正在移動中,因此會針對穩定度而非音質進行最佳化),或是回饋迴路(根據裝置訓練取得的機器學習,輸送帶若發出聲音,顯示它可能歪掉了)。物聯網裝置將會變得更複雜且更具智慧,因為這些能力提升後,運算力也會因此增加。在我們使用新的機器學習工具後,一些之前在雲端或終端完成的關鍵功能,將可以移到終端本身的內部進行。
終端 AI:千里之行始於足下
從智慧型手機到車輛,今日所有電子裝置的核心都是許多的處理器、微控制器與感測器。它們執行各種任務,從最簡單到最複雜,並需要各式各樣的能力。例如,應用處理器是高階處理器,它們是為行動運算、智慧型手機與伺服器設計;即時處理器是為例如硬碟控制、汽車動力傳動系統,與無線通訊的基頻控制使用的非常高效能的處理器,至於微控制器處理器的矽晶圓面積則小了許多,能源效率也高出很多,同時擁有特定的功能。
這意味著利用ML工具訓練如MCU等較不複雜元件來執行的動作,之前必須透過威力更強大的元件才能完成,但現在邊緣與雲端則是理想的場所。這將讓較小型的裝置以更低的延遲執行更多種類的功能,例如智慧手錶、健康追蹤器或健康照護監控等穿戴式裝置。
隨著更多功能在較小型的終端進行,這將可以省下資源,包括資料傳輸費用與能源費用,同時也會產生極大的環境衝擊,特別是考量到全球目前已有超過200億台連網裝置,以及超過2,500億顆MCU(根據Strategy Analytics統計數據)。
TinyML、MCU與人工智慧
根據Google的TesnsorFlow 技術主管、同時也是深度學習與TinyML領域的指標人物 Pete Warden 表示:「令人相當興奮的是,我還不知道我們將如何使用這些全新的裝置,特別是它們後面代表的科技是如此的吸引人,我無法想像那些即將出現的全新應用。」
微型機器學習(TinyML)的崛起,已經催化嵌入式系統與機器學習結合,而兩者傳統上大多是獨立運作的。TinyML 捨棄在雲端上運作複雜的機器學習模型,過程包含在終端裝置內與微控制器上運作經過最佳化的模式識別模型,耗電量只有數毫瓦。
物聯網環境中有數十億個微型裝置,可以為各個產業提供更多的洞察與效率,包括消費、醫療、汽車與工業。TinyML 獲得 Arm、Google、Qualcomm、Arduino等業者的支持,可望改變我們處理物聯網資料的方式。
受惠於TinyML,微控制器搭配AI已經開始增添各種傳統上威力更強大的元件才能執行的功能。這些功能包括語音辨識(例如自然語言處理)、影像處理(例如物件辨識與識別),以及動作(例如震動、溫度波動等)。啟用這些功能後,準確度與安全性更高,但電池的續航力卻不會打折扣,同時也考量到各種更微妙的應用。
儘管之前提到的雲端神經網路框架工具,是取用這個公用程式最常用的方法,但把AI函式庫整合進MCU,然後把本地的AI訓練與分析能力插入程式碼中也是可行的。這讓開發人員依據從感測器、麥克風與其他終端嵌入式裝置取得的訊號導出資料模式,然後從中建立模型,例如預測性維護能力。
如Arm Cortex-M55處理器與Ethos U55微神經處理器(microNPU),利用CMSIS-DSP與CMSIS-NN等常見API來簡化程式碼的轉移性,讓MCU與共同處理器緊密耦合以加速AI功能。透過推論工具在低成本的MCU上實現AI功能並符合嵌入式設計需求極為重要,原因是具有AI功能的MCU有機會在各種物聯網應用中轉變裝置的設計。
AI在較小型、低耗電與記憶體受限的裝置中可以協助的關鍵功能,我們可以把其精華歸納至我們簡稱為「3V」的三大領域:語音(Voice,如自然語言處理)、視覺(Vision,如影像處理)以及震動(Vibration,如處理來自多種感測器的資料,包括從加速計到溫度感測器,或是來自馬達的電氣訊號)。
終端智慧對「3V」至關重要
多數的物聯網應用聚焦在一些特定的領域:基本控制(開/關)、測量(狀態、溫度、流量、噪音與震動、濕度等)、資產的狀況(所在地點以及狀況如何?),以及安全性功能、自動化、預測性維護以及遠端遙控(詳見圖 6)。
Strategy Analytics的研究顯示,許多已經完成部署或將要部署的物聯網B2B應用,仍然只需要相對簡單的指令,如基本的開/關,以及對設備與環境狀態的監控。在消費性物聯網領域中,智慧音箱的語音控制AI已經出現爆炸性成長,成為智慧家庭指令的中樞,包括智慧插座、智慧照明、智慧攝影機、智慧門鈴,以及智慧恆溫器等。消費性裝置如藍牙耳機現在已經具備情境感知功能,可以依據地點與環境,在音質優先與穩定度優先之間自動切換。
如同我們檢視的結果,終端AI可以在「3V」核心領域提供價值,而它觸及的許多物聯網領域,遍及B2B與B2C的應用:
震動:包含來自多種感測器資料的處理,從加速計感測器到溫度感測器,或來自馬達的電氣訊號。
視覺:影像與影片辨識;分析與識別靜止影像或影片內物件的能力。
語音:包括自然語言處理(NLP)、瞭解人類口中說出與寫出的語言的能力,以及使用人類語言與人類交談的能力-自然語言產生(NLG)。
垂直市場中有多種可以實作AI技術的使用場景:
震動
可以用來把智慧帶進MCU中的終端AI的進展,有各式各樣的不同應用領域,對於成本與物聯網裝置與應用的效用,都會帶來衝擊。這包括我們在圖6中點出的數個關鍵物聯網應用領域,包括:
溫度監控;
壓力監控;
溼度監控;
物理動作,包括滑倒與跌倒偵測;
物質檢測(漏水、瓦斯漏氣等) ;
磁通量(如鄰近感測器與流量監控) ;
感測器融合(見圖7);
電場變化。
一如我們將在使用場景單元中檢視的,這些能力有許多可以應用在各種被普遍部署的物聯網應用中。
語音
語音是進化的產物,也是人類溝通非常有效率的方式。因此我們常常想要用語音來對機器下指令,也不令人意外;聲音檢測是持續成長的類別。語音啟動在智慧家庭應用中很常見,例如智慧音箱,而它也逐漸成為啟動智慧家庭裝置與智慧家電的語音中樞,如電視、遊戲主機與其他新的電器。
在工業環境中,供車床、銑床與磨床等電腦數值控制(CNC)機器使用的電腦語音引擎正方興未艾。iTSpeex的ATHENA4是第一批專為這些產品設計的語音啟動作業系統。這些產品往往因為安全原因,有離線語音處理的需求,因此終端 AI 語音發展在這裡也創造出有趣的機會。用戶可以指示機器執行特定的運作,並從機器手冊與工廠文件,立即取用資訊。
語音整合在車輛中也相當關鍵。OEM 代工廠商持續對車載娛樂系統中的語音辨識系統,進行大量投資。語音有潛力成為最安全的輸入模式,因為它可以讓駕駛的眼睛持續盯著道路,而雙手仍持續握著方向盤。
對於使用觸控螢幕或硬體控制器通常需要多道步驟的複雜任務,語音辨識系統特別能勝任。這些任務包括輸入文字簡訊、輸入目的地、播放特定歌曲或歌曲子集,以及選擇廣播電台頻道。其他的服務包含如拋錨服務(或bCall)與禮賓服務。
視覺
正如我們之前已經檢視過,終端 AI 提供視覺領域全新的機會,特別是與物件檢測及辨識相關。這可能包括觀察生產線的製造瑕疵,以及找出自動販賣機需要補貨的庫存。其他實例包括農業應用,例如依據大小與品質為農產品分級。
曳引機裝上機器視覺攝影機後,我們幾乎可以即時檢測出雜草。雜草冒出後,AI可以分類雜草並估算它對農產收穫的潛在威脅。這讓農民可以鎖定特定的雜草,並打造客製的除草解決方案。機器視覺然後可以檢測除草劑的效用,並找出農地中仍具抗藥性的殘餘雜草。
使用場景
預測性維護工具已經從擷取與比較震動的量測資料,進化到提出即時的資產監控。藉由連接物聯網感測器裝置與維護軟體,我們也可能做到遠端監控。
震動分析
這種類型的預測性維護在旋轉型機器密集的製造工廠裡,相當常見。震動分析可以揭露鬆脫、不平衡、錯位與軸承磨損等狀況。例如,把震動計量器接上靠近選煤廠離心泵浦內部承軸處,就可以讓工程師建立起正常震動範圍的基線。超出這個範圍的震動,可能顯示滾珠軸承出現鬆動,需要更換。
磁感測器融合
磁感測器利用磁性浮筒與一系列可以感應並與液體表面一起移動的感測器,測量液面的高低。所有的這些應用都使用一個固定面上的磁感測器,它與附近平面的磁鐵一起作動,與這個磁鐵相對應的感測器也會移動。
聲學分析(聲音)
與震動分析相似,聲測方位分析也是供潤滑技師使用,主要是專注在主動採取潤滑措施。這意味我們可以避免移動設備時產生的過度磨損,否則會為了修理造成代價高昂的停機。實際的例子可能包括測量輸送皮帶的承軸狀況。出現過度磨損時,承軸會因為潤滑不足或錯位出現故障,可能造成整個生產流程的中斷。
聲學分析(超音波)
聲音聲學分析雖然可以用來進行主動與預測性維護,超音波聲學分析卻只能用於預測性維護。它可以在超音波範圍內找出與機器摩擦及壓力相關的聲音,並使用在會發出較細微聲音的電氣設備與機器設備。我們可以說這一類型的分析與震動或油量分析相比,更可以預測即將出現的故障。目前它部署起來比其他種類的預防性維護花費較高,但終端 AI 的進展可以促成這種細微層級的聲學檢測,大幅降低部署的費用。
熱顯影
熱顯影利用紅外線影像來監控互動機器零件的溫度,讓任何異常情況很快變得顯而易見。具備終端 AI 能力的裝置,可以長期檢測微細的變化。與其他對事故敏感的監視器一樣,它們會觸發排程系統,自動採取適當的行動來預防零件故障。
消費者與智慧家庭
將語音運用在消費者與智慧家庭,是最常看到的場景之一。這包括智慧型手機與平板電腦上、未包含電話整合功能的裝置,例如螢幕尺寸有限的穿戴式裝置。這類型的裝置包含智慧手錶與健康穿戴式裝置,可以為各種功能提供免動手的語音啟動。像 Amazon 的 Echo 或 Google 的 Home 等智慧音箱市場的成長,說明消費者對於可接收與提供語音互動等現有裝置的強勁需求,與日俱增。
消費者基於各種理由使用智慧音箱,最常見的使用場景為:
聽音樂;
控制如照明等智慧家庭裝置;
取得新聞與天氣預報的更新;
建立購物與待辦事項清單。
除了像智慧音箱與智慧電視等消費裝置,智慧家庭裝置語音的使用,也顯現相當的潛力。諸如連網門鈴(如 ring.com)等裝置與連網的煙霧偵測器(例如 Nest Protect 煙霧與一氧化碳警報)目前都已上市可供消費者選購,它們結合了語音與視覺的感測器融合功能以及運動檢測。有了連網的煙霧偵測器,裝置在偵測到煙霧或一氧化碳時,可以發出語音警告。
終端 AI 為強化這些能力提供了全新機會,而且常常結合震動(動作)、視覺與語音控制。例如,增加姿態辨識來控制例如電視等家電,或是把語音控制嵌入白色家電,即是以最低成本強化功能性最直接的方式。
健康照護
用來發現醫護資訊的 AI 驅動終端裝置的應用,將為病況的治療與診斷,提供更多的價值。這種資訊可能是資料,也可能是影像、影片以及說出的話,我們可以透過 AI 進行型態與診斷分析。這些資料將引發全新、更有效的治療方法,為整個產業節省成本。受惠於終端 AI 的進展,像 Google Duplex 等語音系統的複雜性將會降低。例如門診預約等勞力密集的工作,也可以轉換成 AI 活動。利用自然語言語音來延伸 AI 的使用,也可以把 AI 用在第一線的病人診斷,然後再由醫師接手提供諮詢。
其他健康照護實例包括像 Wewalk5 等物件,這是一個供半盲與全盲人員使用的智慧拐杖。它使用感測器來檢測胸口水平以上的物件,並搭配 Google Maps 與 Amazon Alexa 等 app,方便使用者提出問題。
結論
由於連網的終端裝置數量越來越多,這個世界也越來越複雜。連接到網際網路的裝置已經超過 300 億個,而微控制器的數量也超過 2,500 億,每年還會增加約 300 億個。越來越多的程序開始進行自動化,不過,把大量資料傳送到雲端涉及的延遲以及邊緣運算的額外費用,意味著許多全新、令人興奮且引人矚目的物聯網使用場景,可能無法開花結果。
解決這些挑戰的答案,並不是為雲端資料中心持續增添運算力。降低出現在邊緣的延遲雖然會有幫助,但不會解決日益分散的世界的所有挑戰。我們需要把智能應用到基礎架構中。
儘管為終端裝置增添先進的運算能力在十年前仍不可行,TinyML 技術近來的提升,已經讓位處相當邊緣的裝置 (也就是終端本身)增添智能的機會大大改觀。在終端增加運算與人工智慧能力,可以讓我們在源頭搜集到更多更具關聯性與相關的資訊。隨著裝置與資料的數量持續攀升,在源頭掌握情境化與具關聯性的資料,具有極大的價值,並將開啟全新的使用場景與營收機會。
終端裝置的機器學習,可以促成全新的終端 AI 世界。新的應用場景正在崛起,甚至跳過傳送大量資料的需求,因而紓解資料傳輸的瓶頸與延遲,並在各種作業環境中創造全新機會。終端 AI 將為我們開啟一個充滿全新機會與應用場景的世界,其中還有很多我們現在想像不到的機會。
附圖:圖1:從集中式到分散式運算的轉變。
(資料來源:《The End of Cloud Computing》,by Peter Levine,Andreessen Horowitz)
圖2:全球上網裝置安裝量。
(資料來源:Strategy Analytics)
圖3:深度學習流程。
圖4:MCU的視覺、震動與語音。
(資料來源:意法半導體)
圖5:AI 工具集執行模型轉換,以便在MCU上執行經最佳化的神經網路推論。
(資料來源:意法半導體)
圖6:物聯網企業對企業應用的使用-目前與未來。
(資料來源:Strategy Analytics)
圖7:促成情境感知的感測器融合。
(資料來源:恩智浦半導體)
資料來源:https://www.eettaiwan.com/20210303nt31-the-dawn-of-endpoint-ai-bringing-compute-closer-to-data/?fbclid=IwAR0JTRpNsJUl-DmSNpfIcymGQpkQaUgXixEaczwDpELxGCaCeJpkTyoqUtI
敏捷開發缺點 在 规模化敏捷开发框架SAFe 缺点有哪些#敏捷- YouTube 的推薦與評價
SAFe 最近很火,想和大家聊聊我的不同看法,欢迎留言指正欢迎朋友观看我的视频合集:职场 ... ... <看更多>
敏捷開發缺點 在 敏捷方法- 學習(Agile Method) - Morris' Blog 的推薦與評價
敏捷開發 重點筆記XP 極限開發簡介溝通為其特色,某方面來講有過於親密的傾向。如果程序猿們按照Pair Programming 的方式運行,被當成基佬們也不意外。 ... <看更多>
敏捷開發缺點 在 瑞嘉耐思NextFortune - 【同仁敏捷感想 的推薦與評價
【同仁敏捷感想|EP19_ Part2】 #覺得團隊導入敏捷後所帶來的優缺點? #優點: 工作分配時大家比較有機會或 ... 不過等敏捷開發都穩定後,這情形發生率應該會大幅減低。 ... <看更多>