關於 Ailge 軟體開發流程的疑惑

感覺又是個換湯不換藥的學術口號

撇開所謂的傳統軟體開發流程，一樣都是人、事、物

只是重心不同、比例不同、名稱不同
Product backlog -> Sprint backlog (Stories) -> Task -> Task board 
(Requirement / Spec -> R&R / Break down / Schedule -> Task / Subtask / Task management system)

頂多是讓部分流程重疊，達到部分加速的效果，但 side effect 有多少卻不知道
因為這世界上不是只有軟體行業，跨單位、跨領域、跨功能的任務，Agile 如何應付?
再來一個新人，加入新的元素，又可以定義出新的架構或流程
以一個 PM / 老闆的傳統思維，用原本的方式進行 Agile，徒增痛苦而已
再來一個 Sprint 中不能變更需求，在某些公司這是天大的笑話。 
誰要當豬? 誰要當雞? 當雞過勞了，錢還是讓豬在領

唯一稍微可以看的就是 Swimlane 的 Task board
一直強調"傳統軟體開發"，根本是個幌子。人的智慧和經驗是會累進改變的，團隊與專案發展的方式，不會完全照著所謂的"傳統軟體開發流程"去走，Agile 只不過是自然的演變 + 名詞定義。用最簡單的 PDCA 就可以解釋 event cycle

Stand up meeting 並不是敏捷測試特有的方式，其他非軟體產業一樣也有相同的方法

除非明確從 Agile 方法得到好處，大幅縮短開發時間與提升成果品質

要不然根本沒什麼特點

如果能大幅得到好處，也代表這單位之前的流程、概念、方法、技能也太爛了吧

好比說畫圖，Agile 只是再去定義哪個配色成分要多少、油畫筆刷要多粗、水彩畫筆刷要多粗、什麼顏色要刷幾次...知識這東西，是一個過程、一個方法、一個價值，Agile 只不過是針對這個知識作取樣和量化，沒什麼差別

另外 Agile 對系統測試部分似乎沒有明確的定義，而且不同產業測試的方法也不同

不可能全部自動化，假想提出這套想法的，應該比較合適於 Web 和網路系統的人
另外也甚少看到大家討論 Issue / Bug 在 Agile 流程中的處置

Agile 四個核心，可以假想就是創始者碰到的困境，所以才針對這四項提出 Agile核心價值。

1. 個人與互動: 這是人的問題。也是管理的問題。程式開發模組跟模組間、開發與測試間、上游與下游、研發與製造、etc. 所以強調這點毫無意義，因為這是整個過程中，本來就應該處理與解決。

2.  交付可行軟體: Agile 若沒有一個系統架構師，依照短周期開發的精神，很容易造出歪離規格的產品。雖然可以透過 requirement 與開會來修正。正本溯源，根本就是 requirement 不明確造成的問題。另外你會拿 source code 給老闆和客人說，這就是我的技術文件嗎? 我想被丟去 ISIS 捅屁屁比較快。

3. 客戶合作: 這個沒救。有錢就是大佬的暴發戶精神是不可能被消滅的，永遠被教導客戶至上，根本就不在同一個討論基準點。

4. 隨著變化做出反應: 這叫勞民傷財。一週一build已經夠累了，現在是一天一build，若一天數build，請問誰要累死

在台灣不同工同酬的壓榨體制內，換個 Agile 不過就是代表繼續用低薪，壓榨出員工更大的產值，老闆利潤 double，員工一無所獲。員工不是電腦，不是靠個 cloud computing / Virtualization / Grid computing 就可以無限制的持續並行付出

Agile 提倡的精神是以人為本，說到底，還是拼命的去完成任務，哪裡以人為本?
Agile 的 PO 決定優先權，團隊決定工作時間，在台灣能嗎? 老闆一句話勝過一切，老闆的爽度決定一切，更慘的是，老闆若一切以客戶為尊，我看也不用 Agile 了，不管做什麼東西，最好就是一個月完成，喔不，最好是 1us 就能產出一個產品是最棒的