msf原則:
1推動資訊共享與溝通（foster open communications）
2為共同的遠景而工作 (work toward a shared vision)
3充分授權和信任（empower team members）
4各司其職，對專案共同負責（establish clear accountability and shared responsibility）
5重視商業價值（focus on delivering business value）
6保持敏捷，預期變化（stay agile, expect change）
7投資質量（invest in quality）
8學習所有的經驗（learn from all experiences）
9與顧客合作(partner with internal & external customers)
敏捷和現有做法的區別:
現有的做法 敏捷的做法
流程和工具 個人和交流
完備的文件 可用的軟體
為合同談判 與客戶合作
執行原定計畫 響應變化
敏捷的團隊:
敏捷對團隊的要求很簡單：
自主管理（self-managing）、
自我組織（self-organizing）、
多功能 型（cross-functional）。
自主管理：以前領導布置了任務，我們實現就可以了，現在要自己挑選任務；每次 sprint 結束之後，還要總結不足，提出改進，並且自己要實施這些改進。「自主管理」 不等於「沒有管理」。
自我組織：以前做好自己的事情就好了，安心下班。現在每個人要聯合起來對專案負責， 有人工作落後了還要幫助他改進，專案缺少某類資源還要自己頂上去。
多功能型：以前規格說明書由pm來寫，測試由測試人員來做，現在每個人都全面負責， 自己搞定規格說明書，和別人溝通，同時自己搞定測試。
敏捷在實踐中的教訓 1
1. 敏捷宣言表明的是一些優先順序，不必當作聖旨或者教條來爭論。
2. scrum master 不是乙個官，而是乙個沒有行政權力的溝通者，就像微軟 的 pm 那樣。他 / 她同時還要在團隊中做具體的工作。直接把原來的 「經 理」變成 scrum master，大多行不通。
3. 一些專案需要很多暗箱操作和政治角力才能搞定，scrum 會把這些矛盾 都擺到明處。這有好處，也有風險。
4. 在複雜的專案裡，要讓一線團隊成員做決定。
敏捷在實踐中的教訓 2
5. 創業團隊其實經常是執行在 scrum 的模式中
只不過大家太忙， 沒工夫論證自己到底有多麼 scrum
6. 在 scrum 計畫階段的估計不是乙個「合同」，領導們不要把它當成乙個 合同。估計總是不准的。堅持短期的 sprint，這樣即使不准的估計也不會有大的損害。
7. 不要和管理層談「流程」，他們只關心「結果」。
8. 在大型團隊、跨地區的團隊，或者複雜專案中，scrum 並沒有非常完美 的答案，scrum 的創始人也承認這一點 。
構建之法 現代軟體工程
我理解的軟體工程 軟體工程就是把系統的，有序的，可量化的方法應用到軟體的開發，運營和維護上的過程。軟體工程包含的領域有很多，軟體需求分析，軟體設計，軟體構建，軟體測試和軟體維護。我理解的軟體工程是，這必須需要乙個團隊或者乙個小組合作才能做出優秀的產品，乙個人是不可能完成的。軟體工程並不是我以前理解的...
構建之法現代軟體工程
讀了鄒欣老師著作的 構建之法 以及參考其他眾位大神對於本書的書評後，我獲益匪淺，具體如下 首先我覺得鄒老師這本書看起來很輕鬆，當然不是指沒含量，實則恰恰相反，只是這裡我要更多的突出是另一方面，那就是這本書給讀者營造的氛圍很輕鬆，讓我不知不覺就看了好多頁，內容很豐富，其中有很多的假設，難得的是每乙個假...
現代軟體工程的構建之法
我們生活在網路時代，網路給我們生活帶了極大便利。正是因為這樣，幾乎所以的操作都會需要軟體與網路的支援。軟體開發對於我這樣的新手來說，可以說是一件很難的事。難在對各類程式語言都略知一二，並沒有掌握程式設計思想。這就是需要努力的地方。軟體有自己的特殊性 複雜性 不可見性 易變性 服從性 非連續性 幾乎每...