Iteration Demo失敗的原因
It's a Trap!
http://jamesshore.com/Blog/Its-a-Trap.html
在Adopt Agile時, 作者認為最常見的一個問題, 就是要達到iteration commiment會有問題. 換言之, team通常在iteration在結束時, stories大部分只完工一半. 因此在iteration demo時通常都是很令人失望.
你可能會覺得, 造成這個結果的原因, 可能很複雜並且不大相同. 等等!! 事實上... 這是一派胡言, 我必須老實承認, 而不是很鄉愿地欺騙你. 當你選擇了只挑容易做的practices, 這件事都註定要發生了. 也就是說 這條道路看起來容易和簡單，但是它充滿了陷阱.
Trap #1: 日益增加的QA負擔 (The Ever-Increasing QA Burden)
就作者所知, 許多agile team大多是adopt iteration, dailystand-up meeting和planning game, 但是他們並沒採用其他agile 的 engineering (像是refacotring, TDD, pair programming等等), 所以他們的iteration看起來只像是mini版的waterfalls. 也就是RD做design 和coding, 之後的結果由QA去做測試.
在日益增加的測試負擔中, QA最終只會走向死亡. 即使QA有建立automated的測試, 但是這些測試往往是整合式的測試，執行的過程很緩慢的, 很容易break的, 並且會有很大的maintenance的cost. 除此之外, 這些事情都是手動維護, 這是另一個更大的負擔。
更糟的是, 這個負擔是和軟體的size成比例的, 並且在每次的iteration中, 這些負擔會一直重複發生.
不久之後, QA及使用完所有時間去測試, Bug還是會蔓延到下一個iteration, 並且影響到team規劃的可靠度, 使得整個team逐漸掉到無底深淵去
最後結果: buggy iteration demos.
改善方法: prevent bugs using agile engineering techniques and involving customers rather than trying to test the bugs out.
Trap #2: 一廂情願的想法 (Wishful Thinking)
另外一個對iteratiom demo失望的原因, 就是team答應超過他們能力所能做的事情. 他們通常歸咎於estimation不夠準確, 但是這不是真正的原因. 真正的原因是team不知為何緣故, 可能是想要取悅RD, customer或manager, 因此膨脹自己能處理的速度
你不管stories是否真正的被做完(有可能只是code complete, 或是來沒被測完, 或是還沒被customer所接受), 但是你都視為他已經完成, 把它算到你的volocity. 你要知道所謂的做完, 是指這個story已經可以被出貨了才叫做完.
所以做完的定義是很嚴苛的, 會使你的velocity數字會很難看的, 所以人們才會捏造它. 常見的手法是自己在自己的capcity數字上乘一個莫名的比例, 讓你的結果看起來比較好看, 比較"積極", "正面".
但是不管你怎樣假造你的數字, 你有能力作多快這件事還是維持不變.
最後結果:
當iteration的demo開始時, team還沒完成任何事. 事實上, 他們甚至做不完他們有能力完成的部份, 因為大部分的工作都是做到一半, 而不是有一半的工作已經做完. 當然, 這將會導致鱉腳的速度, 因而會讓人增加想要去假造較樂觀數字的念頭.
改善方法:
它是最簡單也是最難的方法, 那就是停止去假造你的速度. 根據已經做完的事情來計算, 並秉持謹慎的態度去增加它. 它可會無法產生你喜歡的數字, 但是您會花更少的時間滅火. 您終於可以開始處理您潛在的生產力問題，而不是玩數字的遊戲; 並且在iteration demo, 不會不安的一直低著頭.
It's a Trap!
http://jamesshore.com/Blog/Its-a-Trap.html
在Adopt Agile時, 作者認為最常見的一個問題, 就是要達到iteration commiment會有問題. 換言之, team通常在iteration在結束時, stories大部分只完工一半. 因此在iteration demo時通常都是很令人失望.
你可能會覺得, 造成這個結果的原因, 可能很複雜並且不大相同. 等等!! 事實上... 這是一派胡言, 我必須老實承認, 而不是很鄉愿地欺騙你. 當你選擇了只挑容易做的practices, 這件事都註定要發生了. 也就是說 這條道路看起來容易和簡單，但是它充滿了陷阱.
Trap #1: 日益增加的QA負擔 (The Ever-Increasing QA Burden)
就作者所知, 許多agile team大多是adopt iteration, dailystand-up meeting和planning game, 但是他們並沒採用其他agile 的 engineering (像是refacotring, TDD, pair programming等等), 所以他們的iteration看起來只像是mini版的waterfalls. 也就是RD做design 和coding, 之後的結果由QA去做測試.
在日益增加的測試負擔中, QA最終只會走向死亡. 即使QA有建立automated的測試, 但是這些測試往往是整合式的測試，執行的過程很緩慢的, 很容易break的, 並且會有很大的maintenance的cost. 除此之外, 這些事情都是手動維護, 這是另一個更大的負擔。
更糟的是, 這個負擔是和軟體的size成比例的, 並且在每次的iteration中, 這些負擔會一直重複發生.
不久之後, QA及使用完所有時間去測試, Bug還是會蔓延到下一個iteration, 並且影響到team規劃的可靠度, 使得整個team逐漸掉到無底深淵去
最後結果: buggy iteration demos.
改善方法: prevent bugs using agile engineering techniques and involving customers rather than trying to test the bugs out.
Trap #2: 一廂情願的想法 (Wishful Thinking)
另外一個對iteratiom demo失望的原因, 就是team答應超過他們能力所能做的事情. 他們通常歸咎於estimation不夠準確, 但是這不是真正的原因. 真正的原因是team不知為何緣故, 可能是想要取悅RD, customer或manager, 因此膨脹自己能處理的速度
你不管stories是否真正的被做完(有可能只是code complete, 或是來沒被測完, 或是還沒被customer所接受), 但是你都視為他已經完成, 把它算到你的volocity. 你要知道所謂的做完, 是指這個story已經可以被出貨了才叫做完.
所以做完的定義是很嚴苛的, 會使你的velocity數字會很難看的, 所以人們才會捏造它. 常見的手法是自己在自己的capcity數字上乘一個莫名的比例, 讓你的結果看起來比較好看, 比較"積極", "正面".
但是不管你怎樣假造你的數字, 你有能力作多快這件事還是維持不變.
最後結果:
當iteration的demo開始時, team還沒完成任何事. 事實上, 他們甚至做不完他們有能力完成的部份, 因為大部分的工作都是做到一半, 而不是有一半的工作已經做完. 當然, 這將會導致鱉腳的速度, 因而會讓人增加想要去假造較樂觀數字的念頭.
改善方法:
它是最簡單也是最難的方法, 那就是停止去假造你的速度. 根據已經做完的事情來計算, 並秉持謹慎的態度去增加它. 它可會無法產生你喜歡的數字, 但是您會花更少的時間滅火. 您終於可以開始處理您潛在的生產力問題，而不是玩數字的遊戲; 並且在iteration demo, 不會不安的一直低著頭.
全站熱搜
留言列表
