最近專案組接到乙個需求，需要在銷售訂單上新增折扣資訊，並且可以新增多條折扣資訊（比如生日折扣，聖誕節折扣等等）。這個很好理解，因為我們處在什麼都需要打折來安慰消費者心理的時代，當然打折資訊的記錄也很重要，方便以後進行資料分析。
然後開發人員做出來的成品是這樣的。
1. 用dropdown列出所有的可選擇的打折型別
2. 當使用者通過這個dropdown選出打折型別後，啪，顯示出乙個新增按鈕把選擇的型別新增（這個新增按鈕一開始是隱藏的）。同時這一種打折型別不再出現在dropdown列表下
3. 當新增完一種打折型別後，啪，神一般的出現乙個table，table中的資訊就是剛剛新增的那一條
4. 當dropdown下所有的型別都新增盡了的時候，dropdown 和新增按鈕無聲無息的消失。
看似小小的一塊介面，其實包含了很多的聯動操作，每乙個操作都有可能引起介面是一部分的出現和消失。且不從使用者體驗角度來評價這樣的設計。這麼多的聯動操作，無非想實現乙個功能 --使用者選擇的打折型別的唯一性。而這個功能花費了開發人員一周的時間。
這個事情讓我很頭痛，我無法說服開發人員把這樣的花了一周時間按做出來的東西重新做，並且po認為目前這樣的實現可以接受（其實po不在意這個功能，所以做不做這個功能都可以接受）。因為木已成舟，再做只是增加更多的成本。我想問的問題是
這讓我想到了「可行走的骨骼」，
我們在做產品的時候總是喜歡去死摳每乙個細節，把每一種if else 都加上內容。希望需求分析人員把每乙個需求都弄的巴巴適適的，而且最好需求永遠不要變。這種理想是豐滿的正確的，但是現實很骨感。如果你沒有同感證明你還沒有進入軟體開發圈。
在這種情況下，我們為什麼不先做出乙個「骨骼」，滿足使用者的最主要需求，不要有過多的假象，不要自己yy。等使用者需要加肉的時候就加，使用者需要穿衣服的時候再穿。
有的開發人員說，我不想使用者在做這些操作的時候犯錯誤，所以我想多加些限制。但是你能預知使用者會一定犯錯嗎？你能**使用者會犯什麼仰的錯誤嗎？您不試一下怎們知道呢？不要怕使用者會因為軟體沒有加限制而犯錯誤，因為你永遠無法預知使用者是否會犯錯，會犯什麼樣的錯誤。把你的每乙個假象先通過使用者的實際操作得到驗證後再去實現。請做好你的「骨骼」，並且這個「骨骼」是「可行走的」，要把地基打好，保證現有的可以交付的東西是經得住考驗的。使用者可以盡早用功能，團隊可以盡快的交付，而且讓使用者在驗證我們的假象，我們這樣做怎麼樣！
敏捷開發 敏捷開發中的質量
有小夥伴就問，我們都敏捷了，我們是在效率和質量中找平衡，說敏捷開發中的質量是不容易控制的，要回答這個問題，我設計了乙個faq，內容如下 敏捷開發是什麼？敏捷開發是以需求為中心，以交付價值為目的，持續增量交付的一種軟體開發方法，至於什麼是敏捷，就去問問度娘吧。對於敏捷團隊來說，是乙個自組織的，有集體目...
敏捷開發的原則
一 單一職責原則 the single responsibility principal srp 就是說盡量的單一化類的功能，不要使類具有多個功能。如果類具有多個功能時，任意乙個功能的修改都需要改寫這個類，也就會影響其他的類，而這些類根本沒有使用修改的這個功能。如果單一化功能，這種情況就可以避免。例...
敏捷軟體的開發
平時寫的東西大多和我的 url 家服務網 url 家服務網有關係，但今天來寫一些和敏捷軟體開發相關的東東。接觸敏捷軟體開發已經差不多有大半年了，雖然經常有機會和別人討論敏捷開發的好處和壞處，但還從沒有認真的為它寫點東西。剛好最近有乙個朋友讓我去他的公司介紹介紹敏捷開發，還反覆提醒我要準備準備，我也不...