有關需求變動改善,我突然想到極限編程,極限編程的主要目標在於降低因需求變更而帶來的成本。我覺得極限編程一個很重要的要素,將客戶納入開發,在小單元功能寫完後立即交給客戶測試是否合乎他們的需求,他有一個很重要的理由是其實客戶自己也不知道自己要的是什麼,他們玩過後才知道什麼地方他們認為不合理,開發者看似合理的邏輯,在他們眼中卻不佳,主要是減少了解真正需求所花的時間,越晚了解真正的需求,變動的成本自然也愈高。回頭來看,我們第一階段客戶是誰,其實是QA、企劃、高協理。這些人有辦法真正影響到規格的更改,那是不是可以在開發時就將他們納進來,讓他們來「玩」程式呢?不用「測」這個字的原因,是因為我們找的是他們真正的需求與他們腦袋裡想的邏輯,而不是叫他們抓BUG,只是每個畫面看一看,點一點相關功能,對他們而言所花的時間應該不長吧?
其實我視規格更改為常態,但我只有一句話,改規格可以,但必須延時程。越晚變動,所花的時間成本就越多。那為什麼不提早把需求提出來呢?
其實還有一項想法可以改善介面邏輯問題,叫做走廊使用性(hallway usability)測試,走廊使用性測試是說到走廊攔住下一位經過的人, 然後逼他試用你剛寫好的程式。 如果你做夠五個人, 就可以發現程式中95%應注意的使用性問題。這我們內部就可以做了,更具有實用性大家覺得如何?
其實我視規格更改為常態,但我只有一句話,改規格可以,但必須延時程。越晚變動,所花的時間成本就越多。那為什麼不提早把需求提出來呢?
其實還有一項想法可以改善介面邏輯問題,叫做走廊使用性(hallway usability)測試,走廊使用性測試是說到走廊攔住下一位經過的人, 然後逼他試用你剛寫好的程式。 如果你做夠五個人, 就可以發現程式中95%應注意的使用性問題。這我們內部就可以做了,更具有實用性大家覺得如何?
留言