David Ko的學習之旅

很多測試人員會詢問, 是否有一種測試方法, 可以很系統化地, 來開立所有測試個案.

我也很期待有這種東西, 可惜一直沒有看到, 不管哪種黑箱測試方法, 都有它的優點和缺點.

更重要的是黑箱測試有個重大的致命點, 它是完全依賴測試人員的經驗. 如果測試人員的產品領域知識, 以及產品所處的系統知識豐富, 就能開出更好的測試個案.

常常有人會詢問, 公司再導入敏捷開發, 是否要找敏捷顧問? 

這個問題答案可能很多種, 但是我只能根據自己的經驗, 講我自己經歷過的事情. 僅供參考, 沒所謂正不正確.

在早期時, 當大家都不會的狀況下, 找敏捷顧問是比較快, 比較有效率的方法. 因為他可能先觀念教學. 更重要的是,  他可以分享一些經驗給你, 告訴你這些敏捷方法(XP, Scrum, Kanban … )的優缺點, 適用時機, 導入時間大約要多久, 以及可能遭遇的問題.

有些人提到, 為什麼大家執行 Scrum 感覺起來差這麼多? 這是一個很有趣的問題.

首先, 先跟大家澄清, Scrum 只是個 framework, 因為在這個 framework 下你可以選擇自己的實施方式. 

例如: Scrum 要求要有 product backlog, 並且裡面的需求要照優先順序排好. 這些是 Scrum 要求的. 但是他並沒有說 product backlog 要怎麼寫, 你可以用 SRS, use case 或者 user story, 只要你排好優先順序, 並且可以在一個 iteration 內完成. 我想就可以了.

最近有人在問我, 如何在企業中推行 scrum. 然後再加上 FB 上的一些討論, 讓我想寫一小段話發發瘋

 

個人覺得在企業中要成功導入新的做法, 是件不容易的事情, 尤其在大型企業, 銀行或是公家單位.

在實施 Scrum 時, 最容易被人家採用的, 就是每日立會(standup meeting). 它主要是用來同步資訊, 互相幫助, 以及儘早解決所遭遇的問題.

在我待過的團隊, 通常有以下幾種報告方式:

1. 每個人輪流報告
說明: 大家站在一起, 不管是在站在 task board 面前, 或者不是, 但是在報告的時候, 就是大家輪流講自己的部分, 並不會看 task board, 或是某個檔案.