分類
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 政治和談判


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

分類
architecture frame

[架構][框架] 在PyCharm安裝和使用PyInstaller

Situation

之前用 Python 寫爬蟲自動填寫公司表單,最後的關鍵問題反而是

“Python 要怎麼產生執行檔(.exe)?”


搜尋結果大多數都推薦 pyinstaller。快速掃了 api,感覺也確實還滿簡單的。
以下說明如何在 PyCharm 安裝和使用 pyinstaller。先前提一下我使用的是 PyCharm,如果你的 IDE 不同也許對你沒有太大幫助喔!


Action

A.安裝 pyinstaller

直接在 PyCharm 的 Python Packages 視窗輸入 pyinstaller,找到 pyinstaller 後再點擊右邊安裝按鈕即可


B.使用 pyinstaller 打包並產出 .exe 檔

b1.確認 pyinstaller 的安裝位置 : 如果你按照”A.安裝 pyinstaller “來操作,pyinstaller 的安裝位置就在 A.步驟的專案目錄\venv\Scripts,你應該可以在目錄中看到 pyinstaller.exe,把這個路徑複製起來。我的路徑如下

G:\Projects\PycharmProjects\pyinstaller\venv\Scripts\pyinstaller.exe

b2.開啟 cmd 並移動到你想打包的專案目錄 : 我的打包專案路徑如下

G:\Projects\PycharmProjects\example

b3.使用打包指令 : 在 cmd 貼上 b1.複製的路徑後輸入 -F,再加上打包專案的 .py(通常是專案的入口點,我的是 main.py)

G:\Projects\PycharmProjects\pyinstaller\venv\Scripts\pyinstaller.exe -F .\main.py

b4.等待打包完成 : 按下 enter 後,會出現打包檔案的提示訊息,完成後在G:\Projects\PycharmProjects\example 目錄中會出現兩個資料夾分別為 build 和 dist,在dist資料夾應該就會出現 main.exe,這就是打包完成後的產出囉!

Note : 打包後的 .exe(main.exe)在一般的情況下可以放到其他目錄執行獨立執行。

但若打包專案本身需要依賴某些模組(.exe)才能執行,就必須把被依賴的模組一併移動到打包後的 .exe 相同目錄,否則執行可能會出錯。

像我的爬蟲專案需要依賴 chromedriver.exe,也必須把 chromedriver.exe 也一併移到 main.exe 的相同目錄


Result

成功打包並產出 main.exe,main.exe 可執行,但必須搭配 chromedriver.exe。(應該可以靠其他設定來完成)

分類
architecture skill

[架構][技巧] 以人月評估工作量的問題和可能解法

人月(man-month)通常用來預估或排定時程,也是一般用來評估工作量的單位。

可以單純使用人月來預估工作量的前提有以下兩個 : 
1.工作者彼此之間不需要溝通(包含訓練和交換資訊)
2.工作可以完全切割(被切割的部分沒有連續性)

可以套用人月來計算工作量的簡單範例就是收割作物。
假設1個人採收1公畝的作物需要1個月,佔地4公畝需要4個人月。你可以讓1個人工作4個月來完成,也可以請4個人工作1個月來完成。

也可以說在這種情況下人月是可以互換的。(當然,前提是忽略工作者不會在工作中閒聊或割錯範圍)

但軟體開發很難只透過人月來預估工作量。

1.首先是溝通,溝通包含訓練和交換資訊。

每位投入的開發人員都必須接受技術的訓練,目標和策略的規劃等等
(雖然收割作物也需要訓練,但對比軟體開發而言成本相對小了多)

另外無論元件的交換資訊(API)或開發人員的交換資訊(討論資料格式,架構規劃,程式流程等等),所佔的成本其實是相當可觀,可以計算看看開了多少會議來討論這些問題。
(交流量公式 : n(n-1)/2,n為人數,根據這個公式,3個人的交流量是2個人的3倍,4個人的交流量則是2個人的6倍,以此類推)

2.至於工作是否可以完全分割,以一個很簡單的4個模組來說明,登入模組,主畫面模組,加密模組,儲存模組。依賴關係如下

簡單的依賴關係

假設儲存模組發生儲存資料的內容錯誤,除了查找本身的缺陷(fault)和功能失常(failure)以外,它還必須通知加密模組以及主畫面模組或登入模組查找問題。

因此以測試或除錯的角度來看軟體模組不僅具有連續性而且透過這種連續性引發的行為會大大增加所需的成本,在大型系統(模組數量大於100)的連續性成本更加嚴重。

事實上不單是軟體開發,想單純透過人月來評估工作量都應該至少考慮以上兩個前提(溝通和連續性)

回過頭來,在軟體開發領域是否有其他方式可以減緩溝通和工作連續性所引發的成本?

敏捷開發可能就是個解方。

1.首先就技術的訓練而言,可以透過結對編程(Pair programming)讓老手來帶領新手來減輕新進人員的技術負擔和專案的陌生程度

各種交換資訊所消耗的成本則可以透過Scrum會議(衝刺計劃會議/每日站立會議/評審會議/回顧會議)來減緩

2.工作連續性所消耗成本,背後原因其實是個別元件沒有確實驗證而導致錯誤難以釐清定位。基本上可以透過單元測試或測試驅動開發(TDD)來確實驗證元件的正確性(行為和資料)

分類
architecture skill

[架構][技巧] 優秀的工程師就是優秀的管理者嗎?

前同事阿強是開發部門的技術強者,最近因為大功一件加上考績滿分,被老闆提拔為經理。

看起來阿強走路有風。沒想到在聚會時卻跑來跟我訴苦。

“唉我喜歡技術也專精技術,可是我從沒管過人,也沒想過要管人”

“你有跟你老闆談過你沒意願嗎?”

“有! 但老闆說技術強,其他人就會聽你的,自然就可以管人。我相信你的技術,也期待你管理他們!!”

“好吧…(難道技術能力強也代表管理能力強嗎)”

技術能力強也代表管理能力強,應該是不少企業組織的慣性思維。

這個思維其實引發另一個較為廣義的問題 :

某個職位的優秀人才也是另一個職位的優秀人才嗎?

答案是不一定!

根據個人在不同組織的觀察以及”溫伯格的軟體管理學第三卷-觀照全局的行為”一書中提到,

許多企業組織以一種錯誤思維挑選管理階層,這種錯誤思維稱為”單一面向的挑選模型”,該模型有三個錯誤假設!

錯誤假設 1. 管理者特質是天生的,不是後天養成的
錯誤假設 2. 以單一標準來評量員工
錯誤假設 3. 專業職的職級等於管理職的職級

具體來說這些錯誤假設其實代表著以下隱藏的意義

錯誤假設 1. 管理者特質是天生的,不是後天養成的

明顯的偏見就是認定管理者是天選之人,因此管理技巧訓練大多數是浪費時間和成本! 重點是只要挑對的人來管理就可以了!

錯誤假設 2. 以單一標準來評量員工

雖然現況有許多評量標準,先不論評量標準如何。在企業組織文化,辦公室政治的影響下要進行所謂的公正評量,基本上難度很高!

錯誤假設 3. 專業職的職級等於管理職的職級

這就回到開頭的問題,”技術能力強也代表管理能力強嗎?”,我想重點在於不同職位須具備的特質是否存在衝突。當互相衝突的特質越多,兩者職位相近的程度也越低!

請記得,優秀的工程師未必是優秀的管理者,反之亦然。