owned this note changed 7 years ago
Linked with GitHub

91APP 的敏捷實踐之旅

tags: DevOpsDays Taipei 2018 9/12 16:30~17:10 Track A

歡迎來到 DevOps Days 2018 共筆

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

共筆入口:https://hackmd.io/c/DevOpsDays2018
手機版請點選上方 按鈕展開議程列表。

在大會遇到任何問題都可以在下方的問題回報區中留言
大會問題與建議回報區

請從這裡開始

敏捷為什麼難推?

軟體開發流程技術都買得到

  • 人心最難改
  • 沒人敢要求老闆改
  • 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)

Select a repo