iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 19
1
Software Development

0 -> Android -> Kotlin 開發筆記系列 第 19

[Day19] 與Android無關的軟體開發流程

這篇是Android開發的最後一篇文章,下一篇就開始了未知的新世界了。

筆者這篇想談一下跟Android無關的軟體開發流程。為什麼要談這個?
因為筆者工作數年後,深刻發現軟體開發流程(又或者稱為軟工),
雖然跟開發完全沒什麼關係,"但是"卻可以深深的影響整個開發,
因此這篇我想提出來探討,這篇是用來分享筆者"目前"
認為比較正確的軟體開發流程,但就僅止一篇。


一個好的軟體開發流程應該如下:
需求分析(Require)-> 系統分析(SA) ->
系統設計(SD) ->程式實作(PG) ->
程式白箱測試(CI/自我測試)-> 程式黑箱測試(Test) ->
程式持續部屬迭代(CD) -> 問題回饋(Feedback)
-> 區分Bug or Feature ->
Bug進入Reproduce And 增加 test case,
Feature則是進入下一次的需求分析(循環)

從這連串的流程來看,可以發現如果今天軟體開發出了問題,
那可以斷定大抵上,不會只是程式實作那一個部分的問題。

但是…筆者遇到的開發問題,
最後通常都是程式實作的人直接負責,主管間接負責,老闆賠錢了事。

但損失最多的會是誰?筆者覺得其實會是公司內的全部人,
因為整個公司組織的每個人,浪費了時間歲月。

但為什麼整個組織很多時候不懂或不想改變這些?

筆者覺得不是本篇想說的事,就此略過。


筆者因為出身關係,覺得軟體開發工程有時像是建築工程一樣,
有時又像是畫家或是工藝師,也剛好有書本在談這塊:

有時候開發時遇到PM or SA説:
開發不用規格書就可以開發了,你不懂如何開發,是因為你能力不足。
聽到的時候真的是蠻傻眼的…
難道蓋一棟房子,不用先把建築設計圖設計好,材料估好,
建築師蓋章,土木技師蓋章,卻希望工人可以自己把房子蓋成101大樓…

好,我們不管在哪裡工作可能都會遇到這些問題,最好的方式是什麼?
坦白說,筆者也還在摸索,但很明確地,
如果想真的做好一個自己認同的產品,
繼續培養自己的核心競爭力,把程式越寫越好,是必須的。
而其他的開發技能,筆者認為也必須逐步必備。

至於瀑布流?敏捷開發?哪個比較好?
筆者覺得最重要的還是回歸到人。
這個組織如何的被建立,大家是否認同以及願意學習成長。
如何營運這個環境,就是每個稍有經驗的工程師的責任了,
願不願意真實的面對問題,向上管理、橫向溝通、向下領導,
與接觸到的工作同仁一同學習成長,
如何學習欣賞每個人的優點以及合作,
最終的目的,其實是為了把產品做好,
而且可以準時上線交付,僅此。


建築工法畢竟發展了一千多年,因此比較穩定,
而軟體工程則才剛起步,而且他有時候又像是一門藝術,
但不論如何,筆者相信未來會更好的,共勉之。

本文同步發佈在Medium,連結在此


上一篇
[Day18] Android Test 學習筆記 II
下一篇
[Day20] Why Kotlin? (PhoneGap,React Native, Flutter, Cordova, etc…)
系列文
0 -> Android -> Kotlin 開發筆記30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言