銀彈：

　　我覺得在beta階段我們采用了一個算是銀彈的方法，就是重構代碼吧，由於在我們組之前已經有兩組碰了這個項目，很多代碼都沖突和冗余，重構的話能夠刪除很多沒有用的代碼和加深理解，但是收效甚微，重構導致了進度變慢，實際的新東西也不是很多；可能也是人員少、時間少、分配不均的原因，很多時候都要等待重構完成才能對接。但這種做法可能是一種銀彈，就是對我們這個工程的幫助沒有顯現出來，反而算是有一點幫了倒忙的樣子。但如果能夠為下一屆或者以後的同學起到加快項目進度作用應該算是一個銀彈吧。

大泥球：

　　大泥球是我們組遇到的一個巨大問題，而且這個泥球不是一般的大，由於是接手經過兩個隊伍改動後的項目，可能一開始是個小泥球，然後等它的表面幹了，又弄上了泥，成了兩層的泥球。在拿到這個項目的時候很明顯能感覺到它的很多地方都是分開的，其中有幾個功能在綁一起，但有的功能由於調用了另一個外部框架的原因又是獨樹一幟， 我們發現在調用很多東西的時候本不應該從數據庫中調的東西它存在數據庫中，網頁的框架裏面用了另外的框架，導致我們看代碼的時候進度極慢，新增代碼更是難上加難。我們是想要解決這一問題的，我們的方法是重構代碼。但相對的，新增的東西也少了很多。而且在我們新寫的時候也有泥球產生，比如兩個人在改同一段代碼，然後兩個人都加入自己認為有幫助的代碼，雖然是在理解了對方的基礎上，但在使用對方的代碼的時候會比較偷工減料，這樣也是會產生許多不可復用的代碼。

大教堂和集市：

　　我們的項目是采用集市的辦法，但雖然項目公開，具體有權限修改的只有開發人員。

Worse?Better?：

　　我認為如果真正要做軟件工程，還是不能“worse is better”，因為除了把項目做出來，軟件工程還包括之後的維護工作和其它很多東西，要有維護性，首先就要完整，不能讓讓幾個功能拖慢了整個項目的進展，想這次我們接手別人的任務之後，也感受到了一開始引入的一個小的錯誤變量，後來可能引發嚴重的後果，有的時候當下看起來能夠快速解決問題的辦法在長遠看來反倒是像埋下了一個炸自己腳的炸彈。

瀑布和敏捷：

　　我認為瀑布對我們來說還是早了一點，第一我們時間有限，而在我們現在的水平基礎具體編碼和修改代碼占的時間比重上比較大，經驗也不多，導致了瀑布的前幾個流程可能分配的時間少，說著說是收效甚微；我認為瀑布還是適合那種大型公司，有足夠的時間和專門的人員監督瀑布的每一個流程。相比之下，敏捷坑能還是更加適合我們和一些小型公司，針對需求而做變化，用實際的軟件衡量成果，這也在一定程度上把我們和自己做的軟件距離拉近，也增強了同伴之間的溝通，增加做下去的動力。

方法論：

　　還是要自己動手才知道，雖然方法論的前景美好，但是一味的談論理論也只是紙上談兵，實際有很多需要隨機應變的東西，也需要考慮人的情感和能動性等因素。

個人閱讀作業+總結