流星轟落(Meteo fall)開發

原文連結:http://eiki.hatenablog.jp/entry/meteo_fall

今天來為大家介紹最能代表日本軟體業界的開發方式吧。

其名為:流星轟落(Meteo fall)開發 *1



第一節

通常以 瀑布模型 開發方式進行的專案會是像下面的方式。

Waterfall


那麼 流星轟落開發 則會變成這種形式。
Meteofall



然後變成這樣。
Meteofall2



接著下面是敏捷開發的生命週期。
Agile



但在神的面前一樣婉如螻蟻。
Agile2



神之聲,毀滅萬物。
fallen

而人們則傾注全力從廢墟中重造。
rebuild

這就是流星轟落開發 (≒隕石驅動開發)。



第二節

所有的工作排程都由天界的意識來做決定。這同時也可以被稱為默示錄
Schedule



對於軟體開發來說,Feedback 是重要的一環。
Feedback

但對神來說 Feedback 就像耳邊風一樣。
GodFeedback



只不過,向神奉上祈求是被允許的,雖然很少能傳達到神到耳中
Pray



神明大人有各式各樣的姿態。
從外部顯身,
God1

或是棲息在內部。
God2

甚至,根本還沒見到,或是沒辦法見到的某某某也說不定。*2
God3



讓軟體開發效率激增的銀彈雖然不存在,但相反的存在是有的。在梵教裡面的話來說,就像是帝釋天的箭矢一樣吧。
arrow



第三節

即使如此,當秩序是建立在神只有一人的情況下,這都算還不錯了

問題就出在神存在兩人以上的時候。
這些神祇們會經常性的下達相反的指示,經常性的爭執。
Ragnarok

而這就是吾輩的諸神黃昏《Ragnarok》
然後受害最深的,終究還是我們「人民」



另外,原本只有一個神所建築起來的秩序,當新的神降臨的時候,
古神所構築起來的一切全部都會被推翻
Ragnarok
而這就是聖戰《吉哈德》*3



但因為神的不同,可能會有依舊持有絕對的力量,卻存在感極為稀博的神存在。

God4
需要的時候卻找不到的神,恐怕就是邪神了。*4



然後我們用血與汗堆砌而成的結果,會在吾輩所未知的地方盛大的發表
release
然後在此彼方,將會誕生新的規格



結論

這次我們介紹了非常自然的存在於日本軟體業界裡,最為災厄性的流星轟落開發給各位。


順帶一提,對抗這種情況的解法並不存在。
願汝,不,願吾輩能早日在某天找到對抗手段。



本篇文章純為虛構。與一切實際存在的人物、團體無關。



*1: 命名由來。へっぽこ氏(@heppoko
*2: 簡單來說就是指擁有版權者或是著作者。這種模式更為糟糕。
*3: 最常發生在比預定的 Release 時間晚一年的軟體專案裡。
*4: 出處為馬太福音7章7~12節:『你們祈求,就給你們;尋找,就尋見;叩門,就給你們開門。因為凡祈求的,就得著;尋找的,就尋見;叩門的,就給他開門。』

翻譯授權:EIKI (id:eiki_okuma)
https://twitter.com/eiki_okuma/status/1002390661448982530