【正文】 莉在舊的郵件系統(tǒng)中的用戶賬號就會隨著她結(jié)婚后的新遷移郵件地址一同更新，問題就不會出現(xiàn)。新系統(tǒng)(1) (2) (3) 舊系統(tǒng)(1) (2) (3) （結(jié)婚后忘了改變這一條“遷移”轉(zhuǎn)發(fā)地址。(3) 仍在舊系統(tǒng)中的人給仍在舊系統(tǒng)中的其他用戶發(fā)送郵件時，郵件將會傳送到對應(yīng)的舊郵箱中。這樣他們就可以確保幾個網(wǎng)站的一致性，并可以重復(fù)使用具體實現(xiàn)細(xì)節(jié)。 掌控整個項目的動向。 確保每個工作流至少有一個負(fù)責(zé)傳送的關(guān)鍵聯(lián)絡(luò)點(diǎn)。項目經(jīng)理應(yīng)該把項目劃分成易管理的模塊，并與有才能的人分別承擔(dān)這些模塊，項目（在規(guī)模或復(fù)雜性方面）越大，這一點(diǎn)就越重要。實際上，普通開發(fā)人員會拖累整體生產(chǎn)力，并且使項目花費(fèi)的時間比實際需要的更長。 再聯(lián)想到在延期項目中加人會使項目延期得更長，你就可以理解為什么大多數(shù)企業(yè)發(fā)展緩慢。事實上，統(tǒng)計數(shù)字表明，真正優(yōu)秀的開發(fā)人員要比差的人員好上幾個數(shù)量級，也就是成百上千倍。審查他們是否掌握開發(fā)生命周期的正確知識、方法、工具，以及他們對在分析了代碼，并且與你信賴的開發(fā)人員討論后，你才會知道這個人的方法和風(fēng)格是否適合你的團(tuán)隊。一個優(yōu)秀的軟件工程師能夠立刻修復(fù)“模擬”的語法錯誤，并且不會精神緊張。顯而易見，如果我們當(dāng)初明確記錄了供應(yīng)商修復(fù)每個 bug 所花的具體時間，那么我們可能都無需支付合同約定的上限費(fèi)用。它們暴露出軟件的基本功能存在嚴(yán)重的問題，甚至是在升級以后還存在問題。在這五次接踵而至的升級過程中，每次都要重復(fù)這個過程。一到兩個星期的迭代過程意味著我們必須有早期和頻繁的反饋意見，意味著我們有機(jī)會闡明客戶的期望。作為終端用戶的客戶并沒有認(rèn)識到，如果想在單個屏幕上顯示這種超量的內(nèi)容，我們必須是超人才能實現(xiàn)這個奇跡，于是他們非常失望。 ）盡管這是一家經(jīng)驗豐富的設(shè)計公司，它卻向客戶陳述了這樣的正式要求（我們從來沒有見過）：每一頁的布局符合固定的 800 像素寬和 600 像素高的標(biāo)準(zhǔn)。 邊緣事件：只在極端情況下（例如，最快或最慢的速度，最多或最少的數(shù)據(jù)量，或者最老或最新的瀏覽器接口）出現(xiàn)的問題或情況。不那么“非比尋?！?（但卻更成功）的團(tuán)隊之所以會使用現(xiàn)成的工具，那是因為他們準(zhǔn)備解決的問題都是很棘手的。 ”持續(xù)集成？行。 ”他們不從其他開發(fā)團(tuán)隊的錯誤中汲取經(jīng)驗教訓(xùn)，而是悶頭重復(fù)犯著同樣的錯誤。只要認(rèn)真地遵循這些簡單的技巧，每一個軟件項目都可以取得圓滿成功。 z 。需求分析人員應(yīng)該用簡單樹形圖寫出需求。不論那些需求有多完善，總是難免會有變動。聘用人才而不是技能，這是組建團(tuán)隊的一種完全不同的方式。我們不是在尋找新的人才，我們一直尋找的只是非常具體的精良技能。我聽說你們即將開始一些非常酷、非常新的 Java 項目，所以我才會想來這兒工作，因為我把它看成一個學(xué)習(xí)和成長的機(jī)會。如果我能開出不錯的薪酬，這將會是一件輕而易舉的事。當(dāng)開發(fā)人員最終舉手投降說他們需要在一個系統(tǒng)上重打鑼另開張時，實際情況極有可能是，許許多多沒有償還的技術(shù)債已經(jīng)使他們不堪重負(fù)，債臺高筑之下，他們覺得還不如痛快地宣布這套軟件破產(chǎn)了。修改這種不完善的代碼可以稱為“展開修改” 。如果持續(xù)向未來借債而不償還，那么就會令整個項目變得岌岌可危。明智地使用短期債務(wù)能夠有效地消除現(xiàn)金大漲大落?，F(xiàn)在的問題是，那種固有的復(fù)雜問題中有多少是你強(qiáng)加給最終用戶的？你的軟件是不是一個復(fù)雜問題放大器？成功的軟件通常是一個復(fù)雜問題吸收器，因為它首當(dāng)其沖地為用戶承受了復(fù)雜的問題，而不是將這些問題一路傳遞給用戶。 “飲料” 、 “面條” 、 “比薩餅” 、 “盤菜” 、 “醬”還是“湯”？當(dāng)然，他們可能會給“復(fù)雜性”冠以“功能豐富”的頭銜。說服項目所有人，他們必須自始至終參與這個過程。既然是這樣困難，很多項目所有人，如客戶、項目發(fā)起人或公司主管，就期望項目經(jīng)理能自己定義和細(xì)化這些對軟件的要求。這樣一來，如果有措辭不清楚的情況，我們就能立即發(fā)現(xiàn)它，而不必等到測試可運(yùn)行的產(chǎn)品時才發(fā)現(xiàn)它。在測試和審查本地化的版本時，你總會發(fā)現(xiàn)不止一個具有挑戰(zhàn)性的問題無法得到解決，除非回頭去改變英文版產(chǎn)品。如果不支持，那么，即使英文版運(yùn)行得很完美，日文版的產(chǎn)品也無法運(yùn)行。 當(dāng)估計某一功能的實現(xiàn)時間時，不要只考慮最初寫代碼所花費(fèi)的時間，還要加上提升、調(diào)整和改進(jìn)這些代碼所需的時間。那會令人沮喪，結(jié)果也難以預(yù)料，并且它會減慢產(chǎn)品開發(fā)速度。遺憾的是他們發(fā)現(xiàn)伯尼實現(xiàn)的功能有些奇怪。像往常一樣，顧客喜歡你已經(jīng)完成的功能，但現(xiàn)在需要你做一些改動和完善。你發(fā)現(xiàn)在開發(fā)過程中伯尼實現(xiàn)軟件功能的速度遠(yuǎn)遠(yuǎn)超過羅布。行政助理們很憤怒。 in Human Resources（人力資源專家） ，是由美國認(rèn)證協(xié)會（American Certi fication Institute）推出的在國際范圍內(nèi)比較權(quán)威的人力資源管理知識體系認(rèn)證資格。在一些細(xì)小環(huán)節(jié)上做出的編程決策，或許對于軟件開發(fā)人員和項目經(jīng)理而言道理十足，可當(dāng)軟件投入使用后卻有可能給用戶造成巨大的混亂。畢竟，用戶根本不知道我們在做什么，對吧？直至項目結(jié)束，我們的魔術(shù)師才會匆匆登場，揭去魔法布，然后期望用戶會對我們卓越的產(chǎn)品驚嘆不已。例如，4125可能是學(xué)生手冊，4225則是配套的學(xué)生練習(xí)盤，4325可以代表教師手冊，4425則是營銷宣傳時使用的課程大綱等。在重新設(shè)計時，不知何故，這個項目團(tuán)隊居然忘記考慮實際情況下真人是如何進(jìn)行訂購的。作為項目經(jīng)理，你應(yīng)該盡早并經(jīng)常讓軟件開發(fā)人員和用戶交談。一旦寫的程序能夠運(yùn)行起來，他就把這個程序分成幾小塊。①客戶又一次測試這些功能，結(jié)果后來新增的功能也不能用了。 盡管羅布從一開始就表現(xiàn)得較慢，但實際上他編寫的代碼更勝一籌。問問自己，你是想要速度還是想盡情享受可持續(xù)發(fā)展的樂趣。僅僅是轉(zhuǎn)換成其他語言版本也會影響到你何時做何種決定。 z翻譯版產(chǎn)品的運(yùn)行沒有瑕疵。經(jīng)驗不足的軟件開發(fā)項目經(jīng)理常犯的這個錯誤很簡單。這個版本的任何變化都不可避免地引起其他外文版作出相應(yīng)變化。根據(jù)幾年前一家日本領(lǐng)先 IT雜志社進(jìn)行的調(diào)查，如果按照質(zhì)量、成本和交付期的標(biāo)準(zhǔn)來衡量，日本企業(yè)實施的項目中，超過 75% 都被認(rèn)為是失敗的。而對于軟件項目經(jīng)理而言，他通常沒有權(quán)力或時間來自己發(fā)現(xiàn)、選擇項目需求并排定優(yōu)先級，尤其是當(dāng)該項目可能涉及多個利益團(tuán)體時，大家對軟件完成后應(yīng)實現(xiàn)的功能可能會有相互沖突的設(shè)想。 失敗的軟件項目對項目所有人傷害最大，因為是他們資助了這個項目，是他們一直期待著能靠這個軟件賺回投資。假設(shè)我有一塊涼比薩餅需要熱一下。我猜應(yīng)該選擇“熟食 / 新做” 。當(dāng)開發(fā)人員由于技術(shù)原因不能實現(xiàn)需求時，你的任務(wù)就是翻譯（吸收）這個復(fù)雜的問題，并向用戶進(jìn)行解釋，用足夠多的信息幫助用戶選擇另一個途徑。沃德 ①不要借機(jī)偷懶，這是一種嚴(yán)肅的、保持代碼庫干凈的有效方法。7. 為團(tuán)隊增添人才而非技能我過去采用的招聘標(biāo)準(zhǔn)同我們這個行業(yè)里的每一個人的招聘方式都是一樣的：技能，技能，技能。我信心十足地認(rèn)為這次招聘會進(jìn)展得很順利。你知道，我和我的伙伴之所以會進(jìn)入這個高新技術(shù)產(chǎn)業(yè)，正是因為我們希望走在科技的最前沿。當(dāng)為敏捷開發(fā)團(tuán)隊招聘技術(shù)專家時，我要找的是什么樣的人才？他們需要具備的優(yōu)良技能不過是在幼兒園里就培養(yǎng)的：能和他人融洽相處嗎？ z喜歡學(xué)習(xí)嗎？項目組成員一定有能力完整構(gòu)想該項目的目標(biāo)并完成實際工作。讓需求保持簡單在整個圖中不斷重復(fù)這個過程，直到每項需求都清晰明了。客戶的反饋信息能夠確保準(zhǔn)確的需求，同時發(fā)現(xiàn)需求經(jīng)需求分析員從實際客戶傳遞到項目組時有可能形成的交流差異。相信那個愛的謊言，結(jié)果導(dǎo)致了許多常見的軟件項目問題。這些虛幻而神奇的產(chǎn)品本可以像這個團(tuán)隊一樣非比尋常，當(dāng)然，前提是這個團(tuán)隊真的有幸將它們寫出來。①如果他們跑來跟你解釋他們的問題是多么非比尋常，你就直接向他們點(diǎn)明，他們的媽媽在做出“你是非比尋常”的評價時可能言過其實了。我們同客戶沒有直接的聯(lián)系。用戶討厭水平地滾動網(wǎng)頁，而垂直滾動則被看做是使用瀏覽器的一種現(xiàn)實情況，甚至是一種有利條件。據(jù)他們的說法，我們“沒有滿足書面要求” 。11. 你們的問題，我不買單我們公司正在使用的培訓(xùn)軟件已經(jīng)滯后了五次升級，再不及時升級，供應(yīng)商都不再提供支持。進(jìn)行升級時，我們會發(fā)現(xiàn)應(yīng)用升級程序的錯誤，這些錯誤和我們用來安裝升級寫的客戶腳本并不相關(guān)。腳本可以用來控制軟件應(yīng)用而不用改變應(yīng)用程序的核心代碼。12. 如何發(fā)現(xiàn)優(yōu)秀的 IT 開發(fā)人員軟件項目經(jīng)理都知道，項目的成功取決于擁有出色的開發(fā)人員。我們招聘編程技術(shù)人才時都認(rèn)為其技能“越多越好” 。傳說當(dāng)他感到不滿時，他就會用他的大聲吼叫吹干人們的頭發(fā)。考察他們在工作環(huán)境下應(yīng)用知識的能力。 z的限制條件。但是開發(fā)軟件并不像挖溝，在挖溝時即使最差的挖土機(jī)也能挖出一個洞。 速度：在敏捷軟件開發(fā)中使用的一個術(shù)語，用以表明一個團(tuán)隊或一個團(tuán)隊成員在項目中的速率，即在給定時間內(nèi)一個程序員能完成多少工作量。繼續(xù)加人，渠道的數(shù)量還會繼續(xù)以指數(shù)速度增長。軟件開發(fā)太復(fù)雜，它不是一個裝配線生產(chǎn)過程。這個“大”字讓人浮想聯(lián)翩，它可能意味著 8個人連續(xù)工作 12 個月（你是一個小供應(yīng)商） ，也可能意味著數(shù)百人全年按合同做著維護(hù)工作（對你的客戶而言你是一個IT 巨頭） 。 如果可能，盡量讓主要成員在工作流中有交叉，以使整個團(tuán)隊可以共享每日例會時讓不同團(tuán)隊協(xié)調(diào)整體的傳送質(zhì)量。一旦單身薩莉（Sally Single）被遷移到新的電子郵件系統(tǒng)中，她就有了兩個電子郵件地址，一個是 ，另一個是轉(zhuǎn)發(fā)郵件地址 。雖然免責(zé)聲明只有 100 字左右，但是當(dāng)每個信息在系統(tǒng)中一分鐘就循環(huán)幾次時，內(nèi)容就會迅速增加。Il semble que la perfection soit atteinte non quand il n’ y a plus rien 224。圣 該團(tuán)隊正在經(jīng)歷“規(guī)劃致死”會議；根據(jù)我的經(jīng)驗，這絕對不是一個工作進(jìn)程問題。一個經(jīng)驗豐富的項目經(jīng)理應(yīng)該仔細(xì)查看團(tuán)隊需要去做的所有活動，只保留那些對具體項目成功至關(guān)重要的活動。使用上面這些例子，下面的說明書或許會由系統(tǒng)架構(gòu)師來寫。 倘若不分清需求和說明書的界線，就會導(dǎo)致錯誤的人在作決定。他們應(yīng)該只受限于他們已經(jīng)選用的技術(shù)，而不受制于非編程人員制作的教條式的脆弱說明書。如果我們正在為市場開發(fā)一個軟件產(chǎn)品， “成功”的評價因素是很明確的。當(dāng)在所有項目中選擇主攻某一特定項目時，必須考慮為什么它比那些被擱置的項目更重要。為了減少這種風(fēng)險，項目管理新手常常取消他們的休假，或者更糟糕，根本沒有打算休假。他可能行事風(fēng)格不會完全像你，但是作為你的代理人，他會保持項目之船平穩(wěn)并朝著正確的方向航行。隨著時間的流逝，團(tuán)隊采用且適應(yīng)了這些程序，項目經(jīng)理就會管理得越來越少，并且越來越順利。一個僅需五分鐘就能解決的問題實際上卻用了25 分鐘，短短 10 分鐘的會議會占用 30 分鐘工作時間。編程需要開發(fā)人員同時想著許多東西——如變量、類結(jié)構(gòu)、API、實用方法，甚至是目錄結(jié)構(gòu)。對于開發(fā)人員來說，他并行參與的項目每增加一個就會使他的生產(chǎn)率降低50% 以上。如果一聲令下，所有方面（資源、技術(shù)、需求以及時間表等）就能結(jié)合起來使工作很順利地完成的話，那就不需要任何指導(dǎo)了。之所以需要我們，就是因為執(zhí)行項目本身就是一件容易造成混亂的事件，需要用我們多樣的技能和個性去確保不可避免的困難得到化解、規(guī)避或者使其大事化小小事化了。當(dāng)然，這是相對而言的。所有受雇到我們部門的人員需要在三個項目經(jīng)理手下輪流工作。(1) 根據(jù)用戶輸入創(chuàng)建故事②，確定它們的優(yōu)先級并且交換意見。開完會后，任務(wù)進(jìn)入了任務(wù)追蹤系統(tǒng)。問題來了，為什么那個項目經(jīng)理會認(rèn)為蒂姆毫無產(chǎn)出呢？仔細(xì)觀察就會發(fā)現(xiàn)，這位蒂姆的抨擊者有一個過分控制的管理模式。通過發(fā)揮技巧和聰明才智，終于創(chuàng)造出許多行最終完成工作的聰明代碼。得到一個容易測試、能自定義、小存儲和容易維護(hù)的簡單代碼結(jié)構(gòu)，當(dāng)然是很有價值的。聰明過頭會讓其他人跟不上。從錯誤到事故，到徹底行不通，種種人為失敗都可歸咎于我們喜歡重復(fù)過去的行為方法。銀行監(jiān)管機(jī)構(gòu)的報告指出，弄錯數(shù)字是一個普遍的錯誤，特別是當(dāng)雇員因為工作壓力或個人壓力而沒有百分之百地集中精力時。通過與他們積極對話并且仔細(xì)管理好他們的工作環(huán)境，你可以為他們免除壓力或者將壓力的影響降至最小。團(tuán)隊人員可以共享議題，比如編碼標(biāo)準(zhǔn)、構(gòu)建和布署過程、常見陷阱和先進(jìn)編碼技術(shù)的使用（如依賴注入） 。 z 使用本網(wǎng)站張貼團(tuán)隊日歷。他需要能夠進(jìn)入工作文件和從多個位置訪問領(lǐng)域制品的集中入口。下面給出一些建議。他們知道，團(tuán)隊成員總是面臨分身乏術(shù)的兩難處境，既要履行例行職責(zé)，如處理日常工作、解決問題、協(xié)調(diào)部門合作事宜、答復(fù)日常交流，又要按時完成項目開發(fā)任務(wù)。27. 估算，估算，再估算有種現(xiàn)象在項目管理中是如此常見，我們在項目初始階段（當(dāng)我們只知道一點(diǎn)點(diǎn)時）就對項目進(jìn)行估算，然后在整個項目進(jìn)程中（比剛開始知道得多些時）卻對以前的估算結(jié)果不聞不問。 有時候，我們逐漸知道得更多，這能幫助我們進(jìn)行估算。拿三個大小不同的空瓶子，用吉利豆裝滿。最后，告訴團(tuán)隊成員這是一個做估算的好方法，感謝他們的參與，并且在你離開前問是否還有問題。這唯獨(dú)對軟件開發(fā)人員來說不是個好消息。戰(zhàn)略職能他們評估和指導(dǎo)軟件項目經(jīng)理應(yīng)該如何應(yīng)用最好的方法、工具、技術(shù)以及軟件來成功完成開發(fā)團(tuán)隊的目標(biāo)。所以通常意義上的 PMO 可能包含各式各樣的職責(zé)，有一些如上所述，也有一些本文未提及的獨(dú)特職責(zé)。如果不這么做，你極有可能會被各類不適合的方法、文檔需求和規(guī)程所拖累。我喜歡草坪總是綠茵茵的，于是便讓灑水系統(tǒng)每天自動為其澆水。①周六上午是不是在上