一、較為明白的問題
1. 在文章的第乙個關於square_tech的案例中，**測試和優化都是在所有程式完成以後才進行的，這應該也不符合快速軟體開發的要求吧。如果測試工程師在最開始的時候就加入到軟體開發中的話，軟體開發程序會不會更快呢？
2. 我一直分不清楚幾個pm之間的區別。雖然在網上查了一些資料，但還是不明白product manager 和 program manager之間的區別是什麼。在《程式設計之美》一書中了解到微軟中的pm屬於r&d,就是說program manager屬於研發崗，但是《移山之道》在移山公司最初成立的時候又說pm不用寫**，是這樣的嗎？
現在想想，這個問題一下子就暴露出了自己捉急的智商和對軟體行業的不了解。產品經理和專案經理除了都有乙個字尾」經理「以外，應該就沒有什麼相同之處了吧，也不知道當時自己是怎麼想的。打個比喻說的話，產品經理就是一座橋，連線了使用者和專案團隊；也可以是乙個集市，供使用者和專案團隊交易。而專案經理就是leader，如果把專案組成員比作神經元，那麼專案經理就是神經中樞。
3. 其實我不懂既然有了有效開發，為什麼還需要快速開發。因為從《快速軟體開發》做的比較可以看出，有效開發的產品要好於快速開發的，而且進度和成本不會太差。我知道軟體行業競爭力很大，誰的產品先出來，誰就有可能搶占市場，但是如果沒有足夠好的產品，當更好的產品出來後，不也是會被取代嗎？就算可以先上市後在做調整，但是 有可能因此而花費的精力會更大，所用時間會更長。
這個問題我現在是這麼想的，」快「和」精「，也就是」快速開發「和」有效開發「往往難以取捨。有的東西你為它的精緻負責，它不需要，這是我在北航門戶**實習明白的一些東西。實習的時候，我希望每個我負責的專題都能夠達到自己想要的效果，能做嗎？負責的老師跟我說，只要想做都是能夠做出來的，但是划算嗎？有個詞叫做」價效比」，價效比不高的話，又何苦呢。另外一方面，就是不能偏科的道理，任何乙個具有功利性質的專案，包括商業專案和課堂大作業都是這一類，商業專案求得是贏利，而要贏利就肯定要打敗競爭對手，市場變幻風雲，當然時間就起了很大的決定性作用，先打入市場總會占得一定的先機，有更加充足的時間進行下一步的布局和調整等等有利的因素。而每乙個課堂大作業都有乙個deadline，團隊專案之間存在競爭，這個時候時間就成了定值，也就是說時間是一定的，就看你是走到撒哈拉還是好望角了。總的來說，就是兩個東西，在有效開發的前提下提高效率，或者在快速開發的前提下提高質量。怎麼感覺說了跟沒說一樣。
4. 乙個小型專案團隊中，到底是產品經理還是測試工程師(假設都只有一位)更了解這個產品？
二、還是糊塗的問題
5. 乙個首席程式設計師團隊的核心是首席程式設計師，但是這樣的團隊對於風險控制有極大的要求，如果這個團隊中的首席程式設計師因為什麼原因在中途離開了這個專案組，那麼要保證這個專案的正常進行，這個團隊可以怎麼挽救，需要改造成其它什麼形式的團隊
其實我們這個團隊應該就算是乙個首席程式設計師團隊。程式設計能力最強的一位隊員順理成章地成為了首席程式設計師，而且主動承擔了最為艱鉅的任務，雖然我們一開始並不知道聯網這一塊兒會這麼棘手。慶幸的是他一直沒想著離開這個團隊，如果離開的話，或許這個專案就是宣告失敗了。但是有乙個問題就是，當他乙個人在那兒研究並不斷深入的時候，有乙個問題會出現，就是其它隊員會越來越難以介入，最終導致專案一步一步地往後推。而且首席程式設計師的情緒直接影響到其他成員，高興的時候大家都高興，焦躁的時候全別這種氣氛籠罩。現如今，專案總算是有點點成果了，大多半都是依靠他的不斷探索和努力，很感激他。不過我原來提的那個問題，因為自己並沒有遇到，也很難找到乙個其它例子，還是有些糊塗。
三、冒出來的新問題
1. 通過怎樣的方式能讓專案組的每一名成員都能發揮他的最大價值？對於乙個小型專案團隊來說，怎樣進行專案分工更科學？
2. 一般來說，同乙個軟體開發專案在不同平台的實現都是乙個團隊完成的，而我們有好幾個專案是接手上一屆團隊的，最開始的時候以為這是件好事，只是做維護而已，但是後來發現，這不是再創造的問題，而是重做。學長的**是用oc寫的，我們組沒有乙個會oc的，還有就是交流問題，畢竟不是團隊成員，所以在溝通上總會不方便。所以我想問的是老師當初選了一些上一屆的專案給我們繼續做是出於什麼樣的考慮？
四、讀文章的新體會
1. 大泥球問題。這個問題應該是軟體工程初學者都會出現的問題吧。工程素養都還沒有達到一定的水平，不會像高階軟體工程師和老師們那樣高屋建瓴地去看乙個工程，或者是乙個功能的一段**實現，更多的是想到哪兒寫到哪兒，所以系統性不夠強，就形成了典型的大泥球問題。在後面做測試的時候發現需要修改好大一部分。只想著早知如此，何必當初。有了教訓以後，我們後面做了充分細緻的設計以後在進行實現，質量和效率都提高了不少。
2. 大教堂和集市問題。我們團隊還是用了大教堂的形式。不過出現的問題就是當教堂裡面的神父們水平都很低，參悟不了一些問題的時候，還是得把問題拋到市場上去聚集各方力量。我們在得知靠自己的力量搞定不了開發中的問題的時候，也只能厚著臉皮不斷地請教老師，同學，學長了。
五、課程最後的總結
總結就一點，課程設計沒錯，是自己不夠付出，基礎不到位。不過一分耕耘一分收穫，無論是大是小，做了，總是有點收穫的。
個人閱讀 軟體工程M1 M2階段總結
這是老師很久之前布置的乙個作業，由於學業匆忙以致差點忘記了這個作業。因此在資料庫考試的前夜忙裡偷閒，抽出一點時間來完成這個作業，也藉此希望我明天的資料庫考試順利 update 我猜想明年可能會有學弟學妹來翻看我的部落格，為了給他們一些 指導 我特地將我在火車上寫的 並在微博上 了鄒欣老師的話貼過來。...
個人閱讀 M1 M2階段總結
1.以前部落格的鏈結 2.請說明哪些問題現在自己已經清楚了，請闡明一下，是如何通過看書，實踐，或者討論弄清楚的 問題1 關於 的管理問題 最近寫軟工和編譯作業，隨時都會有一些小小的改動，而且過一段時間後，自己都忘記了改了 而且如果是自己寫的還好，可以去讀 但是像軟體工程這種團隊協作的專案來說，讀別人...
軟體工程 個人閱讀作業2
標籤 軟體工程 1，在第四章 兩人合作 中，p92頁提到兩人合作的不同階段和技巧，文章著重強調如何使一方去影響另一方，如 如何影響對方 p94 如何正確地給予反饋 p95 作者只看到一方而忽略了雙方。如果被動方自己本身並不願意接受，那麼主動方所做的一切就顯得有些蒼白無力。如何正確看待別人對我們的意見...