第九章專案經理
這一章給予我們對專案經理這一職業初步的認識，那麼現在我們每一組組長的角色是不是與「專案經理」有一點點相似？在乙個團隊中發揮統籌協調作用，與其他成員平等工作，對決策的過程享有平等的話語權，使乙個團隊保持平衡。
不是所有的人都擁有成為一名pm的潛質和能力，但我認為快速學習能力、分析管理能力與專業能力這些對pm的基本要求，也是所有軟體開發人員必備的素質。
第十章典型使用者和場景
在需求分析階段，我們必須考慮各種不同型別的目標使用者。而且，光看使用者的表面語言或行動還不夠，更重要的是找到這些語言和行動背後的動機。
為了更好地從使用者的角度出發思考問題，我們可以通過定義典型使用者的方法來思考他們的想法、習慣、能力、偏好以及使用場景等等。一款軟體並不是為所有人服務的，因此明確定義典型使用者是非常關鍵的步驟。
乙個典型場景就是乙個故事，它詳細地記敘了乙個完整的使用者與系統互動的流程。就像我們在設計我們的調查問卷與確定功能時，我們會站在使用者的角度上去思考他想要呈現在他面前的是乙個怎樣的介面，他完成一件事情的流程與步驟是什麼樣的。這其中也有一點user case的思想。
「別迷失在長長的功能列表中，牢記軟體的價值在於給使用者提供價值。」
當我們構造完了功能列表，就要思考各個功能之間的依賴關係、實現的難易程度等，以此來確定功能實現的先後次序，同時還必須考慮很多現實因素，制定開發計畫。在開發階段，還不能忘記及時發布文件。
第十一章 軟體設計與實現
從使用者的需求是什麼，到如何解決需求，再到是否真正解決了這些需求，我們的軟體開發過程需要時刻圍繞使用者的需求開展分析與設計工作。多種圖形建模方法各有特點，有的自由靈活，有的簡單明瞭，有的還可以表達資料的流動。上軟工課以來不止一次的聽到uml，這裡是第一次知道它的確切含義。但grady booch的這句話給我留下了深刻印象——「在uml出現之前和之後，軟體專案成功的關鍵依然是-智慧型地使用技術、遵從乙個好的軟體開發過程、有經驗的開發者和適當的技能組合。」
談到開發階段團隊可能會出現的一些問題及解決辦法，給了我很多思考。
第一，每日的全體會議是否必要？因為團隊成員的自我時間管理也很重要。當通過e-mail交流和報告時，可以根據e-mail的緊急程度做乙個分類，每隔兩到三個小時集中處理這些問題。
第二，當團隊成員的行為只是影響到個人時，可以自由靈活地根據自己的情況處理，但當影響到整個團隊時，就必須遵循嚴格的規則和流程。
第三，要平衡好進度和質量，不能只追求「我寫完了所有的**」，因為寫完**不代表沒有問題。如果不及時地修復一些小漏洞，問題的雪球就會越滾越大，則會給測試工作帶來極大的麻煩。
第十二章 使用者體驗
「有一顆為使用者著想的『同理心』，是好的產品設計的出發點。」
本章中作者模擬了很多其他行業的產品，生動形象地闡述了使用者體驗和使用者介面設計的重要性。從使用者的角度出發，為他們減少認知阻力，讓他們用軟體用得順手用得舒服。
構建之法讀書筆記（三）
project manager 專案經理乙個神秘的角色，他就是夾在銷售人員與程式設計師之間的溝通媒介，銷售人員的方式程式設計師理解不了，程式設計師只想安安靜靜的敲 因此就出現乙個角色 專案經理，負責的就是將銷售人員的方式轉換為程式設計師可以理解的形式，這樣開發的效率就會大大的提高，同時專案經理不僅僅...
《構建之法》讀書筆記（三）
構建之法 讀這本書教會了我在團隊開發時的團隊合作。首先是 規範 1.風格規範。2.設計規範。一.風格規範 1.縮排 一般用四個空格的距離，從可讀性來說正好。2.行寬 行款可以限定為100字元。3.斷行與空白的 行 盡量 if a else 4.分行 不要把多條語句放在第一行。5.命名 在變數名中不要...
構建之法讀書筆記三
在做專案開發上，團隊協作尤為重要。之前也說過 需求分析 的問題，但在讀書過程中我發現了乙個問題，假如使用者方出現了需求更改，或者在原有的基礎上新增了乙個棘手的需求，導致工作變更怎麼辦？回答還是協商。坦白說看到現在我能用兩個詞概況軟體工程要幹的事情 開發與溝通。但要是跟使用者協商溝通，雖然能達到乙個妥...