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