六招如何做好refactoring
The 6 steps to mastering refactoring
http://www.thecodejunkie.com/2010/01/6-steps-to-master-refactoring.html
作者建議當你要進行refactoring前, 以下六件事情很重要
1. 確定你有一組好的測試
- Tests是你做refactoring的安全網
- Feb 03 Wed 2010 12:01
六招如何做好refactoring
- Feb 02 Tue 2010 14:43
14. 細小的差異 (2)
14. 細小的差異 (2)
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
在scrum中規定要有燃燒圖
- Jan 29 Fri 2010 16:55
14. 細小的差異 (1)
14. 細小的差異 (1)
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
這裡有些分歧, 但似乎沒有比之前提的那麼重要. 然而, 能瞭解它們也是很好的.
Scrum規定要有訂好優先順序的產品backlog
- Jan 28 Thu 2010 16:55
13. 兩者都是精實(lean)和敏捷
13. 兩者都是精實(lean)和敏捷
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
我不打算在這裡討論精實思想和敏捷宣言. 但是一般來說, Scrum和看板跟這些價值和原則完全是一致的. 例如:
* Scrum和看板都是拉式排程系統, 相當於JIT(Just In Time)庫存管理精益原則, 這意味著團隊選擇何時及承諾多少工作要做. 當他們準備好時, 他們會"拉"工作來做, 而不是有工作從外面推進來. 就像印表機一樣, 只有當它準備好要印刷時, 它才會拉下一張紙進來(雖然它每次能夠拉的紙, 是很少並且數量有限的).
* Scrum和看板是個持續進行, 和累積經驗的流程優化過程. 它符合精益的改善原則.
- Jan 27 Wed 2010 10:08
12. 兩者都允許同時處理多個產品的工作
12. 兩者都允許同時處理多個產品的工作
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
在scrum中, "產品backlog"是一個較為不幸的名字, 因為它意味著所有項目必須都是為了同一個產品. 這裡有兩個產品, 綠色和黃色, 每一個有它們自己的產品backlog和它們自己的團隊:
如果你只有一個團隊呢? 好的, 把產品backlog想成團隊的backlog. 它會為某個團隊(或一組團隊), 為即將到來的循環列出優先順序. 所以, 如果這個團隊要維護多個產品時, 把它們合併成一份清單. 那會強迫我們去排出產品之間的優先順序, 在某些況下這是有用的. 在實務上, 有幾種方法可以進行:
