Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (20)
需求變更 的 反覆模型
- 1. 需求變更 的 反覆模型
- 2. Ben Lau
- 3. 來自香港
- 4. 上年 COSCUP 2011 也講了一場 Lightning talk
- 5. 題目：『嵌入式開 發 的一則小故事』
- 6. 講述一位小小 的工程師 多艱難才拿到 GPL Kernel 代碼的故 事
- 7. 是個很痛苦 很悲哀的故事
- 8. 但大家笑得好高興
- 10. 雖然我的國語真的 很爛 ...
- 11. 今年又再講 痛苦的故事
- 12. 需求變更 的 反覆無常
- 13. 先聲明
- 15. 在專案開發到一半 的時候 ...
- 16. 你喜歡修改嗎？
- 17. 喜歡？
- 18. 討厭嗎？
- 19. 但你是專業的！ 怎能不改？
- 21. 錯誤示範
- 22. 一般來說，修改的 來源有二個
- 23. 客戶
- 24. 老闆
- 25. 但我不喜歡這麼叫 他們 ...
- 26. 神
- 27. 神說
- 28. 要有光 就有了光
- 29. 但是 ...
- 30. 會說：太光了
- 31. 又說：太暗了
- 32. 彩色好不好！？
- 33. 喜歡大型動物時 就有了恐龍
- 34. 不喜歡時 就拋了顆殞石落去
- 35. 可憐的是 其他動物 ...
- 36. 以上的神 不屬於 任何宗教的神 請見諒
- 37. 但如果你把老闆 當成神 你的生活會好過一 點
- 38. 但我不信神 所以生活都很苦
- 39. 幸好有了 Agile
- 40. 傳統的 Water Fall / 瀑布開發流程 需求階段後 就不會再改
- 42. 永遠不變 的 只有變化
- 44. 工程師被解放了！
- 45. 才怪
- 50. 營運：上線前一刻 我們發現有個問 題 ...
- 51. 工程：這個要求我 們做不到，請改 成 ...
- 52. 設計：這樣會好一 點
- 53. 設計：這樣會再好 一點 ...
- 54. 設計：這樣會更完 美
- 55. 只要有心 人人都可以是神
- 56. 這不是 最麻煩的問題
- 57. 客戶的要求一般是這樣傳達的
- 58. 即使是同一間公司
- 59. 每人收到訊息的時間並不一致
- 60. 而且內容也可能不一樣
- 61. 有些人會不知道 ( 留意工程那部 份）
- 62. 一個假設性的故 事 ...
- 63. 某天，在一間 Cafe 閒 聊時 權威人士：功能 X 拿 掉吧，現在是 Just works 的時代
- 64. 某天老闆路過工程 部見到菜鳥 A
- 65. 『你知道 Apple 為 什麼成功嗎？因為 Just Works （刪掉 20 分鐘的說教）把 功能 Y 拿掉吧。』
- 66. 菜鳥 A 說：「老闆 要我們拿掉功能 Y ，原因，呀， 呀，呀 ... 」
- 67. 展示那天 管理層大罵：「怎 麼功能 Y 沒有 了？」
- 68. 推出後 老闆罵管理層： 「怎麼功能 X 還 在！？」
- 69. 囧
- 70. 到底應該做什麼 啊！？
- 71. God Knows.
- 73. 一片混亂
- 74. 每個人的認知也不同
- 75. 需求變更的傳遞不是直線 的
- 76. 需求變更是可以變質的
- 77. 需求變更的內容是可以反覆回彈的
- 78. 否決過的要求，有天可能會變成 Zombie 回來
- 79. 需求變更本身並不 可怕 你是專業的！
- 80. 沒有中央管理的變 更才是惡夢 ( 剛才的模型就是為了說明這 個現像）
- 81. Agile 還是能幫你
- 82. 星期 X+2 - 加入了功能 Z 星期 X+4 – 功能 Z 被取 代 星期 X+12–Z 又要復活 了
- 83. 砍掉重練好玩嗎？
- 84. 不能再放任這問題
- 85. 你可以試一試拜 神 ...
- 87. 或者請一個 Release Manager 回來 讓他協助你，跟所有 的神溝通。
- 88. 或者自救
- 89. 教會你的上司什麼 是 Release management
- 90. 跟上司說： ( 偷偷告訢你 Product Manager 比 Project manager 更加威風 啊)
- 91. 但別要求許多許多的文件 有很高的機率會變成文件地 獄 這比沒有文件更糟糕
- 94. 越好的軟件設計 越容易應對修改
- 95. 只要有心，人人都 可以當大大
- 96. 世界一直這樣運作 就是因為沒有人去 改變
- 97. 請走出第一步
- 98. 讓工程變成樂趣
- 100. 謝謝