我的做業3——我的總結（Alpha階段）

 

1、 總結本身的alpha 過程

1.團隊的總體狀況

在alpha階段，整個團隊完成效果很差，進度比較慢，隊員狀態比較差，有時候進度幾乎爲零，還好最後仍是可以完成部分功能。

2.我作了哪些工做

在團隊中我是PM，不算合格，沒有很好督促隊員各自任務完成的進度，在分配任務中有時候比較拖。作的一些工做包括：每次團隊博客的整合彙總，三次衝刺博客；web界面原形設計；web網頁開發。

3.我是否完成了pm分配的任務

完成PM分配的所有任務

4.不足的地方

做爲PM不夠主動，沒有很好的組織起隊員，組織能力欠缺。

5.對團隊的建議

及時分配工做，及時完成各自的任務，更重要的是要互相督促，提升責任心。

2、提出問題（軟件工程）

1. 在第4章兩人合做，有講到同伴複覈代碼。發現邏輯錯誤。感受這個實現起來比較難，一我的編程代碼，本身有本身編寫代碼的邏輯和思惟，另外一我的要去複覈其餘人的邏輯這比較困難，若是真的能實現的話，我以爲也應該是創建在互相十分熟悉對方的狀況下的。

2. 在第6章敏捷流程，連續7七天的站立會議，明天都要有進度，根據咱們本身的狀況來講，這樣的作法不太合理，天天都有課程要去上，而且每一個課程都有實驗要作，已經大三了，每一個人都有本身的之後的方向和地位，全部有本身的時間安排，何況對於開發人員來講，編程代碼會花費不少時間，並且之後不從事程序員方面，這樣會不會是給本身加壓又沒什麼幫助呢？

3. 在第8章中說提出的需求分析和用戶調查。若是有一小部分用戶的需求是比較特殊的。那麼是應知足仍是跟隨大部分用戶的需求而設計，摒棄小部分用戶的要求？

4. 在第9章項目經理PM，我有個疑問，要想當一個合格的PM，是否應該具有比團隊成員更強大的編程能力或者編程經驗？

5. 在第12章用戶體驗，軟件服務始終都要記住用戶的選擇，重視用戶的體驗，可是要是開發人員達不到用戶的選擇和體驗，知足不了用戶的選擇和體驗，那麼這個項目是否應該放棄或者從新開發呢？

3、自我評價                         

（e）   1.保持高標準，不要受制於破窗理論(broken windows theory)^[i]。 當你看到不靠譜的設計、糟糕的代碼、過期的文檔和測試用例的時候，不要想 「既然別人的代碼已經這樣了，個人代碼也能夠隨便一點啦。」

   　　a) 歷來沒據說過；   b) 我就是這樣隨便過來的；  c) 若是有明確要求，我能夠作好。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（e）   2. 主動解決問題。當看到不靠譜的設計，糟糕的代碼的時候，不要想「可能別人會來管這個事情」 ，或者「我下個月發一個郵件讓你們討論一下」。要主動地把問題給解決了^[ii]。

   　　a) 不懂啥是靠譜的設計；   b) 隨便應付一下便可；  c) 若是有明確要求，我能夠作好。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（c）   3. 常常給本身充電，身體訓練是運動員生活的一部分，學習是軟件工程師職業的伴侶。每半年就要了解和學習一些新的相關技術。經過按期分享（面對面的分享，寫技術博客等）來確保本身真正掌握了新技術。

  　　 a) 歷來不看書；   b) 看了就忘；  c) 有時分享。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好 

（c）  4.  DRY （Don't Repeat Yourself）——別重複。在一個系統中，每個知識點都應該有一個無異議的、正規的表現形式。

 　　  a) 歷來沒據說過；   b) 據說過，可是認爲意思不大；  c) 這要講場合。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（c）  5.  消除不相關模塊之間的影響，在設計模塊的時候，要讓它們目標明確並單一，能獨立存在，沒有不明確的外部依賴。

   　　a) 歷來沒據說過；   b) 出了問題再說吧；  c) 想作，可是不知道怎麼衡量效果。  d) 可以在多種語言和架構中作到     e) 不但主動作， 還會影響同事一塊兒作好

（c）  6.  經過快速原型來學習，快速原型的目的是學習，它的價值不在於代碼，而在於你經過快速原型學到了什麼。

   　　a) 歷來沒據說過；   b) 把原型直接用於產品，否則就浪費了；  c) 不用原型，一直在產品中直接改。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好 

（d）  7.  設計要接近問題領域，在設計的時候，要接近你目標用戶的語言和環境。

  　　 a) 歷來沒據說過；   b) 按個人想法設計，用戶之後會適應的；  c) 大概贊成，可是怎麼接近用戶呢？  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好 

（b）  8.  估計任務所花費的時間，避免意外。在開始工做的時候，要作出時間和潛在影響的估計，並通告相關人士，避免最後關頭意外發生。工做中要告知可能的時間變化，過後要總結。

   　　a) 作完了，就知道花費了，不用事先估計；   b) 大概估一下，沒必要在乎時間   c) 若是有明確要求，我能夠作好。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（c）  9.  圖形界面的工具備它的長處，可是不要忘了命令行工具也能夠發揮很高的效率，特別是能夠用腳本構建各類組合命令的時候。

  　　 a) 一直用鼠標和GUI；   b) 到時候問牛人；  c) 正在學習命令行工具。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（c）  10. 有不少代碼編輯器，請把其中一個用得很是熟練。讓編輯器能夠實現本身的定製，能夠用腳本驅動，用起來駕輕就熟。

   　　a) 只用老師教的一個；   b) 隨意；  c) 沒有任何定製。  d) 會定製，而且分享給其餘人     e) 還會學習和使用各類編輯器的擴展。

 （d） 11. 理解經常使用的設計模式，並知道擇機而用。設計模式不錯，更重要的是知道它的目的是什麼，何時用，何時不用。

   　　a) 歷來沒據說過；   b) 模式沒用；  c) 每寫100行程序，我就儘可能用一個模式。  d)有實際使用的經驗     e) 能用具體代碼說明模式的利弊

 （a）   12. 代碼版本管理工具是你代碼的保障，重要的代碼必定要有代碼版本管理。

   　　a) 歷來沒據說過；   b) 用QQ，u盤便可；  c) 領導要求才用。  d) 常常用     e) 不但主動作， 還會影響同事一塊兒作好

 （b）   13. 在debug的時候，不要驚慌，想一想致使問題的緣由可能在哪裏。一步一步地找到緣由。要在實踐中運用工具，善於分析日誌（log），從中找到bug。同時，在本身的代碼裏面加 log.

   　　a) 歷來沒據說過；   b) 只會printf；  c) 加log 太麻煩，個人代碼不會有bug 的。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（c）  14. 重要的接口要用形式化的「合同」來規定。用文檔和斷言、自動化測試等工具來保證代碼的確按照合同來作事，很少也很多。使用斷言 (assertion) 或者其餘技術來驗證代碼中的假設，你認爲不可能發生的事情在現實世界中每每會發生。

  　　 a) 歷來沒據說過；   b) 太麻煩，不用；  c) 想用，但沒有時間。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好 

（d）  15. 只在異常的狀況下才使用異常 (Exception),  不加判斷地過多使用異常，會下降代碼的效率和可維護性。記住不要用異常來傳遞正常的信息。

   　　a) 歷來沒據說過；   b) 抓住全部異常  c) 若是有明確要求，我能夠作好。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好 

（c）  16. 有始有終。若是某個函數申請了空間或其餘資源，這個函數負責釋放這些資源。

   　　a) 歷來沒據說過；   b) 隨緣；  c) 有時這樣作。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（c）  17. 當你的軟件有多種技術結合在一塊兒的時候，要採用鬆耦合的配置模式，而不是要把全部代碼都混到一塊兒。

   　　a) 歷來沒據說過；   b) 沒有實踐的機會；  c) 代碼都在一塊兒比較好管理。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（c）  18. 把經常使用模塊的功能打形成獨立的服務，經過良好的界面 (API) 來調用不一樣的服務。

 　　  a) 歷來沒據說過；   b) 拷貝代碼過來用也能夠  c) 若是有明確要求，我能夠作好。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（d）  19. 在設計中考慮對並行的支持，這樣你的API 設計會比較容易擴展。

 　　  a) 歷來沒據說過；   b) 並行不會出錯的；  c) 任何代碼都應支持並行。  d) 考慮在適當的層次支持並行     e) 不但主動作， 還會影響同事一塊兒作好

（d）  20. 在設計中把展示模塊 (View) 和實體模塊 (Model) 分開，這樣你的設計會更有靈活性。 

  　　 a) 代碼都在一塊兒比較好改；   b) 隨緣啦；  c) 沒搞清楚啥是V，啥是M。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（b）  21. 重視算法的效率，在開始寫以前就要估計好算法的效率是哪個數量級上的（big-O）。

  　　 a) 歷來沒據說過；   b) 個人數據量不大，無所謂；  c) 不會有效率問題的，如今CPU 都快了。  d) 主動測試程序效率，以驗證估算     e) 不但主動作， 還會影響同事一塊兒作好

（b）  22. 在實際的運行場景中測試你的算法，不要停留在數學分析層面。有時候一個小小的實際因素 (是否支持大小寫敏感的排序，數據是否支持多語言)會致使算法效率的巨大變化。

 　　  a) 歷來沒據說過；   b) 想用，但不知道工具  c) 主要靠肉眼觀察算法效率。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（a）  23. 常常重構代碼，同時注意要解決問題的根源。

   　　a) 歷來沒據說過；   b) 任何修改均可以叫重構；  c) 天天應該重構兩次。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（c）  24. 在開始設計的時候就要考慮如何測試 ，若是代碼出了問題，有log 來輔助debug 麼? 儘早測試，常常測試，爭取實現自動化測試，爭取每個構建的版本都能有某些自動測試。

   　　a) 歷來沒據說過；   b) 個人代碼不會出問題的；  c) 項目沒有安排時間，我也沒有提這事。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（b）  25. 代碼生成工具能夠生成一堆一堆的代碼，在正式使用它們以前，要確保你能理解它們，而且必要的時候能debug 這些代碼。

  　　 a) 歷來沒據說過；   b) 歷來不看那些代碼；  c) 那些代碼沒有bug。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（c）  26. 和一個實際的用戶一塊兒使用軟件，得到第一手反饋。 

  　　 a) 歷來沒據說過；   b) 用戶太蠢，不值得聽反饋；  c) 想作可是沒有機會。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（c）  27. 在自動測試的時候，要有意引地入bug，來保證自動測試的確能捕獲這些錯誤。

   　　a) 沒據說過；   b) 沒必要這麼麻煩；   c) 若是有明確要求，我能夠作好。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（d）  28. 若是測試沒有作完，那麼開發也沒有作完。

   　　a) 歷來沒據說過；   b) 簽入代碼，就是作完了；  c) 。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（a）  29. 適當地追求代碼覆蓋率：每一行的代碼都覆蓋了，可是程序未必正確。要確保程序覆蓋了不一樣的程序狀態和各類組合條件。

   　　a) 歷來沒據說過；   b) 覆蓋20% 就行了；  c) 要覆蓋至少60%。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（d）  30. 若是團隊成員碰到了一個有廣泛意義的bug,  應該創建一個測試用例抓住之後將會出現的相似的bug。

   　　a) 歷來沒據說過；   b) 每一個bug都是特殊的；  c) 測試用例不值得加  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（c）  31. 測試：多走一步，多考慮一層。若是程序運行了一星期不退出，若是用戶的屏幕分辨率再提升一個檔次，這個程序會出什麼可能的錯誤?

  　　 a) 歷來沒據說過；   b) 若是有問題，用戶會報告的，咱們不用測這些；  c) 若是有明確要求，我能夠作好。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（c）  32. （帶領團隊）瞭解用戶的指望值，稍稍超出用戶的指望值，讓用戶有驚喜。

   　　 a) 歷來沒據說過；   b) 咱們決定用戶的指望；  c) 若是有明確要求，我能夠作好。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（c）  33. （帶領團隊） 不要停留在被動地收集需求，要挖掘需求。真正的需求可能被過期的假設、對用戶的誤解或其餘因素所遮擋。

   　　a) 歷來沒據說過；   b) 用戶不說的，咱們不作；  c) 若是有明確要求，我能夠作好。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（c）  34. （帶領團隊）把全部的術語和項目相關的名詞、縮寫等都放在一個地方。

   　　a) 歷來沒據說過；   b) 都記在我腦子裏；  c) 你們看代碼就好  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（c）  35. （帶領團隊）不要依賴於某我的的手動操做，而是要把這些操做都作成有相關權限的人士都能運行的腳本。這樣就不會出現由於某人休假而項目被卡住的狀況。

  　　 a) 歷來沒據說過；   b) 咱們沒有休假的，不要緊；  c) 出了問題再說  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（b）  36. （帶領團隊）要讓重用變得更容易。一個軟件團隊要創造一種環境，讓你們有輕鬆的心態來嘗試各類想法 （例如，模塊的重用，效能的提高，等）。

  　　 a) 都聽領導的；   b) 團隊嚴肅緊張最好；  c) 沒必要嘗試，失敗的可能性太大。  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

（d）  37. （帶領團隊）在每一次迭代以後，都要總結經驗，讓下一次迭代的進度安排更可靠，質量更高。

   　　a) 沒有時間總結，直接作下一版；   b) 總結用處不大；  c) 若是上級有要求，就作一下；  d) 一直主動這樣作     e) 不但主動作， 還會影響同事一塊兒作好

4、計劃

在第一階段的不足但願在第二階段能過彌補過來，改正本身的拖延症。