Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
9. 我們怎樣進行sprint的展示
Sprint展示(有些叫它sprint review)是scrum中重要的一部份, 但是人們都低估它
"哦! 我們真的需要去展示嗎? 沒有啥好東西可以展示"
"我們沒有時間去準備&%$#的展示"
"我沒有時間去參加其他團隊的展示"
為什麼我們堅持所有的sprint在結束前都要展示
一次做得不錯的展示, 即使可能看起來很一般, 也會帶來深遠的影響.
# 團隊因所完成的結果而得到認可, 他們會感覺很棒
# 其他人可以知道你們團隊現在正在做什麼
# 這個展示可以吸引關係利害人給予重要的回饋
# 展示是(或應該是)一個社交的活動, 不同團隊可以相互交流, 和討論各自的工作. 這是有價值的
# 有展示會促使團隊真正完成一些東西, 並發行它(即使是在測試環境中). 沒有展示, 我們總是會得到一個99%完成的東西. 有了展示, 或許我們完成的東西變少, 但是這些東西是
真正的完成. 這(以我們的例子來說)會比得到一堆看似完成的東西好的多, 而且他們將會影響到下一個sprint的進行.
如果團隊是有點被半強迫去進行展示, 尤其他們沒有太多東西是真正的完成, 這樣的展示將會令人感到很尷尬. 團隊在展示過程中, 可能會結結巴巴的, 之後的掌聲也可會是稀稀落落的. 人們會對這團隊感到有點難過, 也有人感到不太高興, 因為他們浪費時間在一場很爛的展示上面.
這會傷害到一些人, 但是就像良藥苦口. 下一次的sprint, 團隊會真的試著去完成一些事情. 他們會感覺 "好的, 也許下個sprint我們只能展示2件事情, 而不是5件. 但是這些該死的功能一定會正常運作!" 團隊知道無論如何他們必須展示, 讓一些真正有用的東西, 被展示的機會變得大的很多. 這種情況我已經看過很多次了.
Sprint展示的檢查清單
# 確保你已清楚地描述sprint的目標. 在展示中, 如果有人對你的產品一無所知, 花幾分鐘簡介一下產品.
# 不要花太多時間去準備展示, 特別不要去做些花俏的展示. 把那些玩意放到一邊, 只要集中精神在真正可運作的程式碼上面
# 保持快速的結奏, 也就是, 集中精神讓簡報能保持快結奏, 而不是好看.
# 讓展示是保持在商業導向的層次, 不要有太多技術性的細節. 著重於"我們做了什麼", 而不是"我們如何做到它"
# 如果可能, 讓觀眾自己試用一下產品
# 不要展示一堆小的錯誤修復或是微不足道的功能. 可以提到他們, 但不用展示他們, 因為通常會花很多時間, 並且讓大家不能專注於更重要的故事中.
處理"無法展示"的項目
團隊成員: "我不打算去展示這個項目, 因為它無法被展示出來. 這個故事是'改進延展性, 因此系統可以處理10,000同時上線的使用者' 我拼了老命也無法請10,00使用者同時上線來展示, 不是嗎?"
Scrum master: "那你已經做完了嗎?"
團隊成員: "是的, 當然"
Scrum master: "那你怎麼知道?"
團隊成員: "我在效能測試環境中架設好系統, 啟動8個負載伺服器, 對系統同時發出請求 "
Scrum master: "但是你有任何指標能顯示出系統可以處理10,000使用者?"
團隊成員: "嗯, 這個測試機器挺爛的, 但是在我的測試過程中, 它還是可以處理到50,000使用者同時上線"
Scrum master: "你怎麼知道?"
團隊成員(快失去耐性): "好的, 我有份報告, 你可以自己看啊, 上面有如何設定這個測試, 以及多少請求被發出"
Scrum master: "嗯, 太棒了, 這就是你的"展示"啊. 只要給大家看這份報告就可以了, 這比什麼都沒有強, 對嗎?"
團隊成員: "哦, 這樣就夠了嗎? 但是這報告有點難看, 需要去美化一下"
Scrum master: "好的, 但不要花太多時間. 不需要很好看, 只要能表達訊息就可以"
留言列表
