如何應對不斷變化的需求?

這不是一個bug，它是一個特性
問題是，我們的大多數專案都是基於固定的價格(和固定的功能)。在收集了所有的需求之後，就會以一種對我們來說有意義的方式構建了這個東西，實現一些不言而喻的業務規則。

但是，在最初的釋出之後，我們會從客戶那裡得到不斷增加新特性的請求。有時，我們不得不告訴我們的客戶：這在技術上是不可能的（banq注:客戶希望手機裡的應用背景隨著手機外護套顏色變化而變化，有的產品經理不會告訴客戶這是不可能的，而是讓程式設計師實現，程式設計師能不爆發嗎？）。或者我們會直接了當告訴他們，他們認為是錯誤的地方其實是我們設計它的方式是錯誤的。

抵抗變化
這就是命名問題的重要性體現，我們試圖解釋產品的實際工作原理，但我們使用的是我們自己編的術語去給類命名，這就會使得客戶很難理解，也很難實現新的功能，因為我們必須將客戶所說的一切都翻譯成我們自己的技術語言。基本上，該產品已變得無法應對變化的需求了。

這是非常遺憾的，然後開發者開始抱怨:要是客戶他們早點想到就好了！這種抱怨其實沒有任何意義！這完全是對客戶的不尊重，但表達一個善良願望：我們覺得很難達到客戶預期，但是我們真的很想這樣做。

擁抱變化
我還要進一步指出，我們讓客戶失望了，他們認為他們想要X，我們建造了X，他們發現他們實際上需要Y，但到那時已經太晚了，X只能是他們能夠得到的全部。

“敏捷宣言”提到：
響應計劃的改變

這一點很重要，因為客戶對他們所需要的產品的理解是隨著時間的推移而演變的，每當客戶因為這種演變而改變主意，我們就應該慶祝！這是一個接近理想解決方案的機會！我們需要擁抱改變。

那麼，當你不知道變化會是什麼樣子的時候，你該如何規劃它們呢？以下是一些你可以做的事情。

1. 對齊
你知不知道最初對技術債務的描述是這樣的：
如果不能使程式與領域的思考方式相一致，就會失敗。

就我個人而言，我曾經討厭像“看齊”和“協同”這樣的管理詞彙，但不管你討厭與否它就在那裡，它是存在的。如果你有同樣的感覺，那麼更換另一種思維方式就是消除摩擦。

我們可以在啟動程式設計之前花時間理解領域，從而將這種摩擦(或阻力)降到最低，結果發現我們在某些事情上是錯誤的，我們可以按照我們新的理解方式重構程式碼。

這會有用嗎？我們必須承認，無論客戶要求什麼，在他們的領域都是有意義的。如果程式碼也是按照該領域構造的，那麼他們的要求在程式碼中也就有意義了。如果你的訂單包含產品，當客戶要求新增一個產品條目時，您會感到畏縮，但是如果你的訂單中已經包含訂單條目集合LineItems，你就會說：“當然可以。”(因為你已經按照理解了領域本身邏輯，好像能提前預知客戶變化的需求一樣)

2.經常付交
另一種應對客戶變化的需求方法是讓它儘快發生。發生得越早，重構的程式碼就越少。

由AndyHunt和DaveThomas設計的實用程式設計師描述了一種叫做Tracer子彈的技術。訣竅是在短週期內釋出，並根據已經完成的事情收集反饋。這也意味著你必須以一種讓你的客戶能夠理解的方式來組織工作。是的，這意味著你不能從後端開始，然後再構建前端。

這也是為什麼敏捷宣言說：
頻繁地交付工作軟體，從幾周到幾個月，優先考慮更短的時間尺度。

3.開發人員本能
最後，作為一名開發人員，您有一些需要解決的問題。
我喜歡舉的例子是一位同事，他非常沮喪，為什麼? 因為客戶希望他在他構建的動態選單中增加一個額外的級別，而他們之前明確告訴他選單隻需要兩個級別。太天真了，永遠不要相信客戶的話，只能相信你的領域分析。

所以我的建議是：
當顧客告訴你他們只需要兩級選單時，千萬不要相信他們。

我想給你更多的通用性建議，這是一個平衡。如果你把客戶說的每句話都實現得面面俱到，你就會遇到麻煩，但如果你從來不認真對待你的客戶，你最終可能會把所有的東西都設計得過於複雜。

關鍵是，當我們已經建立了大量的軟體，隨著時間推移會看到需求的變化，我們需要跟隨它變化的本能。

原文:
https://medium.com/@scato.eggen/changing-requirements-744274e6b90e

[該貼被banq於2018-08-19 19:07修改過]