# 91APP 的敏捷實踐之旅
###### tags: `DevOpsDays Taipei 2018` `9/12` `16:30~17:10` `Track A`

{%hackmd zjE8rohhTBKEAPwdaLV11Q %}

> 請從這裡開始
## 敏捷為什麼難推?
軟體開發==流程==跟==技術==都買得到
* 人心最難改
* 沒人敢要求老闆改
* HR 狀況外

## 敏捷之前常聽到的
- 研發
- PM 規劃的文件常常寫不清楚
- 很多功能完成上線，卻沒有客戶使用
- 許多急著線索留下的技術債都沒人處理
- 我們有派人去上敏捷課程，不知如何開始，目前只有推內部看版

- 產品
- RD總是花很多時間在估時
- RD總是說不可能全部完成需求，要求我們先做一小部分
- 開發人員每完成一個專案, 就進入另一個專案, 新上線專案的BUG沒有人維護
- 前一公司使用敏捷開發, 希望能有機會導入

### 曾經常見的專案路線
> 規劃 > 估時 > 開發/測試
- 需求做一半, 人都被調走, BUG沒人收
- 客戶不滿意, 排不出第二階段人力
- 技術債留一堆

### 敏捷第一步(2017Q3)

多職能團隊
- 成立以PM為中心的編組, 含Back End, Front End, App, QA, UI/UX等角色，但人員仍屬原功能性組織
- 專案有專人，不再四處調人力

設立 Agile Coach (原 Scrum Master)
- Ruddy 老師加入
- Terry 加入
- 先挑三個團隊試行Scrum

開設「敏捷管理課程」
- 讓管理者了解敏捷的本質

老闆 : 這個功能我可不可以在...時deliver給客戶?
> 改變老闆問問題的方法，而不是直接回答老闆的問題
> EX : 這個Sprint我們完成了幾個點數?

### 問題
- 敏捷怎麼沒有讓開發速度變快?
>敏捷的快 在交付市場服務的快(減少時間花在市場不需要的功能)
- 敏捷如何估時?誰能告訴我何時交付?
- Burndown chart 無法如預期收斂，也看不到歷史數據
>開發團隊建議，QA最好在一開始就參與.

## 敏捷第二步（2017Q4）

* 落實敏捷管理
* 邀請高階主管參與DEMO，並不定期瀏覽看板
>讓團隊覺得主管重視開發
* 設立移動式看板
* 讓看板可以帶進會議室討論
* 導入數位化工具
* 試行 Redmine (沒有 Burndown chart)
* 兩個月後決定改用VSTS

### 問題

SM 要求 PM 不要介入，讓團隊自行討論
* 團隊陷入一片混亂，SM是來亂的嗎？
* 我們真的需要SM一職嗎？
* 沒有SM行嗎？

其他的團隊也想導入Scrum
* Scrum 真的是最好的選擇嗎?
* 還有其他比Scrum更好的方法嗎?
* 可不可以只要看板就好? (半個Scrum)
->若沒有其他特別的風險，只是專案完成的人力分配，可以只跑看板就好

客戶的聲音還是無法反應到專案中

~~可不可以沒有ScrumMaster就run~~

一個SM可以帶幾個團隊?
> 兩個是極限

## 敏捷第三步 2018Q1（組織改造1/3）
推進組織改造第三步驟第一階段：強化團隊
- 所有的團隊加入敏捷, 但不限於 Scrum
- Scrum Master 改名 Agile Coach
- PM 改名 PO
- 每個團隊安排出一位資深 RD 為Tech Lead
> 協助技術的協調與決策

成立 PO Learning Circle
- 讓PO之間互相學習經驗

推行Persona方法
- 挑出幾個Key Account，主管每周拜訪客戶，傾聽客戶的使用狀況
> PO的主管 和 RD的主管 去現場
- 新產品設計時，DMEO給客戶看，請客戶提供意見

### 問題
團隊自主性變強了, 但是形成新的Silo
- 團隊之間難以合作
- 跨團隊工作不協調
- 資源難以移動

敏捷團隊與功能性組織的衝突擴大

與客戶API介接無法在團隊內實踐

業務仍然抱怨客戶的需求沒有排程

## 敏捷第四步2018Q2(組織改造2/3)

- 以產品功能結構重組團隊架構
- 參考LeSS方法, 合併成幾個較大的團隊, 切齊Sprint
- 上設產品與研發聯席會議- One Team
> 產品的目標和研發的目標要一致
- 虛級化功能性組織, 但仍保有人才管理及專業交流的責任
- 推行 Feedback 制度

由OneTeam討論絕地高階的One PBI
- 作為各團隊排工作的基礎
- 公告在VSTS上，讓其他部門主管解現況，並參與接下來的排程

成立專案組(API)
- 獨立進行API專案服務
- 避免產品被不定期的客戶個別需求羈絆

## 敏捷第五部 2018Q3

試行更快更小的敏捷
- 由Andrew Wu 領導3人小組
- 從架構改造開始
- 不限制Sprint行事, 要求每個月交付 Business Impact

擴大DevOps的範圍，開發團隊重新規劃維運則作

業務主管參與PBI討論排程
- 業務參與敏捷會議，讓團隊隨時了解業務目標及市場現況
- 導入OKR方法，讓PBI更能瞄準商業目標

### 無法預期的歷程

推動
- 形成團隊
- 訓練輔導
- 部分先行

管理
- 改變主管
- 敏捷優先
- 透明管理

強化
- 強化團隊
- 擴大敏捷
- 客戶優先

改組
- 敏捷組織
- 整合目標
- 處理例外

突破
- 快打部隊
- 業務合作
- OKR

年底績效考核將至, 如何推行考核制度?
自組織不會自動形成, 一方面拿掉阻礙, 還要加入什麼?
最後的組織改造, 尚待時機

## 結語
第一次推動敏捷考慮外部協助
敏捷不可以在小圈圈裡, 要把stakeholder都拉進來
持續學習, 不斷改進

---
> 場外聊天室，歡迎在下方喇賽

為了怕功能不完整，所以所有都必須有彈性，什麼都有彈性就得開發很久 --> 負向循環

功能上的彈性跟程式設計上的彈性不大一樣吧
> by 在隔壁場的人
> >主要是功能上的彈性。 需求單位不會知道系統/程式設計上的彈性

> 彈性有兩種做法，把所有可能都預想好加到規格，這是不敏捷的彈性。設計上用各種可擴充的方式設計 (只留 interface 不寫 implementation) 等到需要時好改就好 => 這是敏捷的彈性。連 interface 都沒考慮到，就重構擴充 interface...
>> 是啊，所有的都要預想+實做出來的彈性。
>> 對了，時間不可以彈性，上線時間不可以delay (笑)

請問大神,後台Api給的文件常常要通靈在麼辦?
> 一個不夠，那就試試兩個...
> Restful API + SWagger > 自動產生API文件含測試
>> 文件永遠跟不上 code, 除非文件一起進版控，不然就是文件是要被自動產生出來。如果大家都用 C# / VS, code comments 效果遠比單純文件好。sample doc 等較長的文件，練習用 XXX.md, 隨著 source code 一起版控吧。code 改了 doc 就跟著改，一起 commit 一起 push 一起 code review
>>> test case 有跟上比較重要(ㄟ )
>>>>postman
>>>>> 安安近期推出 ： https://developer.91app.com/docs/index.html
>>>>>> 這是自動產生文件的 best practice

> 我們之前的工程實踐是用 swagger + AWS API Gateway 先行構建 Mock API 之後再轉換到正式 backend logic ，這樣可以方便 F2E / Mobile 團隊知道大方向的 API 定義

Agile 的譯意?
> 靈活、彈性

QA要進來, 但我們QA永遠在狀況外.....
(´;ω;`)ヾ(･∀･`)
+1

PO 是什麼？
>Product/Project Owner 吧.
> > 就是 Product Owner 喔 :)
>>> 感恩!
>>>

OKR是什麼？
OKR(Objectives and Key Results)