鈦鉭科技敏捷講座

身為一個敏捷的學習者,這次看到一家名為新加坡立鈦鉭科技的公司有一場敏捷活動分享,所以馬上報名參加這場活動!這是一場很有趣的學習,除了來的人有些人已經具備了一點點敏捷知識外,且我們事先實作之後,才開始學習敏捷相關基本的知識!

位在南港的一家公司

因為非常接近,所以我六點下班後就直接從市政府搭捷運到南港展覽館,大概從 5 號出口走 10 分鐘就到他們公司囉,他們的鄰居有一個是鼎鼎大名的浩鼎生技公司!

鈦鉭科技的位置

破冰之旅

一開始到現場,報名就坐之後,公司非常貼心地提供了輕食給趕來現場的朋友食用,讓我們不用花時間在南港人生地不熟的地方找尋食物,他們在一開始就發揮了 Scrum Master 的精神協助參與者解決了飲食的問題。吃飽喝足後,人們也差不多到齊了。在司儀的引導下我們開始了這場活動。

選擇產品

一開始老師(這篇文章會統稱活動主持人或講者為老師)要我們選定一個主題來決定要開發的產品,然後我們要為這個產品畫上 UI 圖,我們這組選擇了音樂軟體,雖然我們組的人對消費性產品似乎不那麼了解,而且其實一開始根本不知道要做甚麼,但是緊接著,老師要我們針對決定的主題來為這個產品規劃他要有的功能。

規劃會議(10分鐘,共兩次)

雖然一開始腦子中一片空白,不過我想到價值主張年代中的一個圓圈型的圖,所以我向組員提出:「我們要不要從這三個方面去想?顧客為甚麼要聽音樂、他覺得在聽音樂時會獲得什麼,以及他覺得哪些事情在聽音樂時會造成麻煩?」

也很感謝大家的捧場,我們花了大概 3 分鐘的時間了解為甚麼大家想要聽音樂:有些目的是放鬆、有些人目的是為了創作。這時,我們組的Scrum Master 過來提醒我們要趕快開始寫功能卡,因為老師的要求是要寫出至少 30 功能,所以我們團隊也很快速地寫出了 30 個我們「自己」覺得可行的功能。剛好鈴響了,老師要我們進入下一個階段。

剛好想到右邊那個圓形圖

而第二次的規劃會議則是比第一次還要快上的許多了,大家也更明確知道自己要做那些功能,或者負荷那些工作。而且這時也有新朋友的加入,我們花了一點時間向他解釋後,他很快地也挑了一些工作來作,他畫了搜歌功能,非常酷!

衝刺我們團隊的作品(10分鐘,共兩次)

這兩次我們都根據規劃會議時的討論以及發想,揀選幾個重要的功能進行開發,比較這兩次的開發結果,我們發現我們第二次的產量明顯多了,我們認為是因為:

  1. 熟悉彼此以及要做的內容
  2. 根據前次的經驗進行開發上的調整
  3. 有落實要更精進的地方

也因此我們這兩次的開發後,我們做出了很有趣的作品:有遊戲化機制的音樂 APP !詳細內容請看下一個主題!

展示我們的作品(2分鐘,共兩次)

我們一共分兩次進行開發,第一次開發的內容是留言功能、播放功能以及篩選音樂的功能(我展示我實作的部分)

我設計的部分是播放功能,這個播放功能,我結合了八角框架理論的核心驅動四(所有權)跟核心驅動七(稀缺性),我讓免費使用的人跟付費使用者的功能不太一樣,例如付費的人可以看到歌詞以及剪下一段他喜歡的音樂來重複播放等等,同時右上角可以擁有一個付費用戶的證明,證明你與其他人不一樣,藉此希望能吸引消費者付費使用我們的產品!

其他組的展示也非常有趣,像是我們看到第一組的功能非常豐富且多元,讓我覺得好像擁有他們的 APP 就擁有一個完整的美食地圖一樣,而第二組的作品非常專業,他們把 UI 圖直接黏在一張 A4 紙上,所以在瀏覽的時候非常有動態的感覺,在第一次的展示之後,我們也學習了第二組的做法,把畫面接在一起。

而第二次開發的內容是播放清單、直播功能、社群登入與分享功能、音質選擇,以及搜歌的功能。

這是登入頁面

而這邊的遊戲化作法是,利用核心驅動六(倒數計時)與核心驅動八(避免損失)希望讓消費者趕快加入頂級用戶,就可以無線暢聽我們提供的音樂,或這單次購買這首音樂,放入自己的音樂庫,不然就是要等好一陣子(休息酷刑)才能再聽一次。而且也有用到核心驅動七(不確定性)來讓使用者有偶爾的免費聽音樂的驚喜!

利用差異化讓使用者願意付錢

這次的展示會議後,老師要我們為自己跟其他組打分數。

回顧會議(5分鐘,共二次)

這邊我們要回顧我們前面兩次作了哪些事情後,想一下什麼樣作的很好,可以繼續保持的,什麼樣的東西可以做得更好,或者說流程可以更精進的。那我們下一個週期要怎麼達成這些事情。我們組員很快地討論完後,在下個週其調整我們的開發方法來完成我們的 UI 圖

心得以及學習到的東西

這邊我採用零秒思考力的筆記法把我覺得學習到的東西記錄下來。

整體來說,合作是一件非常重要的是,我之前寫過一篇文章提到:

Great Teams Are About Personalities, Not Just Skills(好的團隊由人組成,不是由技術組成),或者是這篇文章:「一個人走的快,一群人走的遠」,但為何有些團隊就是走不遠?原因是真正成功的團隊在於團員人格特質能適得其所地展現,而非只有技術領導。由此我們可以明白,技術是絕對需要,但不是唯一的重點。而人格特質要為團隊帶來巨大的幫助,最重要的在於溝通,於是我們才說「一群人走得快……」。

了解 Scrum 是甚麼

老師非常細心的介紹了 Scrum 的三個特性、三個角色、四個儀式、以及五個精神。雖然看似所學甚淺但是可以知道每家公司使用 Scrum 的方式會有不同的方法,大家都在同樣的框架下發展出不同的實踐敏捷方法,真的是驗證了

Scrum + 企業文化 = 獨特的 Scrum

對此我想多用一些人們說過的話,每個企業的 Scrum 是非常不同的,例如Oleg Kožemjakin在他的文章 My scrum is not Your scrum 中提到:

Now there is no way to take “their” scrum and copy it to different company. It will simply be wrong. It can be used as discussion bases towards understanding what can be done, but not as it is. — Oleg Kožemjakin

參加者提到的問題有哪些?

以下紀錄我聽到的並且還記得的內容,並且附上我部份的想法

問:PM 跟 PO 差在哪裡?

師:其實沒有差,只是名稱不同。

我的想法:PO 跟 PM (此指專案型團隊的 PM)其實都要具有商業分析能力,決定產品的商業價值是否能夠與市場競爭,因此我覺得 PM 跟 PO 沒有太大差別,差別應是在於組織架構上, PM 固定是管理層,而 PO 則是在要決定開發路線時才會成為領頭豬帶領其他豬組成員前進。

問:TDD 跟 Scrum 差在哪裡?

師:一種寫程式的做法,而 Scrum 比較講的是流程。(此處記憶有點模糊,不確定是不是這個答案)

我的想法:同意。

問:如果我有多的 Scrum Team ,請問在一個產品待辦清單中,我們要怎麼樣控管多個 Scrum Team,確保開發路線一致

師:這個有很多可以討論,但是不在我們授課範圍,考量各位參加者所,以暫時不解。

問:要用 CI/CD 嗎?

師:不一定,看情況來決定是否使用,但是有嘗試使用是可以建立好的開發習慣。

我的觀點:這個有點牽涉到 DevOps 的議題了,我覺得用 CI/CD 非常好,因為現在是一個求好求快的是世代, 在 The benefits of DevOps 中提到使用 DevOps 開發思維的好處是:

DevOps organizations can deliver with maximum speed, functionality, and innovation.

但是我覺得還有一個前提是,測試案例要夠好。 CI/CD 才能發會最大的價值。因為我們要交的程式碼要盡量沒有出現問題,而好的測試案例可以降低程式出錯的風險。所以很多作自動的圖都會有一個順序,通常先自動化測試後進行 CI Build ,再進行一次測試,詳細的流程圖可以上這個官網看到 Continuous Integration (CI) Best Practices with SAP: Pipeline Suggestions

When the change has passed the voter build and tests , it is merged into the main line . As a next step after the merge, the CI build is triggered automatically. It builds the change and thus checks the build integrity of the main line. The build is self-testing, that is, it contains automatic tests.

頒獎與交流

很高興這次的小競賽由我們組別勝出,所以我們各獲得了一本方格筆記本,感覺會非常好用,但是我覺得我們的作品有機會還是得要拿去市場上、或者是給贊助者驗證可行性,才能有真正的獲利。

獎品是一個小的方格筆記本!

不得不特別提到這個筆記本,背面完全驅動我啊!給了我一個很大的使命與願景(核心驅動力一),我們要憶起變得更好,更強。除了符合敏捷精神外,更讓我覺得完成這件是會很有成就(核心驅動力二)!

這邊還有一個小小的遊戲化:不確定性(核心驅動七),我意外獲得了在某個時候回答會獲得的神祕小禮物,估算撲克牌,真的很驚喜,而且也有所有權(核心驅動五)與稀缺性(核心驅動六)的擁有感,真的是一個非常棒的體驗!

某個時候回答會獲得的神祕小禮物

總結

或許有人看了這篇文章後,覺得似乎 Scrum 是萬靈丹,是一顆銀彈,但我必須說:不是,要看你的專案來決定是否使用這個方法。

我們常說切水果用水果刀,切菜用菜刀,在作專案也是,中度不確定性且有中度風險的專案適合用敏捷,在 When to use Scrum 這篇文章中提到:

Scrum really pays off for projects which:
1. have stakeholders who frequently change their minds
2. require a quick feedback loop
3. use stakeholders’ feedback to prioritise the next sprint
4. don’t get many interruptions from everyday business
5. have a cross functional team

也因此當大家未來想要用敏捷的後也務必要考慮這些事情。

額外的參考學習

八角框架理論

遊戲化實戰社團 Tw

零秒思考力Tw

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.