你的項目有一個大泥球麼? 有什麼解決辦法？
大泥球這個問題在之前我遇到過，但是不知道它就是大泥球。在我最早寫代碼的時候由于代碼量小，而且寫一次代碼之後我不會再去看他，是以我在程式結構上和變量的命名方式上沒有多大的考慮，是要能夠加快我的這次開發就行了。這造成了我的代碼可讀性比較差，而我也不喜歡讀自己之前寫的代碼。
你的團隊是用什麼方式建造軟體?
我們組的設計模式是大教堂模式，我認為，在我們這樣的小規模程式設計使用大教堂模式要比集市模式好得多，因為我們的人數比較少，使用大教堂模式可以讓我們分工明确。我認為，集市模式更适用于開源社群這種人流量夠大的地方，集市模式可以讓人們自由地參與到軟體中來，這其實是用數量彌補了品質。
這些情況在你的團隊中出現過嗎？
作者主要講述了開源軟體中的過度依賴問題，這個問題在我們的工程中也遇到過。
這是後來大家說的 “瀑布模型”，它有什麼特點?
瀑布模型（Waterfall Model） 是一個項目開發架構，開發過程是通過設計一系列階段順序展開的，從系統需求分析開始直到産品釋出和維護，每個階段都會産生循環回報，是以，如果有資訊未被覆寫或者發現了問題，那麼最好 “傳回”上一個階段并進行适當的修改，項目開發程序從一個階段“流動”到下一個階段，這也是瀑布模型名稱的由來。
你的團隊在開發中用了那些靈活的思想和做法？
-
每日站立會議
每日站立會議是老師要求的，但是我覺得這個很有用，每天我們的隊員在一起彙報一下今天完成的任務和規劃一下明天的任務，這是很有實用價值的。我覺得最大的作用在于鞭策隊員每日按時按量完成自己任務。
-
Scrum
Scrum 是一個靈活開發架構，我們團隊是分為了不同的角色，PM，開發人員，測試人員。不同的角色做不同的事，大大提高了開發的效率
軟體工程的方法論到底有多少好處？同時好好讀一下兩個文章的評論。
軟體工程在之前有了解過，但幾乎沒有過實踐，覺得理論的都是空的，但是真的用過軟體工程的方法之後我覺得軟體工程的方法确實在某些方法很有用。例如疊代，以前遇到一個大的問題不知從何入手，感覺完全沒有方向，總是想要找到一個完全的解決方案，然而在疊代中，每次開發一個小的版本，一點一點添加，最後形成最終版，我覺得這個很有用，可以逐漸解決問題，至少能夠盡快開始問題。又比如說極限程式設計，極限程式設計中有四個核心價值溝通（Communication）、簡單（Simplicity）、回報（Feedback）、勇氣（Courage）。 XP用“溝通、簡單、回報、勇氣”來減輕開發壓力和包袱；無論是術語命名、專著叙述内容和方式、過程要求，都可以從中感受到輕松愉快和主動奮發的态度和氣氛。這是一種幫助了解和更容易激發人的潛力的手段。XP用自己的實踐，在一定範圍内成功地打破了軟體工程“必須重量”才能成功的傳統觀念。總之，軟體工程的學習對于我們進行軟體開發是很有好處的。