More Related Content Similar to ACCELERATE:精益軟體與DevOps背後的科學-重點整理、個人見解與實務經驗 (20) ACCELERATE:精益軟體與DevOps背後的科學-重點整理、個人見解與實務經驗25. 25
以小批量工作
視覺化管理
收集並實做客戶回饋
團隊實驗
感想:團隊間的合作模式與組織文化,會影響這樣作業的難易度。例如,主要以SI進行產品導入專案
的情境,可能就受限於SI的態度。若是由自己開發發佈到雲端SaaS的系統直接面對終端客戶,較容易
達成這樣的工作模式。
精益產品開發
精益產品管理 軟體交付績效
更少過勞
Westrum組織文化
組織績效
35. 35
運用版控系統控制所有生產環境產出(衍生)物:組態配置...
感想:
版號對齊源碼 tag,源碼版本容易追溯
測試與正式發佈,清楚界定
倉庫Tag = 套件組件檔名上或檔案屬性上的版本 =成品版本查詢UI上的版本資訊
產出物與版控系統例如:
1. 源碼、環境組態,Git
2. 套件,NuGet、Maven
3. Container image,Container Registry
4. 測試腳本與測試資料Script:Git
持續交付-1
42. 42
實做持續交付(CD):軟體皆是處於可佈署的狀態,有無法佈署時,會馬上修復
感想:
1. 開發區:源碼交付就會進行持續整合後佈署至開發區,Pipeline failure無成功時,開發者會立刻查
找問題進行排除。源碼隨時可以為正式發行的版本是一個大挑戰,但隨時從成品庫取得上架的成品
進行佈署應該是要確保可行。
2. 整測區:人員[QA]驅動佈署Pipeline,標示標籤、產出成品放置於成品區或倉庫,接著取得成品佈
署
3. 交付型:測試通過後,從成品區或測試版倉庫取出打包交付上架到正式版倉庫
4. 正式區:從正式版倉庫取出佈署
持續交付-8
45. 45
蒐集並貫徹客戶回饋
感想:
1. 每個Sprint demo邀請利害關係人參與,並收集反饋
2. End User的反饋收集,提供聯繫信箱
3. 藉由Google Analytics或自行開發工具收集終端使用者使用狀況數據
4. 提供線上問卷
5. FOAK專案、雲端實驗性產品
產品與流程-11
49. 49
有輕量化變更核准流程:基於同儕審核,勝過外部的變更審核委員會
感想:
1. 每週團隊內部demo review,但這其實可看的量有限
2. 同儕審查或是資深者審核,對人力吃緊的團隊難以進行
3. 可搭配品質分析工具(如: SonarQube、Fortify、Black Duck )檢查,除了省時外,這些工具的
檢查能力,甚至比許多的資深工程師更好。工程師也可以藉此學到許多Good Practice.
精益管理與監控-15
50. 50
橫跨應用程式及基礎設施監控以影響業務決策
感想:
1. 監控注意Hardware足夠支撐業務量
2. 使用者行為數據收集,知名如Google Analytics,但若是套裝軟體架設在無法連線網際網路的客戶
環境,有其他工具可以應用嗎?自行開發是另一個設計議題
3. 收到了數據,該怎麼分析才能找到價值的洞見,這才是重要的!
精益管理與監控-16
Editor's Notes 書上的研究所收集到的數據,這4種量測無法通過所有效度與信度的統計測試,只有前置時間、發佈頻率和恢復時間湊在一起可以形成有效且可靠的構念(交付績效)。但,變更故障率與軟體交付績效構念是強烈相關的。(但沒看到書裡到有為這點講到理由)
自動化測試影響績效
https://www.ithome.com.tw/article/152581
在2021年報告中,對精英團隊的DORA指標績效要求是,必須能夠按需部署(每天多次;Book:佈署頻率),更新準備時間(Book:產品交付前置時間,從程式提交到可以在生產環境中成功運行的全程時間)得少於1小時,而更新出錯時的平均復原時間(Book:平均修復時間MTTR)不能超過1小時,平均變更的失敗率(Book:變更故障百分比)還要低於15%。而且不是只有一項指標達到標準就夠,必須每一項都達標,這個團隊才能視為精英團隊。
官僚體制不必然糟糕=>確保公平性,有些規範也代表知識累積的產物。規範導向文化:遵從規範比達成使命更重要。
這些實踐是否對組織績效有直接深遠影響,可以就生產力、市佔與獲利能力各方面來測量之。
精益產品開發:以小批量工作、視覺化管理、收集並實做客戶回饋、團隊實驗
過勞:體力累、心累 To summarize, in 2017 we found that, when compared to low performers, the high performers have:
46 times more frequent code deployments
440 times faster lead time from commit to deploy
170 times faster mean time to recover from downtime
5 times lower change failure rate (1/5 as likely for a change to fail)
價值流是從最初的請求到客戶實現價值的過程中為客戶增加價值而採取的一系列行動。價值流從最初的概念開始,經過不同的發展階段,然後通過交付和支持。價值流總是以客戶開始和結束。