第十四——十七章做業

時間 2019-12-11

標籤第十四十七简体版

原文原文鏈接

第十四章

15.3.1 有些成功人士或公司認爲不須要獨立的測試角色（Test），你怎麼看？

答：在一些軟件公司中，QA的工做中包含了Test的角色，負責驗證程序是否符合預先設計的功能和特性。可是QA的工做量是不少的，一個好的QA不只須要對程序架構有着很好的理解，對程序功能和性能都有着較深的理解，而且要對測試工程瞭如指掌，如測試用例、MTTF等不少方面。程序員

若是QA人員可以很好地完成工做，是能夠的，可是細化分工可以使得每一個人專於一部分，更好地提高團隊效率。數據庫

15.3.2 爲何一些成功的公司不用測試人員？

答：一些成功的公司中，軟件開發人員的我的能力很強，可以保證自身代碼的有效性。可是這要求開發人員充分信任本身的代碼，而且本身對代碼進行了很詳盡的測試。可是若是開發人員不能有效測試代碼，或者不肯意測試代碼，那麼須要測試人員來進行這項工做。編程

15.3.3 微軟是怎麼作的呢？

答：微軟的開發測試只要有三種角色：網絡

SDE：Software Design Engineer，簡稱dev。架構

SDE/T：Software Design Engineer in Test，也寫代碼，可是重點在測試。運維

STE：Software Test Engineer。編程語言

15.3.4 團隊應該如何安排QA 和測試工做？

答：QA是質量保證，是對軟件製做過程當中的製做質量進行管理，強調控制和評估。軟件測試是對軟件產品的質量自己進行測試，是從技術方面出發測試軟件質量，屬於Life cycle的一部分，更準確的說法應該是QC。。工具

在工做安排上，測試關注的更可能是被測對象上線前的質量，而QA關注的是宏觀意義上的質量，包括開發環節的質量控制（如何提升代碼自己質量）、測試環節、上線環節以及運維環節（如線上出現問題後如何快速止損），甚至還包括用那種開發模式能更有效的提高項目開發質量和效率，於是是一個更寬泛的領域。性能

15.3.5 測試人員的職業發展

答：查閱一些資料，測試人員的職業發展能夠分爲如下幾個階段：學習

初級測試工程師

　　剛入門的擁有科學學位的我的或具備一些手工測試經驗的我的。開發測試腳本並開始熟悉測試生存週期和測試技術。

測試工程師/程序分析員

　　具備1-2年經驗的測試工程師或程序員。編寫自動測試腳本程序並擔任測試編程初期的領導工做。進一步拓展編程語言、操做系統、網絡與數據庫方面的技能。

高級測試工程師/程序分析員

　　具備3-4年經驗的測試工程師或程序員。幫助開發或維護測試或編程標準與過程，負責同級的評審，併爲其它初級的測試工程師或程序員充當顧問。繼續拓展編程語言、操做系統、網絡與數據庫方面的技能。

測試組負責人

　　具備4-6年經驗的測試工程師或程序員。負責管理1至3名測試工程師或程序員。擔負一些進度安排和工做規模/成本估算職責。更集中於技能方面。

測試/編程負責人

　　具備6-10年經驗的測試工程師或。負責管理8至10名技術人員。負責進度安排、工做規模/成本估算、按進度表和預算目標交付產品。負責開發項目的技術方法。爲一些用戶提供支持與演示。開發一些特定領域的技術專長

測試/質量保證/開發(項目)、經理

　　具備10多年的工做經驗。管理8名或更多的人員參加的1個或多個項目。負責這一領域(測試/質量保證/開發)內的整個開發生存週期業務。爲一些用戶提供交互和大量演示。負責項目成本、進度安排、計劃和人員分工

計劃經理

　　具備15年以上開發與支持(測試/質量保證)活動方面的經驗。管理從事若干項目的人員以及整個開發生存週期。負責把握項目方向與盈虧責任。

我的觀點是，在入行前，即工做前的1年時間內，選擇一個大的入門方向；入行後的3~12個月，應該學習基本知識，如黑盒、白盒、自動化測試、測試工具等技能，培養測試、質量和項目管理的經驗；入行後3~5年，根據選定方向，提高本身技能，根據管理或技術方向儘可能作到全面、熟練；在入行5~10內，提高本身宏觀把握能力，考慮長遠的發展計劃。

15.4 如何衡量軟件工程的質量

答：除卻鄒老師提出的這些觀點，我認爲還能夠從如下這些方面衡量代碼：

設計/開發約束：在軟件開發過程當中，許多設計約束和準則對於代碼的可維護性和可讀性都相當重要；
環路複雜度：對於代碼實現和執行過程當中，不一樣方法的環路複雜度不一樣；
Bug的嚴重程度與數量：不一樣的Bug的嚴重程度不一樣，咱們可以容許小Bug或小異常的出現，可是對於嚴重的Bug則屬於不可原諒的。

第十五章

15.1 案例分析

答：根據書中的例子，推斷出兩個團隊的血型：

STG遊戲的跳票（爲了完美，推遲了7天，可是7天以後也沒有發佈……）：O型或B型

英語學習軟件（說了「明早發佈」，可是明早一直沒到）：O型

15.3.1 反動分子阿超

答：阿超的作法是可取的，由於在穩定階段，不適合對整個項目進行大的修改或增長工做，能夠先行發佈一個Alpha版本，後續發佈Beta版本、RC、RTM來不斷完善。可是須要對後續版本的工做明肯定義，不能只是簡單的推脫工做。

15.3.2 銀彈之戰

答：我以爲是有必定做用的，由於首先簡單的爭論是會不容易上升到銀彈程度的，而複雜的問題你們討論好久可能仍是誰也不能說服誰，因此銀彈政策可以在討論的基礎上節省時間。

可是，作項目有一個原則是：若是不一樣意那麼在拍板前必定堅定抗議，一旦決定就不要再提意見。

15.3.3 扁鵲三兄弟

答：分析丹佛機場行李系統：

項目需求：因爲丹佛市原有機場能力有限，須要新建一個機場。新機場有3箇中央大廳，2號中央大廳使用方「美國聯合航空公司」委託「BAE公司」爲其開發自動化行李處理系統。

對於這個項目，乙方估計時間爲2年半內完成，一開始事情都很順利。可是，丹佛市負責新機場建設的小組認爲若是可以假設一個同時爲3箇中央大廳同時使用的集成自動化行李處理系統是一個頗有意義的事情。因此，他們說服原航空公司自行建設的方案，轉而由BAE公司建設整個機場的集成自動化行李處理系統。

BAE做爲在領域內全球最爲頂尖的公司，提出如下這些問題：

* 缺乏安裝行李系統所需的足夠空間
　　 * 建築結構沒法承受行李系統所附加的重量
　　 * 缺乏行李處理系統所需的穩定的電力
　　 * 缺乏消除行李處理系統散發的熱量的通風和空調設施

爲了解決這些問題，提出如下條件：

* 上述的風險都將被做爲項目可否順利完成的重要里程碑
　　 * 超出預訂日期以後的需求或設計變動不被接受，而且需求和設計須要有一段凍結期
　　 * BAE公司在整個新機場的施工現場擁有最高的優先權，包括場地的佔用、工做順序的安排等

雖然BAE公司從專業的角度意識到風險而且明確地提出來，可是因爲項目任務過於龐大，影響因素太多，在前後通過PM辭職、需求變動頻繁、首席工程師去世等事件，並不能按要求完成任務，從而引發了項目的失控。最終美聯航承租的2號中央大廳，仍將由BAE公司建設自動化行李處理系統，大陸航空公司承租的1號中央大廳均使用傳統的拖車系統。

經過分析整個事件，咱們不難發現需求過多、系統過於龐大無疑是主要問題之一。衆所周知，越龐大的項目需求就越複雜，不可控因素越多，也越容易失控。管理層的變更也是影響因素之一，由於通常狀況下，失控項目最初是由項目團隊發現的、甚至是管理層發現的。此外，太高的性能要求，如實時、大規模愈來愈稱爲影響項目的最終成功的問題；最終，大型的涉及到集成的應用，則越容易失控。

第十六章

IT行業的創新練習與討論

16.6.1 VCD的創新

答：先行者如何把技術領先變爲市場領先：

1.先行者善於發現機遇，把握機遇

2. 先行者在研發前進行了市場調研，瞭解消費者需求

3．先行者勇於投資

4. 先行者進行反覆試驗，反覆研發

若是我是競爭者

1. 我會購買一臺萬燕VCD做爲解剖樣機

2. 在樣機基礎上進行進一步的研發與創新，發展更多功能

3. 多進行市場調研，把握消費者需求

16.6.2 BBS的創新

答：Stack Overflow以前是以程序開發爲主題的論壇，現在Stack Overflow做爲Stack Exchange network的子站，已經發展成爲擁有43個主題討論區的社區。

Stack Overflow成功的祕訣在於始終如一地推崇高質量的內容，並對服務進行意義明確的垂直劃分。而後得到了許多貢獻優質內容的用戶，Stack Overflow也得以優化問答服務流程，這樣，能夠實現對少部分用戶進行收費。和其餘問答服務網站不一樣的是，Stack Overflow對用戶提問進行嚴格篩選，淘汰那些容易產生主觀答案或難以產生高質回答的問題，網絡社區管理員和成員都能投票刪掉那些不合適的提問或者對提問進行修改和完善。

16.6.3 《夢斷代碼》大目標和遠景

答：做爲創新參考

16.6.4 討論微軟公司Xbox Kinect的創新，它是如何知足玩家需求的，給微軟公司帶來了多少營收，對所在行業的影響如何。

答：它是一種3D體感攝影機，同時導入了即時動態捕捉、影像辨識、麥克風輸入、語音辨識、社羣互動等功能。玩家能夠經過這項技術在遊戲中開車、與其餘玩家互動、經過互聯網與其餘Xbox玩家分享圖片和信息等。

Xbox Kinect採用最新的計算機圖像處理技術，實現人的動態撲捉，將人和遊戲結合，並進行實時反饋使玩家身臨其境。知足玩家的互動感和代入感需求，不須要經過輸入設備，人的自身就是遊戲輸入設備，能夠得到更直接的體驗。

微軟CEO 鮑爾默18日在舊金山舉辦的Web 2.0高峯會上指出，今年假期旺季微軟將針對Kinect、XBox推出一系列的重要創新。微軟表示，Xbox 360銷售量市佔率達42%，已連續第7個月高於40%。Xbox 360已屢次成爲全美最暢銷的遊戲機。微軟指出，過去16個月當中Xbox 360有15個月是美國遊戲機單月銷售量冠軍。

微軟認爲這種無遙控器式的系統將爲電玩體驗掀起革命。它同時表示人臉辨識功能將讓電玩人物可以和玩家透過表情來溝通，所以遊戲終將加入更多社交經驗於內。

16.6.5 練習創新的招數

答：1.市場調研並分析客戶以及潛在客戶的進一步需求。

2.積極研發，進行技術創新。

3.對其進行新的設計，內部科技與外觀雙方面。

4.聘用更好的廣告團隊，採起更積極的宣傳方式。

16.6.6 軟件工程的技術和實踐如何幫助創新

答：好比以結對編程的合做方式來共贏互惠，經過合做來提升共同的工做效率，得到更完美的工做成果。

16.6.7 創業-堅持前進的方向VS嘗試更多新的想法

答：我在創業，可是市面上和個人朋友圈又流傳更cool 的想法和創新。

做爲創業者，我要深入思考這些新的想法的創新對個人創業有沒有幫助和促進。若是是有幫助的，那麼就把他們的cool想法吸取進來，爲個人事業發展更添一塊磚。這個新的想法創新是對個人創業沒有什麼實質性幫助的，那麼我還要堅決本身的研發道路，同時注意本身的研發過程會不會出現與這些新想法同類型的錯誤，這樣不斷自我檢討，前進發展。

第十七章

人，績效和職業道德

1比較不一樣團隊的績效評估方法，提出本身團隊的績效評估計劃

答：案例中五個小組的績效評估方法各有利弊，咱們團隊的績效評估計劃介於第一種和第五種之間，既分配好每一個人應作的任務和責任，又要造成以重要成員爲中心的明星效應，以此來評估團隊績效。

2. 在團隊中會不會出現「劣幣驅逐良幣」的現象？

答：在團隊合做中確實有可能會出現這種很差的現象，這就須要咱們全部團隊成員一塊兒堅決不移地貫徹校訓的思想：實事求是。一切從實際出發，用事實說話。

3. 討論團隊如何能讓全部人都明確驅動和責任？

答：在一個責任驅動型團隊內部，全部成員的職責都很肯定，分工明確。團隊在完成工做時，表現出的就是分工協做，各司其職，團隊氣氛輕鬆和諧，不多或幾乎沒有內耗，是較高級的團隊組織管理形態。

爲了保持這種管理形態必需要堅持幾點原則：

原則1 每一個責任都有人負責；每一個責任都只有一我的負責。團隊承擔的全部責任，應當都能找到具體負責的人，團隊全部人承擔的責任之和，就是團隊在組織內部承擔的責任。

原則2 權責利、義務、能力和崗位名稱要匹配。權責利要統一不少人都知道，可是在責任驅動型團隊中，強調的是權責利、義務、能力和崗位。

原則3 別人的責任，不要擅自去承擔，團隊應當作到每一個成員都瞭解彼此承擔的責任。

原則4 幫助原則。當你看到別人須要幫助，或當你收到別人的幫助請求時，你在確保不耽誤本身履職的狀況下，給予了他人幫助。而不能出現你幫助了別人，結果本身的責任沒承擔好的狀況。

原則5 分歧處理原則。若是你以爲你的同事作得不對，請當面告訴他你的建議，而不是背後去告訴他的上級。

原則6 衛兵原則。衛兵的職責是確保每一個通行者都有通行證，他的權力是阻止沒有通行證的人通行。所謂的衛兵原則是，衛兵的上級領導有擼掉衛兵的權力，可是他沒有權力干涉衛兵履職，即要求衛兵放行一個沒有通行證的人。

4. 採訪並收集下面幾類公司對員工績效考覈的作法：

答：採訪

5. 走出「自我」和「當下」

答：我以爲這些活動是有價值的

人類是社會性的動物，尤爲在這個高度發達的信息社會，不可能將本身封閉起來不問世事。在一個軟件團隊工做，只考慮到「自我」，不考慮「別人」是不行的。一樣，有些同窗得過且過，只看到「當下」，不放眼「將來」的心態也是不積極的。

在成功的大型企業中，人際交流能力和人際覺察是員工素質培訓的一個重要部分，它包括如何與別人創建平等而融洽的合做關係，如何處理矛盾與衝突，如何影響同事，如何給別人的工做作評價，如何能瞭解別人表面行動下的言外之意、隱含的動機等等。這正是很多在校學生所缺陷的部分，而課堂上這些活動能夠彌補這個缺陷，因此我以爲它們是很是必要的。