第8章 需求分析
問題：8.6 在這一章節中，說的是計畫和估計，我覺得這是程式設計最基礎的問題吧，如果不能很好的估計出程式設計所要寫的時間，就說明對程式設計沒有足夠的了解和認識，但是我在想，如果做乙個工作量很大的軟體，有些可能難以估計出時間的，而且還要整合各個人寫的功能部分，這時該怎麼去顧及呢
第9章 專案經理
問題：專案經理就是pm，在這一章節中，內容比較少，在9.3節中，標題就寫到pmzuo開發和測試之外的所有事情，那麼pm豈不是要做很多的事情，會不會把pm給累壞了，書中寫到pm是帶領團隊達成最重要的目標，並保持團隊的平衡，其實pm要做的具體內容是什麼呢？我還是不清楚
第10章 典型使用者和場景
問題：在10.1.3中怎麼才可以準確的定義使用者典型呢， 還有如何去驗證定義的典型使用者是正確的
《構建之法》 閱讀（第13章 第17章）
第13章 軟體測試 1.名詞解釋 bug 軟體的缺陷 test case 測試用例。測試用例描述了乙個完整的測試過程，包括測試環境 輸入 期望的結果等 2.bug解釋與例項 1 bug可以分解為 症狀 symptom 程式錯誤 fault 根本原因 root cause 症狀 即從使用者的角度看，軟...
閱讀《構建之法》 第5 5 第6 第7章
第5章 敏捷開發以使用者的需求進化為核心，採用迭代 循序漸進的方法進行軟體開發。在敏捷開發中，軟體專案在構建初期被切分成多個子專案，各個子專案的成果都經過測試，具備可視 可整合和可執行使用的特徵。關於每日立會，雖然書中提到可借用文件和其他輔助手段來進行溝通，但聽說在異地開發模式下很難實現快速構建 快...
閱讀《構建之法》第10,11,12章
在10.3中提到團隊開發定製開發計畫 但我們在現實中不斷遇到的是在不斷變化的情況，有技術層面的，有系統衝突的，還有各種各樣的，如何才能從一開始就定製乙個永恆不變的計畫 在11.2.4中有寬嚴皆誤一說 我認為寬一定會助長消極情緒，倒不如在把時間直接分為兩部分前面嚴直到完成百分之80 85為止再去放鬆造...