iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 8
0
Agile

UP, Scrum 與 AI專案系列 第 8

天馬行空看 UP與Scrum

能聽聞當時Gavin與佳麗兩位參與者一搭一唱的講述業界軼聞,Molly 多少也回憶了當時第一次接觸Scrum,於專案中接受洗禮,酸甜苦辣感同身受,所以聽的還蠻開心的。考慮到已經接近傍晚,她可不喜歡因為閒話家常而需要加班,趕緊提醒兩位長輩拉回AI專案來:

"由這段歷史來看,Servo說這個AI探索專案要採敏捷方式是否意味著我們只能採 Unified Process? 其實關於 Unified Process 敏捷不敏捷,業界有不同聲音。我前一家公司,在決定採 Scrum 之前也評估過 RUP,最後不採用UP的最大原因聽說是其所必須製作的文件,對創新團隊來講過於沉重。當然還有其他偏好問題的莫名原因。”

Pete 聽此論述似乎找到知音人,補充;”雖然 UP 是個框架,可以因應專案的特性去訂製符合需要的版本,但是因為我們公司是做軟體委外開發的生意,為了保護甲乙兩方,我們後續增訂出來的 T軟公司標準UP, 我們簡稱 TUP, 而且要用台式英語念成 TaPu, top以示優越,必須製作的文件還是相當多。更慘烈的是UP 似乎比較適合軟體開發專案,我們這種叫做AI 探索的專案,有多少成分是軟體開發? 這幾天我也在思考如何因應,坦白講我也想過要建議採用 Scrum"

“關於這個專案所需製作的文件,我建議如公司傳統的檢驗標準,準備給誰看,看了能產生多少影響。如果最終沒有能對公司、客戶、股東產生任何效益,就儘量少做。這可不是 Moore is better.” 聽到Moore又拋出這個老梗來,Gavin 與 Pete 馬上捧場大笑幾聲。

https://ithelp.ithome.com.tw/upload/images/20181013/20105283IHa634PkDm.png
(圖片取材 Peter Dolog 2009 Unified Process)

Fields 只擔心他並不懂軟體工程,敏捷不敏捷無從判斷;"假使要採用 Scrum 能否提供一點訓練? 進公司的新生訓練TUP佔好大部分,後續專案實施時,又有師兄師姐帶。" 他是看著Molly說的。Molly 感應到立即承諾就算沒要採用 Scrum 她也很樂意分享她覺得受益良多的知識。

佳麗點出公司 TUP 的弱項:”因為我們承接到案子時,客戶已經確認案子的商業價值與可行性,我們裁減掉了UP 決定專案成敗的關鍵階段, Inception Phase。這個專案最好納入,尤其 Business Case 可要好好分析一下。”

Cash對這個主題似乎不感興趣,只是提醒大家:”最近如有要買筆記型電腦,又要帶獨立顯示卡的,務必挑選 Nvidia 的,顯示卡記憶體最低要 4GB,這樣要做機器學習的相關練習會比較有幫助一點,打怪也會比較有效率”。這個話題又引發一番舌戰,略過不表。

這個會議Gavin原先召開是要腦力激盪看如何採用 Agile 方式進行 AI探索,在與佳麗兩人一搭一唱聊公司 UP 歷史時,他擔心讓成員覺得這是沒效率,閒扯淡的團隊,卻引出大家共同話題,隱約可看出一些共識。也許這個團隊已經快要成形了。

他請 Molly 稍微準備一下資料,跟大家介紹一下 Scrum。Molly 希望不是上課式的講Scrum,因為現代人 Google 一下有一堆資料可讀,儘量式互動式的討論。大家都相當讚許這樣的方式。


上一篇
UP元年
下一篇
UP-Scrum對比
系列文
UP, Scrum 與 AI專案31

尚未有邦友留言

立即登入留言