2.3團隊組織關(guān)系
一個項目中的兩種角色安排的三種可能的關(guān)系,他們是:
1 產(chǎn)品負(fù)責(zé)人和技術(shù)主管是同一個人。這種方式非常容易應(yīng)用在很小型的隊伍中,可能是三個或六個開發(fā)人員。在大型的項目中則不容易得到應(yīng)用。原因有兩個:第一,同時具有管理技能和技術(shù)技能的人很難找到。思考者很少,實干家更少,思考者-實干家太少了。第二,大型項目中,每個角色都必須全職工作,甚至還要加班。對負(fù)責(zé)人來說,很難在承擔(dān)全部管理責(zé)任的同時,還能抽出時間進行技術(shù)工作。對技術(shù)主管來說,很難在保證設(shè)計的概念完整性,沒有任何妥協(xié)的前提下,擔(dān)任管理工作。
2 產(chǎn)品負(fù)責(zé)人作為總指揮,技術(shù)主管充當(dāng)其左右手。這種方法有一些困難。很難在技術(shù)主管不參與任何管理工作的同時,建立在技術(shù)決策上的權(quán)威。顯然,產(chǎn)品負(fù)責(zé)人必須預(yù)先聲明技術(shù)主管的技術(shù)權(quán)威,在即將出現(xiàn)的絕大部分測試用例中,他必須支持后者的技術(shù)決定。要達到這一點,產(chǎn)品責(zé)任人和技術(shù)主管必須在基本的技術(shù)理論上具有相似觀點;他們必須在主要的技術(shù)問題出現(xiàn)之前,私下討論它們;產(chǎn)品責(zé)任人必須對技術(shù)主管的技術(shù)才能表現(xiàn)出尊重。
3 技術(shù)主管作為總指揮,產(chǎn)品負(fù)責(zé)人充當(dāng)其左右手。這種組合可以使工作很有效。不幸的是它很少被應(yīng)用。不過,它至少有一個好處,即項目經(jīng)理可以使用并不很擅長管理的技術(shù)天才來完成工作。
2.4團隊組成
在一個大型項目中,軟件項目經(jīng)理必須為成員良好的分工,組成有層次的結(jié)構(gòu)。
系統(tǒng)結(jié)構(gòu)師,從上至下地進行所有的設(shè)計。要使工作易于管理,必須清晰地劃分體系結(jié)構(gòu)設(shè)計和實現(xiàn)之間的界線,系統(tǒng)結(jié)構(gòu)師必須一絲不茍地專注于體系結(jié)構(gòu)。
首席程序員。他親自定義功能和性能技術(shù)說明書,設(shè)計程序,編制源代碼,測試以及書寫技術(shù)文檔。
程序職員。他負(fù)責(zé)維護編程產(chǎn)品庫中所有團隊的技術(shù)記錄。
編輯、秘書。首席程序員負(fù)責(zé)產(chǎn)生文檔。而編輯進行分析和重新組織,提供各種參考信息和書目,對文檔多個版本進行維護以及監(jiān)督文檔生成的機制。
工具維護人員。測試人員。
3. 團隊交流
3.1手冊、或者書面規(guī)格說明
手冊是產(chǎn)品的外部規(guī)格說明,它描述和規(guī)定了用戶所見的每一個細(xì)節(jié);同樣的,它也是結(jié)構(gòu)師主要的工作產(chǎn)物。
隨著用戶和實現(xiàn)人員反饋的增加,規(guī)格說明中難以使用和難以構(gòu)建實現(xiàn)的地方不斷被指出,規(guī)格說明也不斷地被重復(fù)準(zhǔn)備和修改。然而對實現(xiàn)人員而言,修改的階段化是很重要的——在進度表上應(yīng)該有帶日期的版本信息。
手冊不但要描述包括所有界面在內(nèi)的用戶可見的一切,它同時還要避免描述用戶看不見的事物。后者是編程實現(xiàn)人員的工作范疇,而實現(xiàn)人員的設(shè)計和創(chuàng)造是不應(yīng)該被限制的。體系結(jié)構(gòu)設(shè)計人員必須為自己描述的任何特性準(zhǔn)備一種實現(xiàn)方法,但是他不應(yīng)該試圖支配具體的實現(xiàn)過程。
規(guī)格說明的風(fēng)格必須清晰、完整和準(zhǔn)確。用戶常常會單獨提到某個定義,所以每條說明都必須重復(fù)所有的基本要素,所以所有文字都要相互一致。這往往使手冊讀起來枯燥乏味,但是精確比生動更加重要。
3.2周例會
周例會由所有的結(jié)構(gòu)師,加上硬件和軟件實現(xiàn)人員代表和市場計劃人員參與,由首席系統(tǒng)結(jié)構(gòu)師主持。
會議中,任何人可以提出問題和修改意見,但是建議書通常是以書面形式,在會議之前分發(fā)。新問題通常會被討論一些時間。重點是創(chuàng)新,而不僅僅是結(jié)論。該小組試圖發(fā)現(xiàn)解決問題的新方法,然后少數(shù)解決方案會被傳遞給一個和幾個結(jié)構(gòu)師,詳細(xì)地記錄到書面的變更建議說明書中。
接著會對詳細(xì)的變更建議做出決策。這會經(jīng)歷幾個反復(fù)過程,實現(xiàn)人員和用戶會仔細(xì)地進行考慮,正面和負(fù)面的意見都會被很好地描述。如果達成了共識,非常好;如果沒有,則由首席結(jié)構(gòu)師來決定。這需要花費時間,終所發(fā)布的結(jié)論是正式和果斷的。
這種會議的卓有成效是由于:
1.每周交流一次。因此,大家對項目相關(guān)的內(nèi)容比較了解,不需要額外培訓(xùn)。
2.上述小組十分睿智和敏銳,深刻理解所面對的問題,每個人都要承擔(dān)義務(wù)。
3.當(dāng)問題出現(xiàn)時,在界線的內(nèi)部和外部同時尋求解決方案。
4.正式的書面建議強制了決策的制訂,避免了會議草稿紀(jì)要方式的不一致。
5.清晰地授予首席結(jié)構(gòu)師決策的權(quán)力,避免了妥協(xié)和拖延。
3.3電話日志(交流日志,BBS等記錄)
隨著實現(xiàn)的推進,無論規(guī)格說明已經(jīng)多么精確,還是會出現(xiàn)無數(shù)結(jié)構(gòu)理解和解釋方面的問題。顯然有很多問題需要文字澄清和解釋,還有一些僅僅是因為理解不當(dāng)。討論和解決,在BBS上做出記錄。問題的答案(對問題的認(rèn)識或者想法記錄下來)必須是可以告知每個人的權(quán)威性結(jié)論。
3.4質(zhì)量會議
項目經(jīng)理好的朋友是他每天要面對的敵人——獨立的產(chǎn)品測試機構(gòu)/小組。該小組根據(jù)規(guī)格說明檢查機器和程序,充當(dāng)麻煩的代言人,查明每一個可能的缺陷和相互矛盾的地方。每個開發(fā)機構(gòu)都需要這樣一個獨立的技術(shù)監(jiān)督部門,來保證其公正性。
4. 為變化組織架構(gòu)
每個人被分派的工作必須是多樣的、富有拓展性的工作,從技術(shù)角度而言,整個團隊可以靈活地安排。
當(dāng)系統(tǒng)發(fā)生變化時,管理結(jié)構(gòu)也需要進行調(diào)整。管理人員和技術(shù)人才的能力給予培養(yǎng),使管理人員和技術(shù)人才具有互換性。
管理人員需要參與技術(shù)課程,高級技術(shù)人才需要進行管理培訓(xùn)。項目目標(biāo)、進展、管理問題必須在人員整體中得到共享。