原來你不會通靈啊，那就SCRUM吧？
※主圖來源：通靈少女的WikI
之前在追蹤的粉專看到這一篇，沒想到有一天會發生在本小菜雞身上。
❗️身為一位專業的工程師要先有通靈技能❗️ 使用者不知道自己想要什麼..... 使用者想要但是不告訴你..... 使用者自以為想要這個，但是做出來之後他馬上就發現不是他要的..... 那是不是就要工程師先會通靈😫😫😫 不論是程式或任何領...
Posted by 在104上班這款事 on Monday, July 25, 2022
接著跟朋友聊到最近的案子好像是走scrum後，我強烈感受到螢幕另一端的同情。
身為scrum小菜雞，我也常常想現在去報名通靈課程還來不來得及。
Scrum聽起來好像很酷我們也來一下？
Scrum 到底好不好，會不會成功，小菜雞覺得團隊成員跟整體參與度很重要。但有跟大神一樣的成員，參與度又高，用其他開發方式難道不能有一樣的效果嗎？
下面這篇文章幾乎點出了我的所有疑問
如果在一樣的團隊構成跟參與度的條件下，所有人集中心力專心產出一個製品，那scrum 或許能達到快速交付的目的，但如果其中團隊成員同時兼具多項專案，不時需抽離開發，事實上傳統的瀑布開發也未必會比較差。
說好的沒有文件啊？
這是很常見的誤解。敏捷並不是不需要文件，而是產出必須文件，但必須文件的定義又相當曖昧。我相當認同上篇筆者的觀點：敏捷開發不是沒文件沒流程的包裝紙。
曾經跟持續用敏捷開發的朋友請教是不是真的不用文件，獲得的答案是改來改去的過程只要保持最低度的文件管理，但最後還是要將設計相關文件補齊唷。
所以如果實行瀑布開發時就不太產設計文件而說要改用scrum，怎麼聽起來只是為了合理化不出設計書而舉起的遮羞布。
那幹嘛還要敏捷
敏捷跟瀑布還有混合式開發，沒有誰對誰錯，誰優誰劣。選用的理由應該是依照客戶要求，資源分配跟達成目標等等多方評估後而選定。那外包開發適合敏捷嗎？如果顧客參與度高還能接受調整必須的追加預算（一般以人工時來計算），那有何不可。
但截至目前為止查詢到的經驗分享，外包開發不太適合走敏捷開發，主要是當預算固定卻需處理調整時，為了維持交付時程有時必須犧牲開發品質，但這樣一來很容易造成顧客期待值崩塌。
如果外包開發有成功導入敏捷的大神可以分享一下成功的秘訣，祝您好人一生平安。
他山之石
この記事が気に入ったらサポートをしてみませんか？