一、alpha 過程總結
1.作為我們小組的組長，第一階段的沖刺讓我收獲良多。雖然我們並沒有把我們原先計划的卡片做完，但在這七天的實際沖刺過程中，我們又發現了許多我們在沖刺之前所沒有預想到的功能。因此，從實際上來說，其實我們是超額完成任務的，而且是超了不少；
2.在我看來，我們小組在alpha階段沖刺過程中最正確的選擇就是堅持每天收集用戶的最新反饋。因為我們在每天完善功能之后，都會繼續把完善好的四則運算軟件發給一些朋友使用，讓他們繼續幫我們測試、提建議，所以我們的APP實際上每天都在進步，每天都在往更加符合用戶需求的路上前進。而且，在這個反饋的過程中我們還發現了許多新的功能點，這些是我們最開始沒有想到的然后在做的過程中又慢慢摸索到的，這也使得我們的軟件越來越完善，越來越能夠滿足用戶的需求；
3.但反過來說，我們本次沖刺的一大弊端就是早期的用戶需求調查不到位，先前的需求分析有點過於想當然，沒有落地去考察真正需要的對象，造成我們一開始對這個軟件的功能定位存在偏差，導致之后在不斷完善的過程中產生了大量本可以避免的工作。好在老師們及時指出我們需求分析的漏洞，讓我們下定決心去切實落實需求分析，我們才能找到小學數學老師以及個別家長對我們提建議，才有了我們每天完善的四則運算APP；
4.就我個人而言，本次沖刺我還是十分滿意的。本次沖刺我們已經基本上完成了最開始時設想的功能，出題、復習、計時功能都已經實現，同時還把原來限定的1~10以內的題目擴展到任意數量的題目。錯題復習方面，即使還不能做到生成任意數目，但已經可以實現在200道題目以下的任意數目，這個對於實際使用中其實已經是夠用的，但我們還是會繼續完善。我們在用戶調研的過程中還新增了彈窗提醒的功能，這可以幫助用戶對自己的水平有更准確地定位。總而言之，我對我們團隊第一次沖刺的成果非常滿意，我們會繼續努力的。
二、對軟件工程的五個問題
1.關於“結對編程”
《構建之法》書中4.5章節中對結對編程形式有以下的形容：
“在結對編程模式下，一對程序員肩並肩、平等地、互補地進行開發工作。他們並排坐在一台電腦前，面對同一個顯示器，使用同
一個鍵盤、同一個鼠標一起工作。”
然而我現在仍然不是太理解“結對編程”這個編程模式，我承認這種模式有它的優勢，但不可否認的是，這種編程模式有一種浪費資源的嫌疑。大部分同學都跟我一樣，在剛剛開始接觸結對編程的時候都以為是兩個同學為一組，分別完成實現不同功能的代碼，然后匯總在一起，完成整個程序。后來在老師再三強調之后才發現，原來是兩個人同時做同樣的事情，一個做一個審。但是我真的覺得這個編程模式很浪費資源，明明兩個人可以各做一半，為什么非要兩個人一起做一樣的東西呢，這不是浪費時間嗎？而且像我們以前的課程設計或者說IT企業里的小團隊，大家更多的都是使用明確分工的工作模式，一人負責一個模塊的內容，很少聽說哪個團隊的每個人都在一起完成某個單項功能，這非常有可能使效率變得非常非常低下。
2.關於“PSP”
《構建之法》書中2.3章節中對PSP有以下的形容：
“PSP的目的是記錄工程師如何實現需求的效率，而不是記錄顧客對產品的滿意程度。”
就我個人而言，之前的幾次個人作業中都做過PSP表，但我並不知道PSP的作用在哪里，或者說我做了三四次的PSP表我卻並沒有得到一點點收獲。在我做完PSP表的時候，也並沒有感覺到效率的提高，而是做到哪算哪，跟這個表沒有絲毫的關系。
3.關於“換人機制”
為什么要換？換人的意義在班級當中還存在嗎？我個人認為在班級里的換人毫無意義，本次的換人根本就是為了換人而換人，對項目的進行一點幫助都沒有，甚至還有負面的影響，簡直是百害而無一利。首先，各個團隊的換人形式可笑，有搶紅包、擲骰子等等，選出的人根本就是隨機的；其次，各個團隊都保留了自己的核心成員，因此無論加進來的是誰，也只是來寫寫博客的，划划水的，根本達不到鍛煉的目的；最后換人機制搞得同學之間有點尷尬，換掉誰都不合適，因此大部分團隊都選擇互換。
4.關於“代碼復審”
《構建之法》書中4.4章節中對代碼復審有以下的形容：
代碼復審的正確定義：看代碼是否在“代碼規范”的框架內正確地解決了問題。
代碼復審的形式有：自我復審、同伴復審、團隊復審。
軟件工程中最基本的復審手段，就是同伴復審。
我想請問一下，同伴復審跟團隊復審有什么區別嗎？我個人認為團隊復審跟同伴復審有很多相似的地方，為什么不考慮把它們合在一塊呢？只分成自我復審和他人復審不是更簡單直接嗎？
5.關於“其實還是人的問題”
《構建之法》書中17.2章節中對“其實還是人的問題”有以下的形容：
“P={做事的，不做事的，不讓別人做事的，P4=做假的事的，P5=假裝做事的}”
在一個團隊中，肯定難以避免有個別完全打醬油的人，對於這種人應該作為PM來說應該怎么辦呢？
三、自我評價
以下是我根據鄒欣老師的“自我評價表：http://www.cnblogs.com/xinz/p/3852177.html ”得出的自我評價：
| 1-8 |
E |
D |
D |
B |
B |
D |
D |
D |
| 9-16 |
C |
C |
D |
D |
C |
C |
D |
C |
| 17-24 |
A |
C |
D |
B |
B |
C |
D |
D |
| 25-32 |
B |
C |
B |
C |
D |
D |
B |
C |
| 33-40 |
C |
D |
B |
C |
C |
|
|
|
自我反思：在做完這個自我評價表之后，我更加清楚得=地認識到自己就是一個“假工程師”，不愛打代碼，不愛優化算法，就喜歡拖延，把任務堆到deadline的時候才做完，這篇博客就是如此。一個真正優秀的工程師是有着超強的積極性的，是勇於承擔勇於解決問題的，我離這個目標很有很遠的距離，說來慚愧啊，但我是個要強的人，我會正視自己的問題，勇於解決問題，提高自己。