這次閱讀筆記主要關於團隊和流程，課上也又詳細講過，這裡簡單複習下，該章節主要介紹了典型的軟體團隊模式和開發流程以及它們的優缺點、tsp、mvp、mbp、rup
團隊的定義：玩的好的哥們組成乙個隊，他們可以稱之為乙個團隊嗎？
1、應該有一致的集體目標，團隊要一起完成這目標
2、團隊成員有各自的分工，互相依賴合作，共同完成任務
軟體團隊的模式：
1、主治醫師模式
2、明星模式
3、社群模式
4、業餘劇團模式
5、秘密團隊
6、**團隊
7、交響樂團模式
8、爵士樂模式
9、功能團隊模式
10、官僚模式
開發模式：
1、寫了再改模式
2、瀑布模式
3、瀑布模式的變形：1>生魚片模型2>大瀑布帶著小瀑布
4、rational unified process統一流程（rup），包括
a) 業務建模
b) 需求
c) 分析和設計
d) 實現
e) 測試
f) 部署
g) 配置和變更管理
h) 專案管理
i) 環境
等規程或工作流，包括初始階段、細化階段、構造階段和交付階段
5、老版驅動的流程
6、漸進交付的流程，mvp和mbp
tsp的原則：
1、使用妥善定義的流程，流程中的每一步都是可以重複、可以衡量結果的
2、團隊的各個成員對團隊的目標，角色，產品都有統一的理解
3、盡量使用成熟的技術和做法
4、盡量多地收集資料
5、制定切合實際的計畫和承諾，團隊計畫要由負責具體執行的角色來制定
6、增加團隊的自我管理能力
7、專注於提高質量，爭取在軟體生命週期的早期發現問題
經過自己的簡單分析，自己團隊模式屬於不嚴謹的功能團隊模式，說不嚴謹是因為自己團隊並未嚴格符合該模式，在一些功能的劃分上存在著交叉，導致專案開發時遇到了一些意想不到的問題。自身團隊開發模式屬於比較low的寫了再改模式，這樣會導致專案開發效率較低，不過在後期進行了及時的調整，使得開發速度加快了許多，流暢屬於比較老闆驅動流程吧。主要的體會，在進行專案開發時，一定要根據實際情況選擇適合自己團隊的團隊模式以及流程等，如果不適合及時進行調整，保證團隊的最佳狀態。模式選擇參考點（專案的需求，需要達到的目標，對質量的要求，是否需要在短時間內完成，是否需要盡早的得到使用者的反饋，是否需要後期嚴格要求的維護等等，專案的特點，團隊的人員能力水平，資源情況）
自我總結：
1、我過去怎麼做的；只要完成任務就行，團隊模式和流程沒有那麼看重
2、結合書中所講，這樣有什麼不好：團隊模式不恰當，就不能合理地發揮每個人的優點，最終可能會影響程式的完整性以及可靠的執行
3、提出乙個解決辦法，避免再次掉入陷阱：分析專案需求，根據團隊人員特點擊擇合理的團隊模式
《構建之法》閱讀筆記（三）
閱讀第四章 第五章所得 首先提到的是 規範，上課的時候老師也提到了並且強調 的規範對於閱讀 的人或者是編寫 的人來說都是很重要的。風格原則即簡明 易讀且無二義性。其中縮排 4個空格 行寬 可限定為100字元 括號 斷行與空白的 行 分行 命名 匈牙利命名法或其他 下劃線 大小寫和注釋等。複審也是極其...
構建之法閱讀筆記三
構建之法閱讀筆記之三 12 16章節 之前寫程式的時候從來沒想過使用者的體驗這一點，從來就是自己感覺怎麼簡單怎麼來，也沒有過多的想那麼多的問題，就是自己寫自己的，而且就是自己在寫 的時候很多就是跟著前人的腳步走，沒有過多的想法去創新什麼東西 看完這本書之後感覺自己差得很多，而且之前自己寫的也不是很合...
《構建之法》閱讀筆記三
在我們使用軟體的時候，我們總是因為對某個軟體有著某種需求才回去使用，那麼軟體團隊如何去了解和挖掘使用者對於軟體的需求，並且引導使用者表達出對軟體的需求。而如何獲取需求，有很多的辦法，我們最常見到的就是乙個公司上線了一款免費軟體來吸引使用者使用，同時在軟體上面設定了不少的使用者許可權來獲取使用者資訊，...