[畫蛇添足] 1. 結構師的交互準則和機制 2. 自律---開發第二個系統所帶來的後果 [貫徹執行] 1. 文檔化的規格說明---手冊 2. 會議和大會 3. 電話日誌 4. 產品測試

1. 畫蛇添足&貫徹執行
解說人 : Vito

2. 畫蛇添足 ( The second-system effect )
1. 結構師的交互準則和機制
2. 自律---開發第二個系統所帶來的後果

3. 結構師的交互準則和機制
1. 開發人員承擔創造性和發明性的實現責任，只能建議，不能支配。
------對建議保持低調與平靜

4. 結構師的交互準則和機制
1. 開發人員承擔創造性和發明性的實現責任，只能建議，不能支配。
------對建議保持低調與平靜
2. 時刻準備著為所指定的說明(功能、特性)，建議一種實現方法，同樣準備接受其
他任何能達到目標的方法。
------既要對功能提出建議的實現方法，又要準備放棄堅持所做的建議

5. 結構師的交互準則和機制
1. 開發人員承擔創造性和發明性的實現責任，只能建議，不能支配。
------對建議保持低調與平靜
2. 時刻準備著為所指定的說明(功能、特性)，建議一種實現方法，同樣準備接受其
他任何能達到目標的方法。
------既要對功能提出建議的實現方法，又要準備放棄堅持所做的建議
小結 : 一般來說，開發人員會反對結構上的修改建議，通常他是對的，當實現產品
時，某些特性修改會造成意料不到的成本開銷。（一個看似小小的變動，可能要多
花１倍的時間）

6. 自律---開發第二個系統所帶來的後果
[what] 開發第二個系統時，添加許多不必要的功能與想法，導致時間成本提高數倍，
但其質量並不一定有所提高。

7. 自律---開發第二個系統所帶來的後果
[what] 開發第二個系統時，添加許多不必要的功能與想法，導致時間成本提高數倍，
但其質量並不一定有所提高。
[why] 開發第一個系統時，由於大家對系統的認知都不夠了解，結構師傾向於精煉
和簡潔來達成目的。而有了先前的經驗，第二個系統往往是最危險的，結構師會向
系統添加很多複雜的功能與想法，導致開發困難。

8. 自律---開發第二個系統所帶來的後果
[what] 開發第二個系統時，添加許多不必要的功能與想法，導致時間成本提高數倍，
但其質量並不一定有所提高。
[why] 開發第一個系統時，由於大家對系統的認知都不夠了解，結構師傾向於精煉
和簡潔來達成目的。而有了先前的經驗，第二個系統往往是最危險的，結構師會向
系統添加很多複雜的功能與想法，導致開發困難。
[how] 應避免畫蛇添足(多做不必要的事，反而徒勞無功 )，其方法 :

9. 自律---開發第二個系統所帶來的後果
1. 必須堅持至少擁有二個系統以上開發經驗的結構師的決定
------多聽多看再下決定

10. 自律---開發第二個系統所帶來的後果
1. 必須堅持至少擁有二個系統以上開發經驗的結構師的決定
------多聽多看再下決定
2. 保持對特殊誘惑的警覺
------減少華而不實的特性修改與不必要的功能想法

11. 自律---開發第二個系統所帶來的後果
1. 必須堅持至少擁有二個系統以上開發經驗的結構師的決定
------多聽多看再下決定
2. 保持對特殊誘惑的警覺
------減少華而不實的特性修改與不必要的功能想法
3. 不斷提出正確的問題，確保原則上的概念和目標在詳細設計中得到完整的體現
------看到問題一定要問，提前消除可能碰上的麻煩

12. 貫徹執行 ( Passing the word )
1. 文檔化的規格說明---手冊
2. 形式化定義
3. 直接整合
4. 會議和大會
5. 多重實現
6. 電話日誌
7. 產品測試

13. 貫徹執行 ( Passing the word )
1. 文檔化的規格說明---手冊
2. 形式化定義
3. 直接整合
4. 會議和大會
5. 多重實現
6. 電話日誌
7. 產品測試

14. 文檔化的規格說明---手冊
概要 : 手冊或規格書，是非常必要的工具，它描述了和規定了用戶所見的每一個細
節，它也是結構師主要的產物。（類似我方的UX）

15. 文檔化的規格說明---手冊
概要 : 手冊或規格書，是非常必要的工具，它描述了和規定了用戶所見的每一個細
節，它也是結構師主要的產物。（類似我方的UX）
編寫規格書應注意 :
1. 任何的修改，應標記改版時間與版本資訊
2. 規格說明的風格必須清晰、完整、準確，不要有模糊不明確的說明

16. 文檔化的規格說明---手冊
[不明確的例子]
這個頁面定義一個答題時間，放在畫面右上角，進入頁面時它就開始一直跑，完成課程後暫停時間，並跳出pop予以相應鼓勵語。
9秒以內 : 尼瑪太牛了!!
10~20秒 : 你好棒棒!!
21~30秒 : 阿不就好棒棒!!
31秒以後 : 好棒?!

17. 文檔化的規格說明---手冊
[不明確的例子]
這個頁面定義一個答題時間，放在畫面右上角，進入頁面時它就開始一直跑，完成課程後暫停時間，並跳出pop予以相應鼓勵語。
9秒以內 : 尼瑪太牛了!!
10~20秒 : 你好棒棒!!
21~30秒 : 阿不就好棒棒!!
31秒以後 : 好棒?!
1. 未明確說明時間顯示方式 (10.53秒 、 10.5秒 、 10秒 ?? )
2. 若答題時間為 9.3秒 20.6秒 30.1秒，要跳出哪個?
3. 若途中暫停課程，時間會暫停嗎?

18. 會議和大會
週例會 : 每週一次，所有結構師、軟體工程師、硬體工程師、UX皆參與，由首席系
統結構師主持

19. 會議和大會
週例會 : 每週一次，所有結構師、軟體工程師、硬體工程師、UX皆參與，由首席系
統結構師主持
● 在會議之前，任何人都可提出問題和意見，以紙本方式
● 對詳細的變更做出決策
● 這種會議卓有成效的原因

20. 會議和大會
● 這種會議卓有成效的原因 :
1. 相同小組的結構師、測試、開發每週交流一次。因此大家會對於專案的
內容、進度比較了解，減少溝通的時間。
2. 深刻理解面對的問題，且與產品密切相關。沒有人是'顧問'的角色，每
個人都要承擔義務
3. 問題出現時，在界線的內部和外部，同時尋求解決方案
4. 正式的書面建議集中了注意力
5. 授予首席結構師決策的權利，避免了妥協和拖延

21. 會議和大會
年度大會 : 隨著時間的推移，一些決定沒有被很好的貫徹，一些小事情沒有被某個
參與者真正接受，對於這些問題，週例會沒有重新考慮，慢慢堆積起來，為了解決
這些問題舉辦為期2個星期的持續兩週的年度大會。

22. 會議和大會
年度大會 : 隨著時間的推移，一些決定沒有被很好的貫徹，一些小事情沒有被某個
參與者真正接受，對於這些問題，週例會沒有重新考慮，慢慢堆積起來，為了解決
這些問題舉辦為期2個星期的持續兩週的年度大會。
希平方 : 類似於我方的'待辦事項'(使用者需求建議板)，一季會討論一次，再決定出
哪些事要做的，哪些是要剔除的。

23. 電話日誌
概要 : 規格再怎麼完整，還是會有一些理解上的不同，有問題時，應與結構師進行
討論，而不是自行猜測。
（這裏的例子是，有問題打電話問，並且記錄下來。而我方是記錄於slack、jira、
規格書）

24. 產品測試
概要 : 該小組根據規格書檢查產品，查明每一個可能的缺陷和矛盾的地方，每個開
發機構都需要一個獨立的監督部門，來保證產品的品質。

25. 產品測試
概要 : 該小組根據規格書檢查產品，查明每一個可能的缺陷和矛盾的地方，每個開
發機構都需要一個獨立的監督部門，來保證產品的品質。
測試 : 用戶是是獨立的監督人員，在殘酷的UI環境下，每個細微的缺陷都將無所遁
形。測試小組是用戶的代理人，專門尋找缺陷，細心的測試人員總會發現一些沒有
貫徹執行的地方，以及設計決策(規格書)上的瑕疵。出於這個原因，所以測試小組
須與設計同時實施，儘早發現問題，節省時間成本。

26. 產品測試
概要 : 該小組根據規格書檢查產品，查明每一個可能的缺陷和矛盾的地方，每個開
發機構都需要一個獨立的監督部門，來保證產品的品質。
測試 : 用戶是是獨立的監督人員，在殘酷的UI環境下，每個細微的缺陷都將無所遁
形。測試小組是用戶的代理人，專門尋找缺陷，細心的測試人員總會發現一些沒有
貫徹執行的地方，以及設計決策(規格書)上的瑕疵。出於這個原因，所以測試小組
須與設計同時實施，儘早發現問題，節省時間成本。
小結：測試端（測試計畫）與設計端並行，而不是在開發後才開始編寫。