《例項化需求》閱讀筆記（4）-開始改變

例項化需求並不是一個新的思想，而是80年代晚期就被提了出來。為什麼例項化需求沒有被髮揚光大，作者認為業界走了彎路。如何能夠做到例項化需求呢？可以從兩方面做起：改變過程，改變團隊文化

過程的改變可以從以下幾點做起： 如果已經在進行一個過程變更，那麼就通過它實現例項化需求說明的主要思想。 將例項化需求說明的思想當做改善產品品質的靈感。 為那些沒有自動化功能測試的團隊，實施功能測試的自動化。 對那些自動化測試與開發環節脫離的團隊，引入自動化的可執行需求說明（作者好想比較推崇Fitnesse）。 對那些時間測試驅動開發的團隊，使用TDD作為下一步的踏腳石。 一些tips： 可以把例項化需求作為更大變革中的一部分。打到包裡好辦事兒（經驗看的確如此）。 把重心放在專注於質量提高上，而不是改變上，兩者可以相互促進。 如果開發人員和測試人員不緊密合作，這事兒就不好成。 不要一開始就例項化需求，先從把功能測試自動化做起來開始。 在實現功能測試自動化自動化的時候要做好工具選型，工具要適合例項化需求。 團隊文化的改變從以下幾點做起： 避免使用“敏捷”術語。從幫助團隊提高質量和開發效率的一點一滴做起，每一步都起到實效。 獲取管理層支援。因為需要顯著改變工作方式，不可避免會遇到阻力。 把例項化需求當做是比執行驗收測試更好的方式來推銷。酒香也怕巷子深。 不要讓自動化測試成為最終目標。 不要太拘泥於工具。例項化需求並不以程式設計師為重心，程式設計師獨立使用一個工具不會取得良好效果。 在遷移過程中，注意需要有人維護遺留指令碼。 跟蹤那些人在執行/沒有執行自動化檢查程式。