用戶體驗專家Anthony Colfelt使用一個案例告訴我們：僅有敏捷是不夠的；他還深入指出：“以用戶為中心的設(shè)計”（以下簡稱UCD）能夠，而且應(yīng)該與敏捷合并使用。

　　為了表明自己的觀點，Colfelt首先提出：對于發(fā)掘業(yè)務(wù)的真正需求這個難題，敏捷是合適的解決之道嗎？他以此引出自己的觀點。

就其自身而言，敏捷在調(diào)整自己、適應(yīng)變化方面做得很不錯。但是我們必須知道：它能否用來治療某些癥狀，這些癥狀的更深層次原因在于：業(yè)務(wù)不知道自己的真正需求。雖然敏捷能讓開發(fā)團隊更好地應(yīng)對這個問題，但是并沒有從根本上解決問題，很多時候還創(chuàng)建出了新的問題。

　　他從用戶體驗的角度出發(fā)，描述了自己所見過的、敏捷出現(xiàn)問題的6種“雷區(qū)”：

• 雷區(qū)之一：設(shè)計角色不清晰
  敏捷原則說：“在整個項目過程中，業(yè)務(wù)人員和開發(fā)人員必須每天坐在一起。”這幾乎沒有為用戶體驗設(shè)計人員留出任何空間，常常讓開發(fā)人員從事此類工作，而他們又很可能不具備相關(guān)技能。
• 雷區(qū)之二：沒有定義需求收集過程。
  敏捷團隊的頭腦中認為：“需求會像魔法一樣從天而降”，從而不愿意花時間和精力制訂產(chǎn)品的長遠戰(zhàn)略規(guī)劃，認為這“不敏捷”；類似的情形并不少見。
• 雷區(qū)之三：走捷徑的壓力。
  強迫用戶體驗設(shè)計過程使用與其對應(yīng)開發(fā)工作所采取的迭代方式，這會導(dǎo)致沖動式設(shè)計（impulsive design），喪失與用戶測試設(shè)計想法的機會。當然，敏捷允許測試真實的產(chǎn)出的可用性，但是要應(yīng)對由此產(chǎn)生的反饋，所花的時間要超出人們的期望或是他們所能接受的范圍。
• 雷區(qū)之四：稱之為“足夠好”的誘惑。
  即使（也許應(yīng)該說尤其）當敏捷表現(xiàn)出色的時候，團隊總要面對排定優(yōu)先級的需要，是“繼續(xù)改進現(xiàn)有特性，讓它們更好”，還是“向產(chǎn)品中繼續(xù)添加新特性”？正如Cofelt觀察到的：

  經(jīng)常發(fā)生的是：繼續(xù)改進的工作被放在一邊，人們更喜歡令人興奮的新東西。如此這般，我們構(gòu)建出來的產(chǎn)品中，所有的特性都不能令人滿意。

• 雷區(qū)之五：無風險的概念探索時間不足。
  很多敏捷團隊在項目的第一天（或是很接近的時間之內(nèi)）就會開始著手實際工作。有些團隊會使用“第零個迭代（iteration zero）”來做一些前期的規(guī)劃和設(shè)計。Cofelt質(zhì)疑時間是否充足：相對于在編碼之前以粗略的方式驗證某些想法，以可工作的范例來驗證想法這種敏捷的方式是否總能勝出？
• 雷區(qū)之六：傷害品牌。
  將未經(jīng)（以用戶體驗設(shè)計的方式）實地測試的功能特性放到市場之中，即使是有意要這么做以收集反饋，也會讓客戶很快地喪失信心，不再相信你們公司能夠不斷達到目標；這會傷害你們的品牌，而品牌是很難建立起來的，一旦倒下，再想重樹品牌就更難。

　　Colfelt做了一個有趣的總結(jié)，指出：敏捷本身“善于改進，但是不善于定義”。他強調(diào)指出：只用敏捷，也許足以“把現(xiàn)有產(chǎn)品提升至新的水平”；但是，特別是在要開始新東西的時候，“某些層面的規(guī)劃是必要的，這樣可以避免勉強拼湊各人對于最好的設(shè)計方案的看法，那樣只能產(chǎn)生類似于弗蘭肯斯坦式的怪物。”

　　他接下來描述了一種傳統(tǒng)的、也是“典型的”UCD過程，要讀者注意該過程中對于產(chǎn)品“戰(zhàn)略”的前期研究（他在后面稱之為“概念設(shè)計”，并舉出完美的iPod設(shè)計作為典型例子），他強調(diào)指出：即使采取敏捷的方法論開發(fā)產(chǎn)品，前期研究同樣重要。Colfelt的講述方式很小心，沒有說敏捷排斥這樣的前期思考過程，而是提出：敏捷能夠直接鼓勵此類研究，以彰顯敏捷之長處。

　　UCD的重點是“戰(zhàn)略”和“概念”挖掘，它可以而且應(yīng)該與敏捷的“改進”能力相結(jié)合；說到底，Colfelt就是希望提升人們對于這一點的認識。

總的來說，要想把二者結(jié)合在一起使用，就要避免對它們各自的武斷態(tài)度。要記住：敏捷沒有強制如何定義概念或是整體的設(shè)計方向，但是很善于執(zhí)行具體的設(shè)計研究和良好的規(guī)劃。UCD必須要很靈活，以應(yīng)對如下現(xiàn)實狀況：實現(xiàn)團隊遇到問題，不得不強制采取另一種設(shè)計方案。文檔只記錄必要的信息，以便于傳播。設(shè)計與開發(fā)團隊應(yīng)該盡量坐在一起，因為跨職能的協(xié)作和面對面的溝通至關(guān)重要。設(shè)計團隊在開發(fā)團隊之前先使用一個sprint也很有幫助，他們就能有足夠的時間測試和迭代。如果遵循這些規(guī)則，兩種方式就能和諧共存，發(fā)揮作用。

　　在做出任何強硬判斷之前，不妨先花些時間讀讀Colfelt的全文。你不妨看看Johnny Holland這篇相關(guān)文章，其中提到用戶體驗設(shè)計人員在敏捷（Scrum）環(huán)境中如何調(diào)整自己的工作方式，他還討論了與“戰(zhàn)略”相關(guān)的類似主題，不過更關(guān)注與開發(fā)團隊的交互，以及迭代層面的活動和團隊動力相關(guān)內(nèi)容。

　　查看英文原文： Harmonizing Agile with "User-Centered Design"

it知識庫：讓敏捷與“以用戶為中心的設(shè)計”和諧共生，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。