關於文件管理的幾個迷思

關於文件管理的幾個迷思

之前談完了文件與備份

我在軟體開發之文件有感從"這幾句話,輕鬆惹火程式設計師"看軟體開發的成本中就提過這些問題。

技術人不擅長也不喜歡寫文件,那麼文件怎麼會生出來,當然就是不懂技術的助理或技術不強所以才被指派為PM去談規格的管理者生出來,因為不是技術專長,文件當然也寫得不好,技術人事後再抱怨規格不清楚。就算是認為自己願意寫文件的技術人,其實也多半有本位主義,是從自己習慣的方式寫文件,其他技術人也還是看不懂。以上的總總誕生了軟體開發不需要寫文件的敏捷式怪胎。我沒有說敏捷式不好,只指出他會這麼受到工程師歡迎火紅的其中一個原因即於此。

我們先開宗明義談一個問題文件做甚麼用?撇去技術問題不論(因為技術開發問題在不同團隊的看法都不同),行政需求是文件的一個避不開的流程,當然行政需求在 每個專案中定義都不相同。我們舉一個例子,當蘋果電腦開佈道大會時那些投影片一定都有經過工程人員的若干貢獻(再經過行銷人員的包裝)。譬如說本次的產品 有甚麼特色,若說與實際技術開發毫無關係,我反而覺得是不可能的事。不管是申請補助,發布技術文件,佈道大會。這種行政事宜是避不了的。只差在何時寫?寫 到甚麼程度?

因為大家對文件管理這麼沒有標準,不清楚,不熟練,缺乏楷模,常會有幾個迷思。

  1. 文件應該要在開發之前寫完。意思是若是寫不完是否就不可以開始寫程式?專案都是有時程壓力,每個團隊都是在資源有限下運作,除了富二代之外每個人都要付帳單。所以文件所謂的寫完,在每個組織都不同。比較合理的情形是開發與需求人員都確定沒有遺漏的需求或模組,就可以開始進行開發了。這樣的標準是很動態及模糊的,模糊到極致,就是敏捷式號稱不寫文件的那種做法了。這樣的好處是透過開發,可以把遺漏的需求立即發掘出來。
  2. 文件是在開發之後才寫(文件只是表面功 夫)。這是一種比較務實的做法,開發完成後總是要有人寫文件來應負行政事宜。但從好方面想來,這種做法的用處與事先寫文件並不相同,事先寫文件是為了思考設計問題,事後寫文件是為了維護。也就是軟體開發是永續的,完成版本之後不會就停在該處,一定會有後續的人員繼續接手,此時留下完整的文件,就可以讓後續的人員進入時,依舊照原先的開發團隊的思維來維護軟體。避免造成整個架構走偏的情形,也可拉近不同能力的工程師實作的水準。但這種做法就一定要有倒楣鬼(因為會事後寫文件,代表原先一定沒寫文件)留下來好好地善後,這也是工時。
  3. 文件在整個專案過程中會自動更新(到現在我要看的那個版本)。這種情形通常是開發前有花時間寫文件,但是開發下去之後卻未能堅持先前的決議,也沒有透過嚴謹的確認就開始做規格的修改。因此正確的實作漸漸偏離錯誤的設計文件。但是當有人員進出或是行政需求的時候,就會有個人會來抱怨一下大家都不寫文件(但其實這個人一定沒有時時盯著文件,才會到此時才來抱怨)。
  4. 文件應該格式美觀圖文並茂。看情況,多半是看行政需求層級,很多情形勢需要格式美觀圖文並茂的。但這都要看包裝人員是否有這樣的能力。也並非每個程式人員都有好的文字能力,甚至也不是每個人的英文寫作都夠好。這點就真的要視團隊情況而調整。
  5. 有了文件,最大的問題已經解決,就差把它實作出來。這就是呼應第一點,在事前寫的文件是否在開發過程中都不需要調整,在開始寫文件的人勢必是對整個系統最了解的人,他必須跟隨這著案子到最後,時時關心它,調整它。完成了完整的文件只是第一步,之後的每一步都跟第一步一樣重要。
廣告

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s