Ellyssa Kroski談到了選擇/不選擇某種技術的五個原因。
“團隊會傾向于他們覺得用起來順手的技術，因為每個團隊已經建立起了一系列的技能。首要的關注點應該是特性和功能，而非技能集。一定要跟你的技術專家合作，好讓他們理解他們要擴充他們的技能集，而且得到他們需要的培訓。
你的老板會從雜志上讀到它，在培訓時聽到它，在夢里夢到它。如何告訴你的老板其他選擇，而又不致于顯得是在貶損他們的發現？這得把握住分寸，小心翼翼地試探。通過把手頭做的調研工作擴展至其他選項，自愿地讓他更全面的掌握信息 - 當然，應他的請求！
你的朋友告訴你“它是重大創新！”。接受熟人生動地轉述來自客觀源頭的原始數據是我們的天性。但要是選擇技術解決方案也如此的話，這種道聽途說的證據并不能給我們提供一個對于該軟件、其特性、功能或公司可行性的全面評審。
它是昂貴的，是便宜的，還是不要錢的。很容易假設，因為產品最貴，所以它就一定比它的競爭對手要好。類似的，我們大多數有預算壓力的人總是斤斤計較。評估某項技術解決方案時有非常多的因素要考慮，不要孤立的把價格作為衡量價值的指標。”
能力
另一件重要的事情是團隊掌控被引入的新技術的能力。要是你發現有人在一個問題上糾纏了好幾天，大可不必感到驚訝。
在引入新事物時，這是司空見慣的情形。因此，在使用新技術時進行結對是必要的。對于某些問題，所需的腦力超出了單個開發者的水平，因此，結對肯定能對此有所促進。
在敏捷里，團隊規模相當小，因此，假若某人一直在從事新技術，那么團隊就會對他產生依賴。在結對編程時，關于新技術的知識隨之分散到了整個團隊里，團隊就有了一個平衡的“車號”（Truck Number，譯注：車號是評估軟件項目長期存活力的非正式度量，它指的是對于項目成敗非常關鍵的開發者個數，該數值越低越好。更多的描述請參見這里）。
在新技術上結對編程的一個附加好處是團隊的學習。
個人學習是必須的。要想變得高效，程序員必須用最新的技術武裝和增強自己。這不僅對項目有益，而且可以滿足程序員對于知識的渴求。學習將讓他們對自己的工作滿意，進而增加個人和團隊的生產力。
Andrew談到了學習對于工作的重要性。
“為了找到正確的平衡，所有工程師都了解他們整個沖刺過程中在做的事情很重要。假如出現一個癥狀，如你發現有個工程師在角落里埋頭苦干了幾個小時，一兩個Scrum中他們都說只剩下一兩個鐘頭就可以搞定了，然而時間流逝了，卻還是一事無成，那么你就清楚你遇到麻煩了。
有時，這可以通過結對解決，但它還可能是團隊準備工作做得不充分的跡象。”
穩定性、支持和文檔
另一件需要注意的事情是該技術可以得到支持和文檔。我曾經遇到過有些API完全沒有或者只有寥寥幾個甚至是錯誤的文檔，搞清楚它們非常難。要是你是該技術的早期采用者之一，那么情形會變得更糟，因為很少有支持可以以博客/文章/論壇的形式找到。然而，某些沒有非常完善文檔的工具幾乎沒法用，除非你愿意花大量的時間對其進行徹底的探索。
我曾試著在一個項目中使用Apache Batik，關于它的文檔和支持并沒有太多。我經常會遇到問題，在互聯網上找不到關于這項技術使用的太多資料。相反，JavaFX也解決同一問題，但它有很好的文檔和支持。
有一個項目需要一種用戶界面，它既可以作為桌面應用運行，也可以在Web瀏覽器里運行。我們選擇了可伸縮向量圖（利用Apache Batik）來解決這一問題。
使用Apache Batik的時間很快就因為遇到的問題而到頭了。但是，Apache Batik曾經在團隊里討論過、探索過，然后甚至在作為解決方案搭建基礎設施之前就被拋棄了。接著開始去尋找其他技術，JavaFX脫穎而出。JavaFX看起來前途遠大，易于使用而且是新興技術。在一個沖刺內，它的基礎設施被建立起來，其中創建了一個簡陋的UI，之后進一步的開發就采用了 JavaFX。
新技術與項目里已經實現的技術之間的兼容性也非常重要。就像前面提到的項目，有些Swing組件已經開發了出來，JavaFX提供了一個特性可以嵌入Swing組件，這使得那些Swing組件得到了重用，避免了返工。
對于特殊技術的支持也相當重要，因為你可能會碰壁，需要找到條出路。開源產品在此會得到加分，即便你沒有任何關于這個技術的支持，你還可以看看代碼，然后修改它。要是它是閉源的，如果無法得到對于這項技術的充足支持，你就可能會發現自己在某個地方被卡住了。對于開源技術，如果你本身沒有能力去完成，還可以找到公司為你修改和定制產品。
很多流行的開源解決項目都有絕佳的文檔以及一大票免費和商業的支持選擇可以找到。由于社區發展的天性，文檔和說明往往從不同角度來闡述——造就了非常全面的信息、說明和教程。此外，開源項目無法隱藏使用信息，這得歸因于免費可以獲得的代碼。免費的技術支持也可以以郵件列表或新聞討論組的形式得到。然而，某種形式的背景研究、知識或經驗常常是需要的。
Jesus M. Gonzalez-Barahona談到了利用開源技術的優勢。
"可以獲得源代碼和有權進行修改是非常重要的。它促進了軟件產品的無限優化和改進。
有權以任何形式使用軟件。這進而幫助我們搭建起一個軟件支持和定制的市場，可以吸引越來越多的開發者參與項目。
軟件的未來不會依賴于某個實體。如果某個最初創建該代碼的組織或公司打算停止開發，總是有可能找到另一家軟件組織繼續維護和改進，沒有任何法律條文的限制。
修改軟件不需要按拷貝付費。嘗試新技術的人們可以立即的集成和采用它們，沒有商業門檻或保密協議許可。"
算算從它出現在市面上和預計生命長度之間的時間間距。使用一項馬上就要過時的技術毫無意義。如今，技術都以閃電般的速度發展，因此，總是看看技術的競爭者，你可能會得到些驚喜。
迭代引入技術
要想引入新技術/框架，一次一小步是個好習慣。一種好的做法就是探索該項技術一點，然后就分析它是否適合作為解決方案。然后嘗試使用這個新技術/框架解決最簡單的業務問題。不要一開始就全面依賴它，只讓項目的一小部分使用這項技術然后再觀察它的效果。
這有助于熟悉這個技術/框架的語法和其他特性。這種方式的另一個巨大優勢在于你無需花時間單獨的搭建使用所有新事物的基礎設施。
我有一個項目選擇Drools 5來作為解決某個問題的方案。但是，關于Drools 5的應用能力和特性還不知道。除此之外，Drools 5對團隊成員來說還是新事物。因此，有一個沖刺專門來使用Drools 5。一個被設想出來的簡單問題在Drools的幫助下得到了解決。這肯定了Drools將作為本次沖刺的基礎設施被搭建。而且，團隊成員也有時間去了解它。
使用Drools解決簡單問題使得有機會親手實驗，這增強了對于技術的信心。
作為一個Java項目，對Drools 5的依賴被加到了POM中。Spring Bean被定義出來創建會話，簡單的drl文件也被書寫了出來。每個drl文件都有一個Drools特定的規則書寫語法。使用Session Bean把對象傳給代碼，代碼在這些對象上執行規則。這個沖刺之后，Drools的基礎設施就位了，團隊了解了它的語法和其他技術。更重要的是，有了一個 使用Drools 5的解決方案。因此，對于技術的信心增強了。
Robert McIlree談到了迭代引入技術：
“隨著時間的推移，通過足夠的成功遞增引入一項新技術，對于技術來講，可以獲得切入組織其余部分的牽引力。萬一引入因為其他什么原因失敗了，組織整體的風險和成本很低。”
在這個階段，解決方案要實現的問題不應該非常重要。其主要目標是搭建新技術的基礎設施。一旦項目基礎設施創建完成，并且看起來讓人賞心悅目，足以繼續下去，這樣，實現它的風險就會小一些。
性能
一旦應用采納/接受新技術，那么預期結果和它的功能接受標準就都要完成。然而，在你開始深入更復雜的例子且技術成為應用的一部分之前，功能的卓越程度不是你唯一要考慮的東西。性能相關的問題可能會開始讓你煩心。
如果從一開始接觸新技術你沒有關注其性能，那么它很有可能成為當下的負擔，最終喪失采用新技術時投入的所有努力。因此，在引入技術時就得嚴肅地對待性能問題。如果技術可能會成為瓶頸，那么就把它找出來，盡早丟棄它。
風險承受能力
團隊在項目當前狀態下的風險承受能力是決定引入新技術與否的另一個考慮因素。如果項目不那么穩定，團隊甚至還在陷于當前的實現技術和其他問題，那么再增加需要用新技術完成的新任務就不理智了。在這種情況下引入新技術會使團隊遭受重創。他們將在錯誤的時間處理掌握新技術的額外任務。然而，如果團隊表現 良好，產品也很穩定，那么大可大干一番。
Dave Nicolette撰寫了關于管理和計算風險的因素。
“如果提議的解決方案涉及到IT組織支持的標準技術基礎設施中還沒有建立起來的技術或產品，高可覺察風險和低實際風險就會出現。看看是否有機會引入沒有技術實現難度，但你的公司之前沒有使用過的新技術。.
這將推動傳統項目的估算增高，而又不增加項目的實際難度。“
信任
最后，在已經接受技術之后，你所需要做的全部事情就是“信任”它。它是一種個人現象。然而，你對所接受技術的信任程度將導致你跟它相處的難易程度。就像Bahmanziari說的，它完全因人而異，Tammy在計算機信息系統刊物上撰寫的文章談到了信任。
“個人采納者的性格在對信任不熟悉事物的習性上扮演了重要角色。這種性格特征通常被稱為信任度。某些人在毫無任何理由這樣做的時候表現出高度信任，而另一些人則在有理由給予高度信任的時候表現出信任程度很低。”
技術采納者必須完成前文提到的分析以形成對技術的理解。利用分析中收集到的信息，可以加強對技術的信任。你需要信任，因為技術還沒有被嘗試和測試。假使它們被嘗試和測試過了，那就沒有信任的必要了，因為你已經對它了如指掌。
計算機信息系統刊物也談到了信任在技術采納過程中的重要性。
“絕大多數信任理論者可能都同意，盡管沒有人可以給信任下個定論，它在所有情形下都是有用的，但是不確定性和某種程度的漏 洞必需因為信任而存在。畢竟，對完全確定的事物而言，信任是不必要的。正是由于這種不確定性的存在，造就了漏洞。技術采納者在不確定的環境中穿行；因此，他們的評估必然包括對于該技術以及其提供者的個人看法和不完全知識。"
總結
引入的技術應該能夠解決業務問題。它的流行程度不應該作為選擇的基礎。技術的早期采納不應該在項目處于逆境的時候進行。開發者不應該懼怕學習曲線，因為它將增強他們的知識。技術應該迭代引入。每個迭代取得的成功/失敗應該決定下一個迭代的步驟。結對編程應該在新技術上實行，好讓知識在團隊內傳遞。在完全接受它之前需對它留心。一旦信任技術之后，你將化蛹成蝶。