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

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

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

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

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

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

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

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

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

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

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

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

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

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

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