# 軟體工程—影像專案開發管理：講座筆記

###### tags: `軟體工程`, `影像專案`, `敏捷軟體開發`

## 講者介紹
#### 曾維新 技術長
現任　　玩美移動資深副總經理暨技術長
曾任職　訊連科技

## 專案管理經驗分享: Scrum + BML + 看板

### BML
即: Build → Measure → Learn
先快速地、就已有技術做出一些目前能力所及的開發項目
(Build, 即產出程式碼)

結束時整個團隊再來評估哪些做得好、做得待加強
(Measure, 應該會在 Retrospective Meeting 討論)

並接續著快速學習下一個流程需具備、比較不熟的知識 (Learn)

而 BML 開發流程圈圈，進行得 **越快越好**

### 實際的開發樣貌

講者所在團隊的軟體開發，主要以影像應用為主
多聚焦在化妝品產業、保養品產業

而他們利用 BML 這種結構的模式在跑專案
發現成效相當好
團隊成員收到老闆的企劃
瞄準特定產業，準備做一個相當新穎的應用
但有些技術可能太新，團隊成員都沒碰過
但也無須害怕~

因為他們一次次的專案累積了很好的經驗
從 Waterfall，到現今的 Agile
本來是在常常要加班趕工、壓力大的狀態
改用敏捷，搭配以下實施細節:
**在前幾個 Sprints，就把專案 Must to have 的 features 完成！**
而且，因為**一開始 Product Backlog 就有清楚規劃 Priority**
故越後面的 Sprints
都是專案初期規劃為越不重要的項目(Nice to hace)

舉個栗子🌰
講者公司曾有個專案，交期是一年
因為按照上述規劃跑敏捷
重要的 User Stroies 在幾個月後都陸續達成了
到接近專案開始後的一年，重要的功能都開發完成
而當時進行到 Sprint-9 (第九個 iteration)，接近產品交期
儘管其實還剩下不少(粗體字顯示的)未完成項目
但也毅然決然，不延長專案時間，果斷捨棄這些項目
因為都是些最不重要(普遍性低、使用率不高)的功能
而最重要功能在 Sprint-1 早早做完
前幾個 Sprints 也補上能展現產品特色、亮點的地方

專案結束後，評估與此次專案
與前幾年: 用 Waterfall 開發的經驗相比
當時日日需要加班，趕一堆做不完的功能
而這次的敏捷開發後期都是趕非必要功能，輕鬆很多！
且整個專案的一年當中，幾乎沒加過班~
尤以專案後期的進度壓力小了不少

### Scrum 合適的團隊人數
每個 task 一般會需要 2 人
(以利互相 co-programming，彼此 cover)
而整個敏捷團隊，則建議 7±2人
講者用《人月神話：軟體專案管理之道 / Mythical Man-Month》舉例
說明【人】:軟體專案開發人手從 1人往上慢慢增加
完成【月】:專案的完成月數，是會指數型下降的
但人數大過一個數字後，完成月數不減反增

參考這本著作的經驗與論證
以講者的團隊而言，他底下領帥的幾個團隊
每個團隊都採平均接近 7 人的任務編組

### Scrum+BML+Kanban 專案流程の概要
透過這種模式，搭配 敏捷開發的 Scrum
Product Backlog Meeting 制定好許願池(Backlog)
並且 Task Assignment 大家依照不同專長認領好工作後
會利用看板開發(Kanban)
依據認領的 tasks，規劃不同成員在看板中的角色
兩兩一組負責完成一個任務，很快就可以完成

### ☆ Scrum+BML+Kanban 專案流程の重點

#### 重點 1: 實施方式
而上圖的 Backlog 階段
會從大約 20 ~ 40 個 (有些太天馬行空) User Stories
先選出大約 10 個最重要的 User Stories
(Agile - Product Backlog Meeting)
再來，**決定各 User Stories 的【優先權】順序**
各自對應到: 被細化成更多數量的 Tasks
而每個成員會認領數個 Tasks
但每個人**一次只做一個 Tasks**

#### 重點 2: 一個 Sprint 分幾週?
以講者團隊而言
他們一個 Sprint 分為 **6-8 週** (約 2 month)

#### 重點 3: 需嚴格落實看板【人數】，齊心通關
以講者的團隊為例
敏捷團隊 7±2人，講者的經驗採 7 人，每個 task 2 人負責
而**上圖沒寫出每一個流程的人數**
講者的團隊，則會基於上圖，對每個流程的人數做規劃
如: To Do(2), In Progress(2)
括號內的數字，代表該流程人數上限
大家會嚴格落實團隊人數的共識
有些 (2人小組) 做得快先做、有些 (2人小組) 後做
**當有進度最快的 2人小組，已經跑到終點 (Done)
而尚有其它小組還卡在 Testing 甚至 In Progress
進度快的小組，就能夠幫助卡關的隊友
試著找出可能的 problem 及 solution，大家齊力通關**
目標是在 6-8 週的 Sprint 之前
全員通關成功，解鎖任務！

## Ｑ＆Ａ
### [Q1] 想請教技術長對 Open Source(開源程式) 的看法
貴公司會採開源方式完成專案嗎？
### [A1] 重要的核心技術一定閉源。
且重要的是一開始會和目標廠商簽約(如: 化妝品、保養品公司)
(談好專案、合約後)並展開為期一年左右的開發(實際時間依雙方合約簽訂)
開發完核心的 features 以後，這些核心程式碼都鎖著(是重要的資產)
頂多只有比較外部、簡單的，工程師團隊做不出來的
最主要是希望放到開源平台後，有人能幫忙完成

### 補充 1
把重要程式開源，講者認為並沒有太大的商業利益、必要性
且有被模仿、抄襲的風險
但合約的簽訂具法律效力
可以保障有足夠有力($)的供應商、數量夠多的平台使用者
講者席間舉 Facebook 團隊的例子，他們算出:
平台每多一位使用者註冊，平均能帶來 $30 的收益，換算台幣將近一千元

### 補充 2
功能完成後，可能做了不只一個版本
究竟哪種較好？
PO不會知道, SM不會知道
老闆、客戶、資深的開發者都不會知道
需要由市場驗證
即: A/B Test
完美科技，乃至母公司訊連，時不時(開發了一點點新東西後)在做更新
原因是想知道 UI、functions 的偏好
廣大使用者對兩種設計的喜好可能相差 20% 甚至更多

### 補充 3
「成長駭客」一詞，在講者座談間有提到
此應為「行銷駭客」此行銷學相關領域的新興術語
指的是平台使用者的增長，會帶來營收數字顯著的成長
而採取哪些行銷方法(如上述 A/B Test 也是一種)
對於實際的營收能否達到預期，甚至猛烈地增長，其效益是相當重要的

### [Q2] 有沒有考慮過 CMMI
### [A2] 曾經有嘗試過，但實際效果感覺不如預期
(可能是影像相關的專案變化、更新太大，CMMI 所能帶來的程式碼重用性、專案流程重用性，在這類型的開發團隊中效益並不大)

### 備註
曾維新 技術長的講座讓我受惠非常多
除上述專案經驗分享外
亦談及影像處理專案
從
定義問題 → 制定可能的解法 → 嘗試 → 不符SM預期
再
訪談 → 定義問題 → 定義其他可能解法
直到完美解決
都需要一遍又一遍的嘗試錯誤
和影像處理相關的 knowhow
更重要的是:
知道對技術名詞不熟悉的人所說的「形容詞+名詞」是甚麼、
如何將模糊、曖昧不明的需求，轉換成合適的專有名詞，並整理出解法
是在這個領域中更為重要的能力

這些解法跟影像處理息息相關
(訊連科技的老本行)
但記錄在敝人錄製的影片中
整理有點費時，在此不多作介紹