一、個人總結

在alpha 結束之後， 每位同學寫一篇個人博客， 總結自己的alpha 過程；
請用自我評價表：http://www.cnblogs.com/xinz/p/3852177.html 有比較才會有進步。

二、回答問題

我們在課程開始之初，曾經要求大家針對軟件工程提出問題：個人閱讀作業2，那麽在經過alpha階段，大家是否對軟件工程有了一定的了解？請結合自己提出的問題進行回答

問題1：

原文（P1）
程序=數據結構+算法
軟件=程序+軟件工程
程序（算法、數據結構）是基本功，但是在算法和數據結構之上，軟件工程決定了軟件的質量。
——第1章 概論
由上述的說法可以看出，一個高質量的軟件需要算法作為基礎，但是我們大二時開設的算法課是選修課，有的同學沒選，即使選了算法課的同學對於所學的也可能已經忘了。所以我想請教一下，雖然這是門軟件工程課程，看似是軟件的另一個分支，但最終對我們都要落實於寫代碼上，所以算法基礎對於本門課程後期編寫程序是否有影響？對於後期的代碼優化我們是否還要再去學習一些有關算法的相關知識。

回答：在Alpha階段的過程中，剛好我負責的部分涉及到需要考慮算法的地方，在這過程中確實體會到了好的算法和數據結構在一定程度上影響了整個軟件的質量，不過這是基於程序部分的，整體來說用的還是相對比較少的，一個軟件的質量好壞與否很大一部分因素還關乎到軟件工程，在前期的需求分析，還有用戶體驗，用戶界面設計等都在很大程度上決定了軟件的質量。

問題2：

原文（P51-52）團隊對個人的期望
理性地工作：軟件開發有很多的個人的、感情驅動的因素，但是一個成熟的團隊成員必須從事實和數據出發，按照流程，理性地工作。很多人認為自己需要靈感和激情，才能為宏大的目標奮鬥，才能成為專業人士。著名的藝術家Chuck Close說：我總覺得靈感是屬於業余愛好者的。我們職業人士只是每天持續地工作。今天你繼續昨天的工作，明天你繼續今天的工作，最終你會有所成就。
——第3章 軟件工程師的成長
看了這段文字，引發出我一個問題，為什麽說靈感是屬於業余愛好者的，而職業人士只是每天持續地工作？我不否認大量地練習確實對於我們的學習和理解會帶來極大的幫助，但是也不可否認靈感對於一個職業人士的重要性。前期我們確實需要通過大量地操作來進行入門，但當我們的知識積累到了一定程度後，我們要發生質的變化，我們便要學會思考，進行創新，創新的過程中也不乏許多靈感的貢獻。而文中所提“靈感是屬於業余愛好者，職業人士只是每天持續地工作”是否會讓一些讀者陷入誤區？片面地認為靈感於職業人士是不重要的？我個人認為這段的表述如果如《程序員的思維訓練》中所提的：“R&D精神（Rip off and Duplicate，偷師學藝），三個階段： 1. 模仿 ；2. 吸收； 3. 創新”這樣是否會讓讀者更全面地認識程序員的整個學習過程呢。
參考資料鏈接：http://blog.csdn.net/MS_hankwu/article/details/51014169?fps=1&locationNum=2

回答：從一定程度上來看職業人士確實需要嚴格按照事實和數據出發，站在用戶的角度上進行軟件開發。不可否認每天持續地工作，由量變引發最終的質變是必然的結果，一日復一日地工作最終是會有所成就的。而相對於業余愛好者確實自有一些，很大一部分可以按照自己的想法來。不過我還是認為不能把靈感和持續地工作簡單地歸結為業余愛好者和職業人士的區別。我總覺得引用Chuck Close說的這句話，並沒有讓我很好地理解理性的工作的含義。

問題3：

原文（P263）軟件服務始終都要記住用戶的選擇
我同意第一印象很重要，但是當用戶已經是第N次使用你的產品時，你的UI能否為這些用戶提供方便呢？
——第12章 用戶體驗
原文（P351）迷思之三：好的想法會贏
數據顯示，如果使用QWERTY鍵盤，那麽只有10%的英語單詞能在手指不離開鍵盤中間行（Home Row，即ASDFG那一排）的情況敲出來。但是如果使用Dvorak鍵盤布局，你可以在鍵盤中間行打出60%的常用單詞（所有的元音和常用輔音都在那裏）！這樣會減輕手指和相關肌肉的負擔，減少勞損，同時加快打字速度。
那麽，這麽好的鍵盤為什麽這麽少見，為什麽大家都不用更好的鍵盤布局呢？
······
長期以來，人們已經習慣了QWERTY鍵盤，所謂先入為主。
——第16章 IT行業的創新
從上述兩段話中來看，如果當我們的軟件出現了需要大範圍改變的情況才能大大提高使用效率，但是人很容易陷入先入為主的情況，一旦界面功能設計出現大的修改，就容易讓人產生畏難情緒，甚至拒絕接受。就像我們看系列電視劇一樣，當我們看了第一部後，如果第二部的演員突然之間換了人，這時有的人就沒法接受（即使現在的演員演技臺詞各方面都比之前的好），有可能降低人們的觀看欲望，甚至棄劇。我們該如何權衡兩者之間的關系？是繼續使用原來的界面，再進行一步步修改？還是放手一搏，說不定會有出乎意料的效果？

回答：在Alpha階段結束之後，我們團隊發布了一個初步的版本，並且找了一些用戶進行體驗。我們開始發布的版本整體界面過於簡單，同時也存在著在手機上播放不了背景音樂的問題，有用戶反映整個遊戲過程中略顯乏味，整體看起來比較單調。我們對於這些bug也進行了及時的修改。在這期間也發現了一個我們沒有考慮全面的問題，那就是在遊戲界面中沒有一個返回或中途退出遊戲的功能，這確實也是沒有想到的地方，實際上是很有可能出現我不想玩這局遊戲了，我想換個等級的情況，這個我們將在beta階段進行改進。關於上述問題，我覺得對於一些界面功能大的改進不能單單只是淩駕於自己的想法之上的，自己覺得好就好，而沒有站在用戶的角度去思考問題。在這之前一定要做好充足用戶調查，在用戶調查的基礎之上再去考慮使用原來的界面一步步修改還是直接進行大幅度地修改。

三、再提問題

同時，大家一定會在實踐過程中產生更多問題， 結合你的讀書（教材，博客，參考書）， 實踐， 再提出關於軟件工程的 5 個問題。
在每個問題後面，請說明哪一章節的什麽內容引起了你的提問，提供一些上下文。
列出一些事例或資料，支持你的提問 。
說說你提問題的原因，你說因為自己的假設和書中的不同而提問，還是不懂書中的術語，還是對推理過程有疑問，還是書中的描述和你的經驗（直接經驗或間接經驗）矛盾？

問題1：

P114

敏捷開發的原則：
······
3.經常發布可用的軟件，發布間隔可以從幾周到幾個月，能短則短。

對於敏捷開發原則中所說的發布軟件的間隔能短則短，我引發了一個問題：發布間隔真的越短越好嗎？那我可以每天發布一個版本嗎？對於這個發布的時間間隔是否有一個底線？對於這次我們的Alpha階段，可以說是充分“遵守”了這個原則了，在第一個版本發布之後，由於在測試當中不斷發現問題，我們幾乎每天都更新了一個版本。可是總覺得這樣的做法不太好，對於一個已經發布了的版本，過於頻繁地進行版本更新，是否會讓用戶認為我們的軟件存在許多問題？頻繁的更新也容易讓用戶產生負面影響。站在開發者這方，如此容易就能發布一個新的版本，是否也會讓我們在潛意識裏認為發現了問題再去進行修改就好了，而不是在發布之前就盡可能的把所有可能出現問題找出來。

問題2：

P124

敏捷流程的經驗教訓：
·····
2.Scrum Master不是一個官，而是一個沒有行政權力的溝通者，就像微軟的PM那樣。他/她同時還要在團隊中做具體的工作。直接把原來的“經理”變成Scrum Master，大多行不通。

直接把原來的“經理”變成Scrum Master的效果真的不好嗎？這次的敏捷沖刺中，我們團隊就是直接把PM變成Scrum Master，書中P116提到“在沖刺階段，外部人士不能直接打擾團隊成員。一切交流只能通過Scrum大師（Scrum Master）來完成。這一措施較好地平衡了“交流”和“集中註意力”的矛盾。”一切交流由Scrum Master來完成，那是否應該是由一個比較能系統了解整個項目流程和進展的人來完成。也許是因為我們團隊人員太少，項目也不大，相對來說PM是比較了解我們項目的整體情況的，所有由她來作為Scrum Master是比較合適的，最終的效果也挺好的。

問題3：

P163

用戶問卷調查
這種方法是向用戶提供事先設計好的問題，讓用戶回答。有時候用戶在瀏覽某個網站時，一個彈窗會彈出來，打斷用戶的思路，不客氣地要求用戶回答幾個問題。用戶在問答這類問題是，是否會心不在焉，亂點一氣。

作者在文中似乎並未就該問題提出解答。如果我們事先設計好了問卷調查表，應該如何讓用戶“心甘情願”地填寫這份問卷調查表？就此次我們在沖刺之前進行了一次需求調查分析，並且做了一份問卷調查表，為了盡快得到更多的調查結果，我們大多針對身邊要好的朋友或同學發送了問卷調查表，但此做法是否會縮小了調查對象的普遍性，畢竟我們所接觸到的大多難免是跟我們年齡相仿的群體。在現實中，我們由於害怕泄露個人信息，也很難為陌生人去填寫一份問卷調查表。

問題4：

P182

經驗公式：實際時間花費主要取決於兩個因素——對某件事的估計時間X，以及他做過類似開發工作的次數N。
Y=X±X÷N //註：Y是實際時間花費。

從上述的經驗公式可以看出，如果我們之前名沒有做過類似的開發工作，那N就是為0，最終的結果實際時間就是無窮。也就是結果是未知的，這不就是算了等於沒算嗎？對於一個我們沒有接觸過的開發工作，這個經驗公式還適用嗎？

問題5：

P194

PM做開發和測試之外的所有事情

PM應該是整個團隊的核心人物，想來應該是一個無論從技術或者管理能力上都應該讓人信服和信任的人，試想如果一個連代碼都不怎麽會寫的人怎麽能說服隊員聽從他的安排和意見，如何能得到團員的支持。這樣，問題來了，如果一個PM是一個好的程序員而不去做開發，那團隊豈不是少了一個骨幹程序員，這是否會影響整個團隊的開發效率？

個人作業4——alpha階段個人總結（201521123003 董美鳳）