iT邦幫忙

2018 iT 邦幫忙鐵人賽
DAY 26
0
自我挑戰組

再戰軟體工程系列 第 25

『你們敏捷都不寫文件的啊』 -- 真相究竟是...?

敏捷宣言裡有一具:『可用的軟體重於詳盡的文件』。大家聽到都會背了。然而,我認為這句話是四條宣言裡最容易被誤會的一條。敏捷要不要執行、執行得好不好,跟你寫不寫文件一點關係都沒有

一般人學習敏捷開發框架時,總是喜歡拿敏捷跟傳統Waterfall管理方式來做比較。其中總是會提到傳統瀑布式的專案管理,在一開始就把所有的細節都規定好,因此有常常做到一半才發現這設計超難實現,或是做出來的東西客戶根本不要的情況。然而,卻有很多人因此而誤會,以為『敏捷開發不寫文件』,這實在是讓這個框架蒙上不白之冤。

敏捷不是不寫文件,敏捷是只寫『有需要的文件』。

就像User Story一樣,我們有一定數量的庫存backlog,依照重要程度排序著,時間到才依序拉一些進sprint來動手做。文件又何嘗不是?文件為何不能比照辦理?其實可以的。寫程式需要時間,測試需要時間,寫文件也需要時間啊!憑什麼程式可以被排序、估算,與檢討,文件卻不行?

文件也能測試

更有甚者,你知道文件也有測試嗎?試想,程式是人寫的,有正確與否與是否吻合客戶需求的問題,那麼,難道文件不是嗎?寫得不好的文件,無法教使用者用正確方式使用產品,也無法讓使用者簡單地了解功能。因此,文件當然也可以安排測試啊!

如果你的客戶需求與契約中,包含了文件,你就應該在產品成長過程中,大方地 『把文件當成產品的一部份』生成並檢驗品質。簡而言之,你應該像對待程式功能一樣對待文件。為什麼?因為那是妳產品的一部份啊!不然咧?

如果客戶重視,那就寫吧

身為軟體工程師,我一直認為,對待測試與文件,要像對待功能一樣慎重。而在敏捷流程哩,你就要去評估這些需求比次間的優先順序。這個優先順序有賴PO、SM與各Stakeholder的溝通與討論。如果這個客戶這麼重視文件,那就寫吧!出一張User Story,排入Sprint,寫吧!

記得Code Review :)


上一篇
『好的工具帶你上天堂』 -- 你用的工具是設計來給你這樣用的嗎?
下一篇
『我覺得這樣已經很方便了』 -- 測試要做到多自動化才夠?
系列文
再戰軟體工程30

尚未有邦友留言

立即登入留言