這個星期我學習了構建之法的第9章、第
10章和第
11章。
第9章
這一章，首先我知道了pm代表著什麼，pm的
m就是manager
，但是p
有好幾種：
product manager
、project manager
、program manager
，不同的行業和公司對
pm有不同的解釋，但是在這一章，介紹的是微軟的專案經理—
program manager
。專案經理主主要的職責就是根據市場和使用者需求，協調各部門資源，正確地把握產品定位和方向，解決使用者的痛點，持續優化產品。在書中我們可以看到在軟體行業開始的初期，對於專案的分工，團隊之間會存在很大的爭議。但pm的出現很好的解決的這個問題，
pm有兩個重要的特性：
1.負責乙個功能的開發
/測試人員和相關的
pm密切合作，再由
pm代表這一小組去和別的小組或者客戶打交道，大大降低了交流的成本。
2.有專人負責開發
/測試之外的許多事物和專案進度的管理，讓開發和測試人員專注於技術方面的工作。也就是說，
pm做開發和測試之外的所有事情。包括在開發和測試過程**現的風險，
pm要在整個專案的生命週期管理風險。這就要求
pm在風險管理中做到：
1.發現問題後及時了解情況
2.緩和並且防止問題
3.預計
4.把問題變為機會 。
作為乙個合格的pm，需要有一下幾項基本的能力：
1.觀察、理解和快速學習能力
2.分析管理能力
3.一定的專業能力
4.自省的能力。在專案完成期間要積極與組內成員做好溝通，仔細了解每個人對專案投入的認識，整合出來，這對於當好乙個
pm也是至關重要的！
第10章
在這一章中，我學習到了在專案中的典型使用者和場景，了解到了在實現使用者需求的時候，光看使用者的表面語言或者行動還是不夠的，還需要找到使用者語言或者行動背後的動機！
在軟體設計的過程中，軟體開發者會以自己的視角用專業的知識完成整個操作，但是軟體最終設計出來是給使用者使用的，往往那些使用者對電腦不是那麼熟悉，這時候，我們就需要設想出「典型使用者」，強迫我們在考慮問題時從使用者出發。「典型使用者」的設計也需要從不同方面考慮：受歡迎的典型使用者和不受歡迎的典型使用者。我們還需要與這些設想後的典型使用者的現實生活中的代表交流，了解他們的需求，在對自己的典型使用者細化、修改。
在這之後，就需要考慮場景了。典型使用者想要通過系統實現什麼目的，這就是場景所需要完成的。描述典型使用者在這個場景中所處的內部和外部環境，給場景劃分優先順序，按優先順序排序寫場景。不同的任務會把乙個場景編織起來，在這個場景中，我們就需要模仿典型使用者，完成他們的潛在需求。
在實現使用者需求的過程中，用例也是很常用的需求分析工具。它的原則是：1.通過講簡單的故事來傳遞資訊
2.保持對全系統的理解
3.關注使用者的價值
4.足部構建整個系統，一次完成乙個用例
5.增量開發，逐步構建整個系統
6.適應團隊不斷變化的需求。
對於乙個完整的軟體，要想使用者對自己的軟體有較高的熟悉度，規格說明書是必不可少的。軟體功能說明書是主要用來說明軟體的外部功能和使用者的互動情況。軟體技術說明書是主要用來說明軟體內部的設計規範。
為了源源不斷地實現使用者的需求，就需要功能驅動設計，即fdd。它的步驟是：
1.構造總體模型
2.構造功能列表
3.制定開發計畫
4.功能設計階段
5.實現具體功能。
總之，在軟體開發過程中，一定要對典型使用者和場景這一塊內容有深刻的理解，不然對實現使用者的需求會有很大影響。
第11章
我們寫軟體就是要解決使用者的需求，在這個過程中，需要很多的分析與設計，包括以文字為主的文件、用圖形為主構造的模型、用數學語言的描述、用類自然語言+**構造的描述和源**加注釋也能描述。
書中主要介紹了圖形建模和分析方法，它主要是表達實體和實體之間的關係、表達資料的流動、表達控制流和統一的表達方式。當然還有其他設計方法，比如形式化的方法和文學化程式設計等。從設計文件到最後實現，不單單是只需要研究**，在**中可能會有很多漏洞，各個模組之間的合作還有很多問題。測試使用者的需求方面，可能還有很多修改意見。但是，從乙個專案製作以來，從無到有，從簡到繁，把之前的設想變成真真正正的軟體，也是一件非常了不起的事情。
對於開發階段的日常管理，首先，我們做開發軟體，並不是讓團隊像被關在監獄裡面一樣，要有大家自由交流的時間。其次，要想成為乙個成功的軟體公司，在對於每個專案，都要實現每天或者至少每週完成構建，當有乙個能執行的系統時，即使是乙個簡單的系統，團隊的積極性也會上公升。然後，就是在面對構建一直失敗的情況下，針對做事不仔細的人，鼓勵他們，這樣他們自己在受到關注後，也會對專案更加用心。最後，在成員個人行為只影響個人的時候，放鬆處理；但是危及到團隊的話，就要嚴格處理。
總之，在面對軟體設計與實現的時候，我們要盡可能細化到每乙個小細節，完成每乙個小功能，這樣最終才能製作出符合使用者需求的軟體。
第五次《構建之法》觀後感
開篇就講到乙個概念即 軟體 程式 軟體工程。書中說到，程式指的是源程式，也就是基於資料結構上的實現演算法，這是我們軟體學生的基本功。程式設計師需要對 不斷編寫，程式越來越龐大，就需要源 管理。程式是要正確執行的，就需要軟體測試。我們寫的程式需要讓別人的看得懂，就得運用程式理解。程式總會出現bug，就...
第五次作業 關於《構建之法》的心得體會
閱讀了鄒欣老師的 構建之法 這本書，我感受頗多。上個學期在學習軟體工程的課程的時候，並沒有很大的學習興趣。但是讀了這本書，我完全有了新的感受。以下是我的學習心得。閱讀這本書使我對下面個人技術和流程 分析了軟體工程師的成長 軟體團隊合作的幾種模式和開發流程 敏捷流程 需求分析 專案經理 使用者體驗 軟...
構建之法現代軟體工程（第五次）
構建之法現代軟體工程 第五次 這週我閱讀了 構建之法 第六第七章 1 盡早並持續地交付有價值的軟體以滿足顧客的需求 2 敏捷流程歡迎需求的變化，並利用這種變化來提高使用者的競爭優勢 3 經常發布可用的軟體，發布間隔可以從幾周到幾個月，能短則短 4 業務人員和開發人員在專案開發過程中應該每天共同工作 ...