24. Sprint 1 - 初生之犢...被虎吃
1. CI 還沒建好,缺乏持續整合
a. 在 demo 前一天就爆掉了
2. 最後的執行結果跟預估值大約差了3倍
3. 但我想到很好的理由:
a. 第一次沒經驗
b. 有幾個 stories 比較特殊
i. CI (TeamCity)
ii. UAT (Robot Framework)
1. 有時侯付錢也買不到好東西,只好自己來
2. 自製武器 小菜一號 - QML driver for Robot Framework
iii. 自製武器 小菜二號 - Visual Studio Project Template
31. Sprint 7 UAT 大不易
1.UAT 的實作時間很難估算
2.測試區的 camera 有時候會無法連線,導致 UAT failure
a. 成員:是否應架設 UAT 專用的 camera?
32. Sprint 8 燉煮魚翅排骨鳥蛋時蔬百匯
1. UX 覺得要花更多時間來加強使用者體驗
a. 「都可以啊,反正你們只要做 80 分」
2. RD 覺得 UX 都不知道民間疾苦
a. 很多功能不是外表看到那麼簡單,CP 值你懂不懂啊?
3. QA 覺得壓力超級大
a. 中文的 UAT 可行嗎?
4. 請問 PO 說好的 product backlog 呢?
5. 規劃會議&自省會議 是讓佛跳牆團隊成功的關鍵
a. 聚餐、爬山、烤肉 也蠻重要的...
33. Sprint 9 測試展笑顏
1.QA 原本要手動計算來驗證程式執行結果,但 RD用一天寫個 python
lib就全自動搞定了~
a. 感受到 Cross-Functional Team 的好處
2. 自製武器 - 小菜三號:小紅點
3.中文描述
34. Sprint 10 不持續的持續整合
1.Once you stop integrating, you start dying
2.耶,那你為什麼要停掉 CI?
a. 人在江湖身不由己...
b. 破窗效應
"Once you stop learning, you start dying" ~ Albert Einstein
35. Sprint 11 UAT 穩定性
1.UAT 的不穩定性,要花很多時間克服
a. 怎麼可以用 Sleep 呢!
b. 加入 Wait Property
c. 攝影機不穩定..
d. 該失敗的卻沒有失敗..
2.UAT 寫到哭
a. UAT 也是要有良好的設計的
b. Keyword 可重用性,易讀性...跟程式是一樣的
43. 浴火重生
1.更好、更短、更易讀的程式碼
a. 幸好有 UAT, Unit Test,這是重構的基礎
2.親身經歷,才能真正了解
a. RD 對程式碼品質有深刻的體悟
b. 體會到 Code Review / Design Review 有多麼重要
c. 沒有親身經歷,永遠無法體會"理所當然的廢話"
45. 每個角色都能變成 T 型人嗎?
1.RD
a. C++ / JavaScript / Python / QML / Unit Test / UAT / Client & Server
b. 不是每個人都可以變 T 型人
2.UX
a. QML
i. Image / Font / Transition / Animation
b. Subversion
3.QA
a. Subversion / UAT
4. 雖然一開始成本很高,但現在
a. 人力資源很容易交換 (舊組織的一大問題)
b. 更能激發出新的 idea!
48. PO 與 SM 之間的互動
1.透過規劃會議可以了解每個 story 所需要的成本
2.但某些特別的 story 對 "價值" 如何取得共識?
a. Technical Story
b. Refactoring
3.這裡也沒有什麼屌絲的逆襲
a. 純綷就是 Scrum Master 比較鴨霸...
50. 讓成員持續進步
1.讓成員成為頂級工匠 Software Craftsman
2. 保留時間
a. 一天二小時:其實執行效果不好,不會有人 3:30 一到就開始來看書之類的
b. 跑的比較順之後:星期一下午、星期五下午保留下來
3.自省會議讓成員更勇於發言,更容易聽到基層工程師的聲音
a. 動手做事的人,才是最多 idea 的人!