我們也算是經過了一次軟件開發的人了，在Alpha階段過程和結果都不太理想，我們在寫事後諸葛亮會議的時候也感慨了很多，在小組會議的時候也討論了很多，為了完成這次作業，我又翻了翻《構建之法》這本書。這本書給我的感覺還是和第一看的時候一樣--與眾不如。我們平時的那些專業課書少不了概念和代碼，這本書讓我很意外的沒有看到什麽代碼示例

這時我已經產生了第一個問題：這本書是讓我們學什麽的？我通過這本書的學習之後我能充當好一個什麽樣的角色？是一個技術人員，還是一個leader（分配者）？開發一個軟件，是什麽更重要呢?技術嗎？還是合作模式，合理分配，亦或管理，對市場的感知和分析？如果我技術不好，這個團隊還需要我嗎？（這真是我的心聲啊，我這技術......）

第二個問題：一個初級工程師想要成長要掌握這麽多的知識，我們在大學四年是否可以完成這些東西的學習呢，我們的精力和時間都是有限的，要怎麽分配呢，怎麽平衡這些和學校課程和個人愛好，這些東西都是必備嗎？初級工程師想要成長就一定要這些全會嗎？

在書上看見了列出的不適合結對編程的項目情況，那麽第三個問題來了

第三個問題：有沒有不適合結對編程的人呢？比如那些一直想要做領航員的人，這樣會不會造成結對中的不公平？駕駛員想要用漢堡包式的方式告訴那個領航員互換角色，可是那個領航員假裝聽不懂的樣子的時候又要怎麽辦呢？又或是在兩人的合作中，一個人一直假裝聽不懂建議，打馬虎眼時，又要怎麽辦呢？

第四個問題：書本中第五章列舉了很多團隊模式：主治醫師模式、明星模式、社區模式、業余劇團模式、秘密團隊、特工團隊、交響樂團模式等等，那麽哪個會是最高效的團隊模式呢？是有一個最理想的最高效的模式，還是這幾個模式中適合自己團隊的才是最好的呢？

第五個問題：我們之前花費了很多的時間做好了充足的市場需求分析，可是在實現中發生了沖突要怎麽辦，比如deadline要到了，我們的一部分需求功能沒有實現，我們是要舍棄這些功能，還是有向老板再請求一些期限，如果我們項目的殺手功能實現起來遇到了瓶頸，我們要放棄殺手功能嗎？

關於自我評價連接表：

鏈接

個人作業3--個人總結（Alpha階段）