搜尋此網誌

2014年10月31日

關於 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 就能產出一個產品是最棒的

沒有留言:

張貼留言