關於網路那些事...

網路行銷,SEO,網路趨勢,教學文章,網頁設計,生活時事

LEAN 精實軟體度量 簡記

軟體開發過程是一個複雜的體系,

敏捷開發 > 核心 > 快速交付?

快速交付,要交付的是任務

再聊精實度量之前,先談談敏捷開發一些基礎構成

敏捷開發角色大概可分成主要三類:
Scrum master, 產品負責人, 團隊

每兩週為一個 sprint 單位,來做衝刺

為什麼要敏捷開發? 因為要讓專案可以有節奏地進行

敏捷開發最終還是要回歸到專案管理本身
專案管理牽涉的層面較為複雜,通常會需要考量的因素較多
在專案經驗較缺乏的情況下,很容易形成做敏捷而不是變敏捷

只是表面上看起來有在做這件事情

在實施敏捷開發時,也應該針對目前成員及專案狀況來進行
scrumful

scrum 其實有基本的要求,其中包括成員素質、Master特質、專案經驗都有基本的要求
你無法在一個不求進步的團隊落實 scrum,因為最終結局機會讓人全部跑光,或者做出奇怪的東西

scrum 在紀律之下,必須要有充足的尊重跟授權
也就是說,團員要遵守一定的紀律,但Master也充足的授權及尊重他們的意見

整個敏捷開發或精實開發,都是圍繞在一個重點: 專案管理

專案管理最終目的是做出符合使用者期望

這也是純技術團隊發展 Scrum 通常被忽略的重點 - UI/UX 反饋
打造貼近使用者的產品,關鍵都在 UI/UX
這是在產品規劃過程必須考量的重點因素
因此在執行每一個階段後,都必須要再檢視,並檢討修正,確保品質與維持價值

以及要知道你做的產品相對價值,來作出對應的決策方式
低價值的產品高效率的開發,會造成浪費
高價值的產品低效率的開發,會造成失去競爭力

好的專案開發流程,必定會注重開發的度量及品質,

但是,通常在國內常聽見敏捷開發,卻鮮少聽聞關於精實開發的實施者,

造成了敏捷開發過程缺乏度量,僅顧及快速交付而讓品質及產能下降。

因此,對於敏捷開發和精實開發共同實施的情況,才能更有效地幫助整體專案交付

軟體開發體系通常都非常複雜,必須要顧及端對端、系統面、價值面的度量體系

但是整個過程,其實可以用專案管理的角度來看待,就會相對容易理解

首先對於軟體的特徵進行分類,包括使用者、產品架構、開發團隊等

再根據這些分類映射出對應的效率、品質、能力、價值等可度量的標準

細看每一個過程,其實就是一個微型專案管理所組成

度量的目的是為了提升交付能力,而不是控制

並且在精實開發之後,就能更清楚知道整體進步程度、相對以前提升多少效率及產出

整體決策大目標

支撐決策的計畫可以區分為三個方向,從這些方向再衍伸出各種決策計畫,來設定合理的目標

  • 組織

組織的方向除的公司本身,還包含競爭市場分析,內容包括產品規劃、藍圖、資源配置、市場調查

  • 專案

專案主軸在於專案進度計畫,估算產能及工作量,提升品質,防範缺漏及測試,資源分配(交付週期、規模、個人及團隊能力)及能力提升計畫

  • 個人至團隊

個人方面著重個人能力、工作量評估,提升目標則是個人能力、團隊能力及組織技能提升

整體核心

無論敏捷或精實,整體重點離不開以下幾點

  • 進度
  • 效率
  • 品質
  • 能力
  • 客戶滿意度

效率

看板系統 Kanban

待分析 分析 待開發 開發 待測試 測試 完成
團隊1
團隊2
團隊3

每個人在同一時間應該都只會有一張卡片在看板上,
如果一個人有兩張卡片,就意味者他必須要在不同卡片之間切換工作,
切換不僅僅增加了等後時間,更會對開發者造成負擔
因為這兩張卡片在同一時間,會有一張是沒有人處理的狀態

此外,在這些流程中,可以根據每一個張卡片要求標註開發天數、測試天數、發現bug數,最後就可以參考數據做調整

度量對象拆解

就像把一輛車逐步由大而小的方式拆解
最後整以架構都會一目瞭然,井然有序
就能夠知道如何排出優先順序列表,以及每個需求是什麼樣的粒度

價值

低價值的效率是一種浪費
有價值但低效率會失去競爭力

提升價值 關鍵在於回饋

提升軟體價值的方法,關鍵就在於每一個流程都必須要讓用戶參與回饋,讓產品能符合使用者期望
需求 -> 設計 -> 開發 -> 測試 -> 維護

浪費

  • 距離導致的浪費:開發需耗費移動或跨區域等候才能取得結果
  • 層級導致的浪費:第一線人員需具備行動權力,才能減少來回溝通的成本
  • 技術債的浪費:環境不一致導致上線部署出問題,寫出不良程式碼導致後續維護問題,都是技術債的一部分
  • 文件導致的浪費:文件寫作錯誤,可能導致後續極大的損失及浪費,因此需重視文件的品質
  • 度量本身的浪費:從客戶的角度來看,不會關心我們搜集這些度量的成果,他們重視的始終是價值,因此還是要評估現有狀況來導入度量,別因為強制導入而對價值造成影響

雖然組織會有存在一些救火英雄,在最後一刻協助上架,但善戰者無顯赫之功,這會造成一種不公平的現象
應該檢討技術債留者,不要去造成別人要耗費時間幫你救火

個人能力

  • 技術能力
  • 獨創能力
  • 創意能力
  • 溝通能力
  • 程式品質

團隊能力

  • 技術任務輪換
  • 參與支援維護
  • 跨團隊方案討論,程式碼評審

組織能力

  • 學習型的組織:招聘有主動學習習慣的員工
  • 非正式讀書會
  • 鼓勵新方式探索
  • 風險管理
  • 具有失敗容忍度

鼓勵犯錯,才會有機會進步
不鼓勵犯錯的環境,人們通常只會保留意見

最後

度量不是什麼,在這裡做一個小結

  • 度量不是軟體開發固有活動
  • 度量應該盡量避免和績效直接相關
  • 度量不是免費

如果你喜歡我們的文章內容,請在這裡按個讚



最新文章推薦