十分鐘系列

1. 假如我是一個 PM ？
( 軟體專案管理的那些事兒 )
陳鍾誠 2017 年 10 月 31 日
程式人《十分鐘系列》程式人《十分鐘系列》
本文衍生自維基百科

2. 話說
●雖然我喜歡寫程式

3. 但是
●卻不太願意當 PM

4. 當然
●如果給我足夠的錢
或者有足夠吸引我的專案

5. 我也會願意跳下水

6. 但是當 PM
● 有點違反我的個性
● 因為不能隨心所欲的做事！

7. 一群人工作
● 和一個人工作有點不同！

8. 專案經理
● 背負著整個專案能否完成的使命！

9. 為了讓專案順利完成
● PM 必須掌控人員與時程
● 並且盡力讓每個人都清楚的知道下
一步要幹嘛 ...

10. 這可不是一件很容易的事情

11. 到底 PM 的工作是甚麼呢？

12. 其實也沒有人規定阿！

13. 有些 PM
● 只需要出一張嘴 ...

14. 有些 PM
● 會自己開好規格，並且寫好 TDD/BDD
測試
● 然後才讓組員開始寫程式 ...

15. 另外還有些 PM
● 不想要用嘴，也不開規格
● 而是努力地寫程式 ...

16. 問題是
● 哪一種 PM 比較好呢？

17. 我只知道
● 最後那一種是最糟的 ...
也就是不開規格、努力寫程式的那種 PM

18. 假如我是一個 PM
● 除了清楚說明專案，以及安排每個人接下
來的工作之外
● 我應該也會盡可能的寫好 TDD/BDD 測試

19. 因為 TDD/BDD 測試
● 可以清楚的讓成員知道，他接下來
該做些甚麼！
● 這樣才不會該做的沒做，卻做了一
堆不該做的事 ...

20. 像是 JavaScript
● 就可以用 mocha/chai 搭配來寫 TDD/BDD

21. 如果牽涉到 Web Server
● 還可以加上 supertest 這個 server 專用
的測試框架
● 或者加上 PhantomJS/Puppeteer/Selenium
等所謂的 headless browser 來測試 ...

22. 對於手機 APP
● 也可以用 Appium/Calabash 之類的測試框架

23. 對於桌面型視窗程式
● 如果是 Visual Studio 2017 可以用
Live Unit Testing
● 如果是 Electron.js 可以用 Spectron
http://demo.tc/post/836

24. 除了單元測試之外
● 還會進行整合測試、系統測試、 ...
● 而且應該會採用持續整合測試 CI 的
方法 ( 像是用 Jenkins/TravisCI)

25. 只有搞定測試
● 才能盡可能及早發現 BUG 並除掉

26. 當然
● 在軟體開發之前
需求分析 => 系統分析
的部分也一定要越精確越好 ...

27. 對於我已經很熟悉的領域
● 這些分析應該可以做得很精確 ...

28. 但是對於我不夠熟悉的領域
● 除了想辦法盡快弄懂該懂的，並確定
一些未來難以改變的架構之外
● 可能就會採取以 TestCase 為主的規劃
方式，盡可能在每一次的進度開始之
前，先寫好清楚的 TestCase

29. 這樣可以為 PM 自己爭取時間
● 而非讓成員空等，直到 PM 完全準備好 ...

30. 軟體開發與合作
● 本來就是一件非常困難的事情

31. 面對專案的時候
● 我會特別戰戰競競如臨大敵 ...

32. 假如要用到關聯式資料庫
● 那麼我就不能連《正規化》的概念
都沒有

33. 要用到網路
● 就不能不考慮應採用何種通訊模式
與函式庫 ...

34. 要用到 javascript
● 就不能不考慮語法太亂，以及是否
可以用 es6 語法，是否要強制使用
async/await 同步語法等問題。

35. 另外還有
● 採用何種語法檢查、開發測試框
架、工具 ....
等等這些問題 ...

36. 以及是否要用 prototype 雛形
● 進一步確認客戶需求等問題 ...

37. 像我這樣一個大學老師
● 其實是個不合格的 PM

38. 我們常常
天馬行空的思考一些研究議題

39. 但是當面對專案時
● 我們的執行能力
會遠遠不如業界的 PM

40. 所以你應該知道
● 為何國科會的那些專案
幾乎沒有一個是成功的 ...

41. 因為大學老師
● 從來都不是軟體專案的好 PM ...

42. 雖然今年開始教軟體工程

43. 但是我知道
● 距離成為一個好 PM ...

44. 我還差得很遠

45. 我得想辦法盡快趕上

46. 才不會誤人子弟

47. 這就是我們今天的
●十分鐘系列！

48. 希望您會喜歡！

49. 我們下回見！

50. Bye Bye!