分類彙整: 品質文化

新官上任三把火

新政府團隊似乎想要在就職典禮的活動上,改變舊制以發揮新創意,營造出耳目一新的感覺。但實際上卻反而把問題複雜化,造成一團混亂。這讓筆者想到在軟體開發過程中,也經常出現同樣的情況。改革的困難正是考驗著領導者的領導能力,他應該如何領導團隊來進行成功的改革呢? 閱讀全文

分類: CNet/ZDNet, 利害關係人, 品質文化, 專案團隊, 溝通, 職場, 開發流程, 領導 | 6 則留言

專案時間不足,如何達成不可能的任務

在專案時間不夠的情況下,要達成不可能的任務必須要提昇軟開發的產能,必須讓開發的產出與產能可以相互配合。但至於要如何增進良好設計架構的產能呢? 閱讀全文

分類: CNet/ZDNet, 品質文化, 問題解決, 專案監控, 專案規劃, 專案風險, 溝通, 職場, 開發流程 | 4 則留言

總是要到驗收前才發現程式有問題?

對於開發者而言,總是要到驗收前才發現程式有問題可真是可怕的夢魘呀。然而,這樣的現象為什麼老是一而再,再而三地發生,到底是什麼地方出了問題呢? 閱讀全文

分類: CNet/ZDNet, 品質文化, 問題解決, 專案團隊, 專案監控, 專案風險, 思考, 溝通, 職場, 軟體審查, 開發流程 | 3 則留言

當軟體專案計劃趕不上變化時

雖然「計劃趕不上變化,變化比不上老闆一句話」,但趕不上或比不上並不代表要放棄計劃,否則專案的成功也只是聽天由命的偶然罷了。同人認為,軟體專案要成功,關鍵不在於如何照計劃進行,而是要「計劃」當計劃趕不上變化時該怎麼辦。 閱讀全文

分類: 分析設計建模, 品質文化, 問題解決, 專案監控, 專案規劃, 生活感觸 | 3 則留言

品質是檢驗出來的,還是設計出來的?

驗收測試與 TDD 有何不同?一個是由客戶端來驗證軟體是否符合他們的品質要求,另一個則是開發者以測試驅動的方式來開發軟體系統。顯而易見地,「做 TDD,還是驗收測試?」的重點並不在測試,而是「開發者應該自己驗證程式,還是該仰賴客戶來幫你找程式缺陷?」。換言之,就是我們常聽到的一句話:品質是檢驗出來的,還是設計出來的? 閱讀全文

分類: 品質文化, 問題解決, 專案管理, 思考, 軟體審查, 開發流程, 閱讀 | 2 則留言

大型公共建設軟體專案後續討論

本篇文章不談高鐵,而是從我所寫的〈從高鐵談大型公共建設軟體開發專案〉的上下篇的讀者迴響中,發現有一些值得探討的議題,在此做個整理。 閱讀全文

分類: CNet/ZDNet, 利害關係人, 品質文化, 問題解決, 專案團隊, 專案監控, 專案規劃, 專案風險, 溝通, 知識管理, 軟體開發, 開發流程 | 2 則留言

好的設計源自於紀律

一個有紀律的開發者必須不斷地專注在面對「現實」,認清問題,用「目前最合適」的解決方法來解決。「現實」代表解答問題的目標是顯而易見的,所以我們可以輕易地寫程式來驗證目標是否真的可以達到;而「目前最合適」則代表我們馬上可以把設計實作出來,並且用先前的驗證程式驗證出來,這就是設計的紀律的具體呈現。 閱讀全文

分類: 品質文化, 問題解決, 專案管理, 設計原則, 軟體度量, 軟體開發 | 1 則留言

旅行與軟體度量

喲哪桑的「摩托車日記」清楚地道出藉由問對問題來找出適當的度量方法,在讚嘆學長的罕 … 閱讀全文

分類: 品質文化, 專案管理, 軟體度量, 軟體開發, 閱讀 | 4 則留言

改變軟體開發現況的藝術

在鳥毅與 R 君的對談中,R 君說: 很多事情用說的侀’不如先做出來低調點等到其 … 閱讀全文

分類: 品質文化, 系統思考, 組織, 軟體開發 | 發佈留言

軟體度量與數字陷阱

章子怡為軟體度量代言告訴我們軟體度量的 Gilb’s law,任何事 … 閱讀全文

分類: 品質文化, 專案團隊, 軟體度量, 閱讀 | 發佈留言