Java 學習之路
The Three Laws of TDD－從紅燈變綠燈的過程
By joeychen | 2015/12/15TDD 除了最基本的「紅燈、綠燈、重構」循環外，在「紅燈變綠燈」的過程，建議遵循著 Uncle Bob 這三條簡單的規則 …
tags: Agile Scrum Burn Down Chart
估算需求複雜度（4）Scrum 專案金三角
By joeychen | 2015/07/01估算需求複雜度（3）如何評估專案時程中，介紹了在 Scrum 中推估專案時程的其中一種方式。在大家有了推估時程的基礎知識後，接下來就要來介紹一下 Scrum 中的專案金三角有什麼不一樣的地方。
tags: 單元測試 重構 C＃ Legacy Code .NET Static Function
C# Test Legacy Code（4）Unit Test with Static Functions
By joeychen | 2015/06/16這篇文章所要解決的問題類型，也是 legacy code 常見的壞味道，直接與 static function 耦合。這與上面的第二篇直接相依於簡單工廠的 static function 有一點像，但目的卻是不同。
tags: 單元測試 重構 C＃ Legacy Code .NET expected objects
C# Test Legacy Code（3）Compare Object Equality
By joeychen | 2015/05/25在撰寫單元測試進行驗證時，都需要驗證執行結果是否符合預期。然而，不論是驗證測試方法的回傳值、物件狀態的改變、或是與外部相依物件之間的互動，回傳值、狀態或傳遞給外部相依物件的參數，很常都是以物件的方式存在。
C# Test Legacy Code（2）Static Setter Injection
By joeychen | 2015/05/04在 context 流程中，透過簡單工廠依據條件來取得 interface 的 instance 固然美好，卻往往因為與簡單工廠的 static function 直接耦合，導致這段 context 流程無法進行 isolated unit test。
tags: Agile Scrum Estimation
估算需求複雜度（3）如何評估專案時程
By joeychen | 2015/04/27PO 最重要的問題之一就是「如何評估專案時程」，這篇文章將提出一種能在 Scrum 中運用的相對評估方式，以實際推估的數據，來隨時回答 PO 這個棘手的問題。
tags: Agile Scrum Planning Poker Dog Point
估算需求複雜度（2）Dog Point Game
By joeychen | 2015/03/10最重要的精神：「團隊在當下，一起做出每個成員都可以接受的決定，那個決定就是當下的最佳解。」所有做事的人，都估出同樣的數字時，即使這個數字跟實務上的執行有所落差，那也是團隊一起認同、共同承擔與接受的。
tags: 單元測試 重構 C＃ Legacy Code .NET
C# Test Legacy Code（1）Isolated by Inheritance and Override
By joeychen | 2015/02/24Legacy Code 不具備可測試性，所以無法寫單元測試。但如果要重構 Legacy Code 前，又需要測試來保護，那不就變成雞生蛋，蛋生雞的問題了嗎？
tags: Agile Scrum Story Point Planning Poker
估算需求複雜度（1）Story Point 與 Planning Poker
By joeychen | 2014/09/30在軟體開發過程中，團隊往往會有一個疑問：「工時怎麼估才會較為準確？」 ... 許多開發人員總覺得 PM 根本是用 deadline 來回推工時的 ... 許多 PM 則總是覺得開發人員估工時都是灌水居多 ...
技術實務教育者的瓶頸、窘境與挑戰（2）
By joeychen | 2014/08/25有些蠢問題，你在實務上怎麼樣都不會想到，因為實在太蠢。但很有可能在教育訓練的過程中，一個學員提出了這個問題，卻產生一個契機讓你去鑽研某些有趣的方向或領域 …
