在做專案開發上，團隊協作尤為重要。之前也說過「需求分析」的問題，但在讀書過程中我發現了乙個問題，假如使用者方出現了需求更改，或者在原有的基礎上新增了乙個棘手的需求，導致工作變更怎麼辦？回答還是協商。坦白說看到現在我能用兩個詞概況軟體工程要幹的事情：開發與溝通。但要是跟使用者協商溝通，雖然能達到乙個妥協的局面，但難免會給使用者留下乙個不是很好的印象，畢竟使用者看到的是最終結果，他不會管過程是否艱辛。我們作為開發人員也不可能直接跟使用者說：「我們就按照你這個需求來了，不要再有變動了。」我們只能去預期變化，如果將變化的可能性考慮在內，做出應對會簡單很多。
對團隊模式的討論，書中給了幾種團隊模式，一讓我在意的是怎樣才能成為乙個「敏捷團隊」，如果我站在使用者的角度，我指定的開發團隊如果很「敏捷」，那我會非常開心。敏捷團隊要求三點：自主管理，自我組織，多功能型。且不說後兩個，第一點就能砍下去大部分人，人總是愛摸魚的。此外，團隊也是會出現變化的，比如人員變更什麼的，這也是團隊工作中要注意的一點，作為乙個新成員要盡快融入進去；作為乙個老成員要帶新人，幫助他盡快融入氛圍。這並不是領導者的義務，而是團隊成員的義務。
第七章的msf，之所以要單獨拿出來說，是因為這一章，作為學生我看到的是高質量團隊的高效率工作，他們能做出嚴密的測試工作，是實打實的敏捷團隊。如果我以後步入工作，再回過頭來看這一章，說不定能有新的收穫。軟體工程團隊已經做出了大量的介紹，接下來就是對使用者的分析了。使用者需求分析妥當，我們才能有目的的開發。在開發自己產品的時候，就要面向市場需求，首先就是定義自己這款軟體，面向什麼使用者。面向學生，那就做的酷炫一點；面向大眾，那就簡約一點。而且每個使用者期盼的功能還不一樣，為此要做出大量的市場調查。第十章的典型使用者分析講解的十分詳細，包括規格說明書的寫法，在這一章有很多乾貨。這是乙個詳盡的開發思路，而不是三分鐘熱度的「我要做這個」，「開始行動吧」，這種籠統的概括。
構建之法讀書筆記（三）
project manager 專案經理乙個神秘的角色，他就是夾在銷售人員與程式設計師之間的溝通媒介，銷售人員的方式程式設計師理解不了，程式設計師只想安安靜靜的敲 因此就出現乙個角色 專案經理，負責的就是將銷售人員的方式轉換為程式設計師可以理解的形式，這樣開發的效率就會大大的提高，同時專案經理不僅僅...
《構建之法》讀書筆記（三）
構建之法 讀這本書教會了我在團隊開發時的團隊合作。首先是 規範 1.風格規範。2.設計規範。一.風格規範 1.縮排 一般用四個空格的距離，從可讀性來說正好。2.行寬 行款可以限定為100字元。3.斷行與空白的 行 盡量 if a else 4.分行 不要把多條語句放在第一行。5.命名 在變數名中不要...
構建之法 讀書筆記三
現在已經讀完這本書了，感覺自己又充實了。首先了解了敏捷開發的基本原則 1.盡早並持續地交付有價值的軟體以滿足顧客需求。2.歡迎需求的變化 3.經常發布可用的軟體，間隔時間盡可能的短 4.團隊每天共同工作 5.以有進取心的人為專案核心 6.面對面的交流 7.發布可用的軟體 8.領導 團隊和使用者應該能...