Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

從廢柴到成材 - 那 20 個 sprints 教會我們的事 C.C Agile #40

3,398 views

Published on

在網路上充滿了許多敏捷開發的童話故事,例如只要上完課,大家有敏捷思維後就可以變成敏捷團隊,從此過著幸福快樂的日子之類的。

在這次聚會中,我將與大家分享這 20 個 sprints 當中所發生的真實故事:BOSS/PO/SM/RD/QA/UX 等不同角色所面臨的挑戰、各種角色之間高潮迭起的恩怨情仇,以及最重要的...這個一開始用廢材形容也不過份的團隊,最後真的成材了嗎?相信這些情節,也會在你導入敏捷開發時一一發生。

Published in: Education
  • 办理(加拿大SFU西蒙菲莎大学)学历认证+毕业证+成绩单+文凭Diploma+雅思+托福+驾照+回国人员证明 Simon Fraser University QV627212264
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Diro is a powerful scrum master! Good Job!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

從廢柴到成材 - 那 20 個 sprints 教會我們的事 C.C Agile #40

  1. 1. 從廢柴到成材 那 20 個 sprints 教會我們的事 Diro 2015/12/17
  2. 2. 簡介 在網路上充滿了許多敏捷開發的童話故事,例如只要上完課,大家有敏捷 思維後就可以變成敏捷團隊,從此過著幸福快樂的日子之類的。 在這次聚會中,我將與大家分享這 20 個 sprints 當中所發生的真實故事: BOSS/PO/SM/RD/QA/UX 等不同角色所面臨的挑戰、各種角色之間高潮 迭起的恩怨情仇,以及最重要的...這個一開始用廢材形容也不過份的團隊, 最後真的成材了嗎?相信這些情節,也會在你導入敏捷開發時一一發生。
  3. 3. 講者 范姜士武 Diro 個人簡介:VIVOTEK 晶睿通訊 技術經理,自幼熱愛程式設計,近年來努力 推動 Qt/QML 及敏捷開發,希望能為軟體界做出一點小小貢獻。 個人網站:http://diro.tw Slideshare:http://www.slideshare.net/dirofan Qt@Taiwan:https://www.facebook.com/groups/qtdev/
  4. 4. 書上的美好故事
  5. 5. 通常只是童話故事
  6. 6. 讓我們來看看一個敏捷團隊
  7. 7. 一路上的關卡 & 真正的演化過程
  8. 8. 卡司陣容 = SM + UX + GUI + QA + 7 Developers 合力打造新一代錄影監控軟體
  9. 9. 正片開始 真實故事改編
  10. 10. 第一關 /老闆(的老闆*)/老闆的老闆的老闆的老闆 人資。 管理處。同事
  11. 11. 每當你提了一些新想法或新作法... 馬上就會聽到...
  12. 12. 「我們這個產業不一樣啦!」 謎之音:到底是有多不一樣...
  13. 13. 別怕,不是只有你老闆這樣
  14. 14. 這時侯你需要嘴砲舉證...
  15. 15. Agile/Scrum in IP Surveillance H/W AXIS Avigilon Bosch S/W Genetec Axxonsoft Mirasys
  16. 16. 如果成功,你就會得到
  17. 17. 第二關 最大的敵人是自己
  18. 18. Sprint 1 - 初生之犢...被虎吃
  19. 19. 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
  20. 20. Sprint 2 接受事實
  21. 21. Sprint 2 接受事實 1. 到底該不該讓 member 在最後二天瘋狂的加班 2. time-boxing! time-boxing! time-boxing! a. 下了決定:承認失敗,就放棄它吧! b. 連 vmrun 這種看似簡單的工作都要 overtime 了
  22. 22. Sprint 3 抉擇
  23. 23. Sprint 4 意外無處不在
  24. 24. Sprint 5 承認錯誤,可以跑的更快 1. 花很多時間做 design review/code review a. 有些 “task” 也因為這樣自動消失了 2. 讓大家感受到 design review / refactoring 的好處。 a. 但是,也讓速度看起來又更慢了
  25. 25. Sprint 6 基礎建設終於完畢
  26. 26. Sprint 7 UAT 大不易 1.UAT 的實作時間很難估算 2.測試區的 camera 有時候會無法連線,導致 UAT failure a. 成員:是否應架設 UAT 專用的 camera?
  27. 27. Sprint 8 燉煮魚翅排骨鳥蛋時蔬百匯 1. UX 覺得要花更多時間來加強使用者體驗 a. 「都可以啊,反正你們只要做 80 分」 2. RD 覺得 UX 都不知道民間疾苦 a. 很多功能不是外表看到那麼簡單,CP 值你懂不懂啊? 3. QA 覺得壓力超級大 a. 中文的 UAT 可行嗎? 4. 請問 PO 說好的 product backlog 呢? 5. 規劃會議&自省會議 是讓佛跳牆團隊成功的關鍵 a. 聚餐、爬山、烤肉 也蠻重要的...
  28. 28. Sprint 9 測試展笑顏 1.QA 原本要手動計算來驗證程式執行結果,但 RD用一天寫個 python lib就全自動搞定了~ a. 感受到 Cross-Functional Team 的好處 2. 自製武器 - 小菜三號:小紅點 3.中文描述
  29. 29. Sprint 10 不持續的持續整合 1.Once you stop integrating, you start dying 2.耶,那你為什麼要停掉 CI? a. 人在江湖身不由己... b. 破窗效應 "Once you stop learning, you start dying" ~ Albert Einstein
  30. 30. Sprint 11 UAT 穩定性 1.UAT 的不穩定性,要花很多時間克服 a. 怎麼可以用 Sleep 呢! b. 加入 Wait Property c. 攝影機不穩定.. d. 該失敗的卻沒有失敗.. 2.UAT 寫到哭 a. UAT 也是要有良好的設計的 b. Keyword 可重用性,易讀性...跟程式是一樣的
  31. 31. Sprint 12 專職的 PO 擁有一個專職的 PO 是件幸福的事 但是我們沒有....
  32. 32. Sprint 13 眾人智慧的力量 1.SM:開始會有 long-term UAT 要加入 CI 系統了 2.成員A:單純測worker,不要測整個plugin,會比較單純、做起來也快, 整個plugin由UAT來涵蓋 3.成員B:可以考慮引入 FLUX 架構 4.成員C:全新的 Layout 設計! 5.成員D:更棒的 bug report 方式~ 6.成員E: UAT 應該改用 QML 的 UT 7.成員F: CI 應該產生 Debug + Symbol
  33. 33. Sprint 14~16 暴風雨前總是特別美 1.團隊看起來已經合作無間,合樂融融一家親 XD 2.能夠發揮眾人的智慧,大家都能提出新點子來改善工作效率 3.UAT 開發速度也變快了,寫起來得心應手
  34. 34. Sprint 17 湘北的不安定因素
  35. 35. Sprint 18 舉步維艱 軟體是逐步演化而來的 如果演化過程中的時間不夠,就會變成異形
  36. 36. Sprint 19 含淚達成任務 1.程式碼中的"負負得正" ,讓大家不快樂(咦,不是有 Unit Test 嗎?) 2.最後硬撐,還是把任務完成了 RD:我也不知道執行結果為什麼會對..
  37. 37. Sprint 20 砍掉重練 跟 PO 協調,讓我們有時間進行大幅度的重構!!
  38. 38. 浴火重生 1.更好、更短、更易讀的程式碼 a. 幸好有 UAT, Unit Test,這是重構的基礎 2.親身經歷,才能真正了解 a. RD 對程式碼品質有深刻的體悟 b. 體會到 Code Review / Design Review 有多麼重要 c. 沒有親身經歷,永遠無法體會"理所當然的廢話"
  39. 39. 影評與幕後花絮
  40. 40. 每個角色都能變成 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!
  41. 41. RD 與 UX 之間的互動 1.UX 認為產品體驗要做到 100 分 a. 第一個 sprint 做到 70 分,下一個 sprint 可以進化到 80 分 b. 重點功能會做到 90 分 2.UX 改來改去,RD 的感受? a. 設計的本質,就算先做過 usability testing 也一樣 3.UX 要做最好的,不管成本 a. RD 分析實作成本,但最後由 UX 決定要用那一種 4.溝通很重要!!溝通很重要!!溝通很重要!! RD:一樣都會到,為什麼不走樓梯? UX:為了更好的體驗!
  42. 42. RD 與 QA 之間的互動 1. RD &QA 思維大不同 2. 品質是 DQA 的事 -> 品質是團隊的事 3. RD 開發完時,QA 才能玩到完整的產品
  43. 43. PO 與 SM 之間的互動 1.透過規劃會議可以了解每個 story 所需要的成本 2.但某些特別的 story 對 "價值" 如何取得共識? a. Technical Story b. Refactoring 3.這裡也沒有什麼屌絲的逆襲 a. 純綷就是 Scrum Master 比較鴨霸...
  44. 44. ScrumMaster 可以做些什麼事 1.做武器、解 bug、解疑難雜症...可以嗎? 2.育才、Code Review 3.參與開發,才知道問題(C++ / QML / UAT) 4.聚餐、下午茶、Team Building,建立團隊向心力 5.以及...
  45. 45. 讓成員持續進步 1.讓成員成為頂級工匠 Software Craftsman 2. 保留時間 a. 一天二小時:其實執行效果不好,不會有人 3:30 一到就開始來看書之類的 b. 跑的比較順之後:星期一下午、星期五下午保留下來 3.自省會議讓成員更勇於發言,更容易聽到基層工程師的聲音 a. 動手做事的人,才是最多 idea 的人!
  46. 46. 一個 sprint 就能浴火重生? 1.平常就累積了實力跟想法 2.體質很好,只是缺乏訓練以及演化的時間 a. C/C++ 的經驗可以重用 b. 大部份只有重構 QML & JavaScript 3.C++都是 plugin 型式,比較單純,不需要重構 4.這個 sprint 決定了我們能不能成功!
  47. 47. 理論 v.s 現實 1.Story 沒有全部完成怎麼辦? 2.Unit Test / UAT 涵蓋率可以做到 100% 嗎?
  48. 48. 世界上沒有什麼速成秘笈 1. 敏捷給你流程上的改變,做對的事 a. Do the right thing 2.技藝給你本質上的改變,把事做對 a. Do the thing right
  49. 49. 不負責任推薦區 知識分享 1.http://vvtk-digest.blogspot.tw/ 2.https://www.gitbook.com/book/diro/advanced-qml/ 3.https://www.facebook.com/groups/qtdev/?fref=ts 好用的工具 1.https://www.safaribooksonline.com/ 2.https://www.jetbrains.com/teamcity/ 3.http://robotframework.org/ 4.http://www.gurock.com/testrail/ 5.小紅點 正在準備 open source 中 XDD
  50. 50. 負責任推薦區 1.誠徵軟體工匠 a. 如果你對軟體開發懷抱著熱情,希望用軟體技術為世界做出一點貢獻,歡迎加入我們! b. 還有很多開發中的故事沒有跟大家分享,歡迎你來跟我們一探究竟
  51. 51. 負責任推薦區 1.誠徵海盜型軟體工匠 a. 如果不喜歡風平浪靜,也可以到我們的新創公司來看看 XD
  52. 52. 番外篇 拍片現場
  53. 53. Thank You! 歡迎加入我們!
  54. 54. Q & A

×