hw3-Four case study

@Version:v2

@Date:2017-10-16

@Author:顏慷

Situation1:

• 問題一：member T對於他人建議充耳不聞，在scrum meeting中，沒遵守scrum meeting精神，只是自顧講自己覺得重要的細節。

• 問題二：Project lead C對於requirement文件視而不見，並且會在不通知任何人的情況下，在implementation階段直接改掉原先的design。

• 上述例子在課本中，在Project management的Risk management部分，有兩種風險，第一是Project risk affects the project schedule，因為上述兩者都沒遵守在該場域所應有的原則，所以，除了影響project schedule，另外，Product risks affect the quality or performance of the software being developed，在implementation不能再擅自修改之前訂下的requirement，影響software的品質。

• 關於上述問題，我的solution是要有risk management的機制，舉例來說，把requirement當作是一個重要的risk type的指標，在risk analysis 時，他的effects是serious的程度，有了metrics能夠follow up，這樣也會使得Project Lead Ｃ不會輕易改掉requirements，指為了貪圖design流程的方便。

• 另外，課本提到對付Requirement changes的策略，Derive traceability information to access requirements change impact，把沒有follow up的impact記錄下來，當作一個能保護自己的武器。

Situation2:

• 問題一：Project lead Ｃ對於design documents與requirement documents沒有清晰的認知差異。

• 問題二：Project lead Ｃ沒有軟體工程背景，對於design總認為是一些可以看見的東西，至於requirement document卻不去在意。

• 問題三：Project lead Ｃ對架構師傳遞錯誤訊息，讓架構師白跑一趟，並且使他誤以為target user已經同意requirement，甚至惹火target user。

• 問題四：Project lead Ｃ有走捷徑的前科，在尚未測試完畢，就直接把delivery裝在客戶端。

• situation2最大的關鍵是，Project Lead C沒有軟體工程背景，所以在requirement documentation, design documentation, implementation每個階段要執行的任務都沒有清楚的認知。 另外，正因為他是中國人，在當時的能力尚未具足情況下，被promote成Project Leader， 所以他所遇到的另一問題是在他其實是沒有這個背景知識勝任此職務的。

• 如果我是在此Project Leader C底下做事的人，看到這樣的情況，我的solution，會有以下步驟，

• 第一，先檢視自己有沒有在每一個任務、步驟都能夠follow way of working，如果有任何類似混水的行為就盡可能修正，並且參考Software Engineering的Textbook，了解一個Software Project Management所需具備的核心activity(Project planning, Risk Mamagemnt, People management, Reporting Project managers)，

• 第二，在檢視完自己能夠follow the way of working後與了解是否能夠掌握Project Leader的核心技能，接著就是持續積累用正確做事的資料，ex持續留下document，不需要直接跑去跟Project LeaderＣ說他的錯誤，而是在出事時，能夠出去救火，並且在救火時劃宣示是自己救了他，

• 簡單來說，用行動來證明，讓旁人清楚看見我與原先Project Leader的差別，如果最後旁人都沒有聲音，那麼就考慮離開該環境。

Situation3:

• 問題一：Team Member T沒有考慮新ORM的整合問題。

• 問題二：與沒有displine的大陸人工作很受挫，同時還得應付台灣team的無理deadline。

• 在situation3中，我覺得很多情況是與之共事的member背後的background knowledge就有很大差距，所以他很可能連ORM能否整合的問題都不明白，說不定他可能是個programmer還稱不上是software engineer。

• 另外，對應到risk management中屬於tool的風險， 我的solution就像上課的例子，用行動來證明，而非用言語的辯論，在證明成功後，留下document，讓其他人能夠清楚trace records.

Situation4:

• 直接證明ORM能夠抽換底層的DB，而非跟Member T爭論

• 對應到課本的risk type 分類，屬於Database performance，如果我是Project Leader，甚至底下的member沒法解決整合問題時，就要有另外的策略。

• solution是準備investigate買higher-performance 的database。

Artifacts :

• 定義：Artifact是一個general 的term，包含在系統開發中任何被創造、修改、使用的資訊

• 例子：在軟體工程中，像是UML diagrams, user-interface sketches, prototypes, test plans and test procedures。

• 基本上，artifacts又能分為兩種類型，一種是management類型，另一種是engineering類型，前者比較偏向business case and the development plan，後者就像UML diagrams, user-interface sketches, prototypes, test plans and test procedures.