敏捷開發中如何保證界面設計?
01-28
敏捷開發中產品經理可以以用戶故事確定需求,確定優先順序,但如何進行界面設計?
有一些故事很重要,但優先順序不高,在界面中缺少了這些會顯得怪異,用其餘設計代替又有些得不償失,這種情況下,該如何取捨。
先看這張圖
這聽起來很合理吧,但事實上很多所謂的敏捷開發做的就是前的事,為什麼呢?
因為那些PM或那些雄心壯志、備受各種訂閱號追求極致文章影響的BOSS們,他 們 要 做 一 輛 超 級 無 敵 的 跑 車...這是他們內心真誠的衝動、想法、激情,whatever 這沒錯,但是結果是打造這輛無敵跑車需要一份足足可以繞月球3圈的 需 求 清 單,那麼問題來了,我們怎麼快樂的實現這個需求清單呢?聰明的RD們當然會愉快的告訴你,敏捷開發!!!!用戶可以先拋一邊去,他們活在我們的心裡就好,那開始動手吧,嗯,發動機最重要,我們要用10個迭代來做好這個發動機,YO!SO COOL,好吧,光有發動機也沒用啊,我們還是先做個車架吧,至少一眼看上去像個汽車啊...OH,FUCK,這個發動機根本沒法組裝到車架里啊....bla bla bla,回想起來,這些人是多麼的虔誠,工作起來的樣子是多很的認真有魅力,改變世界的多巴胺讓你在每個加班的日夜裡感覺還是多麼的美好,但這個故事我也不想再說下去了,你們都懂。
MVP是什麼,MVP就是一個能發布且解決你所定義的核心問題的最小的需求模型,用產品的核心問題來定義產品的完整性,比如Snapchat,最核心的是閱後即焚,也許snapchat以後會演變為平台,但如果你一開始除了閱後即焚還在謀劃朋友圈,商城,不好意思這不是MVP,這會讓你的流程變得複雜,比如題主說的,如果某個功能在這個迭代不實現,那我應該是讓它空著還是設計臨時的方案還是在下個迭代再全盤修改(設計師和研發開始可笑的干架)每個迭代也無法從上個迭代從獲得有效的反饋MVP不代表簡單粗陋,而是在於它的單一性和完整性,設計師設計產品時並不是憑空而來,而是要考慮各種限制條件,如果一個限制條件還要分幾個版本來考慮,這是多麼扯蛋的事呢。所以,所謂的產品迭代不等同於敏捷開發中的項目版本迭代,每一個產品迭代應該都是一個經過設計師精心設計,反覆驗證過的成熟方案,而非一個半成品,而敏捷的角色依然是面對開發,工程師們關心的是功能的相關性,據此來劃分迭代計劃,最終交付給用戶的是一個完整體驗的產品。把界面設計作為一項開發任務來看待就行了
程序員以前都是做設計的。。。
轉型敏捷千萬別活在《蒙娜麗莎》畫像里
一個按鈕 。。。。。。。一個牛逼的系統中間迭代過程自行腦補 ----敏捷開發
把界面編碼(HTML,CSS,JavaScript)算入伺服器編程碼,用主語言控制副語言,你的界面就會在心裡自然形成。
推薦閱讀:
※狀態模式和策略模式的區別與聯繫?
※一個靜態類或者非靜態類,多個方法依賴一個函數,如何實現?
※C++模版類如何動態獲取類型?
※c++中如何正確實現克隆(原型)模式?
※實現同一介面的不同類使用組合實現了多態,但是這破壞了DRY嗎?