今天晚上接到一通電話,署名是yahoo的賣家,告知前一陣子買的產品轉錯成分期付款帳號了,我心理想前陣子也曾經接獲署名happy go相同的手法,於是直接回應:"我再直接連絡",於是馬上上網查詢原來買家說明,確定為詐騙電話,故發一封email告知買家
買家還很熱心回電告知此為詐騙電話,並說明很抱歉造成困擾,已有買家受騙8萬元!!
可真要提高警覺,千萬不要悶著頭匯款,多找幾個人連絡討論!!
2009年9月24日 星期四
2009年9月21日 星期一
聰明的女人(轉寄)
如果你愛上一個男人但你們又註定無法在一起﹐
如果你不想失去他﹐就不要與他做情人。
情人的角色就像春天最美麗的花﹐盛開得飽滿消逝得也迅速。
當你愛上一個男人﹐最好遠離情人的角色﹐
它一時讓你得到快樂﹐卻讓你背負永遠的心痛
情人之間太敏感﹐因為彼此距離太近而失去朦朧的美麗。
情人的眼裏揉不下一粒沙子﹐一粒在顯微鏡下才能看到的沙子也能將兩顆細膩的心磨損。
而朋友卻意味著寬容﹐讓彼此感到愉快。
如果說情人讓男人感到煩心的話﹐他便會到朋友那裏去傾訴。
情人是沉重的﹐朋友卻是輕鬆的﹔
情人意味著眼淚﹐而朋友卻是頭頂的陽光。
當你成為他的朋友﹐他會視你為一筆財富。
他在你面前輕鬆自然﹐他在快樂與煩心時會想到你他會欣賞你的獨立你的思想﹐
他會回味你的笑容你的神韻﹐他會因你的鼓勵而積極工作﹐
他願意讓到一個成功而光芒四射的男
人與男人做朋友卻是痛快淋漓的﹐
你是你自己的﹐你和他之間也許有一種情愫﹐
但這種感情不會讓你迷失自己。
你們都有各自的生活﹐你不會過多地要求對方﹐你也不會為他晝夜難眠。
一旦兩個人成了情人﹐便不再感到輕鬆透明。
兩個人之間有了種說不清的責任﹐便會自然地向對方生出許多要求。
也許這種要求很正常﹐可當他滿足不了你時難免會傷心惆悵﹐
你便會陷入情緒的旋渦難以自拔。
聰明的女人﹐如果一個男人吸引了你﹐你千萬不要去做他的情人。
re:http://blog.sina.com.tw/dodolee2007/article.php?pbgid=45621&entryid=600289
如果你不想失去他﹐就不要與他做情人。
情人的角色就像春天最美麗的花﹐盛開得飽滿消逝得也迅速。
當你愛上一個男人﹐最好遠離情人的角色﹐
它一時讓你得到快樂﹐卻讓你背負永遠的心痛
情人之間太敏感﹐因為彼此距離太近而失去朦朧的美麗。
情人的眼裏揉不下一粒沙子﹐一粒在顯微鏡下才能看到的沙子也能將兩顆細膩的心磨損。
而朋友卻意味著寬容﹐讓彼此感到愉快。
如果說情人讓男人感到煩心的話﹐他便會到朋友那裏去傾訴。
情人是沉重的﹐朋友卻是輕鬆的﹔
情人意味著眼淚﹐而朋友卻是頭頂的陽光。
當你成為他的朋友﹐他會視你為一筆財富。
他在你面前輕鬆自然﹐他在快樂與煩心時會想到你他會欣賞你的獨立你的思想﹐
他會回味你的笑容你的神韻﹐他會因你的鼓勵而積極工作﹐
他願意讓到一個成功而光芒四射的男
人與男人做朋友卻是痛快淋漓的﹐
你是你自己的﹐你和他之間也許有一種情愫﹐
但這種感情不會讓你迷失自己。
你們都有各自的生活﹐你不會過多地要求對方﹐你也不會為他晝夜難眠。
一旦兩個人成了情人﹐便不再感到輕鬆透明。
兩個人之間有了種說不清的責任﹐便會自然地向對方生出許多要求。
也許這種要求很正常﹐可當他滿足不了你時難免會傷心惆悵﹐
你便會陷入情緒的旋渦難以自拔。
聰明的女人﹐如果一個男人吸引了你﹐你千萬不要去做他的情人。
re:http://blog.sina.com.tw/dodolee2007/article.php?pbgid=45621&entryid=600289
2009年9月16日 星期三
婚姻危機的六個初兆(轉)
每對夫妻結婚之初， 都是最快樂最甜蜜的，都相信能和對方廝守終生。可是何以又產生那麼多怨偶，甚至鬧到離婚方休？哈佛大學的婚姻與家庭研究中心主任赫華德·馬克曼博士說："夫妻雙方如果能早早瞭解到若干婚姻警號的初兆，便可以幫助夫妻在雙方彼此仍深愛對方，理智高於怨恨時，加以調整，及時挽回。"夫妻間有六個看似微不足道的小小徵兆，如果雙方不加理會，將來很可能導致婚姻危機的大問題。
1．事情輕重的秩序：你是否常將其他的事優先擺在夫妻間的共同事情之前？過分壓抑夫妻間的共同事情的優先秩序，終會傷及夫妻間的感情；
2．在相處中顯得孤獨：夫妻相處時是否無法找到片刻安靜的時候。
夫妻結婚後屬於私人的時間會有所減少是正常的，問題在於減少的多寡；
3．不再感到樂趣：你們過去的共同樂趣已消失了，但又沒有新的共同興趣取代，夫妻間的共同興趣是婚姻快樂的最佳"預言家"；
4．彼此猜測對方的心意：你以為自己一定知道對方的心意而懶得問一聲。研究員發現，即使你的猜測都對，這種習慣卻不可取，因為這很容易造成彼此間的埋怨；
5．基本問題的爭執：如果你們在一些基本問題上，如買房子、何時生小孩等，不能得到雙方滿意的結論，就應該警惕了；
6．得不到對方的回應：你是否已經感覺到對方已經不在意你在說些什麼，或是你自己已經變得將對方說的話當耳邊風，根本沒聽進去。
馬克曼博士說，夫妻間偶爾出現以上這些徵兆是常有的事，不值得大驚小怪，但是如果成為一種"慣例"，那就應該及早正視，設法改善了。
1．事情輕重的秩序：你是否常將其他的事優先擺在夫妻間的共同事情之前？過分壓抑夫妻間的共同事情的優先秩序，終會傷及夫妻間的感情；
2．在相處中顯得孤獨：夫妻相處時是否無法找到片刻安靜的時候。
夫妻結婚後屬於私人的時間會有所減少是正常的，問題在於減少的多寡；
3．不再感到樂趣：你們過去的共同樂趣已消失了，但又沒有新的共同興趣取代，夫妻間的共同興趣是婚姻快樂的最佳"預言家"；
4．彼此猜測對方的心意：你以為自己一定知道對方的心意而懶得問一聲。研究員發現，即使你的猜測都對，這種習慣卻不可取，因為這很容易造成彼此間的埋怨；
5．基本問題的爭執：如果你們在一些基本問題上，如買房子、何時生小孩等，不能得到雙方滿意的結論，就應該警惕了；
6．得不到對方的回應：你是否已經感覺到對方已經不在意你在說些什麼，或是你自己已經變得將對方說的話當耳邊風，根本沒聽進去。
馬克曼博士說，夫妻間偶爾出現以上這些徵兆是常有的事，不值得大驚小怪，但是如果成為一種"慣例"，那就應該及早正視，設法改善了。
2009年9月13日 星期日
偷一點兒時間給愛你的人
我好幾次無意中聽到他在電話裏和妻子說謊，
明明加班加到晚上9點就可以結束，他卻對妻子說可能要到10點鐘。
每一次我們走出公司的大門了，他卻在電話裏對妻子說還在加班。
那次他過生日，邀我們去他家做客，看上去夫妻兩個竟是感情極好的樣子。他的妻子笑的溫婉，看他的眼神充滿愛意。
或許他的妻子還蒙在鼓裏。
又有一次，我們加晚班從公司出來，已是繁星點點，他的手機響起，他走到邊上接電話，聲音壓的很低，我還是聽到他在說：
「我還在開會，還有一會兒才能回去，別等我。」
我以為他偷得這一會兒時間，必定要赴另一個溫柔鄉，沒想到他搭了我的車，中途下車，在路邊一個小攤上買了一個烤紅薯捂在懷裏，然後在自家樓前下車，徑直回家去了。
我心裏直犯嘀咕，這人真奇怪，明明馬上就要回家，偏偏跟妻子說還要等一會兒，這唱的是哪出戲啊？
終於忍不住問他，他笑了笑說：「每天早出晚歸的，一天就那24小時，要上班，要應酬，要休息，對老婆又不能怠慢，
只好偷一點兒時間給她了。」
他說，他的婚姻也曾經危機四伏，妻子雖然知道他忙，經常要加班，但被冷落的感覺還是讓她心生怨意。
在冷戰中，他慢慢意識到在忙也不能忘記表達愛，不能因為工作忙就讓妻子體會不到被愛的感覺。
怎樣讓妻子體會到自己的愛，他頗費了一番苦心。
有一次，他不等應酬結束就提前回家，發現妻子因為他的提前歸來而高興的時候，他心有所感，決定偷一點兒時間給她愛。
後來，他隔三差五地故意把回家的時間說的遲一點兒，下班後，他會順路買點妻子喜歡的東西回去，然後告訴妻子是提前從酒席上離開的，或者是為了早點兒回家而加快了工作速度。
妻子原本以為他晚些回家，看到他提前回來，心中自然高興，對老公也就有了更多的體諒。
他笑著說：「你看，我的老婆就是這麽一個容易滿足的人，她其實並不要我做多少家務，她只要被人牽掛就會感到幸福。」
在不斷的奔波中，我們給不了愛的人那麽多，只好偷一點兒時間給她。
這句是平凡人的真愛吧，也是愛的智慧。
我想起自己的老婆，或許我也應該做一件小事
讓她感受到我的綿綿愛意，也許為她做不了太多，但是，每天給她一封E-mail，或者一句問候，或者早點回家，應該是可以做到的。
明明加班加到晚上9點就可以結束，他卻對妻子說可能要到10點鐘。
每一次我們走出公司的大門了，他卻在電話裏對妻子說還在加班。
那次他過生日，邀我們去他家做客，看上去夫妻兩個竟是感情極好的樣子。他的妻子笑的溫婉，看他的眼神充滿愛意。
或許他的妻子還蒙在鼓裏。
又有一次，我們加晚班從公司出來，已是繁星點點，他的手機響起，他走到邊上接電話，聲音壓的很低，我還是聽到他在說：
「我還在開會，還有一會兒才能回去，別等我。」
我以為他偷得這一會兒時間，必定要赴另一個溫柔鄉，沒想到他搭了我的車，中途下車，在路邊一個小攤上買了一個烤紅薯捂在懷裏，然後在自家樓前下車，徑直回家去了。
我心裏直犯嘀咕，這人真奇怪，明明馬上就要回家，偏偏跟妻子說還要等一會兒，這唱的是哪出戲啊？
終於忍不住問他，他笑了笑說：「每天早出晚歸的，一天就那24小時，要上班，要應酬，要休息，對老婆又不能怠慢，
只好偷一點兒時間給她了。」
他說，他的婚姻也曾經危機四伏，妻子雖然知道他忙，經常要加班，但被冷落的感覺還是讓她心生怨意。
在冷戰中，他慢慢意識到在忙也不能忘記表達愛，不能因為工作忙就讓妻子體會不到被愛的感覺。
怎樣讓妻子體會到自己的愛，他頗費了一番苦心。
有一次，他不等應酬結束就提前回家，發現妻子因為他的提前歸來而高興的時候，他心有所感，決定偷一點兒時間給她愛。
後來，他隔三差五地故意把回家的時間說的遲一點兒，下班後，他會順路買點妻子喜歡的東西回去，然後告訴妻子是提前從酒席上離開的，或者是為了早點兒回家而加快了工作速度。
妻子原本以為他晚些回家，看到他提前回來，心中自然高興，對老公也就有了更多的體諒。
他笑著說：「你看，我的老婆就是這麽一個容易滿足的人，她其實並不要我做多少家務，她只要被人牽掛就會感到幸福。」
在不斷的奔波中，我們給不了愛的人那麽多，只好偷一點兒時間給她。
這句是平凡人的真愛吧，也是愛的智慧。
我想起自己的老婆，或許我也應該做一件小事
讓她感受到我的綿綿愛意，也許為她做不了太多，但是，每天給她一封E-mail，或者一句問候，或者早點回家，應該是可以做到的。
女人一定要有錢；情婦也會輸給妳
女人一定要有錢；情婦也會輸給妳。
「女人一定要有錢；情婦也會輸給妳」忘了在哪本書看過，但內容印象深刻。
筆者是一位女性，她的父親曾教她如何當一個女人。她被父親帶到高級俱樂部，去看那些女人如何和她的父親相處。後來她結婚了，他的另一半沒有情婦，只有她一個女人。
她學了什麼？
她學會了如何打高爾夫，如何評鑑美酒；她學會了溫柔聆聽，學會了表達自已的意見；
她學會了攝影，學會了舞蹈；她學會讓自已高貴美麗，經營自已的事業。她不取悅男人，但男人喜歡她；她不是情婦，卻叫人難忘。
女人懂得經營自已，情婦也會輸給妳。
曾經在一件T恤的背面看到一句我一輩子都不會忘記的話：「佔老婆的缺，做情婦！」
無奈的人性，聰明的女人，幸福是要靠用心經營才不會消失的。「女人一要有錢」，再窮也要去旅行。腦袋決定你的口袋，口袋裡的自由，決定你一生的幸福，也決定你臉上的笑容。
「白頭偕老」已經快要成為神話的現代社會，女人擁有一張長期飯票的機率越來越低。當婚姻破碎了，金錢糾紛很容易導致男女雙方惡言相向，受害的一方往往是女人。即使婚姻幸福的女人，也有機會單獨面對現實人生；因為婦女普遍比男性長壽八至十歲，年輕守寡的事也時有所聞。
在職場上，女性普遍比男性處於劣勢；女性收入普遍比男性低，即使同工也不同酬。女性換工作的頻率也比男性高，公司裁員多半先裁掉女性員工。顯然，女性比較不容易領到退休金，就算領到退休金，也少得可憐；因為，男性總將低微的工作分配給女人做。
年輕的時侯，女人覺得這一天永遠不會來臨，總是很樂觀的認為「船到橋頭自然停」。女人總是逃避現實，缺乏居安思危的觀念，不願意去想倒楣的事；等到問題發生了才燒香拜佛，祈求上蒼眷顧，幫忙降福改運。其實，女人如果儘早學會理財，為沒有依賴的日子做好準備。命運可以掌握在自已手中。
前一陣子，「女人要有錢」這本書賣到缺貨；不僅女人在看，男性讀者中也十分搶手。作者是美國主婦—茱蒂．瑞斯尼克。
她強調：「女人要青春，要美麗；要遇見好男人，更要有錢才會幸福」。女人從來不替自已的未來生活做打算是很危險的事。
作者在書中一再對婦女洗腦；「聰明的女性尋覓的是一個溫馨和充滿關懷的伴侶，而不是長期飯票。」
她說：「女性必須體認到，白馬王子早在 50 年代就絕跡了，而且職場不是一個公平競爭的地方；如果女人完全依賴別人，可能導致個人健康和財富的損失。」
茱蒂說：「女人要開始投資和儲蓄。起步越早，成功的機會越大；越年輕開始充實這方面的常識越有利；在能力範圍內犧牲物質享受，學會精打細算，為未來做準備；不要甘於貧窮，才能擁有真正的自由。當然，絕對不可為後金錢而不擇手段。」
高職畢業的台灣名女人，何麗玲，曾經在一次訪談中說：「我很小就明白，美貌和理財是女人一生最重要的事。」她提到她的祖母告訴她：「女人讀書成績差一點沒關係，但是一定要懂得理財。」他在八歲的時侯，祖母就開始訓練他理財觀，丟給他一本帳簿，教他如何記帳。帳本裡面有兩百多個互助會名單，這個國小二年級的小女生，開始跨出理財的第一步。
何麗玲也說過一句發人深省的話：「女人能年輕多久，可以無憂無慮多久。」身為依賴成習的女性，有時我們該思考。如果有一天發生意外狀況，我有沒有能力自給自足，總有一天我們必需靠自已想辦法過日子。只有自已才能保障自已的未來。因此，女人要有錢，並不是要追求享樂，而是生命的尊嚴。
她說：「如果女人懂得理財，懂得獨立，人生就是你的；女人無法在廚房中要求獨立，學會理財才是追求獨立自主的基礎。」
何麗玲在職場和情場上成功，不是沒有道理的。有些女性認為理財是男人的事，懶得傷腦筋。也有些女性害怕自已太能幹，而得不到男人的愛。但現實生活裡，看到許多例子，懂得財務規劃的夫婦，婚姻比較幸福。會理財的妻子也比較能得到丈夫的歡心。
身為一般婦女的父兄或師長，為什麼不能趁早指導女性學習金錢觀念？如同教育他們舉手投足像淑女一樣。
一位男性友人心有戚戚焉的提到「可口可樂總裁」說過的一句話：「我們每個人都像小丑，手中玩著五個球。這五個球是—工作、健康、家庭、朋友、靈魂。而這五個球，只有一個是用橡膠做的；掉下去會彈起來，那就是工作；另外四個球都是用玻璃做的，掉了，就碎了。」
事實上，在不景氣的年代，連工作都是玻璃做的。唉！有時侯覺得，在動亂的時空下，生涯規劃往往趕不上變動；提供家庭經濟來源的男性都感受壓力沉重，更何況是處於為環境較弱勢的女人呢？
女人們，加油喔！
「女人一定要有錢；情婦也會輸給妳」忘了在哪本書看過，但內容印象深刻。
筆者是一位女性，她的父親曾教她如何當一個女人。她被父親帶到高級俱樂部，去看那些女人如何和她的父親相處。後來她結婚了，他的另一半沒有情婦，只有她一個女人。
她學了什麼？
她學會了如何打高爾夫，如何評鑑美酒；她學會了溫柔聆聽，學會了表達自已的意見；
她學會了攝影，學會了舞蹈；她學會讓自已高貴美麗，經營自已的事業。她不取悅男人，但男人喜歡她；她不是情婦，卻叫人難忘。
女人懂得經營自已，情婦也會輸給妳。
曾經在一件T恤的背面看到一句我一輩子都不會忘記的話：「佔老婆的缺，做情婦！」
無奈的人性，聰明的女人，幸福是要靠用心經營才不會消失的。「女人一要有錢」，再窮也要去旅行。腦袋決定你的口袋，口袋裡的自由，決定你一生的幸福，也決定你臉上的笑容。
「白頭偕老」已經快要成為神話的現代社會，女人擁有一張長期飯票的機率越來越低。當婚姻破碎了，金錢糾紛很容易導致男女雙方惡言相向，受害的一方往往是女人。即使婚姻幸福的女人，也有機會單獨面對現實人生；因為婦女普遍比男性長壽八至十歲，年輕守寡的事也時有所聞。
在職場上，女性普遍比男性處於劣勢；女性收入普遍比男性低，即使同工也不同酬。女性換工作的頻率也比男性高，公司裁員多半先裁掉女性員工。顯然，女性比較不容易領到退休金，就算領到退休金，也少得可憐；因為，男性總將低微的工作分配給女人做。
年輕的時侯，女人覺得這一天永遠不會來臨，總是很樂觀的認為「船到橋頭自然停」。女人總是逃避現實，缺乏居安思危的觀念，不願意去想倒楣的事；等到問題發生了才燒香拜佛，祈求上蒼眷顧，幫忙降福改運。其實，女人如果儘早學會理財，為沒有依賴的日子做好準備。命運可以掌握在自已手中。
前一陣子，「女人要有錢」這本書賣到缺貨；不僅女人在看，男性讀者中也十分搶手。作者是美國主婦—茱蒂．瑞斯尼克。
她強調：「女人要青春，要美麗；要遇見好男人，更要有錢才會幸福」。女人從來不替自已的未來生活做打算是很危險的事。
作者在書中一再對婦女洗腦；「聰明的女性尋覓的是一個溫馨和充滿關懷的伴侶，而不是長期飯票。」
她說：「女性必須體認到，白馬王子早在 50 年代就絕跡了，而且職場不是一個公平競爭的地方；如果女人完全依賴別人，可能導致個人健康和財富的損失。」
茱蒂說：「女人要開始投資和儲蓄。起步越早，成功的機會越大；越年輕開始充實這方面的常識越有利；在能力範圍內犧牲物質享受，學會精打細算，為未來做準備；不要甘於貧窮，才能擁有真正的自由。當然，絕對不可為後金錢而不擇手段。」
高職畢業的台灣名女人，何麗玲，曾經在一次訪談中說：「我很小就明白，美貌和理財是女人一生最重要的事。」她提到她的祖母告訴她：「女人讀書成績差一點沒關係，但是一定要懂得理財。」他在八歲的時侯，祖母就開始訓練他理財觀，丟給他一本帳簿，教他如何記帳。帳本裡面有兩百多個互助會名單，這個國小二年級的小女生，開始跨出理財的第一步。
何麗玲也說過一句發人深省的話：「女人能年輕多久，可以無憂無慮多久。」身為依賴成習的女性，有時我們該思考。如果有一天發生意外狀況，我有沒有能力自給自足，總有一天我們必需靠自已想辦法過日子。只有自已才能保障自已的未來。因此，女人要有錢，並不是要追求享樂，而是生命的尊嚴。
她說：「如果女人懂得理財，懂得獨立，人生就是你的；女人無法在廚房中要求獨立，學會理財才是追求獨立自主的基礎。」
何麗玲在職場和情場上成功，不是沒有道理的。有些女性認為理財是男人的事，懶得傷腦筋。也有些女性害怕自已太能幹，而得不到男人的愛。但現實生活裡，看到許多例子，懂得財務規劃的夫婦，婚姻比較幸福。會理財的妻子也比較能得到丈夫的歡心。
身為一般婦女的父兄或師長，為什麼不能趁早指導女性學習金錢觀念？如同教育他們舉手投足像淑女一樣。
一位男性友人心有戚戚焉的提到「可口可樂總裁」說過的一句話：「我們每個人都像小丑，手中玩著五個球。這五個球是—工作、健康、家庭、朋友、靈魂。而這五個球，只有一個是用橡膠做的；掉下去會彈起來，那就是工作；另外四個球都是用玻璃做的，掉了，就碎了。」
事實上，在不景氣的年代，連工作都是玻璃做的。唉！有時侯覺得，在動亂的時空下，生涯規劃往往趕不上變動；提供家庭經濟來源的男性都感受壓力沉重，更何況是處於為環境較弱勢的女人呢？
女人們，加油喔！
2009年9月7日 星期一
轉寄:如何用正確的方法寫出高質量軟件的75條體會
如何用正確的方法寫出高質量軟件的75條體會
1. 你們的項目組使用源代碼管理工具了麼？
MVM：應該用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的選擇是VSS。
2. 你們的項目組使用缺陷管理系統了麼？
MVM：應該用。ClearQuest太複雜，我的推薦是BugZilla。
3. 你們的測試組還在用Word寫測試用例麼？
MVM：不要用Word寫測試用例（Test Case）。應該用一個專門的系統，可以是Test Manager，也可以是自己開發一個ASP.NET的小網站。主要目的是Track和Browse。
4. 你們的項目組有沒有建立一個門戶網站？
MVM：要有一個門戶網站，用來放Contact Info、Baselined Schedule、News等等。推薦Sharepoint Portal Server 2003來實現，15分鐘就搞定。買不起SPS 2003可以用WSS (Windows Sharepoint Service)。
5. 你們的項目組用了你能買到最好的工具麼？
MVM：應該用盡量好的工具來工作。比如，應該用VS.NET而不是Notepad來寫C#。用Notepad寫程序多半只是一種炫耀。但也要考慮到經費，所以說是「你能買到最好的」。
6. 你們的程序員工作在安靜的環境裡麼？
MVM：需要安靜環境。這點極端重要，而且要保證每個人的空間大於一定面積。
7. 你們的員工每個人都有一部電話麼？
MVM：需要每人一部電話。而且電話最好是帶留言功能的。當然，上這麼一套帶留言電話系統開銷不小。不過至少每人一部電話要有，千萬別搞得經常有人站起來喊：「某某某電話」。《人件》裡面就強烈譴責這種做法。
8. 你們每個人都知道出了問題應該找誰麼？
MVM：應該知道。任何一個Feature至少都應該有一個Owner，當然，Owner可以繼續Dispatch給其他人。
9. 你遇到過有人說「我以為…」麼？
MVM：要消滅「我以為」。Never assume anything。
10. 你們的項目組中所有的人都坐在一起麼？
MVM：需要。我反對Virtual Team，也反對Dev在美國、Test在中國這種開發方式。能坐在一起就最好坐在一起，好處多得不得了。
11. 你們的進度表是否反映最新開發進展情況？
MVM：應該反映。但是，應該用Baseline的方法來管理進度表：維護一份穩定的Schedule，再維護一份最新更改。Baseline的方法也應該用於其它的Spec。Baseline是變更管理裡面的一個重要手段。
12. 你們的工作量是先由每個人自己估算的麼？
MVM：應該讓每個人自己估算。要從下而上估算工作量，而不是從上往下分派。除非有其他原因，比如政治任務工期固定等。
13. 你們的開發人員從項目一開始就加班麼？
MVM：不要這樣。不要一開始就搞疲勞戰。從項目一開始就加班，只能說明項目進度不合理。當然，一些對日軟件外包必須天天加班，那屬於剝削的範疇。
14. 你們的項目計劃中Buffer Time是加在每個小任務後面的麼？
MVM：不要。Buffer Time加在每個小任務後面，很容易輕易的就被消耗掉。Buffer Time要整段的加在一個Milestone或者checkpoint前面。
15. 值得再多花一些時間，從95%做到100%好
MVM：值得，非常值得。尤其當項目後期人困馬乏的時候，要堅持。這會給產品帶來質的區別。
16. 登記新缺陷時，是否寫清了重現步驟？
MVM：要。這屬於Dev和Test之間的溝通手段。面對面溝通需要，詳細填寫Repro Steps也需要。
17. 寫新代碼前會把已知缺陷解決麼？
MVM：要。每個人的缺陷不能超過10個或15個，否則必須先解決老的bug才能繼續寫新代碼。
18. 你們對缺陷的輕重緩急有事先的約定麼？
MVM：必須有定義。Severity要分1、2、3，約定好：藍屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但這種約定可以根據產品質量現狀適當進行調整。
19. 你們對意見不一的缺陷有三國會議麼？
MVM：必須要有。要有一個明確的決策過程。這類似於CCB (Change Control Board)的概念。
20. 所有的缺陷都是由登記的人最後關閉的麼？
MVM：Bug應該由Opener關閉。Dev不能私自關閉Bug。
21. 你們的程序員厭惡修改老的代碼麼？
MVM：厭惡是正常的。解決方法是組織Code Review，單獨留出時間來。XP也是一個方法。
22. 你們項目組有Team Morale Activity麼？
MVM：每個月都要搞一次，吃飯、唱歌、Outing、打球、開卡丁車等等，一定要有。不要剩這些錢。
23. 你們項目組有自己的Logo麼？
MVM：要有自己的Logo。至少應該有自己的Codename。
24. 你們的員工有印有公司Logo的T-Shirt麼？
MVM：要有。能增強歸屬感。當然，T-Shirt要做的好看一些，最好用80支的棉來做。別沒穿幾次就破破爛爛的。
25. 總經理至少每月參加次項目組會議
MVM：要的。要讓team member覺得高層關注這個項目。
26. 你們是給每個Dev開一個分支麼？
MVM：反對。Branch的管理以及Merge的工作量太大，而且容易出錯。
27. 有人長期不Check-In代碼麼？
MVM：不可以。對大部分項目來說，最多兩三天就應該Check-In。
28. 在Check-In代碼時都填寫註釋了麼？
MVM：要寫的，至少一兩句話，比如「解決了Bug No.225」。如果往高處拔，這也算做「配置審計」的一部分。
29. 有沒有設定每天Check-In的最後期限？
MVM：要的，要明確Check-In Deadline。否則會Build Break。
30. 你們能把所有源碼一下子編譯成安裝文件嗎？
MVM：要的。這是每日編譯（Daily Build）的基礎。而且必須要能夠做成自動的。
31. 你們的項目組做每日編譯麼？
MVM：當然要做。有三樣東西是軟件項目/產品開發必備的：1. bug management; 2. source control; 3. daily build。
32. 你們公司有沒有積累一個項目風險列表？
MVM：要。Risk Inventory。否則，下個項目開始的時候，又只能拍腦袋分析Risk了。
33. 設計越簡單越好
MVM：越簡單越好。設計時候多一句話，將來可能就帶來無窮無盡的煩惱。應該從一開始就勇敢的砍。這叫scope management。
34. 盡量利用現有的產品、技術、代碼
MVM：千萬別什麼東西都自己Coding。BizTalk和Sharepoint就是最好的例子，有這兩個作為基礎，可以把起點提高很多。或者可以盡量多用現成的Control之類的。或者盡量用XML，而不是自己去Parse一個文本文件；盡量用RegExp，而不是自己從頭操作字符串，等等等等。這就是「軟件復用」的體現。
35. 你們會隔一段時間就停下來夯實代碼麼？
MVM：要。最好一個月左右一次。傳言去年年初Windows組在Stevb的命令下停過一個月增強安全。Btw，「夯」這個字念「hang」，第一聲。
36. 你們的項目組每個人都寫Daily Report麼？
MVM：要寫。五分鐘就夠了，寫10句話左右，告訴自己小組的人今天我幹了什麼。一則為了溝通，二則鞭策自己（要是游手好閒一天，自己都會不好意思寫的）。
37. 你們的項目經理會發出Weekly Report麼？
MVM：要。也是為了溝通。內容包括目前進度，可能的風險，質量狀況，各種工作的進展等。
38. 你們項目組是否至少每週全體開會一次？
MVM：要。一定要開會。程序員討厭開會，但每個禮拜開會時間加起來至少應該有4小時。包括team meeting, spec review meeting, bug triage meeting。千萬別大家悶頭寫code。
39. 你們項目組的會議、討論都有記錄麼？
MVM：會前發meeting request和agenda，會中有人負責主持和記錄，會後有人負責發meeting minutes，這都是effective meeting的要點。而且，每個會議都要形成agreements和action items。
40. 其他部門知道你們項目組在幹什麼麼？
MVM：要發一些Newsflash給整個大組織。Show your team’s value。否則，當你坐在電梯裡面，其他部門的人問：「你們在幹嘛」，你回答「ABC項目」的時候，別人全然不知，那種感覺不太好。
41. 通過Email進行所有正式溝通
MVM：Email的好處是免得抵賴。但也要避免矯枉過正，最好的方法是先用電話和當面說，然後Email來確認。
42. 為項目組建立多個Mailing Group
MVM：如果在AD+Exchange裡面，就建Distribution List。比如，我會建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。這樣發起Email來方便，而且能讓該收到email的人都收到、不該收到不被騷擾。
43. 每個人都知道哪裡可以找到全部的文檔麼？
MVM：應該每個人都知道。這叫做知識管理（Knowledge Management）。最方便的就是把文檔放在一個集中的File Share，更好的方法是用Sharepoint。
44. 你做決定、做變化時，告訴大家原因了麼？
MVM：要告訴大家原因。Empower team member的手段之一是提供足夠的information，這是MSF一開篇的幾個原則之一。的確如此，tell me why是人之常情，tell me why了才能有understanding。中國人做事喜歡搞限制，限制信息，似乎能夠看到某一份文件的人就是有身份的人。大錯特錯。權威、權力，不在於是不是能access information/data，而在於是不是掌握資源。
45. Stay agile and expect change
MVM：要這樣。需求一定會變的，已經寫好的代碼一定會被要求修改的。做好心理準備，對change不要抗拒，而是expect change。
46. 你們有沒有專職的軟件測試人員？
MVM：要有專職測試。如果人手不夠，可以peer test，交換了測試。千萬別自己測試自己的。
47. 你們的測試有一份總的計劃來規定做什麼和怎麼做麼？
MVM：這就是Test Plan。要不要做性能測試？要不要做Usability測試？什麼時候開始測試性能？測試通過的標準是什麼？用什麼手段，自動的還是手動的？這些問題需要用Test Plan來回答。
48. 你是先寫Test Case然後再測試的麼？
MVM：應該如此。應該先設計再編程、先test case再測試。當然，事情是靈活的。我有時候在做第一遍測試的同時補上test case。至於先test case再開發，我不喜歡，因為不習慣，太麻煩，至於別人推薦，那試試看也無妨。
49. 你是否會為各種輸入組合創建測試用例？
MVM：不要，不要搞邊界條件組合。當心組合爆炸。有很多test case工具能夠自動生成各種邊界條件的組合——但要想清楚，你是否有時間去運行那麼多test case。
50. 你們的程序員能看到測試用例麼？
MVM：要。讓Dev看到Test Case吧。我們都是為了同一個目的走到一起來的：提高質量。
51. 你們是否隨便抓一些人來做易用性測試？
MVM：要這麼做。自己看自己寫的程序界面，怎麼看都是順眼的。這叫做審美疲勞——臭的看久了也就不臭了，不方便的永久了也就習慣了。
52. 你對自動測試的期望正確麼？
MVM：別期望太高。依我看，除了性能測試以外，還是暫時先忘掉「自動測試」吧，忘掉WinRunner和LoadRunner吧。對於國內的軟件測試的現狀來說，只能「矯枉必須過正」了。
53. 你們的性能測試是等所有功能都開發完才做的麼？
MVM：不能這樣。性能測試不能被歸到所謂的「系統測試」階段。早測早改正，早死早升天。
54. 你注意到測試中的殺蟲劑效應了麼？
MVM：蟲子有抗藥性，Bug也有。發現的新Bug越來越少是正常的。這時候，最好大家交換一下測試的area，或者用用看其他工具和手法，就又會發現一些新bug了。
55. 你們項目組中有人能說出產品的當前整體質量情況麼？
MVM：要有。當老闆問起這個產品目前質量如何，Test Lead/Manager應該負責回答。
56. 你們有單元測試麼？
MVM：單元測試要有的。不過沒有單元測試也不是不可以，我做過沒有單元測試的項目，也做成功了——可能是僥倖，可能是大家都是熟手的關係。還是那句話，軟件工程是非常實踐、非常工程、非常靈活的一套方法，某些方法在某些情況下會比另一些方法好，反之亦然。
57. 你們的程序員是寫完代碼就扔過牆的麼？
MVM：大忌。寫好一塊程序以後，即便不做單元測試，也應該自己先跑一跑。雖然有了專門的測試人員，做開發的人也不可以一點測試都不做。微軟還有Test Release Document的說法，程序太爛的話，測試有權踢回去。
58. 你們的程序中所有的函數都有輸入檢查麼？
MVM：不要。雖然說做輸入檢查是write secure code的要點，但不要做太多的輸入檢查，有些內部函數之間的參數傳遞就不必檢查輸入了，省點功夫。同樣的道理，未必要給所有的函數都寫註釋。寫一部分主要的就夠了。
59. 產品有統一的錯誤處理機制和報錯界面麼？
MVM：要有。最好能有統一的error message，然後每個error message都帶一個error number。這樣，用戶可以自己根據error number到user manual裡面去看看錯誤的具體描述和可能原因，就像SQL Server的錯誤那樣。同樣，ASP.NET也要有統一的Exception處理。可以參考有關的Application Block。
60. 你們有統一的代碼書寫規範麼？
MVM：要有。Code Convention很多，搞一份來發給大家就可以了。當然，要是有FxCop這種工具來檢查代碼就更好了。
61. 你們的每個人都瞭解項目的商業意義麼？
MVM：要。這是Vision的意思。別把項目只當成工作。有時候要想著自己是在為中國某某行業的信息化作先驅者，或者時不時的告訴team member，這個項目能夠為某某某國家部門每年節省多少多少百萬的納稅人的錢，這樣就有動力了。平凡的事情也是可以有個崇高的目標的。
62. 產品各部分的界面和操作習慣一致麼？
MVM：要這樣。要讓用戶覺得整個程序好像是一個人寫出來的那樣。
63. 有可以作為宣傳亮點的Cool Feature麼？
MVM：要。這是增強團隊凝聚力、信心的。而且，「一俊遮百丑」，有亮點就可以掩蓋一些問題。這樣，對於客戶來說，會感覺產品從質量角度來說還是acceptable的。或者說，cool feature或者說亮點可以作為質量問題的一個事後彌補措施。
64. 盡可能縮短產品的啟動時間
MVM：要這樣。軟件啟動時間（Start-Up time）是客戶對性能好壞的第一印象。
65. 不要過於注重內在品質而忽視了第一眼的外在印象
MVM：程序員容易犯這個錯誤：太看重性能、穩定性、存儲效率，但忽視了外在感受。而高層經理、客戶正相反。這兩方面要兼顧，協調這些是PM的工作。
66. 你們根據詳細產品功能說明書做開發麼？
MVM：要這樣。要有設計才能開發，這是必須的。設計文檔，應該說清楚這個產品會怎麼運行，應該採取一些講故事的方法。設計的時候千萬別鑽細節，別鑽到數據庫、代碼等具體實現裡面去，那些是後面的事情，一步步來不能著急。
67. 開始開發和測試之前每個人都仔細審閱功能設計麼？
MVM：要做。Function Spec review是用來統一思想的。而且，review過以後形成了一致意見，將來再也沒有人可以說「你看，當初我就是反對這麼設計的，現在吃苦頭了吧」
68. 所有人都始終想著The Whole Image麼？
MVM：要這樣。項目裡面每個人雖然都只是在製造一片葉子，但每個人都應該知道自己在製造的那片葉子所在的樹是怎麼樣子的。我反對軟件藍領，反對過分的把軟件製造看成流水線、車間。參見第61條。
69. Dev工作的劃分是單純縱向或橫向的麼？
MVM：不能單純的根據功能模塊分，或者單純根據表現層、中間層、數據庫層分。我推薦這麼做：首先根據功能模塊分，然後每個「層」都有一個Owner來Review所有人的設計和代碼，保證consistency。
70. 你們的程序員寫程序設計說明文檔麼？
MVM：要。不過我聽說微軟的程序員1999年以前也不寫。所以說，寫不寫也不是絕對的，偷懶有時候也是可以的。參見第56條。
71. 你在招人面試時讓他寫一段程序麼？
MVM：要的。我最喜歡讓人做字符串和鏈表一類的題目。這種題目有很多循環、判斷、指針、遞歸等，既不偏向過於考算法，也不偏向過於考特定的API。
72. 你們有沒有技術交流講座？
MVM：要的。每一兩個禮拜搞一次內部的Tech Talk或者Chalk Talk吧。讓組員之間分享技術心得，這筆花錢送到外面去培訓划算。
73. 你們的程序員都能專注於一件事情麼？
MVM：要讓程序員專注一件事。例如說，一個部門有兩個項目和10個人，一種方法是讓10個人同時參加兩個項目，每個項目上每個人都花50%時間；另一種方法是5個人去項目A，5個人去項目B，每個人都100%在某一個項目上。我一定選後面一種。這個道理很多人都懂，但很多領導實踐起來就把屬下當成可以任意拆分的資源了。
74. 你們的程序員會誇大完成某項工作所需要的時間麼？
MVM：會的，這是常見的，尤其會在項目後期誇大做某個change所需要的時間，以次來抵制change。解決的方法是坐下來慢慢磨，磨掉程序員的逆反心理，一起分析，並把估算時間的顆粒度變小。
75. 盡量不要用Virtual Heads
MVM：最好不要用Virtual Heads。Virtual heads意味著resource is not secure，shared resource會降低resource的工作效率，容易增加出錯的機會，會讓一心二用的人沒有太多時間去review spec、review design。一個dedicated的人，要強過兩個只能投入50%時間和精力的人。我是吃過虧的：7個part time的tester，發現的Bug和干的活，加起來還不如兩個full-time的。參見第73條。73條是針對程序員的，75條是針對Resource Manager的。
來源:http://www.wowbox.com.tw/blog/article.asp?id=859
1. 你們的項目組使用源代碼管理工具了麼？
MVM：應該用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的選擇是VSS。
2. 你們的項目組使用缺陷管理系統了麼？
MVM：應該用。ClearQuest太複雜，我的推薦是BugZilla。
3. 你們的測試組還在用Word寫測試用例麼？
MVM：不要用Word寫測試用例（Test Case）。應該用一個專門的系統，可以是Test Manager，也可以是自己開發一個ASP.NET的小網站。主要目的是Track和Browse。
4. 你們的項目組有沒有建立一個門戶網站？
MVM：要有一個門戶網站，用來放Contact Info、Baselined Schedule、News等等。推薦Sharepoint Portal Server 2003來實現，15分鐘就搞定。買不起SPS 2003可以用WSS (Windows Sharepoint Service)。
5. 你們的項目組用了你能買到最好的工具麼？
MVM：應該用盡量好的工具來工作。比如，應該用VS.NET而不是Notepad來寫C#。用Notepad寫程序多半只是一種炫耀。但也要考慮到經費，所以說是「你能買到最好的」。
6. 你們的程序員工作在安靜的環境裡麼？
MVM：需要安靜環境。這點極端重要，而且要保證每個人的空間大於一定面積。
7. 你們的員工每個人都有一部電話麼？
MVM：需要每人一部電話。而且電話最好是帶留言功能的。當然，上這麼一套帶留言電話系統開銷不小。不過至少每人一部電話要有，千萬別搞得經常有人站起來喊：「某某某電話」。《人件》裡面就強烈譴責這種做法。
8. 你們每個人都知道出了問題應該找誰麼？
MVM：應該知道。任何一個Feature至少都應該有一個Owner，當然，Owner可以繼續Dispatch給其他人。
9. 你遇到過有人說「我以為…」麼？
MVM：要消滅「我以為」。Never assume anything。
10. 你們的項目組中所有的人都坐在一起麼？
MVM：需要。我反對Virtual Team，也反對Dev在美國、Test在中國這種開發方式。能坐在一起就最好坐在一起，好處多得不得了。
11. 你們的進度表是否反映最新開發進展情況？
MVM：應該反映。但是，應該用Baseline的方法來管理進度表：維護一份穩定的Schedule，再維護一份最新更改。Baseline的方法也應該用於其它的Spec。Baseline是變更管理裡面的一個重要手段。
12. 你們的工作量是先由每個人自己估算的麼？
MVM：應該讓每個人自己估算。要從下而上估算工作量，而不是從上往下分派。除非有其他原因，比如政治任務工期固定等。
13. 你們的開發人員從項目一開始就加班麼？
MVM：不要這樣。不要一開始就搞疲勞戰。從項目一開始就加班，只能說明項目進度不合理。當然，一些對日軟件外包必須天天加班，那屬於剝削的範疇。
14. 你們的項目計劃中Buffer Time是加在每個小任務後面的麼？
MVM：不要。Buffer Time加在每個小任務後面，很容易輕易的就被消耗掉。Buffer Time要整段的加在一個Milestone或者checkpoint前面。
15. 值得再多花一些時間，從95%做到100%好
MVM：值得，非常值得。尤其當項目後期人困馬乏的時候，要堅持。這會給產品帶來質的區別。
16. 登記新缺陷時，是否寫清了重現步驟？
MVM：要。這屬於Dev和Test之間的溝通手段。面對面溝通需要，詳細填寫Repro Steps也需要。
17. 寫新代碼前會把已知缺陷解決麼？
MVM：要。每個人的缺陷不能超過10個或15個，否則必須先解決老的bug才能繼續寫新代碼。
18. 你們對缺陷的輕重緩急有事先的約定麼？
MVM：必須有定義。Severity要分1、2、3，約定好：藍屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但這種約定可以根據產品質量現狀適當進行調整。
19. 你們對意見不一的缺陷有三國會議麼？
MVM：必須要有。要有一個明確的決策過程。這類似於CCB (Change Control Board)的概念。
20. 所有的缺陷都是由登記的人最後關閉的麼？
MVM：Bug應該由Opener關閉。Dev不能私自關閉Bug。
21. 你們的程序員厭惡修改老的代碼麼？
MVM：厭惡是正常的。解決方法是組織Code Review，單獨留出時間來。XP也是一個方法。
22. 你們項目組有Team Morale Activity麼？
MVM：每個月都要搞一次，吃飯、唱歌、Outing、打球、開卡丁車等等，一定要有。不要剩這些錢。
23. 你們項目組有自己的Logo麼？
MVM：要有自己的Logo。至少應該有自己的Codename。
24. 你們的員工有印有公司Logo的T-Shirt麼？
MVM：要有。能增強歸屬感。當然，T-Shirt要做的好看一些，最好用80支的棉來做。別沒穿幾次就破破爛爛的。
25. 總經理至少每月參加次項目組會議
MVM：要的。要讓team member覺得高層關注這個項目。
26. 你們是給每個Dev開一個分支麼？
MVM：反對。Branch的管理以及Merge的工作量太大，而且容易出錯。
27. 有人長期不Check-In代碼麼？
MVM：不可以。對大部分項目來說，最多兩三天就應該Check-In。
28. 在Check-In代碼時都填寫註釋了麼？
MVM：要寫的，至少一兩句話，比如「解決了Bug No.225」。如果往高處拔，這也算做「配置審計」的一部分。
29. 有沒有設定每天Check-In的最後期限？
MVM：要的，要明確Check-In Deadline。否則會Build Break。
30. 你們能把所有源碼一下子編譯成安裝文件嗎？
MVM：要的。這是每日編譯（Daily Build）的基礎。而且必須要能夠做成自動的。
31. 你們的項目組做每日編譯麼？
MVM：當然要做。有三樣東西是軟件項目/產品開發必備的：1. bug management; 2. source control; 3. daily build。
32. 你們公司有沒有積累一個項目風險列表？
MVM：要。Risk Inventory。否則，下個項目開始的時候，又只能拍腦袋分析Risk了。
33. 設計越簡單越好
MVM：越簡單越好。設計時候多一句話，將來可能就帶來無窮無盡的煩惱。應該從一開始就勇敢的砍。這叫scope management。
34. 盡量利用現有的產品、技術、代碼
MVM：千萬別什麼東西都自己Coding。BizTalk和Sharepoint就是最好的例子，有這兩個作為基礎，可以把起點提高很多。或者可以盡量多用現成的Control之類的。或者盡量用XML，而不是自己去Parse一個文本文件；盡量用RegExp，而不是自己從頭操作字符串，等等等等。這就是「軟件復用」的體現。
35. 你們會隔一段時間就停下來夯實代碼麼？
MVM：要。最好一個月左右一次。傳言去年年初Windows組在Stevb的命令下停過一個月增強安全。Btw，「夯」這個字念「hang」，第一聲。
36. 你們的項目組每個人都寫Daily Report麼？
MVM：要寫。五分鐘就夠了，寫10句話左右，告訴自己小組的人今天我幹了什麼。一則為了溝通，二則鞭策自己（要是游手好閒一天，自己都會不好意思寫的）。
37. 你們的項目經理會發出Weekly Report麼？
MVM：要。也是為了溝通。內容包括目前進度，可能的風險，質量狀況，各種工作的進展等。
38. 你們項目組是否至少每週全體開會一次？
MVM：要。一定要開會。程序員討厭開會，但每個禮拜開會時間加起來至少應該有4小時。包括team meeting, spec review meeting, bug triage meeting。千萬別大家悶頭寫code。
39. 你們項目組的會議、討論都有記錄麼？
MVM：會前發meeting request和agenda，會中有人負責主持和記錄，會後有人負責發meeting minutes，這都是effective meeting的要點。而且，每個會議都要形成agreements和action items。
40. 其他部門知道你們項目組在幹什麼麼？
MVM：要發一些Newsflash給整個大組織。Show your team’s value。否則，當你坐在電梯裡面，其他部門的人問：「你們在幹嘛」，你回答「ABC項目」的時候，別人全然不知，那種感覺不太好。
41. 通過Email進行所有正式溝通
MVM：Email的好處是免得抵賴。但也要避免矯枉過正，最好的方法是先用電話和當面說，然後Email來確認。
42. 為項目組建立多個Mailing Group
MVM：如果在AD+Exchange裡面，就建Distribution List。比如，我會建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。這樣發起Email來方便，而且能讓該收到email的人都收到、不該收到不被騷擾。
43. 每個人都知道哪裡可以找到全部的文檔麼？
MVM：應該每個人都知道。這叫做知識管理（Knowledge Management）。最方便的就是把文檔放在一個集中的File Share，更好的方法是用Sharepoint。
44. 你做決定、做變化時，告訴大家原因了麼？
MVM：要告訴大家原因。Empower team member的手段之一是提供足夠的information，這是MSF一開篇的幾個原則之一。的確如此，tell me why是人之常情，tell me why了才能有understanding。中國人做事喜歡搞限制，限制信息，似乎能夠看到某一份文件的人就是有身份的人。大錯特錯。權威、權力，不在於是不是能access information/data，而在於是不是掌握資源。
45. Stay agile and expect change
MVM：要這樣。需求一定會變的，已經寫好的代碼一定會被要求修改的。做好心理準備，對change不要抗拒，而是expect change。
46. 你們有沒有專職的軟件測試人員？
MVM：要有專職測試。如果人手不夠，可以peer test，交換了測試。千萬別自己測試自己的。
47. 你們的測試有一份總的計劃來規定做什麼和怎麼做麼？
MVM：這就是Test Plan。要不要做性能測試？要不要做Usability測試？什麼時候開始測試性能？測試通過的標準是什麼？用什麼手段，自動的還是手動的？這些問題需要用Test Plan來回答。
48. 你是先寫Test Case然後再測試的麼？
MVM：應該如此。應該先設計再編程、先test case再測試。當然，事情是靈活的。我有時候在做第一遍測試的同時補上test case。至於先test case再開發，我不喜歡，因為不習慣，太麻煩，至於別人推薦，那試試看也無妨。
49. 你是否會為各種輸入組合創建測試用例？
MVM：不要，不要搞邊界條件組合。當心組合爆炸。有很多test case工具能夠自動生成各種邊界條件的組合——但要想清楚，你是否有時間去運行那麼多test case。
50. 你們的程序員能看到測試用例麼？
MVM：要。讓Dev看到Test Case吧。我們都是為了同一個目的走到一起來的：提高質量。
51. 你們是否隨便抓一些人來做易用性測試？
MVM：要這麼做。自己看自己寫的程序界面，怎麼看都是順眼的。這叫做審美疲勞——臭的看久了也就不臭了，不方便的永久了也就習慣了。
52. 你對自動測試的期望正確麼？
MVM：別期望太高。依我看，除了性能測試以外，還是暫時先忘掉「自動測試」吧，忘掉WinRunner和LoadRunner吧。對於國內的軟件測試的現狀來說，只能「矯枉必須過正」了。
53. 你們的性能測試是等所有功能都開發完才做的麼？
MVM：不能這樣。性能測試不能被歸到所謂的「系統測試」階段。早測早改正，早死早升天。
54. 你注意到測試中的殺蟲劑效應了麼？
MVM：蟲子有抗藥性，Bug也有。發現的新Bug越來越少是正常的。這時候，最好大家交換一下測試的area，或者用用看其他工具和手法，就又會發現一些新bug了。
55. 你們項目組中有人能說出產品的當前整體質量情況麼？
MVM：要有。當老闆問起這個產品目前質量如何，Test Lead/Manager應該負責回答。
56. 你們有單元測試麼？
MVM：單元測試要有的。不過沒有單元測試也不是不可以，我做過沒有單元測試的項目，也做成功了——可能是僥倖，可能是大家都是熟手的關係。還是那句話，軟件工程是非常實踐、非常工程、非常靈活的一套方法，某些方法在某些情況下會比另一些方法好，反之亦然。
57. 你們的程序員是寫完代碼就扔過牆的麼？
MVM：大忌。寫好一塊程序以後，即便不做單元測試，也應該自己先跑一跑。雖然有了專門的測試人員，做開發的人也不可以一點測試都不做。微軟還有Test Release Document的說法，程序太爛的話，測試有權踢回去。
58. 你們的程序中所有的函數都有輸入檢查麼？
MVM：不要。雖然說做輸入檢查是write secure code的要點，但不要做太多的輸入檢查，有些內部函數之間的參數傳遞就不必檢查輸入了，省點功夫。同樣的道理，未必要給所有的函數都寫註釋。寫一部分主要的就夠了。
59. 產品有統一的錯誤處理機制和報錯界面麼？
MVM：要有。最好能有統一的error message，然後每個error message都帶一個error number。這樣，用戶可以自己根據error number到user manual裡面去看看錯誤的具體描述和可能原因，就像SQL Server的錯誤那樣。同樣，ASP.NET也要有統一的Exception處理。可以參考有關的Application Block。
60. 你們有統一的代碼書寫規範麼？
MVM：要有。Code Convention很多，搞一份來發給大家就可以了。當然，要是有FxCop這種工具來檢查代碼就更好了。
61. 你們的每個人都瞭解項目的商業意義麼？
MVM：要。這是Vision的意思。別把項目只當成工作。有時候要想著自己是在為中國某某行業的信息化作先驅者，或者時不時的告訴team member，這個項目能夠為某某某國家部門每年節省多少多少百萬的納稅人的錢，這樣就有動力了。平凡的事情也是可以有個崇高的目標的。
62. 產品各部分的界面和操作習慣一致麼？
MVM：要這樣。要讓用戶覺得整個程序好像是一個人寫出來的那樣。
63. 有可以作為宣傳亮點的Cool Feature麼？
MVM：要。這是增強團隊凝聚力、信心的。而且，「一俊遮百丑」，有亮點就可以掩蓋一些問題。這樣，對於客戶來說，會感覺產品從質量角度來說還是acceptable的。或者說，cool feature或者說亮點可以作為質量問題的一個事後彌補措施。
64. 盡可能縮短產品的啟動時間
MVM：要這樣。軟件啟動時間（Start-Up time）是客戶對性能好壞的第一印象。
65. 不要過於注重內在品質而忽視了第一眼的外在印象
MVM：程序員容易犯這個錯誤：太看重性能、穩定性、存儲效率，但忽視了外在感受。而高層經理、客戶正相反。這兩方面要兼顧，協調這些是PM的工作。
66. 你們根據詳細產品功能說明書做開發麼？
MVM：要這樣。要有設計才能開發，這是必須的。設計文檔，應該說清楚這個產品會怎麼運行，應該採取一些講故事的方法。設計的時候千萬別鑽細節，別鑽到數據庫、代碼等具體實現裡面去，那些是後面的事情，一步步來不能著急。
67. 開始開發和測試之前每個人都仔細審閱功能設計麼？
MVM：要做。Function Spec review是用來統一思想的。而且，review過以後形成了一致意見，將來再也沒有人可以說「你看，當初我就是反對這麼設計的，現在吃苦頭了吧」
68. 所有人都始終想著The Whole Image麼？
MVM：要這樣。項目裡面每個人雖然都只是在製造一片葉子，但每個人都應該知道自己在製造的那片葉子所在的樹是怎麼樣子的。我反對軟件藍領，反對過分的把軟件製造看成流水線、車間。參見第61條。
69. Dev工作的劃分是單純縱向或橫向的麼？
MVM：不能單純的根據功能模塊分，或者單純根據表現層、中間層、數據庫層分。我推薦這麼做：首先根據功能模塊分，然後每個「層」都有一個Owner來Review所有人的設計和代碼，保證consistency。
70. 你們的程序員寫程序設計說明文檔麼？
MVM：要。不過我聽說微軟的程序員1999年以前也不寫。所以說，寫不寫也不是絕對的，偷懶有時候也是可以的。參見第56條。
71. 你在招人面試時讓他寫一段程序麼？
MVM：要的。我最喜歡讓人做字符串和鏈表一類的題目。這種題目有很多循環、判斷、指針、遞歸等，既不偏向過於考算法，也不偏向過於考特定的API。
72. 你們有沒有技術交流講座？
MVM：要的。每一兩個禮拜搞一次內部的Tech Talk或者Chalk Talk吧。讓組員之間分享技術心得，這筆花錢送到外面去培訓划算。
73. 你們的程序員都能專注於一件事情麼？
MVM：要讓程序員專注一件事。例如說，一個部門有兩個項目和10個人，一種方法是讓10個人同時參加兩個項目，每個項目上每個人都花50%時間；另一種方法是5個人去項目A，5個人去項目B，每個人都100%在某一個項目上。我一定選後面一種。這個道理很多人都懂，但很多領導實踐起來就把屬下當成可以任意拆分的資源了。
74. 你們的程序員會誇大完成某項工作所需要的時間麼？
MVM：會的，這是常見的，尤其會在項目後期誇大做某個change所需要的時間，以次來抵制change。解決的方法是坐下來慢慢磨，磨掉程序員的逆反心理，一起分析，並把估算時間的顆粒度變小。
75. 盡量不要用Virtual Heads
MVM：最好不要用Virtual Heads。Virtual heads意味著resource is not secure，shared resource會降低resource的工作效率，容易增加出錯的機會，會讓一心二用的人沒有太多時間去review spec、review design。一個dedicated的人，要強過兩個只能投入50%時間和精力的人。我是吃過虧的：7個part time的tester，發現的Bug和干的活，加起來還不如兩個full-time的。參見第73條。73條是針對程序員的，75條是針對Resource Manager的。
來源:http://www.wowbox.com.tw/blog/article.asp?id=859
訂閱：
文章 (Atom)