在10.3中提到團隊開發定製開發計畫
但我們在現實中不斷遇到的是在不斷變化的情況，有技術層面的，有系統衝突的，還有各種各樣的，如何才能從一開始就定製乙個永恆不變的計畫
在11.2.4中有寬嚴皆誤一說
我認為寬一定會助長消極情緒，倒不如在把時間直接分為兩部分前面嚴直到完成百分之80-85為止再去放鬆造各種改進直到收尾。
在12章使用者體驗中
現在的使用者都很精明 尤其中國情況 在乎面子，在乎是否收費，對介面重視 ，所以我認為這是中國開發者首要關注的問題，國內都走不通，怎麼走向世界
閱讀《構建之法》第三10 11 12章
第十章典型使用者和場景 1 典型場景和典型使用者 對使用者的認識，例如使用者的價值，如何定義使用者，使用者與場景的結合，在從場景到任務等，還有使用者的模板或者故事。2 規格說明書 1 功能說明書 定義相關的概念 規範好假設 避免誤解，界定一些便界條件 描述主流的使用者 軟體互動步驟 一些好的功能和 ...
閱讀《構建之法》第13 17章
第13章 通過場景內容進行測試驗收能很好讓人了解程式的 可用 度，能很好的反饋資訊給客戶 第14章 14.2.2問題1 既然有專人負責，那我就不用負責了 即使在開發的過程中有明確的分工，但不同人員之間要有密切的聯絡，而不是做完自己的部分就直接交個下一位，因為軟體的開發並不能如流水線生產一樣。第15章...
閱讀《構建之法》第8,9,10章
第八章 需求分析 本章節講述軟體需求的4個步驟，講述了9種使用者調研方法，nabcd模型和四象限方法，我覺得使用這幾個方法分析出來比較的具體，比自己空想要好，因為使用者的需求才是我們開發軟體的方向，如果方向錯了，只能是白做工。提出的問題 如果使用者需求很多很多，我們應該全部滿足，還是側重滿足?第九章...