我了解到的就是這幾點：
第一，有很多條件促使大泥球產生，包括"一次性**"，時間緊缺，急於完成最小集，初期嘗試，功利主義等等。
第二，有些時候可以允許**沾一點泥：在初期嘗試階段，沒有必要預先設計長期的架構，那樣反而會束縛住探索。
第三，不能放任**變成"大泥球",對應的方法有兩個，一是重構，二是複審。
第四，隨著軟體需求、特性的更新發展，會面臨重構，需要對過去的失敗原因進行剖析充分吸取經驗之後重構。
在實戰中，我們組首先確定**要可維護，並且時間寬裕，其次任務大多採用結對程式設計方式完成，不斷複審，因此最終的結果也是避免了讓**變成大泥球。
敏捷的核心在於以人為核心的迭代開發、增量交付、需求驅動，目前我們利用scrum的方法，完成了乙個迭代的衝刺，達到了預期目標，並且接下來將以alpha階段的成功為平台繼續發揮，體驗到了一種步步為營的感覺。我認為在現在的課程中尚未出現使用者需求的重大改變，因此alpha 和 beta只是在按照最初的計畫穩步進行而已。如果在alpha階段結束後能把使用者反饋統計的功能做好的話，可能會檢測到使用者需求的變化，真正體驗到敏捷開發的重要性。
人件給我的印象是：管理者要利用腦力勞動者所具有的屬性實現團隊的高效（單位時間產出）工作。
給我印象深刻的幾個點：
1.大腦時間（flow）：讓團隊裡的人能夠進入狀態來工作而不被打斷--讓個體高效。
在alpha階段中，盡量讓工作在同一任務上的同學在同一環境下工作，避免因為不相干的工作干擾工作狀態。
2.發掘成員的潛力：正確的人在其適合的方向上成長--團隊成長與個人成長的統一。
我們的團隊確實找到了合適的人，每個人都被安排到其樂意或者擅長的方向，而這些方向剛好是專案所需。這提高了工作質量和效率。
3.作為服務的領導力：領導者不凌駕於成員之上，而是作為一種服務存在，只求合理安排讓每個人充分發揮自己的長處--領導者的心態。
我在做pm的過程中，首先了解清楚每個人都適合做什麼樣的事，跟每一位成員混的比較熟，接下來就只是把自己擺在乙個催化劑的位置，做好安排，處理雜事，時刻了解並處理好突發問題，讓每個成員在各自方向上安心發育，為其盡量掃平障礙。當然每個成員都相應地按時完成計畫任務。
4.團隊凝聚力：隊員樂在其中，自信而充滿熱情--團隊活力與耐久性。
這方面在alpha階段做得還算比較到位：當前後端和模型第一次合體時，全員都擠在我寢室狹小的空間裡，每次輸入一張進去時大家都驚訝於生成對聯的完美效果，每個人都意識到這是團隊共同作用的結果。團隊成員的感情也加深了一層。beta階段雖然大家在學校和組裡的事情更忙了，但是希望這種凝聚力繼續保持。
5.讓改變成為可能：要意識到需求是可能發生變化的，改變是必要的，過程是崎嶇的，不可避免的。要轉換思想，實踐整合，讓改變成為可能。
這一步我們尚且沒有遇到：**還比較規整，沒有遇到需求的突變，重構不是迫在眉睫，但是我認為這一點是重要的，要有改變、適應的意識。這對以後有好處。
軟體工程15個人閱讀作業2
文中 單元測試應該整合到自動測試的框架中,這樣每個人都可以隨時 隨地執行單元測試 提出問題 將單元測試整合到自動測試的框架中應該注意什麼 查閱資料 單元測試有一點特殊性，就是在乙個系統中，函式會非常非常的多，變化也比軟體的功能頻繁的多。面對這麼多的函式，這麼頻繁的變化，純手工測試是不現實的。所以，我...
軟工網路15個人閱讀作業1
個人部落格位址 目的 管理你的專案，記錄 原始碼 文件，歷次版本變更，bug發現與修復 等資訊。碼雲位址 應該是偏向硬體這塊，以後工作方向可能是監控 網路佈線之類的。不是個人的第一志願，在學習中思考未來就業方向。比較符合，學習過程中帶有實驗課的實際操作，較切合實際。是比較接受的領域，不太擅長。有小的...
軟體工程網路15個人閱讀作業1
201521123094 吳慧婷 關於專業知識 技能與能力，學過資料結構 編譯原理 作業系統 組合語言 計算機原理 計算機系統結構 離散數學 概率論 計算機網路 資料庫 微控制器 演算法設計 數理統計 高階語言程式設計 物件導向程式設計，從dos的tubropascal時代學起，一直學到vc6。然而...