其他

 在逐個報告進度的項目進度會議上最容易發生“議程小雞（Schedule Chicken）”的情況。專案經理會問大家的進展情況如何。每個人都說自己在按排程進行。而實際情況卻是，沒有一個人做到。每個人都在等別人眨眼睛並承認自己沒能跟上進度。而且除非已經太晚了，沒有人會承認自己錯過了項目進度安排。議程小雞一個講求實效的專案經理會有如下選擇。避免逐個進行的進度報告會議（見10.1.2節）。可以採取10.5節中的方法來判斷項目真正的進展狀態。

 非常非常多的知識工作者，特別是技術人員，都從未學習過如何估算。就算是嘗試過估算的人，他們也過於樂觀了，總是會過低估計一項任務需要的工作量。要麼得不到任何對估算的反饋，所以他們不會知道自己的估算是不準確的；要麼他們預測不到一個任務中會牽涉多少子任務，比如準備測試環境或是簽入代碼這樣的任務。在任何情況下，當有團隊成員以為自己完成了90%的任務，而實際上還有90%工作尚未完成的時候，“90%完成狀態”就發生了（見圖6.14）。圖6.14

 我們都知道，排程只是估計而已，不過是大概猜測罷了。項目議程是對於團隊何時到達哪個裡程碑、何時完成項目的最佳推測。排程並不是預言，僅是猜測而已。但是有些專案經理的出資人會將這個猜測視為承諾。 如果面對上述困境，可以問問如下兩個問題：你是否關心團隊交付的東西？ 你是否關心產品的品質如何？

 巴尼是一個專案經理，組織的高層只知道瀑布式生命週期。他們覺得迭代式的做法就是浪費時間。他們希望在項目的第一周就看到甘特圖，這樣專案經理就可以按照甘特圖管理，一切都能按部就班進行。如此一來，無可避免的是：要是巴尼報告說項目沒有按計划進行，有些高層就會這麼說：“哎，按照排程，你的進度應該到這兒。沒能按照計划進行，你是怎麼回事啊？”決策層對於項目的瞭解並不深入，他們不知道，人們在項目中是根據經驗來思考和行動的。他們相信，關鍵路徑會永遠保持不變，任務安排順序也一直大體相同。發生如此狀況，原因在於：一直

  幾年前，我接到一個項目的求助電話。等我參與的時候，項目正處於發布周期的中期。我跟團隊成員一起識別出他們可以交付什麼、應該交付什麼、還有哪些應該延遲。項目團隊後來也按可交付物列表完成了交付。發布之後，我建議團隊召開回顧會議，看看有哪些工作是在下一次可以改進的。副總裁卻認為沒有人能從回顧中學到東西。他忘了我為什麼要來幫忙，光注意到了大家的成功。他說：“不過大家這次幹得很不錯。他們滿足了我們對這個版本的所有要求。”他的話把所有的問題一掃而光——特別是優先順序的變更——灰都被掃到地毯下面了。團隊裡可

 【說明：工作繁忙，好久沒有更新這個遊戲系列了，現在恢複。】有一個副總聲稱自己有“多動症”（Attention Deficit

 我遇到有些組織，他們有個不成文的規定：絕不討論項目議程。這種情況我見得太多了。管理層想要一個日期，項目團隊就會說：“當然，沒問題，就聖誕節吧！”但他們不會明說是哪個聖誕節。最後，當某個聖誕節到來之時，已經過了不少日子了，人們開始討論排程。而這時項目已經錯過不少裡程碑的交付日期，甚至有可能幾個早先期望的項目結束日期都已經過去了。我曾跟這樣一個項目團隊共事，他們在5年之內沒有達成項目議程中任何一個裡程碑或其他任何要求。他們總是在反複製定最佳化的項目議程，卻沒有信心範圍。最後，在資深管理層變動之後，

 老闆給專案經理曼尼打電話說道：“曼尼，我們得聊聊你的項目了。”曼尼答道：“當然，有什麼問題？”“嗯，如果這次不加入這個功能，我們就完蛋了。大客戶們不會買這個版本的。”曼尼歎了口氣，說道：“我跟大家說一下吧，回頭告訴你結果。”曼尼轉頭跟項目團隊解釋了這個情況，大家同意在目前的版本中加入這個額外的新功能。不過大家已經對按議程及時交付不抱希望了，順便說一句，項目議程從來都沒有改過。在這個例子中，每個人都希望項目成功：老闆、專案經理、項目團隊。可他們沒有權衡這樣做給項目帶來的影響，從而使得項目完全失去

 一天，一封來自公司大人物的緊急郵件把你招呼到公司。郵件裡說：“別弄那個項目了，趕緊開始做這個吧！”可以確定，如果此事發生一次，它就還將多次重演。專案經理和團隊都會周旋於幾個項目之中，或是在兩個項目之間不停切換。不管是哪種狀況，專案經理都陷入多項目、多任務切換的泥潭，而且整個團隊亦是如此。專案經理知道自己無法取得任何成果，所有項目的緊急程度卻在不斷攀升、攀升、攀升……當管理層害怕或無法一次將精力集中在一件事情之上時，就會發生屁股著火的狀況。有以下幾種形成原因：技術人員過去就曾延遲交付，公司沒有戰

 幾年前，一個資深經理打電話給我，說道：“我們有個項目出問題了。在啟動的時候，我們充滿了希望，但是現在看來已經不可能了。”我問了幾個問題，發現他們之前從來沒有做過類似的項目。相對以前，這個項目的規模更大，使用新的開發語言，基於新的平台，而且排程更短。整個公司的未來都押在這個項目的成功上，問題是它比以前做過的項目都要複雜，而且要求也更高。他們唯一的策略就是“希望”。他們沒有安排任何關於項目所在領域、使用的開發語言或新作業系統的培訓。他們對這個項目希望能夠達到的時間要求，也是以前從未做到的。僅有希望

 我曾遇到這樣一個經理，他的原話如下：“我希望你能在項目A上花50%的時間，在項目B上花30%的時間，在項目C上花20%的時間。在閒置時候，你能看看給老大的報告嗎？”我答道：“什麼空閑時間？”“分散注意力”就是與多項目、多任務相關的遊戲。如果管理層無法把精力投入到一個項目或是工程的策略之中，就會引發此遊戲。他們不會對每個項目說“是”或“否”，也不會問“什麼時候？”，而是對所有的項目點頭稱是。專案經理可以採取下面這些行動。與工程團隊一起嘗試16.7.1節中的解決方案，特別是有助於工程團隊或管理層團

QtCreator 1.3的發布裡增加了開發Symbian程式的支援。文檔上說這是一個實驗性的功能，我當了一把小白鼠試了一下，能正常工作。以下是我的幾個操作步驟。1. 兵馬未動，糧草先行。該安裝的東西都得先裝上，基本上和利用Carbide做開發的需求是一樣的。a. S60 Platform SDK 3rd Edition FP1 或者更高版本b. Open C/C++ v1.6.0 或者以上版本安裝到你的s60 sdk上，編譯Qt程式要用到c. GCCE

自動化佈建屬性autoprops Subversion的回合組態區特性，Subversion的許多全域的配置參數都是放在回合組態區中，回合組態區實際上就是一個目錄，在我的XP作業系統這個目錄是“C:/Documents and Settings/rock/Application

 Symbian OS中，在可顯示表單上畫圖是通過圖形裝置(graphics device)和圖形上下文(graphics context)來實現。一、圖形裝置    圖形裝置是對呈現圖形的裝置(螢幕、印表機等)的抽象。它提供了一組獨立於裝置的介面，應用程式使用這些介面，通過圖形上下文(graphics context)來畫圖。圖形裝置是畫圖的中介，圖形上下文在畫圖時畫在這些圖形裝置上。在Symbian中圖形裝置通過圖形裝置類來體系，其繼承結構如下：     CgraphicsDevice

 作為專案經理，管理層想讓你再向目前的版本中塞進來一個功能。他們在玩“我們必須擁有這個功能”的遊戲。作為一個負責任的專案經理，你告訴了團隊成員新的功能要求。你已經跟管理層說團隊會評估請求，而且會告訴他們新的發布日期，或是加入新功能帶來的成本。可是當你開始跟團隊成員討論這個功能及其帶來的影響時，大家都不願意說“不”、“還不行”，或是“這樣做會帶來新的成本”。大家兩眼一閉，就把新的工作接下來了，而不去討論時間和資金上的成本，還有對當前工作的影響（見圖6.12）。團隊這麼做，有時是處於內疚，有時是因為

 設定檔管理經驗總結對於做技術的人來說，少不了經常從網路下載資料，慢慢的資料就會越積越多，如果不妥善處理，可能會出現諸如因資料太多而懶得去看（資訊超負），不知哪些還沒有看過及看過的又看了多少（閱讀狀態），對重要資料沒有存檔（資料存檔）等問題。下面就談談自己的經驗：一、如何應對資訊超負的問題為了防止資料下載過多導致產生一種“反正也看不完，懶得去看”或者“這麼多資料，不知從哪裡看起”的心理，建議採取以下措施來避免上述情況：1． 盡量選擇高品質的資料進行下載。2． 盡量從可靠的資訊源進行下載。3． 下

一般訣竅 1.‘Symbian 開發師網路’提供大量資訊資源，協助您為Symbian OS 作業系統編寫應用程式。您應經常訪問www.symbian.com/developer 網站以便擷取最新的SDK、技術資料、編碼範例和白皮書。您從開發師網 絡網站能夠獲得：• Symbian OS‘常見問題’(FAQ) 庫。這是一個對開發人員來說極有價值的資訊庫，涵蓋了最常見的設計和編碼問題。•許多白皮書。其中包括《Symbian OS C++ 編碼通訊協定》。在Symbian OS

DLL動態連結程式庫是程式複用的重要方式，DLL可以匯出函數，使函數被多個程式複用，DLL中的函數實現可以被修改而無需重新編譯和串連使用該DLL的應用程式。作為一名物件導向的程式員，希望DLL可以匯出類，以便在類的層次上實現複用。所幸的是，DLL確實也可以匯出類。然而事實卻沒這麼簡單，匯出類的DLL在維護和修改時有很多地方必需很小心，增加成員變數、修改匯出類的基類等操作都可能導致意想不到的後果，也許使用者更新了最新版本的DLL庫後，應用程式就再也不能工作了。這就是著名的DLL

      翻譯自SDK » Developer Library » Symbian OS Guide » Essential idioms » Code efficiency概要      速度和資源使用方面的代碼效率總是值得關注的，本節提出的方法對Symbian平台的開發人員來說是很常用的。棧應用應用程式中的每個線程都有一個8Kb的標準棧，應當小心地使用。因此：Ø           除了基本類型避免值拷貝。Ø           應該在堆上而不是棧上建立任何大的對象或數組。Ø       

　　在Symbian S60第三版中，按下紅色的結束通話鍵，程式預設退出，當還想保持程式繼續運行狀態，可以在AppUi的HandleWsEventL函數中進行處理，以下代碼來自ScreenShot。 // ————————————————————————–// Starting from S60 3.x, pressing End key will terminate application.// We don’t want this to happen in this application,