scrum和敏捷講師mohammad nafees sharif butt指出，好的工程實踐是一種工具，有助於敏捷團隊交付可交付產品。雖然不少工程實踐已被證明是有效的，但它們並沒有得到應有地廣泛使用。nafees提到，軟體甜筒測試、累積的技術爭議和功能筒倉等敏捷反模式（anti-pattern），阻礙了團隊在sprint末期交付潛在的可發布產品。通過運用系統思維定期地進行檢視與調整，可以解決上述反模式問題。
\\ 在swanseacon 2016大會上，nafees將會報告關於建立「潛在可發布產品增量」（potentially releasable product increment）的工具。infoq就此訪談了nafees，所涉及問題包括：什麼是敏捷反模式及如何處理它們、為什麼卓越技術是很重要的、其所推薦的工程實踐、組織應如何去建立具有優秀工程實踐的文化等。
\\infoq：在組織中，你見到過哪些敏捷反模式？
\\
\\\mohammad nafees sharif butt：從技術角度看，我觀察到了如下十分常見的敏捷反模式：
\\ 一、甜筒測試自動化。其中大多數的測試是通過ui進行的，這違反了成比例的測試金字塔（testing pyramid）理念。遵循這種反模式的團隊和組織總是試圖通過ui測試去自動化大多數接收的測試。如此的ui測試中所存在的問題包括：由ui測試本質上的非確定性所導致的漏報、測試的執行和維護成本高、迷你瀑布模型的建立延遲了對團隊的反饋，團隊不能靈活地處理將來的ui改進。
\\ 二、另一種常見的反模式是罔顧權責的技術爭論。這個問題源於緊迫性意識（所有的產品開發組發現他們都陷入當今這樣創新的時代中），以及錯誤地假設團隊並不具備足夠的時間進行設計。該反模式的乙個小的變種也是十分常見的。這種情形下，從業者既不遵循工藝也不去執行「童子軍」規則，任由**庫發生腐爛變質。
\\ 三、將應用構建伺服器與持續整合等同。儘管近十年中持續整合與持續交付相關的工具已成熟了很多，在持續整合過程中組織仍繼續丟失「持續」的精髓所在。長生命週期的特性分支、痛苦而破壞性的衝突合併是這種反模式的常見症狀。
\\ 四、功能性筒倉。這些結構性障礙未必是技術上的限制，但具有嚴重的技術衍生。在不理解底層原則的情況下就「貨物崇拜」式地應用敏捷實踐，這種做法所產生的***包括：業務分析與「開發」的分離、階段式地經由架構組實施的大規模架構更改、n+1方式的設計sprint。以上這些問題，無論存在其中任何一種，都將導致過程和產品中的消耗。
\
infoq：你是怎麼處理上述反模式的？
\\
\\\nafees：有兩種攻擊途徑可給出解決方案。首要的是持續側重於「檢視與調整」（inspect \u0026amp; adapt），其次是系統性思考（system thinking）。在當前可見的技術實踐中，組織不能從一棵樹看到整個森林是大多數的反模式的根源所在，導致該問題的原因在於組織決策的結果是區域性優化的。乙個學習的團隊和組織不僅需要具有全域性視角，而且需要理解自身行為與系統狀態之間的因果關係。定期做這種檢視並根據結果進行相應的調整，這有助於對反模式的處理。
\\ 乙個具體的例子來自我幾年前曾供職的乙個團隊，該團隊為避免對其全新產品的每個sprint做手工回歸測試，開始採用selenium web browser automation產品做接收測試。雖然當時他們成功地實現了測試場景自動化，但是缺點也同時在一些sprint中顯現出來。在sprint回顧中，團隊分析了現狀，並得出測試目標並非是為了現狀而進行自動化的結論。如果因為這些測試延遲了反饋（由於測試需要很長的執行時間）而導致團隊遭受返工的損耗（測試需要在ui改變時重構），那麼就團隊就需要乙個可替代的策略。這裡有經驗的從業者是十分有用的，他可引導團隊通過皮下測試，即不依賴於需完成的ui改變就對api進行測試。這種測試可更快地提供反饋，並在ui發生改變時無需進行重構。雖然spint回顧將激發組員間固執己見的討論，但是組員專注於為實現總體優秀而做的持續改進，這並沒有被完成工作的成就感所阻礙，因此spint回顧方法可以解決這樣的問題。
\
在「關於軟體開發者的問答」一文中，sandro mancuso解釋了為什麼卓越技術是很重要的：
\\
\\\敏捷是為改進我們交付軟體的方式而建立的。如果我們以卓越技術為重點，那麼我們軟體的質量將回退到某一點，在該點上做改變是非常痛苦和緩慢的。同時在該點上採用了哪種敏捷過程都是無所謂的，因為開發人員不再能快速前進，這導致企業失去敏捷性。
\
infoq：為什麼卓越技術是如此的重要？
\\
\\\nafees：過去使用瀑布模型時， 我們可奢侈的在大規模預先設計（big design up front，bduf）和架構上花費數月的時間。現在我們再也不能這樣做了。按精益軟體開發中對湖與石頭的隱喻，敏捷中常見的小規模頻繁的迭代會立刻顯現如上實踐的低效。交付增量改變而無需凍結預先設計範圍的承諾是乙個嚴重錯誤，這為使用那些被牢記於心的卓越技術去構建強大產品奠定了基礎。如果不使用卓越技術，組織將發現自己不能確保遵守逐次迭代地交付客戶需求的承諾，因為它揹負著腐爛**庫的包袱。所有這樣的努力只能歸結為是對敏捷的口頭服務，而非真實敏捷的先行者。
\\
\\
\\\首先，對領域驅動設計（domain driven design，ddd）的需求是無論怎麼強調也不為過的（我並非在力推微服務，僅是簡潔地去設計你的產品，使得產品不僅可跨越領域間所界定的接縫，而且……）。初創企業更容易用少量工程師實現創新理念的快速交付，但是當開發組規模增加到數十人（甚至更多）時，組織對市場需求變化的交付能力開始受到損害，這種損害是由多個團隊的不同應用元件間的協調和依賴所導致的。以領域驅動設計為理念所架構的產品就可以實現對組織的授權，甚至是在組織已經跨越了在初創企業和成功商業之間所存在的深淵之後。
\\ 其次，對非功能性需求的忽視是我所見到的另乙個慣犯（諸如2023年澳大利亞人口普查）。在我看來，如果你的產品需要受限於某種具有特定響應時間限制的負載，那麼該工作負載就是你功能性需求的一部分，並需要在一開始就被考慮到（並不是留給強化sprint和整合sprint）。在功能性需求中所應用的atdd的嚴格性標準，需同樣被應用到那些被稱為非功能性需求的事情上。說實話，將這些需求稱為非功能性需求並將以二等公民對待，只能導致具有這些方面需求的產品被忽視，產品交付也因長時間的忽視而延遲。
\
在先期的「james grenning訪談錄：關於測試驅動開發及**異味」一文中，當被問及在大力實施技術實踐以提公升技術的卓越的過程中需要做些什麼時，james grenning的回答是：
\\
\\\我認為強調獨自工作以及專業化的文化在某種程度上是錯誤的。如果你所能見的都只是你自己的**，你會產生這樣的觀念，一切都很好並且已經沒有什麼新東西要學的了。在開發周期的後段進行**評審意味著改進將變得最困難。公司應當鼓勵員工更緊密地一起工作。結對程式設計對傳播技術的卓越之處非常有益，這是個雙向的過程。
\
infoq：如果想要建立具有良好工程實踐的文化，組織應該怎麼做？
\\
\\\nafees:去針對未來的狀態而招聘人員。新的人才幾乎總是會對現有的平衡產生撼動。如果與工程實踐相關的現有組織文化是不成熟的，我推薦通過找尋匹配當前文化人才的方式為達成目標成熟度而招聘人才。這種方式下新的人才可用於對現狀產生積極的影響，並擔當目標成熟的催化劑。
\\ 另乙個重要的因素是獲取外部幫助。對於大多數組織而言，當前架構源於上世紀的程式設計師，鑑於架構中垂直結構的存在，這使得組織難以成熟化其工程規範，即使在組織的領導層中存在熱衷於此事的管理者。獲取外部幫助可激發組織對現狀的反思，即使這意味著去挑戰現存的官僚機制。
\\ 最後，如果工程師被要求去實現乙個解決方案而非提出乙個需要解決的問題，這會使得迭代開發感覺上像是永不終止的惡性迴圈。授權全體員工，讓他們進行自組織（甚至自構形）並提供專案的目的所在，這可提公升全體員工的主人翁意識並激發他們努力工作。每個員工都是珍惜挑戰機會的，這超越了傳統管理所願意認同的。如果適當地輔以自治和做事目的，員工會願意將自身的所有能量投資於專案中。
\
swanseacon 2016大會將於九月12日至13日期間在英國斯旺西自由體育場（liberty stadium）召開。2016大會將會是第二屆敏捷開發和軟體工匠大會，面向南威爾斯的軟體開發人員、軟體架構師、專案經理、分析師和顧問。infoq將以問答、摘要和報道文章等方式全程覆蓋大會。
\\檢視英文原文：deliver shippable products with good engineering practices
\\ 感謝夏雪對本文的審校。
\
C 專案實踐 工程的組織
最近做了乙個多人協作，規模也不小的c 專案，其中做了很多有價值的 實踐，在此記錄，以來說明c 專案需要關注的各方面的問題 當專案由團隊共同開發，而非一人來完成時，工程的如何組織會成為乙個重要問題 工程組織它是團隊工作的基礎，不能很好的解決這個問題，將使專案陷於 混亂。而此問題的本質是，建立何種工程結...
如何使用好pyqt的signal和slot
如果你是使用pyqt 4.5之後的版本，除了傳統的signal slot的連線方式外，你還多了一種比較符合python樣式的寫法。這種寫法是透過下面兩種新的pyqt物件來達成 正如其名,pyqtsingal是用來定義signal，而 pyqtslot 則是用於slot。首先，我們來了解如何利用pyq...
基於工程實踐的軟體系統設計
我的工程實踐題目是mip，即醫學影象處理，目的是設計一種基於深度學習的通用病灶識別系統，該系統可以通過檢測使用者的輸入，來得到具有對影象病灶處標註的最終影象 通常病人做好一系列臨床上的檢查後，醫生需要人為的看 然後根據自身的知識和經驗 來對病人的疾病情況做出判斷，是比較耗時耗力的，如果可以把重點病灶...