Agile is Dead
[翻譯] 敏捷已死
縮網址：http://wp.me/p16AXN-xV
原文網址：https://www.linkedin.com/pulse/agile-dead-matthew-kern
Matthew Kern
Enterprise Architecture Evangelist MSEA BSEE CEA3 CISSP-ISSAP PMP ITIL
企業架構管理專家
2016 年 4 月 20 日
[已徵得作者同意翻譯]
Are you an IT consultant or contractor? Agile Software Development work is dead. If you practice that, you are a doorstop. If you manage that way, you are a boat-anchor. The wave has ended, it is over, and if you went for the head-fake and bought certifications, you wasted some money. Soon recruiters will be putting your resume in the circular storage container. I have been warning you for some time, and the day is here. Hah, you should have listened. Move along.
你是一位科技業顧問或外包合約商嗎？我告訴你敏捷開發已經死亡了。假如你正在團隊中套用敏捷開發，你本身就是專案的阻礙。敏捷開發的潮流已經走到終點。假如你只是想拿證書做半套，那麼只是浪費錢。人資只會把你的履歷束之高閣。我很早就警告了這種現象，敏捷大限已到。如果你還沒聽過我的看法，看下去。
[For the less intuitive, please note that these overstatements are intentionally somewhat facetious. Some detail oriented readers completely missed the point of the sarcasm here. Agile is not a hamster and cannot die dead, splat, all at once. Death is an inevitable process, and it will continue to die. See below.]
〔給一些比較遲鈍的朋友，我用的誇張言論是故意而為。很多讀者似乎專注在文字遊戲而沒辦法看出我的諷刺。敏捷開發並不是生物，當然不會真的死亡或瞬間消失。但確實它是正在死亡中。請看內文〕
In truth, it will probably take a while. Many big things keep moving after death, like giant zombie worms. Big corporations, government agency business processes and obsolete technologies can be that way. Some small bits may live on forever, like the anti-hero’s hand or eye in a horror film.
事實上，還需要一些時間。很多設計在死亡後都還會存活一陣子，就像殭屍一樣。大型的機構，政府行政流程，及淘汰的科技比比皆是。一些小型組織會永久存在，像是驚悚電影中英雄可能的缺陷一樣存在。
All these hyped trends have a lifespan. Management fads especially have a lifespan. In the modern environment these waves are closer together, and closer, and closer. The end of the curve can mean unpopularity, few sales, reduced margins i.e “death". No more big money to be made, margins and fees reduced- this will happen when the market penetration is very high, at maximum, and then begins to fall. There will be too many people in the market, and this causes the salaries and fees to drop. This is opposed to the geek meaning, more akin to “brain death", implying the thing has no more technical merit. [Note: I ultimately had to spell this out. So much for sarcastic subtlety.]
全部流行都有炒作週期。管理領域的時尚特別如此。在現代，這種週期越來越快。每個流行通常歸結於不受歡迎，銷不出去，就是我所說的死亡。沒辦法再創造價值，或邊際價值。通常發生於市占率極高的時候就會開始反轉。在市場中有太多的供應者，薪水及收費則會下降。從尖端專業變成庸俗，我稱之是腦死狀態，也就是沒辦法再創造更多的技術價值。〔我不得不用這些精準描述的術語〕
So the job of the consultant is to grab a wave and make money while he can, then grab another. He may not serve customer interests much, but he can eat. At the beginning of some waves you will find engineering and technical rigor and proof, but at the end more concern for consultant fees, revenue and profit with some normal concerns regarding the extension of marketing and sales.
顧問的工作是抓住流行，持續賺錢，然後再搭上另一波潮流。顧問不可以只服務客戶的喜好，卻會因此賺錢。每波流行開始時，它們都是解決技術及工程的問題，但最後都是在追求衍生產業的收入，利潤，及顧問費。
These waves can be seen as the superimposition of Gartner Hype Cycle ™ curves for multiple technologies. Did you think it would last forever? Nothing lasts forever, but things based on solid engineering last longer. Guess where that puts Agile Software Development? In the trash. Manifesto indeed, I hope it felt good.
這些潮流在不同科技的 Gartner 炒作週期曲線中看得出來。你認為會永久持續的技術都不會永久，基於工程的事物會比較長久。猜猜看敏捷在這條曲線的哪裡？在垃圾區。只是像口號一樣，希望我這樣說它不會受傷。
Anyway there is a cycle, so it will eventually die in a marketing sense- replaced by the next thing.
總之，所有的事物都是循環，最終在市場的定義中會屬於已經死亡，或是被取代。
Who Said?
誰說的？
Who said Agile is dead? The founders of Agile and its practitioners said it, not me. Don’t go thinking I made this up. (I claim nothing myself regarding its current death, I just report the claims of many developers. It’s dead with or without me or my post. As for my interpretation of “dead", see above. This section explains a second meaning of “dead".)
誰曾經這麼說過呢？敏捷的創立者及他的實行者都這樣說。這故事並非我所編造。（我本身並沒有宣稱他目前死亡了，我會提出其他開發者的說法。不管我這篇文章存在與否，都不會影響其事實。而我對於這個死亡狀態的定義下面會提到。這邊我先列出提到相同看法的證據）
# Dave Thomas was one of the original 13 who proposed Agile Software Development. He says it is dead. Hate to read? See the Video. (He said roughly that they had lost control of the term “Agile" so another term must be used. Quickly, by the rules of such things, only the soundbyte remained, that they had lost control of the term “Agile". Agile was dead, per his title.)
# Richard Bishop wrote an angry developer response, agreeing.
# William Edmonson says Agile is dead.
# Kent Beck, one of the 13, had little to say about if Agile was a success. “I don’t have a sound-bite answer for you on that." So much for brand enthusiasm.
# Andrew Hunt of the 13 said it’s dead.
# Scott Ambler is now pushing Disciplined Agile Delivery because the original stuff didn’t cut it for enterprise class systems.
# Hayim Makabee says it died of oversimplification, and provides myths.
# Andrew Binstock says Agile was corrupted in Dr. Dobbs
# Mike Hadlow explains why agile failed.
# Stuart Eccles says “The more you try and practice Agile the less agile you become. # And vice versa."
# Darren says Agile should not have been a management process, roughly.
# Nathan Dintenfass says the language used is broken.
# Garreth Dottin says it’s destructive.
# Kristopher Wilson blames the stand-up meeting.
# Erik Dietrich provides great sarcasm as to why it was all silly.
# The Editors at Software Development Times say mainly the term is dead.
# DogitalRoot says it’s too convoluted, and therefore dead.
# These guys have a whole website to take advantage of the death.
# There is a Twitter Feed.
# I left out several hundred. Sorry for that.
# 開始推廣敏捷開發的十三位初始成員之一的 Dave Thomas。他說敏捷已死，還有影片為證。他很概括地說他們已經失去對於敏捷開發這個名詞的掌控權，所以應該要另外定義一個名詞。
https://pragdave.me/blog/2014/03/04/time-to-kill-agile/
https://www.youtube.com/watch?v=vqz8ND-N1hc
# Richard Bishop 以一位憤怒的開發者的角度回覆，同意這種觀點。
http://rubiquity.com/2014/03/12/agile-is-dead-angry-developer.html
# William Edmonson 也說敏捷已死
http://www.williamedmondson.com/agile-dead/
# Kent Beck 同樣是十三位成員之一，對關於敏捷是否成功表示遲疑。
http://www.infoworld.com/article/2624279/agile-development/agile-programming-10-years-on–did-it-deliver-.html
# 同樣是十三位成員之一的 Andrew Hunt 表示敏捷已死
http://techbeacon.com/agile-manifesto-dead
# Scott Ambler 正在推動 Disciplined Agile Delivery 因為原本的東西不符合企業等級的系統。
https://www.ibm.com/developerworks/community/blogs/ambler/entry/reworking_the_agile_manifesto14?lang=en
# Hayim Makabee 說簡單來說敏捷已死 https://effectivesoftwaredesign.com/2014/03/17/the-end-of-agile-death-by-over-simplification/
# Andrew Binstock 在 Dr. Dobb’s 說敏捷已經崩壞
http://www.drdobbs.com/architecture-and-design/the-corruption-of-agile/240166698
# Mike Hadlow 解釋為何敏捷開發失敗
https://dzone.com/articles/coconut-headphones-why-agile
# Stuart Eccles 說你越是想要認真執行敏捷開發，你就距離敏捷更遠。
https://madebymany.com/blog/the-more-you-try-and-practice-agile-the-less-agile-you-become-and-vice-versa
# Darren 說敏捷不應該是一個管理流程
http://51elliot.blogspot.tw/2014/03/when-agile-went-off-rails.html
# Nathan Dintenfass 說敏捷這名詞已經被用壞了。
https://medium.com/deconstructing-agile/deconstructing-agile-the-language-of-agile-is-broken-e0b60ba28901#.xvpkyxfr6
# Garreth Dottin 說敏捷是毀滅性的。
http://habitsanddesign.com/2016/02/08/agile-is-dead/
# Kristopher Wilson 譴責站立會議。
http://kristopherwilson.com/2015/03/09/the-daily-stand-up-is-an-antipattern/
# Erik Dietrich 挖苦為何敏捷是如此的蠢
# Software Development Times 的編輯說這名詞已經死亡
http://sdtimes.com/from-the-editors-agile-is-dead-as-a-term/
# DogitalRoot 說敏捷正在兜圈子，接著會死亡。
http://www.brianmulford.com/digital_root/2011/09/agile-is-dead.html
# 竟然有一個宣傳敏捷已死的網站
http://www.agileisdead.com/
# 以及一個宣傳敏捷已死的推特帳號
剩下的族繁不及備載
The moral of this part of the story is that if you want to use a specific brand/term (Agile) in a specific commercial domain (software development) with a specific meaning (manifesto), then get a trademark from USPTO. Otherwise your naive efforts will be co-opted, and your control/meaning will soon be lost as money is involved.
這段故事的教訓是說假如你在一個商業領域（軟體開發）有一個特定的名詞（敏捷）內有一連串特定的意義，請去申請一個商標。否則你的任何努力最後都會被分享並操作，最終主導權跟定義權會被奪走，當然也無法因此賺錢。
The meaning (of the brand name “Agile) was lost, the technical merit was diluted, and those looking for technical excellence abandoned the effort, but for the efforts of “true believers" it might be history already.
這個招牌敏捷的定義已經不如以往，技術上的功勞已經被稀釋。我們已經不再找尋技術上的精進，只剩下支持者對過往的信仰不斷強化。
Inevitable
不可避免的
The geeky death of the brand-name occurred some time ago, though few noticed. I thought its demise was inevitable myself. Yes, I participated some early on, then stepped back from the media event boondoggle. Why?
這個品牌的墮落是在一段時間之前發生，雖然很少人注意到。我想死亡是不可避免的。在早期我參與了它，但精確來說為什麼在媒體介入之前我就退出了？
# Agile had a sweet-spot, and a range of inapplicability, but everyone wanted to ignore that.
# I knew it was being hype-marketed, and the facts were secondary.
# There was a sacred mythology, strange terminology, special sacred tools and other weird cult behavior. (For example many Agile practitioners are bullies, and want to browbeat you into agreeing with them. They will attack you or undermine your credibility when you disagree. I was just threatened yesterday 4/28 by one young acolyte.)
# I saw everyone hammering it to fit with much more important corporate controls. Clearly we had suboptimization with development thinking they were the most important part of the ecosystem.
# I participated in an Agile development effort where the focus on the user was clearly highlighted as a myth in transformation initiatives. The end-users had no idea that their organizational function was obsolete and redundant. There was no reason to automate it. Millions were wasted.
# We really need repeatable process, maturity, but as soon as you turn Agile into process you have the compromised junk design that results from trying to bridge a dichotomy.
# Agile did not support strategic goals well. Attempts to scale Agile to reach strategy fell short. There was no mechanism for alignment.
# Agile had (still has) an inherent problem with fiduciary responsibility. You do not know what the software will do before you build it, and you cannot estimate its effect on operations. Therefore you cannot calculate ROI before you start. You are writing a blank check for an uncertain return.
# It never did really work well for big, complex systems. (Yeah, tons of people did an anti-agile manifesto, that was just my take.)
# It did not work well in enterprise environments, where I do most of my work.
# The Agile over-reliance on user stories interfered with test and evaluation, especially higher level test and evaluation and security testing. Insufficient testing is a problem bigger than the scope of developers.
# I knew emergent design was junk architecture. They call it the Big Ball of Mud pattern.
# There were so many big Agile failures that I lost track. The success rate for Agile projects was 67% in 2012, not much improvement, aided by a lack of concrete completion criteria and dates no doubt, but the failures are mostly big and complex projects, highly visible, with big budgets. (Allen Woods finds this example enlightening.
# Software quality is low. The industry is not focused on quality. Lists of security defects for major software companies show high levels of open deficiencies. The ever increasing backlog of defects in Agile can be seen in the problems with the “technical debt crisis". Even websites more often work poorly. This has occurred despite claims of higher quality in Agile, probably because various non-functional and derived requirements are simply never discovered. It has affected development cost.
# Then the new FITARA law seemed to be in conflict, so the big bucks in government contracting were at risk. For me, the Fat Lady was singing.
# 敏捷曾經有過好球帶，代表有特定的不適用範圍，但每個人似乎都刻意忽視這個部分。
https://www.linkedin.com/pulse/20140704132728-86002769-agile-limits?trk=mp-reader-card
# 我知道敏捷面臨炒作，還有墓誌銘作為證據
https://www.linkedin.com/pulse/agile-hype-cycle-matthew-kern-msea-cea-pmp-itil-cissp-issap?trk=mp-reader-card
https://www.linkedin.com/pulse/interpreting-agile-manifesto-kern-msea-cea-pmp-itil-cissp-issap?trk=mp-reader-card
# 曾經有一個神聖的方法學，奇怪的名詞，特殊的禮拜工具，以及其他奇怪的儀式。（打比方說很多敏捷參與者就像是教堂長老，他們會認為你應該要認同他們。當你不同意時，它們會攻擊你，逐漸削弱你的發話權。我才剛在四月二十八日被一個年輕的司祭威脅過。）
http://www.csj.org/infoserv_cult101/checklis.htm
# 我曾看過每個人都想用敏捷取代更重要的公司運作。顯然我們試著只關心小地方是否有效率，而忽略了整個生態系統。
https://www.linkedin.com/pulse/20140826222008-86002769-what-is-suboptimization?trk=mp-reader-card
https://www.linkedin.com/pulse/who-munged-agility-matthew-kern?trk=pulse_spock-articles
# 我曾參與過敏捷開發課程，在創新的轉換中專注於把使用者神化。終端使用者不知道他們在組織中功能竟然其實是累贅與阻礙。這個部分其實不需要自動化。百萬元浪費在這裡。
# 我們其實有時是需要可以重複執行的固定流程，但當我們把敏捷導入的時候二分法卻造成垃圾般的設計。
https://www.linkedin.com/pulse/20141120095201-86002769-agility-vs-maturity?trk=mp-reader-card
https://www.linkedin.com/pulse/agility-maturity-matthew-kern-msea-cea-pmp-itil-cissp-issap?trk=mp-reader-card
# 敏捷其實並不支援戰略角度，想要把敏捷提升到戰略的高度會顯得缺漏。企業需要標準化，敏捷沒有這些工具。
https://www.linkedin.com/pulse/big-picture-matthew-kern-msea-bsee-cea-cissp-issap-pmp-itil?trk=mp-reader-card
https://www.linkedin.com/pulse/20141116170109-86002769-enterprise-architecture-vs-safe?trk=mp-reader-card
https://www.linkedin.com/pulse/20141120000844-86002769-alignment?trk=mp-reader-card
# 敏捷有與生俱來的委任特性，在流程之前你不知道專案做了甚麼，也不能追蹤整體專案的產出。因此你在開始敏捷之前你並不能追蹤效率。也就像是你在一個不知道要傳回甚麼的函式中作一個盲目檢查。
# 在巨大且複雜的系統中敏捷沒辦法運作正常。（甚至有一堆人嘗試證明敏捷會帶來反作用）
https://www.linkedin.com/pulse/anti-agile-manifesto-matthew-kern-msea-cea-pmp-itil-cissp-issap?trk=mp-reader-card
# 在企業環境中不適用。
http://www.infoq.com/articles/agile-fails-enterprise
# 敏捷大量依賴測試及量測所帶來的使用者故事，特別是高功能性的試用，測試不足就導致更大的問題。
https://www.linkedin.com/pulse/systems-test-evaluation-matthew-kern-msea-cea-pmp-itil-cissp-issap?trk=mp-reader-card
https://www.linkedin.com/pulse/enterprise-system-requirements-matthew?trk=mp-reader-card
https://www.linkedin.com/pulse/too-much-modeling-little-testing-matthew?trk=mp-reader-card
# 短時間內可以展示的最小設計其實是垃圾設計。被稱為大的泥巴球。
https://www.linkedin.com/pulse/20140803144645-86002769-the-best-architecture-is-not-emergent?trk=mp-reader-card
# 我沒有追蹤很多失敗的敏捷案例。但我知道在2012年敏捷專案的成功率是百分之六十七，而且沒有怎麼進步，大多數失敗是在複雜的大專案，無法忽視又有高預算的。（Allen Woods找到了證據）
https://www.linkedin.com/pulse/why-federal-projects-fail-kern-msea-bsee-cissp-issap-cea-pmp-itil?trk=mp-reader-card
http://www.computerweekly.com/news/2240187478/Why-agile-development-failed-for-Universal-Credit
http://www.drdobbs.com/architecture-and-design/agile-success-factors/232601858
http://www.jamasoftware.com/blog/rethink-agile-manifesto-projects-still-fail/
# 軟體品質其實普遍低落，尤其業界自己就不在意品質。大型軟體公司的安全漏洞顯示出高等級的缺陷。在一篇軟體債務危機的文章中甚至可以看到敏捷帶來遞增的缺陷記錄。網頁就做得更差。在高品質的敏捷中還是發生，也許是因為很多沒有功能的功能及延伸的需求並沒有被接露。敏捷甚至讓預算增加。
http://www.qualitydigest.com/april03/articles/03_article.shtml
https://www.kennasecurity.com/press/companies-leave-vulnerabilities-unpatched-for-up-to-120-days-kenna-security-finds/
https://www.cvedetails.com/top-50-vendors.php
http://sdtimes.com/guest-view-the-software-debt-crisis/
http://www.infoworld.com/article/2878425/application-development/low-software-quality-blame-poor-requirements.html
http://searchsoftwarequality.techtarget.com/feature/Software-defects-increase-cost-of-Agile-projects
# 敏捷開發是否違反聯邦法律這件事還在討論中，導致政府的錢其實暴露在危機中。對我來說只是還沒爆發而已。
https://www.linkedin.com/pulse/fitara-vs-agile-m-k?trk=mp-reader-card
Others were skeptical too, of course. Here is a great article by David Longstreet expressing a range well thought out of misgivings. Yet Agile has become the most popular software project management paradigm, certainly exceeding my expectations. People commonly fix some of these issues above, ignore the manifesto, and call it Agile anyway (AINO). Market penetration is high, real applicability is limited, problems have not been solved, the original supporters have left, the name is tarnished, implementations are highly modified away from original goals.
其他人則當然抱持陰謀論。David Longstreet寫了一篇文章說明他一連串的擔憂。但敏捷仍然變為了一個最熱門的軟體開發管理範例，已然超過我的預期。人們通常很快速地把錯誤修好，然後把這個流程叫做敏捷，同時沒有想想這流程的問題。市占率很高，實際上的適用率卻很受限，問題其實沒有被解決。創立者已經離開，名銜黯淡無光，實際執行的內容與剛開始的目標已經不一致。
按一下以存取 Agile%20Method%20and%20Other%20Fairy%20Tales.pdf
https://www.linkedin.com/pulse/aino-agile-name-only-matthew-kern-msea-cea-pmp-itil-cissp-issap
To continue selling, marketing money will be shifted to supporting a new product name and highlighting the problems of the old product. Agile will be obsolete. This is how the market for such methodologies and services works.
為了持續販賣敏捷開發，投資會轉為支援新的產品，詆毀舊的產品。敏捷此時立即變成障礙。這就是針對方法論及服務的市場如何運作的道理。
[Whatever the next wave is, there is certainly are a mass of deficiencies to highlight in the Agile wave. Surely they will be exploited? The point of this section is less that I am calling the baby ugly to anger the fanatic parents- but rather that others are probably coming to do so. They have plenty of ammo.]
[不管下一波流行是甚麼，現在的敏捷潮流中已經開始發現一堆缺陷。顯然很快就會爆發，這段的重點是其實不希望最後是噁心的孩子開始對狂熱的母親生氣，但其他人可能開始這樣做了。他們已經準備好了]
The moral of this part of the story is that if you produce some compact politicised ideology (manifesto) consisting of principles and rules there will be unintended consequences. Success creates a religion or cult, and defeat is being ignored. No such doctrine is perfect. Thinking you will change the world with a manifesto is naive, and if you succeed you may not have improved the world.
這段故事的教訓是說假如我們的產品是政治性的理論，其中包含準則及規則導致了不預期的後果。成功的人會創造一個宗教或儀式，而失敗者就被忽略。沒有學說是完美的。用一套宣言改變世界是天真的，甚至假如成功時，世界也不一定會被改善。
What Can be Saved
有甚麼應該保存？
I am certain parts can be saved. I participated in a large project about 1994 with small teams, daily standups (we sat down) for problems and weekly progress checks. It worked great, and I was a big fan. I also participated in what was essentially scrum development with a genius team in 2005- without a manifesto or various nonsense. In both cases the architect knew what the thing would do before effort began, and you could identify ROI. Surely there is more that works fine and can be saved if you take out the insane bits of cult logic.
我確信其中一部份是應該留下來。我在1994年跟幾個小團隊參與一個大型專案，每日站立會議（但其實我們是坐著）解決問題確認每周進度。運作得很好，我很支持這樣的做法。我也在2005年跟天才團隊參與核心的 Scrum 開發，沒有照著甚麼宣言或無意義的規範。在兩次經驗中，在實做之前都知道該做甚麼，也很清楚產出的效能數據。當然假如我們把瘋狂跟儀式化的邏輯拿掉，很多部分都可以保留下來。
User stories for example are fine, if you use them to produce real requirements. Poor requirements and poor testing have driven the software quality problems related to Agile. I do not here refer to very low-level testing which might be automated, but the rest of it.
舉例來說使用者故事是合理的，用它可以產生實際的需求。需求及測試不明確真的產生軟體品質的問題。我這裡不是在談那些低階的自動化測試。
The name of Count Agile may live forever, as an ideal, both undead and brain-dead. I recently heard I could program in FORTRAN- oops- Fortran again for 6 figures. Yet the specific term “Agile" as a brand probably has to go- Dave Thomas was right.
理想中敏捷會永存，也有可能腦死。就像是我現在仍可以用 FORTRAN 噢不是 Fortran 寫程式。當然這個敏捷的招牌必須拿掉，正如 Dave Thomas 所說的一樣。
However the Agile Manifesto should be replaced with reputable research findings and serious management. This “manifesto" eschewed all management and engineering rigor in favor of laziness. Some of it should probably also be burned, buried and then a very big rock placed on top. Then a warning to future generations should be carved in the rock. ‘Something like “Naive oversimplified management ideology does not sell services forever, especially when promoted by non-managers. BOHICA!"
然而敏捷的那些宣言應該被知名的研究發現及嚴肅的管理學所取代。那些宣言因為懶惰的原因避開了管理及工程的檢驗。其中的一些甚至應該燒掉，埋葬，用巨石鎮壓，然後把這個警告刻在石頭上：天真地過分簡化管理，特別是被非管理者所提倡的那些理想永遠都不應該拿來販賣。別再來了！
What’s Next
下一波是什麼
So next comes the DevOps wave. It is the “heir apparent". If you buy software development services at a medium or large scale then someone will be in your office selling you DevOps this year. (When they do, they will say it is better than mere Agile. You have to buy it.) There is still a chance to fix this one.
下一波是開發營運協同（DevOps）的潮流，它繼承了我們所說的這一切。假如你曾經買過軟體開發的顧問服務，那麼這個人今年會來兜售 DevOps。（當他們這樣做的時候，他們會說那比敏捷還好。你得趕快購買。）你還有機會不要中招。
# We could take a wider focus than last time on enterprise considerations.
# We could integrate corporate controls.
# We could recognize the real reason enterprise software exists, where most of this custom coding happens, and focus on code relevance.
# BiModal IT could fix some of it, if any of these analysts could grasp the full lifecycle and where each method fits for but a moment.
# We could lose the “full stack developer" mythology.
# 我們可以從企業的角度看得更廣一些。
https://www.linkedin.com/pulse/20141101092654-86002769-devops-or-devops?trk=mp-reader-card
# 我們可以更關心整合合作的角度。
https://www.linkedin.com/pulse/20140809223124-86002769-beyond-devops-combined-ops?trk=mp-reader-card
# 我們可以試著辨識企業軟體存在的目的，現在的程式出現甚麼問題，專注在程式碼是否能真正解決問題。
https://www.linkedin.com/pulse/20140803161040-86002769-the-value-of-enterprise-software?trk=mp-reader-card
https://www.linkedin.com/pulse/enterprise-software-matthew-kern-msem-bsee-cea-cissp-issap-itil-pmp?trk=mp-reader-card
https://www.linkedin.com/pulse/code-relevance-matthew-kern-msea-cea-pmp-itil-cissp-issap?trk=mp-reader-card
# BiModal IT 也許可以解決一些問題，假如它的分析家可以掌握生命週期，同時知道每個方法在哪個時候適合使用。
https://www.linkedin.com/pulse/20141111154421-86002769-bi-modal-it-combined-ops?trk=mp-reader-card
https://www.linkedin.com/pulse/bimodal-matthew-kern?trk=mp-reader-card
# 我們可以丟掉全端工程師這個神話。
There are also various modified forms of Agile resulting from practical experience and improvement. Maybe someone will make a real marketing effort with one of those.
從實務的觀點來看有很多種不同的改良敏捷版本。也許某人可以看得出來行銷潛力。
The moral of this part of the story is that if you started adopting Agile now, you would be a very late adopter. Adopting any such sweeping change has a high startup cost. You may be better off skipping a wave and moving directly to whatever comes next.
這段故事的教訓是說假如你開始套用敏捷，你已經是一個反應很慢的人。每次的改變都是有很高的成本。你應該試著跳過這一波，然後提早因應下一波潮流。
Recommendation
建議
In the meantime, if you are currently using AINO (like my government colleagues) you are at the state of the art, and doing the right thing. Be prepared to adjust DevOps the very same way, accommodating governance and controls. Consider relaxing mandatory methodology rules to allow the PM to customize for the situation at hand. Consider that Agile may not be best for large, complex projects. If they force you to use Agile, agree and adapt whatever you need to to make it work- regardless of purists. Read this.
假如你現在其實行事就夠敏捷（像我在政府單位工作的同僚一樣），你就已經內化了敏捷的精神，這就很好了不需要改變。在 DevOps 這一波來時用同樣的方法去面對它，適應即將來到的管理及外部控制。試著針對方法學保持適度的彈性，允許專案經理對狀況做客製化。試著理解敏捷方法其實對大專案並不是最好的。假如他們逼迫你使用敏捷開發，表面上對信徒們表示同意，然後私底下在調整後的範圍內工作。讀讀這篇文章：
https://www.linkedin.com/pulse/20140821111841-86002769-buying-ideas?trk=mp-reader-card
However if you ask me what direction we should be going in, I do have an opinion. While in manufacturing approaches like Lean and Six-Sigma are meant to improve quality, Agile and DevOps are meant to increase volume. But the quality of our software is too low, and the requirement has increased. The number of defects, including vulnerabilities is far too high. In enterprise software, the quality of software measured as “fit for purpose" is also become too low, decreasing operational improvements. If I were king, I would prefer to see a methodology using the (ISC)2 recommended practices in the SDLC, and the emerging OWASP practices, with more certifications like the CSSLP. I would like to see us turn away from greater volumes of sloppy software before it destroys civilization.
但假如你問我，若是要認真實行敏捷，我們該如何進行，我還真的有一點意見。當在公司內部想要推廣精實，或六西格瑪來改善品質時，推廣敏捷及 DevOps 來增加總量時。但我認為我們的軟體品質太低，需求常常不斷增加，臭蟲包含安全性問題的數目則太高。在企業級軟體中，軟體常常只要你"適合需求"，此時品質必定低落，同時會很難在操作上改進。假如我有權力改動，我就會在軟體開發週期使用這兩篇 ISC 提到的方法論並推薦認證過的軟體生命週期規範（Certified Secure Software Lifecycle Professional）中的幾篇文章。我們就能避開那些將摧毀一切的軟體開發方法。
http://www.cio.com/article/2415991/enterprise-software/7-sensible-steps-to-improve-software-quality.html
https://www.linkedin.com/pulse/who-munged-agility-matthew-kern?trk=pulse_spock-articles
https://www.owasp.org/index.php/Secure_SDLC_Cheat_Sheet
https://www.isc2.org/csslp/default.aspx
http://time.com/3928086/these-5-facts-explain-the-threat-of-cyber-warfare/
Outlook
前景
The Agile hype-wave is over. There were serious, fundamental problems. I really doubt anyone will fix those issues in DevOps. Enterprise customers will have to create hybrid approaches, just like Agile. Our current culture in software technology is not about real improvements. We currently prefer comfy culture over strategy and effectiveness.
敏捷的炒作曲線已經結束。它有一些嚴重且基礎的問題。我很懷疑在 DevOps 中，這些問題有人能解決。企業級的顧客必須採取混合的做法，其實就像敏捷的精神一樣。我們現在使用的軟體科技環境並非希望真實改善情況。而是期待安全勝過於策略及效率。
https://www.linkedin.com/pulse/20140719164159-86002769-the-culture-of-mediocrity?trk=mp-reader-card
https://www.linkedin.com/pulse/20140822173711-86002769-culture-vs-strategy?trk=mp-reader-card
If you really want to fix it, I’ll be right here to talk about that. In the meantime you might look up systems engineering, CMMI, corporate controls, security testing, operational evaluation and start thinking how that can be bolted on to DevOps. Or you can work in a product oriented software development company and stay away from enterprise software implementation. That oversimplified crap may work inside a software development company, but not in an enterprise customer environment. (Toby Wootton recently expressed it well, with a PM spin.) Big enterprises have switched to AINO (Agile In Name Only).
假如你真的想要改善問題，我接著才談這個問題。同時你必須查看系統工程，CMMI，公司控制，安全測試，操作的評估，然後開始想想看那些東西如何會在 DevOps 中發生衝突。你也可以改在一間產品導向的軟體開發公司工作，免去企業軟體的問題。在純軟體開發中會大大簡化我們遇到的問題。因為那些產品並非給企業客戶使用。（Toby Wootton 在這篇中：https://www.linkedin.com/pulse/dont-join-cult-stop-worshipping-agile-craftsman-deliver-toby-wootton?trk=prof-post 用一個專案經理的角度闡述了這個說法）。大公司其實已經夠敏捷了。
In the meantime when you say “Agile Software Development" everyone will know you are referring to just another methodology, one that failed to produce the promised results, one that was widely implemented inadequately, one no better than Waterfall or Spiral overall, one with certain relative strengths and even more weaknesses. ‘No more magic dust. Several of the founders of Agile Software Development and many other influential developers have pronounced it dead. Only consultants and managers with a vested interest in the brand-name “Agile" still want it alive.
同時，當你說到敏捷軟體開發時，每個人必須知道你要說的是一種無法產生預定結果的方法學，一種被廣泛地不適當執行的方法學，一種比瀑布式或螺旋式沒有好多少的方法學，一種雖然有優點，但是也有相對缺點的方法學。這不是甚麼魔法，幾個敏捷軟體開發的創始人都認為它已經死亡。只有顧問跟把敏捷當作興趣的經理才會希望敏捷長存。
Summary
總結
Here is the summary of what I said:
最後是我想說的結論：
(1) Agile became a brand-name, with marketing hype. It therefore became subject to the rules of all such hyped products. First there is great acceptance, then a crash. A period of long term acceptance may occur, or not, based on real results. However the days of fanaticism and huge hype will be over forever. This is “death" in a marketing sense.
敏捷已經變質為一個招牌，還是一種行銷的炒作。它只是波潮流所推送的產品中的品項。先要求你承諾，接著帶來摧毀。也許會有一種長期的效應發生，然而狂熱及欺瞞終究會結束，這就是從市場來看的死亡。
(2) As this happened, the deep programming thinkers who created and adopted the methodology became disillusioned as none of the vision was being implemented. The name Agile was co-opted. Substitutions and changes did not accomplish the goals of the proposal. It was abandoned by those deep thinkers. The core technical merit was lost. This was “death" in a the geek sense.
當這件事發生時，具有遠見並創造這些方法學的程式人員就會醒悟，發現願景並沒有真正落實。敏捷的這個名稱是被操弄的。這些取代及改變並沒有真的實現原本計畫中的目標。這個名詞已經被創始者所遺棄。核心的技術功勞已經不存在，這是從技術人員來看的死亡。
(3) Those who remained sold Agile in a highly modified sense, keeping the name but little of the original vision. This pragmatic view was driven by sales and marketing, as the name still had time left in the cycle to be exploited. Customers adopted Agile with massive changes to fit in with real enterprise governance and corporate controls, for example. See my post on AINO.
仍然努力販賣敏捷的那群人，只擁有這些名稱，而缺乏原本的願景。他們務實的態度是由銷售數字及市場來驅動的，假裝這名字還存在而利用它。使用敏捷的客戶做了無數的改變只是為了假裝融入大企業的領域及控制，我的很多文章已經舉例說明。
This last is the nature of current adoption, but the hype wave has ended or is ending. This is a post about hyped technologies and methodologies, marketing, and the end-game of a brand-name abandoned by its originators. It is about the cynical nature of what remains. It is about the old brand being currently superseded by the new brand, with fundamental problems unaddressed.
最後即便炒作周期已經走到終點，給現在還在適應的這群人。這篇文章是用來說明方法論，科技，市場及一個已經被創始者遺棄的品牌結局的騙局。這是一篇諷刺現況的文章。這是一個有問題的新科技取代舊科技的故事。
Read the follow-on post, “Agile Is Dead 2″.
Then read Real Agility.
And also “The Enterprise Quality Gap".
請依序接著讀我的文章：敏捷已死第二集，真的敏捷，企業品質差異。
https://www.linkedin.com/pulse/agile-dead-2-matthew-kern?published=t
https://www.linkedin.com/pulse/who-munged-agility-matthew-kern?published=u
https://www.linkedin.com/pulse/enterprise-software-quality-matthew-kern?trk=pulse_spock-articles
———————————————–
(Note: Just to be clear, software development has little to do with the common daily duties of an enterprise level architect. (EA does often keep the list of organizational standards. Agile could be among those. There is some possible relevance.) But, as some of you know, I was long ago a PM for integration projects, a solution architect, and did some of my own prototyping, wrote some drivers, did some assembler for a couple years. Hence my interest in this topic. I do not think of this as one of my many EA posts. No more flames claiming I think dev is EA. Thanks.)
備註：這邊說清楚，軟體開發跟一般的企業等級架構運作稍有不同。（EA倒是有一個組織標準：敏捷就在其中。確實有一些相關性）但是，你們中的一些知道，我以前曾是專案經理，架構師，我以前也實作原型，好幾年寫驅動級組語。因此本篇算是我的興趣。我不認為這代表 EA 的我，請不要說這代表 EA 的開發態度。謝謝。
https://www.linkedin.com/pulse/enterprise-architecture-centric-matthew?trk=mp-reader-card
https://www.linkedin.com/pulse/management-enterprise-architecture-matthew?trk=mp-reader-card
https://www.linkedin.com/pulse/top-3-myths-enterprise-architecture-matthew?trk=mp-reader-card
(Note: This was partly meant as a public service to my colleagues who are still seeking the mystical one, wherein the screen and keyboard disappear and only your mind and the code remain. You published truth and the marketing machine ignored it. I took my shot. I did not expect all the management consultants still pushing Agile (to make money) to launch desperate attacks and claim it has an endless bright future. This is not why I selected the image, it was just not expected to be such an incendiary topic. Really. I just randomly picked that image. No?)
…Another item off my “bucket list".
備註：我部分地把這篇文章當作給我還汲汲於敏捷的同僚的免費服務。我以為我發了文章之後會被大家所忽略。沒想到，那些還在銷售敏捷（賺錢）的管理顧問開始垂死的攻擊，宣稱敏捷仍無限美好。我挑選封面圖片時還沒預期到這樣的情形，沒預期到戰火會這麼猛烈。真的。我只是隨機從我的清單中挑了一張。
NDark MSN Live Space 
去你大爷的