The Introduction of Passing the Word



這是人月神話:軟體專案管理之道(20週年紀念版)的第六章:,這一章的開場白:『他將會坐在這兒,說:「做這個!做那個!」然後什麼事都不會發生。』—杜魯門.《總統的權力》,繁體中文版的有個譯註解釋這句開場白的由來,簡體中文好像沒有這個解釋,但是如果你去Google還是可以找得到『More quotes by Harry S. Truman』的一些引用,這是一場總統大選時杜魯門揶揄艾森豪這個軍人當上總統會是怎樣,我想很多的台灣的選舉,很多競選人也多會運用這樣的批評對頭吧!

但是如果把它運用在本章的話,有另外一個詮釋了,一個專案經理如何指揮實作人員來落實架構設計的決策呢?ㄚ琪覺得這一章一言以蔽之,應該就是溝通吧,如何做好溝通,以下介紹了一些工具:

書面規格–手冊

『手冊載明的是產品的外部(external)規格,用來描述並制定出使用者從外觀上將會看到的所有細節,而撰寫手冊便是架構設計師的主要工作。』

『架構設計師為了造福實作人員,將修改的程度予以量化(quantize)是很重要的–在時程上應該要有載明日期的版本資訊。』

『架構設計師應該提出一種實作方式…但不應硬性規定採用特定的實作方式。』

秉持不流於瑣碎(not trial)的原則。

正式定義

採用正式標記法(formal notation),這個標記法有優缺點,所以也需另外有個散文式的定義,以便讓人看懂,有一些工具,Backus-Naur Form(巴科斯範式,即 BNF)、抽象語法(abstract syntax)、APL(APL語言)以及新型註記法。

避免拿現成的實作來當作正式定義,雖然這樣開法比較快,但是後續還是會發生問題。

將定義直接融入實作

開會

這裡附上一段簡體文的引用:『

1. 數月內,相同小組——架構設計師、用戶和實作人員——每周交流一次。因此,大家對專案相關的內容比較了解,不需要安排額外時間對人員進行培訓。

2. 上述小組十分睿智和敏銳,深刻理解所面對的問題,並且與產品密切相關。沒有人是“顧問”的角色,每個人都要承擔義務。

3. 當問題出現時,在界線的內部和外部同時尋求解決方案。

4. 正式的書面建議集中了注意力,強制了決策的制訂,避免了會議草稿紀錄方式的不一致。

5. 清晰地授予首席系統架構設計師決策的權力,避免了妥協和拖延。』

總之,開會是必要且重要的,雖然我一直很討厭開會。

多重實作

電話紀錄

還記得以前當兵時候,在安官室站哨最重要的就是電話紀錄,我一直很嚮往這種方式,真的是好啊!

產品測試

有誰認為這不用做的,應該沒有人說不用,繼續保持!

Print Friendly, PDF & Email

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *

這個網站採用 Akismet 服務減少垃圾留言。進一步瞭解 Akismet 如何處理網站訪客的留言資料