在『在原來你才是絆脚石』中提到,敏捷宣言中第二條:可用的軟體 重於 詳盡的文件,背後代表的價值觀是透明性。對顧客和利害關係人來說,透明性就是在每個迭代都看到團隊做好的產品,然後給意見。如果我們做的符合顧客需求,那很棒我們可以繼續做其他需求。萬一做的不是顧客要的,那我們最多也是損失一個短衝的時間,而不會像傳統的開發方法,都花了好幾個月的時間開發,顧客一句話就被打掉重練。
敏捷宣言第二條提到:可用的軟體 重於 詳盡的文件,為什麽要特別把文件與軟體做比較呢?
我認爲這一條的背景是在傳統的軟體開發模式中,因爲比較像流水綫形式的分工,比如專案經理跟客戶訪談拿需求,專案經理訪談後要整理需求並撰寫需求文件,然後把需求文件交給軟體開發單位的主管,開發單位的主管再依據需求寫出技術設計文件,最後把技術開發文件交給開發人員進行程式開發,而這邊還沒有提到與其他單位所需要的文件,比如說給品質保證部門的測試案例,或是之後程式上綫前的發佈文件。
如果你能充滿耐心的看完上面的流程,就會發現依照傳統的瀑布式開發流程,在開始寫軟體之前,就會需要寫出一堆文件。而且在之後任何的需求變更或設計變更,都需要把文件更新,萬一沒有更新到,後續接手的人就會像是看天書一般,有看沒有懂。而在軟體業界混久的人,都會知道開發文件的作用不大,這主要有三個原因。
第一個原因是軟體專案時程都很急迫,在壓縮專案時程的同時,第一個被放棄掉的都是寫文件,然後把時間留給寫軟體。反正寫文件是爲了讓之後接手的人看懂,現在我顧自己都來不及了,哪有時間考慮未來的事情呢。好一點的就是寫個大概,差一點的就直接把以前的文件複製貼上,當作文件完成了。
第二個原因是軟體是相對抽象的概念,不像是蓋大樓,把藍圖畫好後看圖的人可以視覺化的看到完成的具體形狀。所以顧客只能大略的描述他想象中的情況,也許可以加上圖示 Mock up 幫助顧客想象使用的流程,但許多問題還是在實際使用的時候才會被發現。所以當專案經理在寫需求文件的時候,也沒辦法照顧到太多細節。
最後一個原因也是最根本的原因,更新軟體太容易了,改一行程式碼,也許就需要更新到好幾份文件。更新軟體的速度遠遠快過更新文件的速度,工程師就會想那我等更新程式碼多幾次後再來更新文件,省的麻煩,最後連更新文件都省了。造成很多的文件不如説是歷史記錄。
因爲以上的這些原因,在敏捷開發中提倡的做法是讓程式碼本身就是文件(Code as documentation),就是讓後續接手的人,可以光從程式碼與測試案例就知道大部分的資訊,並可以開始維護與更新程式碼。當然這是個理想中的狀態,所以宣言中説的是『詳盡的文件』而不是說『文件』。能被及時更新的關鍵文件,還是有需要的。
而爲什麽說『可用的軟體』而不直接說『軟體』呢?在傳統專案管理中,客戶大都是接近結案的時候才會看到產品的狀況,而如上面所說的軟體是個抽象的概念,客戶期待的都會跟實際做出來的差很多,然後團隊就會進入不斷修改需求的無間地獄。
俗話說:醜媳婦總得要見公婆。
所以敏捷開發中認爲與其早晚都要見公婆,不然早一點見,讓公婆給些意見和反饋,好讓我們可以儘快改善讓以後的生活更幸福。
在『在原來你才是絆脚石』中提到,敏捷宣言中第二條:可用的軟體 重於 詳盡的文件,背後代表的價值觀是透明性。對顧客和利害關係人來說,透明性就是在每個迭代都看到團隊做好的產品,然後給意見。如果我們做的符合顧客需求,那很棒我們可以繼續做其他需求。萬一做的不是顧客要的,那我們最多也是損失一個短衝的時間,而不會像傳統的開發方法,都花了好幾個月的時間開發,顧客一句話就被打掉重練。
而透明化這個價值觀的體現,在 Scrum 中則是團隊成員都彼此互相理解工作的情況。在企業中的透明化則包含對流程和制度的透明化,和可以方便地取得完成工作所需要的文件。比方説知道什麽職務可以決定交際預算的使用,或是產品的營運狀況如使用人數等等資訊。
透明化的目的是爲了讓大家工作更順暢,所以過度透明會造成資訊爆炸,比如過度會議,反而使得工作的效益降低,所以透明化拿捏要以工作為核心出發,而不是所有事情或資訊都要透明化。
如果您喜歡這篇文章,歡迎分享轉貼,請註明作者及出處即可,謝謝!