這是老師很久之前布置的乙個作業，由於學業匆忙以致差點忘記了這個作業。因此在資料庫考試的前夜忙裡偷閒，抽出一點時間來完成這個作業，也藉此希望我明天的資料庫考試順利……
*************************=update*************************=
我猜想明年可能會有學弟學妹來翻看我的部落格，為了給他們一些【指導】，我特地將我在火車上寫的、並在微博上@了鄒欣老師的話貼過來。肺腑之語，唯望細觀！
我在回家之前看到了我們軟工m2階段的得分，現在我坐在火車上，我都沒有乙個好心情。有些話，真是不說不快。
這門軟工課從團隊專案開始到現在，除去中間大家為大作業忙碌的時間，我們團隊可以說剩下的時間基本都用在了軟工上。我還記得我們多少個凌晨5點還在群裡討 論的日子，多少個夜晚組員都沒有睡覺，甚至跨年夜我們還在做軟工的那些過往。。。即使是經歷了這麼多艱辛，我也從來沒有後悔選了移植學霸**這個坑爹項 目。我只是感謝整個hots團隊，感謝剩下的3組學霸團隊。因為有了大家的共同努力，這個專案才能做成。因此即使是任務艱辛，我們也能苦中作樂。甚至到現 在，我們組員還打算假期回去為學弟學妹寫乙個完整的介面文件。可以說，軟工這門課，我們對自己是問心無愧，對學弟學妹是仁至義盡。
老師給出的所有建議中，我最不能接受的就是老師所謂的態度問題。我衷心的希望這並不是我們組扣分的理由。我不知道老師怎麼看出我的心理防禦，其實我對老師毫無牴觸，只是認為在和老師平等地討論學術問題而已，就像現在我寫了這篇微博並敢@鄒欣老師。 面對老師有些質疑點時，我態度堅決地反對。一方面是因為我對我們團隊工作情況的了解和自信，試問乙個開發人員如果對自己開發的專案都不自信，那他憑藉什麼 去鼓舞自己繼續開發？我的自信並不是對自己的自信，我也不覺得自己開發能力最強，我也不是團隊中工作量最大的那個人，我的自信是出於對我們的團隊的了解和 對團隊的自信。而敢於反駁的另一方面，是出於對老師的容人之量的信任，我相信老師並不會因為學生和自己意見不同就扣分。但是事實卻讓我大跌眼鏡，且不說吳 際老師有沒有故意刁難，既然老師都覺得自己沒有刻意針對學生，那又為什麼覺得我是刻意針對老師呢？事實上，對於我們的不足，我都坦誠的承認了，比如我們沒 有嵌入統計活動使用者的模組，壓力測試的報告分析不詳盡，移動端還有待優化等等。但是，對於我們做的好的地方，我為什麼要容忍質疑不能反駁呢？老師為什麼忽 略這一點？我在大學三年，經歷過無數次答辯，面對過若干次質疑，也都反駁了回去，還從未見過老師因此而對我有偏見。事實上，答辯歸來我都承受著很大的壓 力，組員怪我對老師態度不夠友好。我一直告訴他們這不會有什麼影響，所以今天看到成績我真的很難過。即使到現在，我還是願意相信這不是我們扣分的理由，我 不希望是我的個人原因而影響了大家。
說了這麼多，其實就是因為我不能接受我們組的得分並不是最高。我也並不是針對sixsix，但是我們的課程是軟體工程，不是軟體程式設計。據我所知，他們的項 目基本由乙個人完成，那團隊專案體現在何處？我可以自信的說，我們團隊是8個小隊之中分工最好，對敏捷開發執行的最好的小組。我們沒有冗餘人員，並且人盡 其用，針對每個人的能力分配了不同的工作。並通過責任劃分，包命名，降低功能耦合的方式提高團隊整合效率，這和乙個人的工作完全不同。這些我們都在 alpha階段做了解釋，不知道beta的匯報上老師們是否知情。而對於我們組的每個考核點：能否利用前兩組的資料，有什麼卓越的ui設計，使用者數量和活 躍使用者數量，搜尋的準確性和壓力測試，我們也都給老師做了說明或展示，尤其是軟體工程頗為看重的測試，我們也用了大量篇幅介紹。我不知道我們是有什麼地方 做的不完備？其他問題我在上文已經說了，如果學霸專案潛力確實如此，那我們也無能為力。我完全可以接受sixsix中能力突出者個人得分非常高，但是我不 能接受他們團隊勝於我們團隊。其實我感到更不值的是ourteam團隊，他們負責學霸**的迭代，我們和他們一起共事，非常清楚他們的貢獻，可是他們竟然 是學霸4組裡得分最低的。他們修復了很多學霸**原來的假功能，並實現了很多新功能。當然這不是他們最大的貢獻，他們最大的貢獻是對資料庫進行了修改（我 們組也有少量參與），為資料庫增加了外碼約束並新增了很多觸發器和儲存過程，使得資料庫邏輯上非常完備，大大降低程式複雜度。並且他們提供了所有的 webservice介面留給下一屆使用，本來我們組想在m2階段全部更換他們的介面的，但考慮到代價太大並且我們有一些自己的新增功能，因此放棄了這個 打算，我們亦在部落格中提出了這個期望。可以說，他們組對後人的貢獻是卓越性的，這些都是歷經了兩年的迭代的前人都沒有做到的。我們兩組之所以這麼做，都是 因為我們被學長的爛尾專案坑的不淺。因此，我們對學弟學妹真是仁至義盡。然而，做的這麼多卻沒有得到老師的肯定，真是可悲又可笑！還記得當初我們去向學長 取經，學長對我們愛搭不理、一問三不知，並且「傳授」我們只要最後說的好就行。後來看了學長的**並看到了今天的成績，我才徹底相信學長所言不虛，誠不欺 我。我還記得答辯的最後，有乙個老師問我我是不是pm，因為我對**的技術細節知道的十分詳細。他便問我為什麼我比pm知道的還清楚。我回答說，因為我是 開發人員，我當然知道這些。我還記得鄒欣老師《構建之法》裡對pm的描述：團隊裡唯一不接觸**的人。因此這不由地使我對老師的專業性產生了懷疑。不能接 受觀點差異，似乎對軟體工程不那麼專業，現在我也不奇怪學長的那種專案是怎麼從老師那裡通過並得到高分的了！
——寫於z43火車上
*************************=update over*************************=
已經清楚的問題：
1.pm不熟悉現階段專案用到的技術，無法準確控制開發的時間和進度，dev leader懂技術懂**但是隊員的水平參差不齊，有些事情只有leader能解決，這時候該怎麼辦？
我當時的答案：
我認為這時候解決問題的最好方法是leader在對專案工程進行一些問題修復的時候讓全隊旁觀，相當於每次的工作都是一次教學，畢竟大家的磨合才能使團隊進步。如果水平的不足是既定的事實了，那麼只好尋找方法去彌補。
現在的思考：
這個問題是我們在開發階段中切實遇到的乙個問題。我們開始企圖讓pm為我們安排進度，後來發現別說是pm，就算是dev自己有時候都可能對自己的開發進度出現估計失誤。在實踐的過程中，我們採用這樣的方法：首先由乙個對android開發較了解的dev搭建整個系統的框架，然後我們對任務進行大的分割，在這個分割過程中充分發揮敏捷開發的特點，使得每個人負責的功能間的耦合性很低。在分割的過程中也充分考慮到隊員間的能力差距和個人意願，使得每個人承擔的任務基本和其能力及興趣相符。在接下來的開發過程中，pm不對詳細的開發過程時間設限，只給出乙個大體的規劃時間，例如周一前完成大功能1，周五前完成大功能2，而對於詳細子模組的時間安排，則由dev在每日例會中交流討論，得到乙個大體的時間規劃並上報pm。在討論的過程中，有經驗的dev可以給出指導，依據經驗調整時間安排。而pm則在這個過程中收集整合隊員們上報的時間安排，並按照這個deadline去監督dev們的工作。
2.如果團隊裡遇到了技術很牛但是合作精神逐漸才發現很糟糕的人該怎麼辦。如果此時找不到任何能接替他的技術人員了，是放棄他還是放棄專案？
現在的思考：
我們隊伍中確實有這樣乙個類似的人，但是他並不是合作精神很糟糕，只是很樂於全部由自己完成自己的部分(可能這樣做更放心吧！)。他所完成的部分我們確實都不了解，於是問題來了：在beta階段這個同學好像突然從專案裡消失了一樣= =當然放棄專案肯定是不可能的，我們也只好先放棄他的這部分了……
還是上面的那個問題，如果團隊裡遇到了技術很牛但是合作精神逐漸才發現很糟糕的人該怎麼辦。如果此時找不到任何能接替他的技術人員了，是放棄他還是放棄專案？
我們現在能做的就是對這個人給予充分的信任（他也確實很靠譜），希望他可以完成自己的任務。但是如果現實中真的遇到這樣的情況，那一般會怎麼選擇？
1.pm這個職位是本來就固有的還是從程式設計師轉上去的？
2.敏捷開發和瀑布模型到底哪乙個更實用？
3.老師究竟是怎麼能讓學長那樣的專案通過的？？
按照軟體工程方法操作的團隊，反而不及乙個人單打獨鬥的團隊，我還有什麼說的呢？
需求：如何使用nabcd模型進行需求分析
設計：對估計的練習和分而治之
實現：基本實踐了msf基本準則（尤其是為共同的遠景而工作、充分授權和信任、各司其職，對專案共同負責、保持敏捷，預期和適應變化）
測試：黑盒測試和白盒測試
發布：如何進行使用者推廣以及事後諸葛亮會議
維護：還未進入維護階段
個人閱讀 M1 M2階段總結
1.以前部落格的鏈結 2.請說明哪些問題現在自己已經清楚了，請闡明一下，是如何通過看書，實踐，或者討論弄清楚的 問題1 關於 的管理問題 最近寫軟工和編譯作業，隨時都會有一些小小的改動，而且過一段時間後，自己都忘記了改了 而且如果是自己寫的還好，可以去讀 但是像軟體工程這種團隊協作的專案來說，讀別人...
個人閱讀作業 軟體工程M1 M2總結
一 較為明白的問題 1.在文章的第乙個關於square tech的案例中，測試和優化都是在所有程式完成以後才進行的，這應該也不符合快速軟體開發的要求吧。如果測試工程師在最開始的時候就加入到軟體開發中的話，軟體開發程序會不會更快呢？2.我一直分不清楚幾個pm之間的區別。雖然在網上查了一些資料，但還是不...
現代軟體工程 M1 部落格要求
各個小組都大致確定了自己的專案和人員分工,這太好了。第乙個里程碑馬上就要開始了。請同學們按照下表的要求,把各個角色,各個階段要做的事情都快速地用部落格表達出來吧。每個部落格的截止日期是 每日部落格 第二天早上9點。每週部落格 下一周周一早上9點。每個團隊有6 7 個人,如果把工作分配好的話,每個人的...