前兩篇討論的結果如下

團隊中大家一起努力完成工作 -> 12 天
團隊中每個人都做自己擅長的事 -> 11 天

團隊中大家一起努力完成工作,每個 Story 完成的時間如下表

團隊中每個人都做自己擅長的事,每個 Story 完成的時間如下表

你可能會說才差一天, 12/11 = 1.09 好像看不出太大的差異
不過如果 Sprint Backlog 長這樣,這是一個極端的例子

A.團隊中每個人都做自己擅長的事,完成的天數是 11 天

B.團隊中大家一起努力完成工作,每個Story 都只有 1 個人擅長,其他 3 人都不擅長,
所以每天能夠完成的 Task 為 1+ 3x0.5 = 2.5 張,完成一個 Story 需要 11/2.5 = 4.4 天
完成所有 Story 的天數 4x(11/2.5) = 17.6 天

17.6/11 = 1.6, 這時就差了 60%

想一想在敏捷裡我們所追求的是什麼?
我們捨去了產出,所換來的是什麼?

我們先回頭看一下剛剛的例子
A.團隊中每個人都做自己擅長的事,完成的天數是 11 天
每個 Story 完成的時間如下表

B.團隊中大家一起努力完成工作,完成一個 Story 需要 11/2.5 = 4.4 天
完成所有 Story 的天數 4x(11/2.5) = 17.6 天
每個 Story 完成的時間如下表, 4.4 天算第 5 天完成,以此類推

不曉得你有沒有看出其中的差異,
A.團隊中每個人都做自己擅長的事, 4 個 Story 所完成的時間都是第 11 天
B.團隊中大家一起努力完成工作, Story 完成的天數分別為第 5, 9, 14, 18 天

情況一

我們有說過在 Sprint Backlog裡,價值最高的 Story 優先順序 會在最上面.
所以我們假設 4 個 Story 的價值如下:

Story 1 值 400, Story 2 值 300, Story 3 值 200, Story 4 值 100.
當 Story 完成後,隔天就可以上線幫我們賺錢,因為我們做的是產品,所以他會每天都一直幫我們賺錢,
也就是說在 B 裡,第一個 Story 在第 5 天做完,所以第 6 天開始每天幫我們賺 400,

所以兩個方法的賺錢比較表如下:

我們這邊算到 19 天就好了,後面雙方都是一樣的
A 方法中,從第 12 天開始賺錢到第 19 天,總共賺了 8,000
B 方法中,從第 6 天開始賺 400,第 10 天開始賺 700,第 15 天開始賺 900,第 19 天開始賺 1,000.
總共賺了 400x4 + 700x5 + 900x4 +1,000 = 9,700

看到這邊有沒有想過是什麼造成兩者間的差異?
其實就是先完成價值最高的東西,然後就可以交付,開始賺錢
當然開始賺錢是個美好的情況,也許情況不一定賺錢,而是市場根本不想要你的東西,
這時用方法 B 你也可以很快的得到 Feedback 調整產品的方向.
如果是方法 A 那就只能等到第 12 天上線後才知道要調整.

所以這裡我們拿產出所換來的是快速驗證,趕快的把東西推出去,拿到回饋,不論是賺錢或者是調整產品方向

情況二

如果今天在第 6 天,整個情況有變,突然要插一個 Story 進來,
那麼 A 方法中,沒有一個 Story 完成, 這時你可能要考慮要停掉那一個 Story.
不過 B 方法中,已經有一個 Story 完成,此時第二個 Story進行到一半,另外兩個都還沒有進行,你的損失比較小
當然有關插件的問題,我們之前也有討論過,請看 Day 13 半成品和插件
這邊就不多說了.

所以這裡我們拿產出所換來的是靈活度,減少半成品所造成的浪費

敏捷所追求的

當然還有其他的情況,不過這裡我個人的想法是,敏捷所追求的其實是 增加適應性 ,

這時你會想,怪了,敏捷不就是快嗎?怎麼反而變慢了.
如果你有這個想法,那請參考下面兩個連結
天下武功，唯快不破？ – 敏捷開發是為了快嗎？
敏捷開發的價值