十一章：軟體設計與實現
把**修改記整合到**庫中
將開發人員手頭上的經修改過的大碼簽入源**控制系統的步驟：
1、根據場景和開發任務來決定整合的次序
2、互相依賴的任務要一起整合
3、在測試場景時，要保證端到端的測試
4、場景的所有者必須保證場景完全通過測試，然後把場景的狀態改為「解決」
開發人員的標準工作流程：
參考《構建之法》p205
在書本中提到了一點，小飛說他在辦公室裡做了10個小時：然後真正能花在開發工作的時只有3個小時，然後工作進展大概只有；兩個小時，他說他的時間主要是被一些隨機事情干擾了，然後就耗費了許多時間。其實在我的思維中，我一直覺得只要有關本次專案程式的事情，都不算是隨機事情，比如在寫程式的時候，遇到了乙個關於有效性的問題或者是完善的問題，我或許就會改變方向先將這方面做完，我覺得這點並不算是隨機事情，畢竟以後發布的正式版本還是需要考慮到這點問題。早考慮晚考慮，早晚都要考慮，老師你覺得呢？你認為這樣想可以嗎？
課後練習與討論：如何對付客戶不買賬的行為？
在我個人看法中，如果遇到這點，我覺得首先我會想是不是我和客戶溝通上出現了問題，在早期我可能會先耐心下來與客戶再次好好溝通（畢竟客戶就是上帝）,盡可能達到客戶的需求，只要能在我們小組工作範圍之內的，可以理解的要求我們都盡可能的滿足，盡快給客戶乙個滿意答覆。但是，如果我們所遇到的是一位喜歡刁難的客戶，每次都提出一些極端的要求，那麼我覺得對於這類客戶，我們之間也沒有必要有合作的餘地了。
十二章：使用者體驗
使用者體驗這章，也正是我們小組專案當前正在進行的內容，看完本章對於我們小組接下來的工作有了很大的幫組。
使用者體驗的要素：
1、使用者的第一印象
在設計方面需要注意一下幾點：
1、我們所面對的典型使用者是誰？
2、使用者初次體驗非常重要，這點必須要認真考慮。（在使用者使用次數少的功能上少花時間，要突出程式的主要功能，特色有價值的功能。）
主要涉及到5個「w"和1個「h」上:
即：who誰是目標使用者：
when使用者何時會使用我們的產品：
where使用者何地會使用我們的產品：
what我們的產品是什麼？特色在**？
why使用者為什麼會選擇我們的產品，哪方面吸引到了使用者？
how使用者如何與我們的茶農發生互動的？
2、從使用者的角度出發考慮問題
從書本上看到那個銀行假幣投訴的例子，簡直是無法理喻，這完全是阻斷了使用者使用的路徑。
3、使用者需要幫組，但是使用者沒有那麼蠢
一些簡答的解釋，如果太多了，就會變得冗餘重複囉嗦了。
4、軟體服務始終要記住使用者的選擇
經過書本上對於使用者設計的一些例子「類似於飛機上的服務遙控器」
其實這些問題看起來小，看完之後才感覺到，裡面含有許多大道理、這點，我們沒有實際遇到過，還真一時半會想不到，不過，我覺得在這方面，機組人員必須經過一番專業培訓，然後在乘客登機的時候，應該告知乘客這些東西，更多的是一種互動的方式來告知乘客，這樣就或許能達到意想不到的效果。
那麼本章問題來了，那我想請問老師，我們該如何在這第一次至關重要的使用者初次體驗中，盡可能的讓使用者達到他們想要的效果，這畢竟是第一次體驗，體驗不就是收集問題嗎？那我們這又說第一次要做到完美才行，那做到完美還怎麼讓使用者提出問題。這是不是有些矛盾？
閱讀十一 十二章節
第11章 軟體設計與實現 問題 典型的開發流程與開發階段的一些管理方法是什麼？答 從spec到實現 把修改集整合到 庫中 開發人員的標準工作流程 完成。開發階段的日常管理 閉門造車 每日構建 每天或者至少每週完成構建是非常必要的 小強地獄 構建大師。問題 每週進度報告 還有多少事沒做完 答 我們每天...
讀《構建之法》8 9 10章有感
團隊在開發前，需要跟客戶進行溝通，對於客戶提出的新的功能，pm形成需求文件交給專案負責人，經過專案負責人與團隊開發人員的討論，形成反饋文件給予客戶與pm確認，如果確立好可以進行開發。需求分析的過程時軟體開發中比較重要的過程，一旦弄錯功能需求，專案開發到一半卻要重新開始，這既浪費精力又浪費時間。對軟體...
讀構建之法8 9 10章有感
第八章 需求分析 書中介紹了一些獲取需求的常用方法 流程 及分析框架，看了後才發現原來需求分析還有著者這麼多的學問。以前聽人說，需求分析在實際專案開發中所佔分量很重，甚至往往需要花的精力比敲 要多。我聽到時不以為然 認為需求分析不就是看一下軟體要什麼功能，要做成什麼樣而已嗎。再後來，我真的接手了乙個...