PTT職涯區 / Soft_Job (軟體人)

[請益] 這些軟體工程的方法在台灣的普及度?

看板Soft_Job (軟體人)作者時間12年前 (2014/01/25 00:31), 編輯推噓6(6推 0噓 65→)
留言71則, 8人參與, 最新討論串1/3 (看更多)
目前軟體工程最紅的新方法大概就是DevOps/Continuous Delivery 想問一下目前有沒有人的公司正在使用或是想要使用這幾個東西: DevOps Continuous Delivery Continuous Integration Test-Driven Development 其實前三個應該是同一套的東西，涵蓋的範圍大小不同而已 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.165.202.148
→
01/25 00:32, , 1F
前三個還算常見啦，特別是持續經營的軟體產品幾乎是必備
01/25 00:32, 1F
→
01/25 00:33, , 2F
第四個通常是有諧此道的導師在帶才會進行。
01/25 00:33, 2F
推
01/25 22:07, , 3F
前三個只要系統夠大, 開發人員夠多幾乎都會使用
01/25 22:07, 3F
推
01/25 22:10, , 4F
TDD通常需要比較多的開發時間, 多花時間就等於多花錢
01/25 22:10, 4F
→
01/25 22:10, , 5F
就看有沒老闆願意花錢去落實了~ B-)
01/25 22:10, 5F
→
01/25 23:14, , 6F
TDD 不是真的多花時間，是把該做的動作做足應該包含的時間。
01/25 23:14, 6F
→
01/26 00:16, , 7F
我們公司都有..大一點個產品公司應該都有
01/26 00:16, 7F
→
01/26 00:16, , 8F
SI專案公司的話 除非案子夠大 不然應該連測試都沒
01/26 00:16, 8F
→
01/26 09:58, , 9F
唔，蠻意外的，因為前三個東西是建在Agile之上，Agile都沒
01/26 09:58, 9F
→
01/26 09:59, , 10F
的話前三個根本不用提，就我所知台灣連Agile都沒的公司應
01/26 09:59, 10F
→
01/26 09:59, , 11F
還不算少...只是前三個很容易被人覺得裝些tool就是了，事
01/26 09:59, 11F
→
01/26 09:59, , 12F
實上真的要達到前三個，沒有個至少兩三年全公司上下下定決
01/26 09:59, 12F
→
01/26 10:00, , 13F
心作整個開發方法和流程的轉移，是不可能辦到的
01/26 10:00, 13F
→
01/26 15:11, , 14F
看你怎麼定義 agile，我是覺得台灣不少廠商採用類 agile
01/26 15:11, 14F
→
01/26 15:12, , 15F
精神在開發的。現在我反而是越來越少看到 waterfall 了
01/26 15:12, 15F
→
01/26 15:12, , 16F
我是覺得這些都是定義問題。
01/26 15:12, 16F
→
01/26 15:13, , 17F
另外，「持續經營的軟體產品」本身在台灣算少數喔。
01/26 15:13, 17F
→
01/26 15:14, , 18F
就我的觀點來看台灣還是 SI 佔大宗，但討論這個問題時基本上
01/26 15:14, 18F
→
01/26 15:14, , 19F
我們會自動把 SI 去掉，所以這也可能是觀點不同的地方。
01/26 15:14, 19F
→
01/26 15:15, , 20F
對我來說，agile、scrum 這種東西在新專案，只要有好的
01/26 15:15, 20F
→
01/26 15:15, , 21F
mentor 走在前面，根本就不用下什麼決心或做什麼轉移喔，
01/26 15:15, 21F
→
01/26 15:15, , 22F
原則上跟著 mentor 好好走就好了。很多小團隊都有這種條件的
01/26 15:15, 22F
→
01/27 01:14, , 23F
新創公司容易很多沒錯，反正只要有一兩個人帶就可以，東西
01/27 01:14, 23F
→
01/27 01:14, , 24F
都從頭開始也沒啥包袱，但已經存在幾年，有點規模的公司
01/27 01:14, 24F
→
01/27 01:14, , 25F
光是要從waterfall變Agile就要不小工夫了...變成Agile皮
01/27 01:14, 25F
→
01/27 01:15, , 26F
waterfall骨的猜測應該也不算少吧
01/27 01:15, 26F
→
01/27 01:18, , 27F
至於Continuous Delivery，應該是這本書寫得比較清楚
01/27 01:18, 27F
→
01/27 01:18, , 28F
01/27 01:18, 28F
→
01/27 01:20, , 29F
基本上就是徹底的自動化，頻率極高的build(一天十次以上)
01/27 01:20, 29F
→
01/27 01:20, , 30F
手動測試降低到最低，任何新的code從check in到version
01/27 01:20, 30F
→
01/27 01:21, , 31F
control到真正到使用者手上只花幾小時，而且按一個鈕就完
01/27 01:21, 31F
→
01/27 01:21, , 32F
成
01/27 01:21, 32F
→
01/27 19:14, , 33F
@TonyQ, Agile要求還蠻嚴格的, 不太能夠各自表述吧.
01/27 19:14, 33F
→
01/27 19:15, , 34F
在台灣所謂類Agile, 通常的意義上都像Wolfken講的agile皮
01/27 19:15, 34F
→
01/27 19:16, , 35F
waterfall骨, 只有需求隨便加, 沒有減少的.
01/27 19:16, 35F
→
01/27 19:19, , 36F
不過前三項也不是只有Agile需要, 形式週期名稱也許不同, 但
01/27 19:19, 36F
→
01/27 19:20, , 37F
稍有規模的公司都是會需要的---也是從現實需求衍生出來的啦.
01/27 19:20, 37F
推
01/27 22:48, , 38F
有些 agile 只是做事不經大腦的美稱 @@
01/27 22:48, 38F
→
01/28 10:58, , 39F
@atst2 因為在國外 scrum team 跑過，其實也沒很嚴謹在跑，
01/28 10:58, 39F
→
01/28 10:58, , 40F
我知道大家對國內的企業有很多成見，事實上也很多地方不爭氣
01/28 10:58, 40F
→
01/28 10:59, , 41F
，但我覺得可以討論哪些地方有做好跟做了什麼。XD
01/28 10:59, 41F
→
01/28 10:59, , 42F
有了範例之後再來對照比較好條列標準。
01/28 10:59, 42F
→
01/28 11:00, , 43F
不然所謂 agile 皮，終究還是有個 agile 皮～
01/28 11:00, 43F
→
01/28 11:00, , 44F
是不是 waterfall 骨，我不知道你們再說哪也很難回 XDDD
01/28 11:00, 44F
→
01/28 11:00, , 45F
像我是會砍需求啦 :P
01/28 11:00, 45F
→
01/28 11:10, , 46F
@Tony 我所謂真,假agile, 端看缺少的部分有沒有替代方案.
01/28 11:10, 46F
→
01/28 11:11, , 47F
例如有些團隊跑Agile, 但沒有引入Pairing Programming
01/28 11:11, 47F
→
01/28 11:11, , 48F
如果這個團隊雖沒有Pairing,但有確實執行code review, 那我
01/28 11:11, 48F
→
01/28 11:12, , 49F
也會認為它確實是有在跑Agile的.
01/28 11:12, 49F
→
01/28 11:14, , 50F
單就目前個人見過的狀況, 會說台灣的類Agile不夠確實, 主要
01/28 11:14, 50F
→
01/28 11:17, , 51F
也是針對台灣的團隊, 往往都只「套用」方法, 一但有困難, 便
01/28 11:17, 51F
→
01/28 11:18, , 52F
東砍西減, 卻很少去找適合的替代方案...也就是不瞭解方法論
01/28 11:18, 52F
→
01/28 11:19, , 53F
所要解決的問題與目的, 反而看起來更像是:別人都這樣做, 我
01/28 11:19, 53F
→
01/28 11:20, , 54F
們也來試看看...做不好?那這方法一定適合我們的環境...
01/28 11:20, 54F
→
01/28 11:21, , 55F
大致上是這種感覺吧....
01/28 11:21, 55F
→
01/28 11:22, , 56F
不
01/28 11:22, 56F
→
01/28 14:37, , 57F
我可以理解 所以才需要討論具體的方法論 這樣環境才會改變
01/28 14:37, 57F
→
01/28 14:37, , 58F
像我也是把 pair 跟 code review 跟著我帶到我在的團隊
01/28 14:37, 58F
→
01/28 14:38, , 59F
我是覺得 iteration 大概是目前比較多團隊還需要練習的地方
01/28 14:38, 59F
推
01/28 14:39, , 60F
滿足特定條件套用 agile 才會加分, 不然持平或扣分都可能
01/28 14:39, 60F
→
01/28 14:40, , 61F
方法論不是問題, 而是要實行方法得要有實行的能力
01/28 14:40, 61F
→
01/28 14:40, , 62F
就好像不是知道月面空翻的方法就人人都會月面空翻
01/28 14:40, 62F
推
01/28 14:46, , 63F
(等一下...這什麼爛比喻 0rz) 舉個最簡單的例子
01/28 14:46, 63F
→
01/28 14:47, , 64F
要能做到 "Welcome change requirement event late ..."
01/28 14:47, 64F
→
01/28 14:47, , 65F
就要有能建立 "easy to change" 的架構的能力
01/28 14:47, 65F
→
01/28 14:48, , 66F
類推, 每一項 agile 精神都需要一定的對應能力
01/28 14:48, 66F
→
01/28 14:49, , 67F
沒有相當的能力隨便 agile, 等於找死
01/28 14:49, 67F
→
01/28 14:50, , 68F
*even
01/28 14:50, 68F
推
01/28 23:05, , 69F
其實Agile說穿就是ConcurrentEngineering+風險管理
01/28 23:05, 69F
→
01/28 23:05, , 70F
根本就不是因為Agile造成問題，而是使用的人有問題
01/28 23:05, 70F
→
01/28 23:06, , 71F
所以不如說是執行者及成員素質不到位，Agile等於照妖鏡
01/28 23:06, 71F
‣ 更多 Wolfken 的文章
文章代碼(AID): #1IufLuMS (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 Wolfken 的文章
文章代碼(AID): #1IufLuMS (Soft_Job)