-敏捷流程包括了幾大原則：backlog、burn-down、sprint、scrum.
敏捷開發注重個人之間的交流，提倡盡早的交付有價值的軟體滿足顧客的需求， 在開發過程中不斷與客戶進行互動，變化.
第一步就是要找出完成產品需要做的事情-product backlog 估計每一項工作的完成時間.再決定當前的衝刺要解決的事情 sprint backlog 將整個產品的實現劃分成相互聯絡的「塊」，再由「塊」劃分成可在短時間內完成衝刺的單位, 這些單位任務則有團隊成員自主認領.接下來就是衝刺了「sprint」,在這個關鍵階段，團隊成員不熟外部影響 只在隊員之間進行交流，討論。進行每日例會來**任務的進**況和困難. 這樣以來就可以逐步漸進的得到完善的軟體版本。最後發布給使用者，根據新的需求在此基礎上進行提公升完善. 當然敏捷開發的問題也是很明顯的,想要達到理想的情況 每一步都要精確好，處理得當.由於產品是被人為的分成相互聯絡的單位，而隊員又是自主認領人物， 那麼團隊之間必然會出現問題，比如任務a要在b的基礎上完成，但是b卻沒被認領，自己如果能力不足以完成， 必然會推遲專案的進度的;還會出現忙閒不均的情況.至於在每日例會中，最好就是隊員之間面對面的交流，討論具體任務 信，最好能夠記載完成任務的進度和還需要多少時間.這樣對整個專案的推進才會有意義，而不是每個人都硬性的 的討論「任務」這個詞. 當然也不是說將**寫出來，集合起來就完事了.測試也是至關重要的一塊，不過在敏捷開發中沒有明確的 指出測試的人員。在推進一步就會進行乙個整合測試，保證階段性的完善才進入下一步，也就避免了在最後整合時 出現前面留下的大量可能不是很致命，但是卻繁瑣的bug的情況. 書中提到敏捷可以讓我們知道能不能按期完成任務，盡早看到客戶專案的部分功能，也許這已經讓使用者滿意了， 就不用去花費時間完成其他需求；亦或者是使用者看完部分功能後有新的需求，就不用去花費對於時間實現過時的需求 這是不是說乙個專案到手都是可以先考慮敏捷呢？
-msf(microsofe solution framework) 最令人印象深刻的就是九大原則： 推動資訊共享和溝通 為共同的遠景而工作 充分授權和信任 各司其職，對專案共同負責 交付增量的價值 保持敏捷，預期並適應變化 投資質量 學習所有的經驗 與顧客合 第一點是實現下面原則的前提，沒有公開的資訊談何建立清晰的責任和共同的職 責、保持敏捷，預期並適應變化;在team裡面有了共同的遠景，才能夠兄同心，其利斷金. 在開發乙個專案之前，要先清楚的知道你為甚麼要開發這個產品，他能夠解決什麼問題，怎麼去獲取使用者報酬等 所以要重視商業價值，提供漸進價值。再加上敏捷的「身段」，使得這個專案能夠出生，不至於還沒開發出來就過時了. 還有就是投資質量也很重要，不能過分追求質量，特別是非商業軟體上，不能讓追求質量而拖程序. msf演化成兩個分支： msf的敏捷開發模式 強調與使用者的交流. 重視在實戰條件下的質量. 精簡過程,直奔主題.
msf cmmi開發模式。 cmmi 是能力成熟模型整合英文的縮寫. 資料顯示，如果乙個額專案答管理達到了cmmi的較高的等級，那麼專案的質量與按期完成率都有較大的提高.
構建之法2
團結就是力量 善於運用團隊，發現無限潛能。前幾周老師提出結對作業的時候，我覺得只是這麼乙個小小的程式，沒有結對的必要性吧。可越到後來越發現結對的好處，隊友可以找到網盤想不到的問題。尤其是看完書後覺得，結對不是單純的從乙個人變成2個人寫。而是從乙個角色變成另外乙個角色，就像是領航員與駕駛員，在不同的位...
構建之法筆記2
鄒老師在針對這些教學的弊病以及學生所展現出的問題，他也給出了一些解決方法，而在我校本課程的實際教學中，也大量應用了鄒老師所給的方法，自身也從中頗有獲益。當然，更多的是 書中所提到的很多概念和理論方法等都將我引入了乙個全新的世界，這些在以往的學習中從未遇到 從未想到 從未經歷的事，隨著課程的學習，個人...
11 26 構建之法2
2.1 單元測試 重要的單元測試 有效解決程式設計師對模組功能的誤解 疏忽或不了解模組的變化之類的問題，使自己負責的模組功能定義盡量明確，模組的質量得到穩定的 量化的保證。好的單元測試的標準 在最基本的功能 引數上驗證程式的正確性 單元測試必須由最熟悉 的人 程式的作者來寫 單元測試過後，機器的狀態...