# 第1堂課：scrum in titansoft
###### tags: class_01
Date：2022.2.19（六） 14:00-17:00
Place：成大
lecturer：Leon
( [筆記模板](https://hackmd.io/TN6mnsUXRQeXhSzKTdf__A#%E8%AA%B2%E7%A8%8B%E7%AD%86%E8%A8%98%E6%A8%A1%E6%9D%BF) )

---

科技業主要分成硬體、軟體、韌體等大類，而鈦坦在科技業中屬於專攻應用的純軟業，本課程會介紹純軟業的架構與組成，以及軟體業中主要的分工與生態。
此外，鈦坦的 Scrum 團隊在業界也是數一數二的，想知道鈦坦如何利用敏捷思維響應不斷變化的產品需求，同時降低風險嗎?快來上課吧！

---

## 課前準備：
- [ ] 帶自己的 **履歷手稿**
- [ ] 到 [發問專區](##發問專區) 提出你的任何好奇！

## 注意事項：

1. 請同學於課程開始前 10 分鐘進行報到，採梅花座就座。
2. 出席學員當天需於簽到表進行簽到與簽退
3. 請配戴口罩，若身體不適，請勿參與活動。
4. 學校將視中央流行疫情指揮中心的公告進行評估，若疫情趨於嚴峻，將會延後本次課程，並保留已選上同學課程名額，另行通知後續課程安排。

## 發問專區
* 專案型公司例子
* 叡揚資訊
* 小軟體公司
* 軟體業的資料分析師
* 看公司需不需要分析資料
* 台灣的UI/UX會不會都混在一起?
* 台灣純 ux 比較少，大部分兩個都要會
* 如何切割待辦清單?
* 從可見、有意義的結果作為大項目(user story)，再以同樣原則慢慢切成更小的項目
* 對內會有冗員或是有人沒事做的情況嗎?
* 有可能 ex.純設計師
* 但如何進行人力配置可由團隊決定
* 上述文字可能會有一些誤導，特此補充說明

有人沒事做並不是什麼職能的問題，而是團隊的決定。

Scrum team 必須是跨職能的有能力自己產出產品，
以軟體開發團隊為例，如果團隊中的工程師們自認為設計能力不足，無法產出對應期待的產品，
判斷需要聘請專業設計師作為團隊成員之一，那就是團隊的選擇，團隊選擇讓設計師補上團隊中的一個員額。

一個可見的情況是那設計師很有可能會因為無法參與多數工程師的 coding 工作而導致某些時間沒事做，
這的確可能發生，但一個健康的團隊應該不會讓這件事變成常態，
應該會在 retrospective (回顧會議，Scrum 核心活動之一)時發現這件事不合理，
並在工作節奏上做些「調整/改善」(Scrum 三本柱之一)，
例如讓設計師預先進行設計 survey 或是預設計下一個 sprint 會用到的素材等，
調整方案是團隊自己決定的。

「有人沒事做」這件事能「被看見」(透明 & 觀測，Scrum 三本柱之二)，
反映了團隊分工不妥的現象，即便是工程師本身，如果團隊工作沒有合理分配，一樣有可能會變成冗員，
例如一個團隊負責的產品其實就只要三個工程師就足夠處理，
那如果聘到六個工程師不就很容易會有人無事可做嗎? 
所以與職能沒有絕對關係，純設計師只是一個舉例。

* scrum giude 實作細節
* 釐清 sprint 所有需求
* 精煉：定義怎樣才算是做對
* planning 為了這個功能需要做那些變動
* 切割成能在短時間內(例如一小時)完成的小任務，任務切得愈小，可控性愈高，出問題帶來的風險和修復成本相對低
* **預測 Goal**: 開發團隊預估這個 sprint 可以完成多少項目
* 不同背景間溝通?
* 實例化需求(specification by example)、認知對齊
* 估計點數：例如使用費氏數列(1,2,3,5,8,13,21,...)來代表工作複雜度
* 需求跟需求間的整合?品管
* 小組本身要有測試的能力
* definition of done (DoD): 團隊要自己定義怎樣才算「完成」一個項目
* scrum 在疫情期間有甚麼樣的挑戰?或是暫時無法解決的事情?
* 善用工具
* 傳遞的訊息一定會有誤差，但要盡可能降低衝擊
* 平時可以多演練突發狀況的因應措施

---
## 課程筆記

### hello world
在軟體業的世界，請謹記三件事
* 沒有標準答案
* 資源有限
* 變化是必然

### 課程活動1：台南之旅

活動目的：由於來台南玩的朋友行程不斷變動，從中體驗在軟體業中經常發生的事，也就是面對時間壓力和任務經常變動。而透過敏捷的精神來面對這樣的狀況。

敏捷：一種**精神與文化**
變化來的時候可以很快速地應變

敏捷由來：2001 軟體開發大神所訂定的精神，而當中有建立4個價值觀

個人與互動>>流程與工具
可用的軟體>>詳盡的文件
與客戶合作>>合作協商
回應變化>>遵循計劃

### 敏捷特點
1. **接納不完美**
* 完成>未完成
* 100 x 60% > 100 x 0%
穩定獲利 > 一夕間的賭注
* 技術債：有意識地欠債(知道自己目前差多少)
* 多好才算完美：如果追求完美，那要到什麼程度才能上線?

2. **專注 vs 多工**
* 清晰目標與代辦事項
* 漸少認知轉換(資源消耗)
->平行運作

3. **Do the right thing > Do things right**
* 事前計劃釐清(有效的溝通)
* 安全感
* 共通語言
* 資訊同步
* 越簡單越好
* 投入資源換取效率

4. **快速驗證**
* 縮短取得回饋週期(一週>一個月)
* 降低工作成本
* 資訊揭露、組織扁平
* 降低失敗成本
* 小小淺嚐、試錯
* 有意識延遲決定
5. **從錯誤中改善**
* 可視化紀錄>>>讓足跡被看見
* 檢討
* 行動

### Scrum
輔助敏捷的框架，前提是組織要敏捷否則在執行上會遇到很多狀況和不順暢。

三個支持Scrum的想法(三本柱)
* 透明：ex.每人都可以看到待辦清單和項目順序、團隊運作的每個環節都要透明
* 檢核：ex.看板、定期回顧
* 調整/改善：ex.retro

Scrum過程裏頭會牽涉到的幾個數字

3 roles
3 artifacts
5 events
5 values

### Scrum的流程
過程裡面的重要概念
* 迭代(iteration)：短時間迴圈，讓事情透過一次次迭代愈來愈好
* 時間限制(timebox)：提醒取捨，凡事都有 timebox
* 增量(increment)：在時間限制裡成長(增加)，每個迭代都要有可見且有價值的成果

資源是有限的，但需求是無限的QQ>>>找最有價值的事來做

st=>start: Sprint 開始
e=>end: Retrospective (回顧會議)
op=>operation: Planning (精煉會議、計畫等)
op1=>operation: Daily scrum
op3=>operation: Review (成果發表)
cond=>condition: 開發 Timebox 
時限已到?

st->op->op1->cond
cond(no)->op1
cond(yes)->op3
op3->e

### 適合 scrum 場景

不是任何人都適合Scrum，較適合需求不明確、解決方案也不清晰的對象

### 軟體業
專案型
* 接案
* 通常以月為單位
* 時程控管
* 一般來說是 B2B 居多(畢竟個人直接去找軟體公司開發專案的情況較少)
* 可嘗試最新技術

產品型
* 長時間產品 ex.Gmail
* 持續優化、維運
* B2B/B2C

Waterfall 組織中可能有的角色
* PM
* SD
* SA
* PG
* Cst

他們之間互動的關係為：上層 Cst 接需求 > PM 管時程 > SD、SA 發規格書 > PG 寫程式

### 課程活動2：義大利麵堆高高

活動目的：透過義大利麵、膠帶嘗試把棉花糖堆在高處，越高越好。過程中組員會不斷嘗試修正結構讓義大利麵能夠穩故

---

## 下課囉！除了簽退，你還可以...

- [ ] 完成 [課後心得](###課後心得)
- [ ] 完成課後花絮

**「輸入」知識的同時，也要練習「輸出」喔！**

### 課後心得
麻煩上完課後來這邊寫下你的回饋、問題、建議等等，方便寫花絮的同學整理編輯喔！
`本週課程花絮負責人：` ```仲德```

---
`楷傑`

今天課程由安排台南行程作為開始，結果限制條件一直更改，最後我們安排的行程就一直改一直改。
原來這是讓我們體驗軟體工程師的日常，又或是體驗未來工作上需求的不斷變化。

接下來是敏捷與 Scrum 的介紹，過程中收穫最大的是，我們要樂於接納自己的不完美，因為世界改變得太快了，很多不確定的事情不必再花十年磨一劍，而是可以透過更快的做出「小成果」，也許會更能貼近目標。

最後的尾聲，我們用義大利麵與膠帶，試圖在短時間蓋出一座高塔，作為課程最後的練習。
我們不知道怎麼蓋，然後有材料與時間限制，所以就直接埋頭開始建造，最後因為棉花糖太重了，所以重新砍掉，讓整個塔可以穩固地站著。

這真的體現我們不用真的蓋出超完美的高塔，而是嘗試用不同的材料、結構去達成目標—撐住棉花糖，深刻的學習到了敏捷的精髓，「面對變化，保持樂觀」

---
`名涵`

先前對於敏捷式開發以及SCRUM皆略有耳聞，有別於原本從課本、網路、書籍所了解到的SCRUM，本次課程透過第一線的軟體開發實務經驗，使我瞭解到敏捷開發的重點並不在於各式各樣的流程與文件，而是在於其核心精神。

以SCRUM的流程框架作為輔助，在專案運行過程中秉持著明確的任務目標、接納不完美、快速驗證、持續改善，等幾項原則，來達成SCRUM的三本柱「透明」、「檢核」、「改善」。

---
`秀綺`

常常在課堂上聽老師提起敏捷，卻一直以為所謂敏捷就是快速、迅速，直到上了這堂課才發現原來我只知其名而不知其意，其實敏捷是一種快速應對變化的精神！

在開發過程中總是會碰到各種變化，傳統的waterfall除了上下層之間無法妥善溝通外，也很難因應突如其來的需求與改變，可能會導致浪費許多時間與精力；而擁有敏捷精神的scrum則是透過團體內相互溝通、協調、達成共識，並且使用迭代將專案或產品像蓋房子般一步步構建成型。

除此之外Leon學長也跟我們分享了一些業界經驗，如接納不完美、有意識地欠技術債等等。希望未來在面對變化時，我也能保有agile的精神！

---
`姵涵`

課程一開始用pair 的方式，討論要如何招待一個朋友遠從他方造訪台南。原以為給定了兩天一夜的時間，就能夠好好安排自己所謂的「完美行程」，沒想到都排好行程後，朋友突然一個改口，像是從兩天一夜改成一天一夜，甚至改成一日遊。
這個遊戲把「專案進度」比擬成「原給定的時間」；「朋友突然的改口」比擬作「執行專案時發生的變數」。由這個小遊戲帶出了一個團隊在面對「改變」時，所須具備的反應能力，也為「敏捷文化在組織裡扮演重要角色」埋下伏筆。

Leon歸納出來的五個敏捷特點
1.接納不完美
2.專注v.s.多工
3.做對的事與把事情做對
4.快速驗證
5.從錯誤中改善

自己最有感觸的是「接納不完美」。雖然我不是什麼完美主義者，但其實規範自己完成進度的時候，常常對自己的半成品不滿，雖然也不會就不繳交，但心裡常感受到一種不踏實。五個敏捷的特點也都是環環相扣的，如果最前面沒有接納不完美，那就代表後面沒有辦法快速驗證、從錯誤中改善等等。在學習實踐敏捷精神時，我認為我應該將「接納不完美」放在心上，先求有，再求好。

寒假時我其實就有把整個scrum guide 看過一遍，看完第一遍還看不太懂所以又看了兩三遍～結果還是忘了蠻多重要環節的！Leon在介紹完Scrum 流程後，也以拋出問題的方式，引導我們思考、驗證剛剛聽完的內容有沒有融會貫通，讓我對Scrum 整個流程有了更深刻的印象。

然而，也不是什麼工作都導入scrum 才是最佳解藥。在需要解決「複雜的問題」（需求清晰程度與解決方案清晰程度皆不明）時，最適合用scrum 的方式。

接近課程尾聲，我也在短短時間內認識軟體產業。根據產出的性質又分為「專案型」和「產品型」。自己覺得專案型公司有種「80天環遊世界」這本世界名著裡流露出來的快感；而產品型公司像是馬拉松比賽，每往前邁進一步的艱辛，是要用更長久的耐力還得而來。

除了認識這兩種公司的異質性外，Leon也大略介紹了各種不同的軟體工程人員通常負責的任務是什麼。相信這些說明都可以讓非電資學院背景的夥伴們更知道自己能夠在軟業界扮演什麼角色、需要再多磨練哪方面的技能。

課程最後以義大利麵、膠帶、一張紙、一條棉繩和一顆棉花糖所建構成的「巴別塔」來做收尾。在搭建的過程，我尤其記得夥伴拿著棉繩，試圖找出整個塔的「重心」在哪裡！覺得很酷因為從還沒蓋塔前，我就覺得如果真的蓋得起來，那會是件很不可思議的事～過程中，大家也懷抱敏捷精神，勇敢試錯，錯了再重來。雖然成果都有經過了一些調整，才有了最後的高度，但整個過程確實令人發省，到底怎麼做才能夠更順利的朝向原本設立的高度？怎麼做微調才不會讓最後放上去的的棉花糖壓垮下面的義大利麵呢？覺得很有趣的一個活動，以後可以常常挑戰🤣