分類彙整: 專案管理

不要把 TDD 和做測試混為一談

最近讀到一篇文章〈不要盲目的 BDD / TDD,我對寫測試的看法〉,看完作者 XDite 反對不論如何都要導入 TDD 的理由,讓同人想提出我對這篇文章的看法。 閱讀全文

分類: 利害關係人, 品質文化, 問題解決, 專案團隊, 思考, 溝通, 生活感觸, 職場, 開發流程 | 21 則留言

從公共建設的系統失常看系統開發的複雜性

要認識系統開發的複雜性,這並不是一件很容易的事。不過,忽略它會讓我們和湊熱鬧的外行人一樣,從他人系統失敗的經驗中只能看得到表相;以為這只是犯了離譜的技術或方法論的錯誤。 閱讀全文

分類: CNet/ZDNet, 利害關係人, 問題解決, 寫作, 專案監控, 思考, 溝通, 生活感觸, 職場, 開發流程 | 2 則留言

絕對支持品質流程的宣稱

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

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

成員能力優勢與團隊多樣性

比起個人的單打獨鬥,團隊合作可以創造更高的效益,但該如何組織高效率的團隊,却往往 … 閱讀全文

分類: 問題解決, 專案團隊, 思考, 生活感觸, 組織, 職場, 閱讀, 領導 | 3 則留言

專案管理最重要的事情

聽到同事轉述管理階層的說法,倒是讓我覺得如果管理只要照著做,那問題可就大了。同人這篇文章寫下我對這事件的看法,不過我並不想討論管理階層所制定流程系統的優劣,而是想探討到底對專案管理而言,最重要的事情到底是什麼。 閱讀全文

分類: 問題解決, 專案團隊, 思考, 溝通, 生活感觸, 職場, 衝突, 領導 | 1 則留言

管理者如何面對專業受責難

短期來說,高層管理者所不願承擔的壓力加諸在專業人員身上,他們總是無力反抗而必須默默承受。但長期讓專業第一線的工作人員一直承受壓力,而不懂得適時激勵來增加專業人才的士氣,總有一天將會令專案付出慘痛的代價:損失重要的專業人才。因此,對於專案管理者而言,這是值得關切的問題。 閱讀全文

分類: CNet/ZDNet, 利害關係人, 問題解決, 寫作, 專案團隊, 生活感觸, 系統思考, 組織, 職場, 閱讀, 領導 | 1 則留言

掌握設計演進的節奏

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

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

以整理房間來隱喻軟體開發

有沒有比較生活化的例子可以用來隱喻測試驅動開發和重構呢?同人覺得用最近我們搬家整理房間的經驗,正好可以隱喻這些實務的開發方法。 閱讀全文

分類: 問題解決, 專案管理, 思考, 生活感觸, 開發流程 | 發佈留言

測試驅動開發的步驟

敏捷開發並不是教條式的照本宣科,開發者要懂得變通最重要的是用心思考,而非把必要的思考都看成精神層面的問題,這並非適用於敏捷開發的心智模式。以下是同人在 Facebook 的 Scrum community in Taiwan 的回應,但文辭有略為做過一番修飾,可以用來澄清我對測試驅動開發步驟的看法。 閱讀全文

分類: 問題解決, 專案管理, 思考, 溝通, 生活感觸, 編程技巧, 職場, 衝突, 設計原則, 開發流程, 閱讀 | 1 則留言

測試驅動開發要徹底重構?

對 David Ko 提出 Kent 認為 Red/green/refactor 是 TDD 的三字箴言的說法,同人倒是覺得有探討的必要。以下分享我在 Facebook 回應 David Ko 的觀點,這些觀點應該可以解釋為什麼測試開發不需要徹底重構;其實重構並不是問題,而是到底什麼叫做徹底?而且如果 TDD 可以徹底重構,那麼一開始就可以讓設計一次到位,那寫好的測試程式以後也用不著了,不正是多此一舉? 閱讀全文

分類: 問題解決, 專案管理, 思考, 溝通, 生活感觸, 編程技巧, 開發流程 | 2 則留言