專業主義

大概在今年6月底收到MTD team的需求，希望開發一個Tool，把所有machine test reports 做一個資料分析，彙整成一份報告(csv格式)。

以下是一開始從MTD team收到的資訊:

• 目前大約有200台machines, 都放置在 ~\machine_data 資料夾裡面
• 每個machine有60個test report要分析
• 每個test report 依據test name，存放在~\mXXXX\test_results\YS@prepship\Test
• 每個test report的xml格式都很類似

時程估算方面，依據之前工程師用matlab開發MAS的經驗，一個test report大約一個小時，所以粗估60個test reports大約要7天。

然後，我就開始做了...災難也開始了...

首先，根據MTD team的說法，由於我先前已經做了一個parsing tool，所以"只要修改一下"原本的parsing tool，便可以符合他們的需求。
這個認知整慘我了...
因為 input 與 output已經不同了，我幾乎是重寫整個parsing tool，這部分大概花4天，絕對不是"只要修改一下"

再來，MTD team給我的資訊只有部分正確，詳述如下:

1. 目前大約有200台machines, 都放置在 ~\machine_data 資料夾裡面
• 錯! 200台machines的資料放置在 ~\machine_data 與\\172.xxx.xxx.xxx\d 資料夾裡面
•  ~\machine_data 不需要 Id/Password ，但是\\172.xxx.xxx.xxx\d 需要Id/Password才可連線，這部分大概花了1天
2. 每個machine有60個test report要分析
• 錯! 60個test report是200/250的machine，後來又新增加了12個350的test reports
• 這12個新增加的test reports是全新格式，這部分大概花2天
3. 每個test report 依據test name，存放在~\mXXXX\test_results\YS@prepship\Test
• 錯!~\mXXXX\test_results\YS@prepship\Test 這個資料夾結構是人工後續手動輸入，因此有很多錯誤，造成test report 找不到
• 因此，只好加入log，針對找不到的test report手動把資料夾結構調整成正確
• 手動把資料夾結構調整再加上log機制，就花了3天
4. 每個test report的xml格式都很類似
• 錯!xml schema只要有一點點不同就必須"特別處理" (special handle)。幾乎每個test report都要個別處理，共通性的test report少之又少...
• "特別處理"意味著需要額外的effort，大概花了6天

另外，最後彙整產出的csv檔案還需要加上:

• 顯示machine type (從CM_Options.xml讀取)
• 顯示單位(從HTML而來)
• test report (xml) 與CS 習慣閱讀的HTML，KPI顯示的字串不同，必須一個一個檢查

這些零零總總又多花了3天...

總結上述天數是19天，是原本粗估(7天)的2.7倍...
在開始專案之前，我應該要審慎評估的，這才是專業!

Functional requirement & Non-Functional requirement

要寫好一份'軟體需求規格文件' (SRS) 不容易。 '使用者需求'是它的Input，'軟體設計文件' 是它的Output。
[User Requirements] --> [SRS] --> [SW Design (High Level Design + Detailed Level Design)]

什麼樣的SRS才是好的? 下列四點是個不錯的判斷依據:
1. 提供回饋給user。最好的回饋方式就是讓User看到! 比如UI、Output files, Tools
2. 用軟體的觀點來看問題，把問題分解成幾個SW components。What (SW components, Tools) should be enhanced/changed/updated/removed/created...
3. SRS是SW design 的Input。SRS 只需定義'規格' (What)，它是一份合約。實作方式則定義在SW Design (How)。
4. SRS 必須用'外顯'、'可量測' 的角度來撰寫，好讓Tester判斷正確性。

看了許多的 SRS, 節錄出下列幾個重要方向:
Functional requirement: 定義系統要做的事 (What the system does)
• Business Rules
• External Interfaces (ex: UI, output files...)
• Audit Tracking (ex: Logging)
• Transaction corrections, adjustments and cancellations
• Administrative functions
• Authentication
• Authorization levels
• Certification Requirements
• Reporting Requirements
• Historical Data
• Legal or Regulatory Requirements

Non-functional requirements: 定義系統的能力 (What the system's capability - the power to do it)
• Reliability - 可以依據既定規格而持續運行的能力
• Serviceability
• Availability
• Performance – for example Response Time, Throughput, Utilization, Static Volumetric
• Scalability -  To handle a growing amount of work (系統處理工作量的成長)
• Capacity - 系統可以產出(或提供服務)的最大量
• Recoverability
• Maintainability: 維持原有的形式，萬一發生錯誤也可以回復到原有的形式
• Security
• Regulatory
• Manageability
• Environmental
• Data Integrity
• Usability
• Interoperability

Non-functional 影響層面有:

• Reliability: Improvement in number of hits [hits/ syst yr] (Hit 次數)
• Serviceability: Improvement on Maintenance and in MTTR (diagnostics, access, repair and/or recovery) repairing of system [hrs] (維修, 回復 時數)
• Availability: Improvement in hours of downtime both USD (Unscheduled) as well as SD (Scheduled) [hrs/syst yr] (Downtime 時數)
• Manufacturability: Improvement in CT (Cycle Time) or A-time in production [hrs/ syst]
• Safety: Improvement of probability of incidents occurring
• Usability: Functional improvement of machine for operator
• Machine Performance: Non-functional improvement of customer requirements

Pull System v.s. Push System

Pull system 與 Push system 的差別在於 - 工作是如何分配給 developer 去做?

Pull system: (developer 自己拿工作)
所有工作根據 priority 被條列在 product backlog上。目前手邊沒事做的 developer 可以由 product backlog 上面把 high priority 的工作拿下來做 (pull the work out of the list)

Push system: (工作被分配給 developer)
主管建立一些工作，然後把工作分配給 developer 去做 (work is pushed to developers)

Story Point v.s. Velocity v.s. Focus Factor

Story point:
用來量測 story 複雜度的一種方式，是一種 story 的 size。每個 team 可以有自己的量測方式與單位 (days or hours)。已經定下來的 Story point (即使非常不精確) 也不應該隨著時間而改變。隨著每個 sprint 加入新的 story，這些新的 story 可以與之前舊的 story 做比較，而得到比較精確的 story point。

Velocity:
用來量測 team 可以完成多少 stories 的一種方式。每個 team 可以有自己的量測方式與尺度。如果 story point 的估算是具有一致性， velocity 便可以顯示出 team 的 performance 是加速還是減速。如果想要提高 velocity， 可以透過各種方式來改善 team 的 performance。


Focus factor:
用來量測這個 team 有多少時間比率花在 story 上面。Focus factor 的算法如下：
   Focus factor = Velocity / Capacity

比如說，team 的平均 Velocity = 41，team 的平均 capacity = 6 people * 12 days = 72 man-days
則 Focus factor = 41 / 72 = 0.57 ( 0.57 story point can be done per man-day)

一般 focus factor 會先抓 0.5，也就是一天 8 小時的工時，其實只有 4 小時會花在 story 上。
其它時間則花費在會議 (非story相關的會議)，寫報告 (非story相關的報告)，請假，等等

有了focus factor，便可以用來預測這個 team 在這個 sprint 可以 deliver 多少個 stories。
假設這個 team 在這個 sprint 可以有的 capacity = 6 people * 13 days = 78 days， 則這個 sprint 可以 deliver 的 story points 為：
   Story points (for this sprint)= 78 * 0.57 = 44 [story points]

Everything MUST be transparent

敏捷式開發強調快速反應!

為了達到這樣的好處，"事事溝通"非常重要 - 任何事情都要溝通。

360度溝通 - 對上級，對測試人員，對客戶，對使用者...都要溝通。