敏捷方法是否應該有認證計畫？

我大多數的朋友和同事都非常反對軟體開發中的認證計畫，我也很贊同這種觀點。這並不表示我認為軟體認證在定義上是糟糕的，只是我們看到的大多數認證都無法通過基本測試。

持續整合是軟體開發中的一種流行技術。在研討會中，許多開發人員會談論他們如何使用持續整合，而持續整合工具在大多數開發組織中也很常見。但我們都知道，任何像樣的技術都需要一個認證計畫，而且很幸運地，確實有一個認證計畫。它是由持續交付和 DevOps 領域的頂尖專家之一所開發的，以其管理速度極快，但結果非常有見地而聞名。雖然它已經相當成熟，但知名度還不夠，所以我作為這個技術的愛好者，認為有必要與我的讀者分享這個認證計畫。你準備好接受持續整合認證了嗎？你將如何應對考試結果揭示的驚人真相？

成熟度模型是一種工具，可幫助人們評估個人或群體目前的效能，並協助找出他們需要進一步獲得哪些能力才能提升績效。在許多圈子中，成熟度模型聲名狼藉，但儘管它們很容易被濫用，但如果使用得當，它們還是有幫助的。

我經常遇到一個抱怨，即敏捷方法沒有嚴謹的定義。抱怨者可能會談論這意味著你無法判斷一個特定的團隊是否使用敏捷方法。他們還可能會說，這使得很難教人們如何執行敏捷方法 - 課程是什麼？

在某種程度上，我確實感受到了這種抱怨的痛苦 - 但我接受沒有治癒方法。這種缺乏嚴謹性是敏捷方法定義性質的一部分，也是其核心哲學的一部分。

對於第 n 次，而且我敢肯定不是最後一次，我陷入了一場關於定義實務、將其中一些標籤為「最佳」以及可能是 C 字（認證）的對話。這是一個熟悉的討論，儘管我們才剛開始，但我可以預測它將走向何方。這是由一個完全合理的願望所驅動的，即找出誰是更好的軟體開發人員，以及現有的開發人員如何提高他們的技能。

SEMAT（軟體工程方法與理論）是由 Ivar Jacobson、Bertrand Meyer 和 Richard Soley 發起的努力。其既定目標是「基於穩固的理論、已驗證的原則和最佳實務，重新建立軟體工程」。與軟體界許多臭名昭著的人一樣，我被邀請參加。到目前為止，我已經拒絕了，並覺得有必要解釋原因。

這個月是審查 IEEE 的軟體工程知識手冊。這是一種嘗試定義我們專業的知識體系，以便為執照專業奠定基礎。