《20171130-構建之法：現代軟件工程-閱讀筆記》

軟件 = 軟件 + 軟件工程

軟件質量=程序質量+軟件工程質量

軟件工程的質量體如今：軟件開發過程的可見性、風險控制、軟件內部模塊，項目中間階段的交付質量，項目管理工具的因素、開發成本的控制、內部質量指標的完成。軟件的質量不能僅僅依靠測試人員去保證，編程人員在進行編程時要盡力保證本身代碼的質量以及各模塊鏈接之間的穩定性。

 《構建之法》中印象比較深的是其中有一章講解了「典型用戶和場景」，書上開始舉了一個很好理解的例子，是一個理髮師給顧客剪頭髮的例子，由例子可見，你光看用戶的表面語言是不夠的，咱們應該理解的是用戶語言背後的動機。當咱們作一個服務於顧客的軟件時，咱們應該遵循的規則是同樣的。在咱們軟件的需求分析中，顧客的分析是必不可少的。咱們應該羅列咱們軟件的典型用戶，咱們應該分析他們的需求，針對他們的特色來肯定咱們的軟件服務於誰，而且要實現哪些具體的功能。咱們應該設計一個場景，這個場景是咱們的用戶最可能使用咱們的軟件時遇到的場景。將用戶放到這個場景中，分析咱們的軟件應該爲用戶如何提供更好地服務，讓用戶使用起來更方便。在咱們本身這學期的軟件製做中也是同樣，咱們應該有典型用戶的分析，來明確咱們的軟件究竟是提供給哪個類型的用戶使用，而且用戶大多數狀況下是在什麼場景使用咱們軟件，這是咱們必須考慮的。因此咱們應該肯定典型用戶，咱們的典型用戶應該就是當下的大學生，因此咱們應該切實從大學生出發，場景應該爲學校，因此咱們應該從在學校使用咱們軟件的大學生出發去完善咱們軟件的功能。

每一個團隊都應該有本身的團隊績效，應該用團隊績效來評估該團隊的成員在這一階段對這個軟件作出的貢獻。咱們應該從不一樣的方面來評估一我的在這一階段對軟件作出的貢獻。單單從一個方面去評估一我的的價值是不合理的。每一個人在每一個方面的貢獻都是不可低估的。另外這章中還提到了團隊合做的幾個階段，開始你們彙集在一塊兒，是團隊的萌芽階段，每一個人都很生疏，不知道作事的流程，不知道在團隊中該怎麼作。接着團隊進入磨合階段，這時候團隊中會迎來疑惑和衝突，這正是咱們的磨合期，沒有任何一個團隊能夠一團和睦的從頭至尾，爭吵總會有的，關鍵也在於咱們應該尊重別人的意見把團隊磨合的愈來愈好。接着進入規範階段，每一個成員彷佛都意識到了爭吵是沒用的，每一個人都知道了工做流程，循序漸進的工做，最後是創造階段，進入這個階段的團隊已經很厲害了，這個階段的團隊已經能夠本身創造出一些屬於本身的東西。咱們的團隊已經成立了一段時間，好像還處於第一階段，咱們對本身的工做流程好像並不熟悉，咱們仍是沒有規整的工做計劃，咱們應該制定一個工做計劃，堅持天天彙報本身的工做，而且爲每一個人分配好固定的工做，而後你們一塊兒努力爭取早日進入規範階段。