分類
architecture skill

[架構][技巧] 軟體估算系列 – 軟體估算的基礎 – 什麼是軟體估算

老闆:
各位,這個專案必須在第三季前完成,完成的意思包含正式上線,所有的測試和驗收。你們先安排一下時程再來跟我報告!

你 :
(心裡盤算了一下)
老闆,我們預計會安排Peter和John進行開發,但在第三季前完成還是有點困難,不知道是不是有機會可以…

老闆:
不行!這是客戶要求的。Mary不是快有空了嗎? 可以在第三季前加入啊

你 :
好吧,我試試看…(根據人月神話,在後期加入人手通常對速度沒有幫助)


目標和計畫,估算和承諾

對於估算的認識通常來自於上方對話,對話中包含估算的基本知識,目標,計畫和承諾。

在開始進行估算之前必須先瞭解且能分辨這些基本知識,估算才能代表某些意義。


1.目標

最常聽到的通常是”目標“,目標包含目的物,時間和狀態

這三者也代表對理想商業願景的描述,對話中就是“這個專案(目的物)必須在第三季前(時間)完成(狀態)”。

目標通常聽起來很理想,有願景,但未必能完成。


2.計畫

計劃是針對目標進行一系列規劃的過程,計畫的最終結果就是滿足目標。

很多人會把計畫直接當作估算,但兩者完全不同。

計畫是主觀追求目標,估算是客觀分析目標。

通常比較好的做法是把估算作爲計畫的基礎,而不是直接把計畫當作估算。

在對話的“預計會安排Peter和John…”就是根據目標進行的簡單計畫。


3.估算

估算是對項目花費時間或成本的分析預測,也是公正客觀的分析過程,不受其他外在壓力影響。但實際上估算和目標,承諾,管理卻會互相作用。


4.承諾

承諾是根據特定日期以特定標準可提供功能的保證。 迫於各種壓力,很多人對目標會直接給予承諾,但沒有經過估算的承諾,其實對任何人都沒有好處。

在對話的“好吧,我試試看“,就是簡單的承諾。如果老闆記性不錯,這可能就是下一次對話的起點。

為什麼分開判斷目標,計畫,估算,承諾很重要

很多人會把老闆提出的”目標“當作唯一的選擇,把它視為不可違抗,不可變動的。其實站在專案管理的角度,這是沒有幫助的。

大多數的老闆通常沒有技術背景,即使有技術背景也無暇顧及每個專案的細節,因此也不可能知道他所提出“目標”的困難點在哪? 為何困難?。

因此身為專案負責人必須清楚分辨”目標的計畫(理想)“和”目標的估算(現實)“,判斷兩者的差異在哪?差距有多大?

試著對兩者的差距進行管理,將理想和現實拉近,讓專案可以順利完成。也讓你的承諾具有實質意義。

這才是專案管理的本質之一,也是良好估算的定義 :

估算目的在於清楚反映專案的實際狀態,讓管理者能做出良好決策來控制專案以達到目標。

良好估算的定義
分類
architecture skill

[架構][技巧] 軟體估算系列

一個良好估算的價值在於提供實際和理想的差距,讓你能針對差距做出良好決策以達到目標。

軟體估算的價值

對於每位工程師或專案經理而言,無可避免的工作就是估算。
估算目標可能是功能,特性,時間,成本。
估算方式可能是單憑經驗或精心計算。

但你了解估算嗎? 你的估算準確嗎? 

我們都希望提升估算準確率,讓預期和實際越接近越好。但無論在教育體系或就業環境很少出現專門教你了解估算或學習估算的課程。

《軟體估算的藝術》說明進行估算必須了解的基本知識,教你如何提升估算能力以及面對估算難題。讓你下次面對老闆或客戶提問不再啞口無言或隨便說說。

接下來我將列出一系列關於《軟體估算的藝術》中必須知道的知識或技巧,透過這些知識內容,可以更清楚容易的學習軟體估算。

軟體估算可分為三大部分,各為軟體估算的基礎,軟體估算的技術,軟體估算的挑戰


1.軟體估算的基礎

先說明什麼是估算,估算的價值以及影響估算的各種因素。這些基礎知識會讓你對估算有更多的了解。

1.1 什麼是軟體估算
1.2 軟體估算的好處
1.3 影響估算的因素


2.軟體估算的技術

透過範例清楚介紹各種估算的技巧,告訴你在哪種情況下選擇哪種估算技巧最準確以及各種估算技術所帶來的優缺點。

2.1 估算技術介紹
2.2 計數,計算,判斷


3.軟體估算的挑戰

描述實際進行估算所面臨的問題和相關解決方法,包含專案規模,工作量,進度,談判等等。

3.1 估算專案規模的問題
3.2 估算工作量的問題
3.3 估算進度的問題
3.4 估算的展示
3.5 政治和談判


最後,軟體估算的知識和技巧其實並不限於軟體工程師,也不限於軟體領域。其應用範圍涵蓋各種領域層面。

分類
Architectural Pattern Techniques

[架構師][技巧] 技術雷達

甚麼是技術雷達?

技術雷達是一種評估工具,用來判斷軟體領域中各種技術並對這些技術應採取什麼行動的方法。(來源為 ThoughtWorks,參閱這裡)

象限

技術雷達本身是一個切割成4等份的圓形,這4等份各為技巧(左上),工具(左下),語言框架(右上),平台(右下),代表技術種類(在官方網站中稱為象限)。

技術種類如下:

1.工具
軟體開發的各種工具,範圍很廣,包含IDE,資料庫,版控等等。

2.語言框架
大部分是開源的程式語言,函式庫,框架等等

3.技巧
可強化軟體開發的實務技巧,包含各種設計實踐(模式/原則/開發法/建議/演算法)

4.平台
可在其上建構技術的多樣平台,包含作業系統,微服務,分散式系統

要注意的是象限並不是雷達的重點,只是放置技術的分類。

圓環

在圓形中從圓心由內而外分為四層,各為採納(第1層)(最內層),試驗(第2層),評估(第3層),暫停(第4層)(最外層),代表採取行動。(在官方網站中稱為圓環)。

採取行動如下:

1.採納
已被證實成熟,應該立即使用的技術,但要注意並不代表應該在任何情況下都使用,必須經過評估。

2.試驗
可以使用的技術,但還未被充分證明。重點在知道如何使用這項技術,可以在一些無關緊要的專案實施。

3.評估
可以了解並釐清未來是否會對組織造成影響。進行Survey,開發探索,研究計畫,會議,但還不需要實施在專案中。

4.暫緩
可能是技術不夠成熟或被錯誤使用,別在專案中引入。

項目

出現在雷達上的單一圓點就是項目,代表目前出現的軟體技術。項目位置會不斷變化代表其應該採取的行動

在 ThoughtWorks 實際的技術雷達如下

Radar From ThoughtsWork

透過這四層及四等份就可列出應該對什麼技術採取什麼行動,畫成表格如下

技術種類\進行動作採納試驗評估暫停
技巧應該採用的技巧應該試驗的技巧應該評估的技巧應該暫停的技巧
工具應該採用的工具應該試驗的工具應該評估的工具應該暫停的工具
語言框架應該採用的語言框架應該試驗的語言框架應該評估的語言框架應該暫停的語言框架
平台應該採用的平台應該試驗的平台應該評估的平台應該暫停的平台

建立雷達的策略

ThoughtWorks 每半年會更新一次雷達,基本上可以根據該雷達來挑選想採取的行動和技術,也有提供建立私人雷達的方式,參閱這裡

另外每個不同的組織都有不同的商業目標,要發展的軟體策略也不盡相同,因此最好自行建立組織本身需要的技術雷達。

對於架構師而言,廣度應該優先於深度(但不代表深度不重要),在加入項目的策略上應該盡量讓項目平均分佈在四個象限,而不是讓項目全集中在某個象限或某個象限只有一個項目。

也要特別注意別輕易引入暫緩的項目。若採納的項目和自己專業有關但還很陌生,也請花一些時間進行了解(測試式學習是一個好的開始)。