分類彙整: 品質文化

絕對支持品質流程的宣稱

在公司高層這種態度和形成的公司文化氛圍之下,公司產品最後會變成「把做好的東西丟到牆的那一邊去」就不足為奇了。再加上以西方優越感產生文化的價值批判,在這種情況之下,QA 對產品品質的提昇有多少著力點呢?同事丙的離開做出了最好的回答。 閱讀全文

分類: 品質文化, 問題解決, 寫作, 專案團隊, 溝通, 生活感觸, 職場, 領導 | 1 則留言

掌握設計演進的節奏

在軟體開發的過程中,有沒有方法可以避免我們浪費心力在無謂的堅持上,然後用比較簡單而又有效率的方式來完成我們的工作呢?經過與同事上面的對話,同人想到運用到我在分享會中所提到的觀念與實務,可以很輕易地掌握設計演進的節奏。藉由此篇文章分享出來,也算當做同人在 1/9 敏捷開發分享會後的一個註腳吧。 閱讀全文

分類: 品質文化, 問題解決, 寫作, 專案管理, 思考, 生活感觸, 職場, 設計原則, 軟體審查, 開發流程, 領導 | 發佈留言

再談技術經理當教練

技術經理當教練如果對公司是不好的徵兆,問題應該還是出在領導上,誠如同人過去發表過的文章所講的:強將手下無弱兵,但也不會有強將。沒有辦法訓練培養人才的教練,還是因為技術經理不諳教練之道呀! 閱讀全文

分類: 品質文化, 問題解決, 專案團隊, 思考, 溝通, 生活感觸, 職場, 領導 | 發佈留言

Java 泛型複雜嗎?

表面上看起來好像實作泛型可以讓某一段程式碼重複使用,但 Java 在泛型的限制,也增加他重構程式碼的困難度與複雜度。這麼說來,假如石頭成的想法是正確的,用 Java 的泛型來重構程式碼,只會讓程式員沒事自討苦吃。然而,同人在仔細研究他的程式碼之後,發現可以用更簡潔的方式來使用 Java 的泛型。 閱讀全文

分類: 分析設計建模, 品質文化, 問題解決, 學習, 編程技巧, 職場, 設計原則, 軟體開發 | 發佈留言

簡單,複雜世界的致勝之道

世界愈複雜,我們就更需要簡單。簡單讓我們看清楚事物的脈絡,掌握重點,以協助做出選 … 閱讀全文

分類: 利害關係人, 品質文化, 問題解決, 學習, 思考, 溝通, 生活感觸, 職場, 閱讀, 領導 | 2 則留言

當聽到不精確的溝通用詞時

朋友的分享讓同人看到,她的主管用一些不大精確的語言來讓她感覺問題不大。比如說用「c++、vb 都只是工具而已,不管你用那一種工具來開發系統,其實都不會有太大的差異,所以我們大可不用擔心」的說法,正是用不精確的語言來表達不當的概念,這其實是相當要不得的簡化。 閱讀全文

分類: 利害關係人, 品質文化, 問題解決, 專案團隊, 思考, 溝通, 生活感觸, 職場, 閱讀, 領導 | 2 則留言

聚餐也談品質流程

在台灣,品質最大的問題是人們習慣將品質流程獨立於設計及開發過程之外,以為兩者是可以完全分割的。然而這種思維對品質的結論就會是「把做好的東西丟到另一端去」,讓開發人員認為品質是品質部門的責任,而品質部門則認為提昇品質不是他們的責任,以為最多只能做到知道產品有問題,而不知道如何改善它們,只能退回到開發人員那邊來解決。 閱讀全文

分類: CNet/ZDNet, 利害關係人, 品質文化, 問題解決, 專案監控, 專案規劃, 思考, 生活感觸, 職場, 開發流程 | 10 則留言

訊息交易的抽象化思考

在〈開發者的 common sense〉的留言中,同人看到一些網友的批評。我發現 … 閱讀全文

分類: 分析設計建模, 品質文化, 問題解決, 思考, 易經思維, 生活感觸, 編程技巧, 設計原則 | 9 則留言

一句話改變我對高捷的評價

元旦假期到高雄遊玩,我們搭乘高鐵到高雄,然後以高捷做為連結各個景點的主要交通工具 … 閱讀全文

分類: 品質文化, 問題解決, 溝通, 生活感觸, 管理, 職場 | 12 則留言

軟體缺陷的信用創造

專案經理利用軟體缺陷的創造信用來進行短期信用的流通,把 bug fixing 變成 feature request 的好處就等同於創造增加軟體開發修改 bug 代價的貨幣。然而,把 feature request 變成信用商品的後遺症,正是讓信用生產結構的迂迴,使信用崩潰延遲發生。 閱讀全文

分類: 利害關係人, 品質文化, 問題解決, 學習, 專案風險, 思考, 生活感觸, 職場, 閱讀 | 發佈留言