本次閱讀了第十一 軟體設計與實現、十二章 使用者體驗
在做班級派團隊專案時，缺少了與團隊成員的溝通，導致作業模組的介面成為一大遺憾，而且功能的實現也有欠缺，進度的報告沒有能及時有效的提交
沒有太多的考慮到使用者的體驗，只想自己要實現的功能，可以說有些跑偏，但幸好不太多
如何避免在產品開發後期不斷有重大修改，導致其它模組的連鎖反應?
dcr tell mode vs. ask mode設計變更
在專案早期，如果大家覺得要做乙個設計變更，便可以採用告知模式（tell-mode）的形式，也就是說，修改方必須通告所有關係人：「我在這裡修改了某某介面, 我在某個api 增加了乙個引數。」但是修改方不必取得其他關係人（或者模組）的事先同意，就是說可以先行設計並編碼。當然，如果其他關係人不同意，修改還是不能簽入。
當專案進行到穩定階段，例如達到了**完成（cc）階段，tell-mode 要改為請求模式（ask-mode），這時，修改方必須先問「我是否可以在這裡修改某某介面？」（當然還要有更詳盡和充分的理由），得到肯定的答覆後，才能進行修改。這時的預設回答是「不」。
如何避免詫異的反應
問： 每次里程碑結束後，我們向客戶匯報的時候，客戶總是會驚訝地說，某某功能不是我們當初商量的那樣啊，而pm卻也同樣一臉詫異地說，不對啊，當時咱們就是這麼說好的啊，有文件為證。客戶不幹了，威脅不加/不改xx功能就如何如何，這時pm該怎麼辦?
阿超： 我們在合同裡要寫明到底我們要交付的是什麼，這就要看pm的分析和說明能力了。有時要對客戶說「不」。同時，我們在需求說明中也要從使用者的角度去描述問題和解決方案，這樣使用者才能了解他們最終會得到什麼，另乙個方面是，當你給使用者演示一些介面的時候，要說明哪些介面只是示例而已，哪些介面是大家同意的最終設計。敏捷的開發流程鼓勵使用者經常參與設計和計畫，如果有條件這麼做，那當然很好。
問： 專案開發中後期，開發人員用工具一統計，乖乖，足足xx萬行**，xx千個儲存過程，可是每到給客戶演示時，卻不時出現程式的各個功能相互不配合，不能自圓其說的尷尬場景，dev leader很鬱悶，想想自己可是沒少加班啊，**量也夠多，可是問題究竟出在什麼方面呢？
阿超： 乙個原因是每個人都沉浸在「我要寫出最強大的某某類或某某模組」中，不停地優化一些沒有人用的功能，但是真正能夠為其他模組使用的功能卻未能實現。他們忘了他們寫的**是給別人用的，而且是為了解決使用者問題的。所以這個時候我們要想想「用場景驅動」的方法，保證典型的使用者場景能夠實現。如果從「場景」出發，各個模組的互相整合就能得到充分的測試，按照場景演示起來就更有保障了。
問： 在專案開始之前, 有很多隊員還沒有接觸過程式語言（例如c#），導致pm在分配任務時很難用時間來衡量，就拿寫乙個web service這一模組來說，乙個熟練的程式設計師可能只需要兩個小時，而對於初學者來說，就得先花兩天來理解web service的實現機制和原理。在有限時間的催促下，導致一些緊急的任務不斷向高手集中，而初學者的任務越來越少。這時應該怎麼辦？
阿超： 對於這些隊員，可以考慮在他們自己的任務估計值之上再乘以4。另外，如果你是寫乙個商業專案，請不要讓連開發語言都沒有接觸過的隊員進行開發工作。並不是非得 「寫」 程式才是對專案有貢獻，有時不寫也有很好的貢獻。如果他們有熱情，就從測試開始學習吧。請參看前面提到的「大馬哈魚洄游模型「
今後一定會做好組內溝通，在每一階段都找一些潛在使用者來測試我們的軟體並請他們提出建議，自己每天的進度也要寫報告，順帶練習寫文件的能力
構建之法閱讀筆記04
夢斷 01 人類文明執行於軟體之上。但是，軟體建立藝術卻隱於暗處，即便對於專家們也是如此。在歷史上，我們從未如此的完全依賴於這樣一種人類自己不知道怎麼樣做得好的產品。在對軟體系統的加速依賴和踱著步學習怎樣做好軟體之間，有一條巨大且有時叫人恐懼的壕溝。對軟體的依賴以指數級增長，而做軟體的技能 和應用技...
構建之法閱讀筆記04
1.msf，微軟解決問題框架，他有如下基本原則 1 推動資訊共享與溝通2 為共同的遠景而工作3 充分授權和信任4 各司其職，對專案共同負責5 交付增量的價值6 保持敏捷，預期和適應變化7 投資質量8 學習所有的經驗9 與顧客合作。在msf團隊模型中任何技術專案都必須到達特定的關鍵質量目標，才能被認為...
構建之法閱讀筆記04
第七章，msf msf是微軟解決方案框架，也就是微軟推薦的軟體開發方法。它有9條基本原則 1.推動資訊共享與溝通，就是所有信心都保留並公開2.為共同的遠景而工作3.充分授權和信任，關鍵是授權，一是給某人權力和權威，二是給與某人更多自信和自尊4.各司其職，對專案共同負責，即團隊中每個角色都有自己的職責...