第一次閱讀做業

項目	內容
這個做業屬於哪一個課程	軟件工程（羅傑）
這個做業的要求在哪裏	第一次閱讀做業
我在這個課程的目標是	瞭解軟件工程，並用實踐來熟悉對軟件開發的整個流程。
這個做業在哪一個具體方面幫助我實現目標	閱讀了《構建之法》，對軟件工程有了基礎的認識。

一.讀完教材後的問題

1.第3章 軟件工程師的成長——專與精的關係

書中在這一段將全棧工程師比喻成街賣藝的單人樂隊，什麼都會一些，但什麼都不精。因而我對此產生了疑問，在個人想象中，全棧是很厲害的一個發展方向，一我的算法也能作，工程也能作，確定是一個大牛。但在書中，對全棧的評價並非那麼高。因而我在網上查閱了以後，發現這就是一個深度和廣度的討論。一我的的精力是有限的，大多數人都只能在一個方面作到精通，或者在多個方面都作到了解。真正的樣樣精通是很理想化的一種追求，不少時候追求樣樣精通最後就成了樣樣不精通。所以我改變了個人想法，我但願我能成爲T型人才，在學校時和工做早期，儘可能去多瞭解各個領域的知識，而後再選擇一個本身適合並擅長的領域垂直髮展下去。

2.第6章 敏捷流程——6.2 敏捷流程的問題和解法

第二步：把一個任務從產品層級的描述逐步細化到技術實現層面，是很須要技術能力和交流能力的。

所以究竟要如何對一個任務進行細化呢，並且這個細化的工做是在產品最開始的時候進行的，所以若是細化工做時出現了對工做不正確的預估（很容易出現這種想固然的問題），在敏捷流程中又該如何解決呢？我在查閱了(博客)[http://blog.sina.com.cn/s/blog_72ae45e40101c2cm.html] 獲得了下面的回答。

在通過目標故事評估以後，咱們已經有了一份有優先級和工做量估算的目標故事清單和一個整體工做計劃。一個整體計劃一般要劃分爲若干個階段性計劃，經過對階段性工做任務的安排和執行，來逐步完成整體工做計劃。
每一個階段性工做以一個任務計劃會議開始。
在任務計劃會議上，首先經過目標故事清單的優先級和工做量估算，肯定本階段工做要實現的目標故事。
而後，根據本階段要實現的目標故事，逐個對目標故事進行目標細化。在目標細化時，把目標故事分解成通常不超過8小時工做量的工做任務。把本階段要實現的目標故事分解完後，就生成了本階段工做的任務計劃清單。
對本階段要實現的目標故事進行細化，是由執行團隊的承諾驅動的：按優先級，逐個目標故事細化到任務，直到填滿這個階段的團隊工做總時數。經過這樣的一個細化過程，執行團隊就承諾了在這個階段，按照團隊工做總時數，可以完成的每個細化了的任務。
目標細化的過程是一個造成執行團隊共識，開展團隊學習的過程。許多學習型組織的修煉方法均可以應用在目標細化的過程裏。

從上面能夠看到，這個敏捷流程的細化操做不必定要在任務的一開始就所有作完，能夠先分幾個階段，而後每一個階段再分別細化流程。細化的過程要你們都參與進來，這樣就會減小對細化目標的錯誤估計。

3.第6章 敏捷流程——6.3 敏捷的團隊

1. 自主管理：之前領導佈置了任務，咱們實現就能夠了，如今要本身挑選任務；每次Sprint結束以後，還要總結不足，提出改進，而且本身要實施這些改進。「自主管理」不等於「沒有管理」。
   . 自我組織：之前作好本身的事情就行了，安心下班。如今每一個人要聯合起來對項目負責，有人工做落後了還要幫助他改進，項目缺乏某類資源還要本身頂上去。

在這一段中，對敏捷的團隊提出了要求。在這裏我想到，在敏捷流程的要求下，是否各個項目中的分工可能就會變得模糊？組裏的人要聯合起來對項目負責，所以在敏捷開發這個流程中是否全棧工程師更加吃香？所以全棧是否在敏捷流程中是必要的？這些問題在網上沒有找到較好的回答。

4.第16章 IT行業的創新——16.1.3 迷思之三：好的想法會贏

好的想法會贏學理工科的同窗都比較理性，大多會認爲，好的想法固然會贏啦。就像解數學題同樣，好的解法固然會得高分啦。好主意必定會把不太好的主意都比下去。可是在現實中，好的主意不必定贏。例如，看看咱們平常使用的電腦鍵盤，做者打賭99.9%的鍵盤都是這樣的佈局（QWERTY）
可是不少研究者認爲下面的鍵盤佈局（Dvorak）更有效率...
...
可是，長期以來，人們已經習慣了QWERTY鍵盤，所謂先入爲主。

我認爲Dvorak的鍵盤佈局並非必定是個好想法，由於，雖然設計出了更有效率的佈局，可是它沒有考慮到對於人們更換鍵盤並從新適應所帶來的代價。並且這個效率提高也不是一個質變的提高，爲了這種小的提高而去從新適應，換新的鍵盤，這個代價反而使得這個好想法變成了壞想法。

5.IT行業的創新——16.5 創新和做坊

做坊，英語叫Workshop，好多學術論文也發表在各類Workshop中，你們也以爲挺有面子的。美國好多家裏的車庫（Garage）、地下室都兼做主人的小做坊。在中國的上下文提到「做坊」，你們會想到什麼？我想到：
本身手工勞動，作出產品。
人很少，師傅帶徒弟，或家傳手藝。
只作某種行業，不太改行，商業技巧很少。
不太作廣告，主要靠口口相傳，容易被技術進步淘汰。
和顧客很熟悉，能夠賒帳……
這些好像都不是缺點吧？爲何要着急走出去？咱們一條一條地細說。
...
創新的出路到底在哪裏？不能在各類峯會上發言的IT人士，不妨走進各自的小做坊。

對於這裏的對小做坊有了好的評價，所以我想問一下，對於剛畢業的學生，究竟是進入這樣的小做坊去轉研創業，仍是進入大公司在公司的體制內提高本身呢？我本身暫時的想法是在職業的初期最好能進入一個小做坊，或者一個好的工做小組，努力提高本身。可能在這種環境，我的會有更大的提高。但我仍是對這個問題不是很清晰，由於沒有什麼經驗。

二.請問 「軟件」 和 「軟件工程」 這些詞彙是如何出現的 - 什麼時候、何地、何人？

• 在1958年1月9日，美國的統計學家John W. Tukey在《具體數學教學》中使用了軟件一詞
• 在1969年先後,在阿波羅任務的任務過程當中，Margaret Hamilton在美國宇航局工做時創造了「 軟件工程 」 一詞。

三.【附加題】：你們知道了軟件和軟件工程的起源，請問軟件工程發展的過程當中有什麼你以爲有趣的冷知識和故事？

「埃尼阿克」誕生之初，因爲它存在諸多缺陷，沒法普遍應用。直到1951年，莫克利和埃克特在「埃尼阿克」基礎上研製出了UNIVAC(通用自動計算機)，電子計算機纔開始從實驗室走向社會。不久，一件偶然事件的發生，又使其知名度迅速提升。
1952年，適逢美國大選。爲了對選舉資料進行處理，哥倫比亞廣播公司租用了UNIVAC，用來預測大選結果。選舉結束後僅僅45分鐘，UNIVAC就計算出艾森豪威爾將以438票的絕對優點贏得勝利。但在選舉前，幾乎全部的專家和媒體都預測競選雙方平分秋色。因此對於計算機的預測結果，廣播公司拒絕報道。工程師們只好從新計算，但該計算機仍堅持艾森豪威爾將大獲全勝。當選舉結果正式揭曉後，全部的人都驚呆了：艾森豪威爾實際得票爲442票，UNIVAC的預測只有不到1%的偏差率！今後，整個世界開始對電子計算機的功能有了新的認識，電子計算機的發展進入了一個新時代。

四.上網調查一下目前流行的源程序版本管理軟件和項目管理軟件都有哪些， 各有什麼優缺點？

軟件	人數	優勢	缺點
Github	31,000,000	錯誤跟蹤，快速搜索，良好的社區，方便共享，良好的兼容性，支持Git，SVN，HG，TFS導入。	大小限制：文件大小不能超過100Mb，存儲庫能夠託管信息1Gb。
Bitbucket	5,000,000	對於小團隊免費，一個集成的查詢管理系統，經過社交媒體和GitHub認證，集成Jira工具，導入現有Git項目，支持Git，CodePlex，Google Code，HG，SourceForge，SVN導入。	不開源，系統不穩定
Launchpad	3,965,288
SourceForge	3,700,000	代碼很是多，古往今來，各種都有，版本控制多樣選擇	查看log很費事，不少沒人管理的項目
GitLab	100,000	免費，GitLab在開源許可證下運行，錯誤跟蹤和基於Web的代碼編輯，與LDAP(輕量級目錄訪問協議)集成，支持Git導入	界面相對較慢，存儲庫常見的技術問題。
GNU Savennah	93,346
OSDN	54,826
Ourproject.org	6,353

參考資料：

• 版本管理軟件用戶數目