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