敏捷式開發與使用性(Jakob Nielsen)

當公司採用一些迅速開發(RAD, rapid application development)方法論，如敏捷式開發或Scrum方法論，可能會對使用者經驗的品質帶來正面的或負面的影響。

敏捷式開發的優點

敏捷式開發能解決三個長期以來受到使用性專家爭論的議題：

1. 這五十年來，幾乎所有的開發專案都顯示出，「傳統的瀑布開發方法論」會導致不良的使用者經驗。理由很簡單：專案的需求與規格總是不正確的。
   
   • 好的情況是 -- 當專案被細心處理的時候 -- 專案的需求能反映出使用者的需求。但是，更常見的情況是，專案的需求只反映出使用者「表示出想要」並且不明白實際涉及執行工作的那一部份。在所有的專案中，「使用者想要的」與「使用者需要的」是截然不同的兩件事。這也是為何在使用性準則中，總是要求要在專案初期應該要「觀察使用者作些什麼」，而並非只是「聽使用者講些什麼」。
   • 如果，定義需求與實際完成產品中間需要一段頗長的時間，那麼專案可能面臨到使用者需求變遷的狀況，這更進一步拉遠了使用者實際需求與專案需求的距離。
   • 過去25年來的使用性工程經驗告訴我們，評估設計品質最好的方法是觀察使用者與產品實際互動的情況(不論是功能性原型或是視覺原型)。同樣的，如果評估與開發的時間經過的越久，絕大多數的產品會被導向錯誤的設計方向。
   
   
2. 在瀑布式流程中，即使規格定義與需求文件都被被細記錄下來，但仍然會導致問題。事情會隨著開發者與規格設計者的傳遞而越來越糟。在實際執行細部的互動設計開發中，問題會一個個浮現出來；開發者無法解決這些因前期設計規格變動所產生的問題。
3. 自從1989年開始，我們提出「輕簡式使用性工程(discount usability engineering)」，主張「快又便宜的使用性研究方法 」最能改善產品使用性。因為開發者能夠在開發工作中「經常性地進行使用性工程」。然而，如果專案中只要求「一次使用性研究工作」，那麼這樣的事情便無從發生。
   

而敏捷式開發法能夠突破這些傳統開發方法上的限制。

敏捷式開發的缺點

敏捷式開發最大的問題，在於這個方法論是由「程序員」所提出，並且主要只針對系統開發中的執行問題。因此，敏捷式開發也往往忽略了互動設計與使用性工程在專案中的參與。但是，在這三十多年來，我們已經明白使用者經驗對系統開發的重要性日漸增加，並且我們也由大型系統為主變成以網際網路應用服務為主。當使用者的母群基礎與案例越來越多的情況下，對優秀使用性工程的需求是增加的。

為了建立好的使用者經驗，開發團隊需要有進行互動設計與使用性工程的方法。對較小的團隊而言，不需要區分設計師與使用性專家。最好的可能方案是「由開發者來執行互動設計與使用性工程」。但是，專案團隊需要明白這兩種活動也是明定的開發程序之一，不論今天是由不同的人執行這兩項工作，或是由一個人來執行多種工作。

對一個專案而言，要認真看待互動設計與使用性工程的話，需要跟開發程式一樣，指派他們一些「故事點數(story points)」(即，資源)。

另一個問題是，在敏捷式開發中，所有的開發工作都被拆解為一次執行一次的小工作。如果要評估整合所有產品的使用經驗，在敏捷法中是困難的。

為了解決這個問題，專案團隊需要設計一套「故事腳本」或「原型」以整合使用者介面架構，並以此作為一個參考點來設計個別的功能。為了避免花費過多的時間在前端開發上，專案團隊需要設計出一個「低保真度」的原型 -- 如不需要程式的「紙上原型 」。

典型的敏捷專案團隊會在每三週進行一次的「短程報告(sprints)」以建立功能清單。在這麼短的開發時程中，開發者可能會因為假設他沒有足夠時間，而忽略過使用性測試或研究。

我們為這些問題，提出三個解決方向：

1. 以短天數內進行使用性工程，如使用者測試。一個有效的方式是在可以實際測試前先計畫測試。「每週測試」就足夠使你在專案短程內整合一些使用者回饋。
   
   • 我們有一個三天的課程，教導如何利用專案團隊成員進行一輪完整的使用者測試。你可以在一天內進行這種快速的測試。並且不到一天就可以準備測試與分析結果。
2. 許多成功的團隊採用一種「平行開發」方法。就是，一方面開發一方面緊接著持續進行使用者經驗工作。
   
3. 最後，我們需要一些在功能開發之外的「基礎性使用者研究」。理想上，機構或組織應該在開發專案前就進行這類的工作。同樣的，較大的公司應該建立一些在專案之外，關於使用者行為、角色特色、使用性準則的基本知識，讓這些知識可以在歷年的專案間被重複使用。

讓敏捷開發與使用性工程一齊發功

我們相信使用性工程與敏捷式開發方法是能一齊運用，並改善使用者經驗。這基於以下的理由：

• 敏捷開發能克服傳統開發方法中的問題，而這些問題也是長期以來使用性工程所關注的。
• 僅僅將敏捷開發有限的應用在程式開發的方法論上，而非應用在系統開發的方法論上，將會危害到近來當代對使用性工程與專案開發的整合工作。但是，如同前文所陳述的要點，有許多方法是可以避開這些問題點。一旦專案團隊明白這些問題，進而處理這些問題，就不會對產品品質造成危害。
• 最後，我們由我們的研究中得知，已經有許多公司採取品質導向的將敏捷式的系統開發方法，因此可以平順地整合開發品質與使用者經驗這兩種工作。
  

我們這份研究對中對於機會、風險的評估，以及實徵的事實證據，是根據兩項研究所做出的結果：

1. 對105位設計與開發專業人士所作的調查研究。
   
2. 對12個公司中的敏捷式開發專案進行的深度個案研究。
   

雖然研究的資料顯示出許多正面的可能性，但是我們也發現一些個案的結果並不理想，並強調對整合敏捷式開發與使用性工程需要有更明確的步驟指引。

對於需要應用到敏捷式方法的使用者經驗實務工作者而言，最主要的調整在於心態上。擁有優秀的、普遍性的使用者經驗知識，將會協助使用者經驗工作 者瞭解，如何修改傳統設計與評估方法，以符合敏捷式開發團隊的重點。然而，如果使用者經驗工作者想要獲得成功的整合成果，仍必須同時相信自己的專業與敏捷 式開發概念並不違背。

如果你已準備好要調整你的實務工作，承擔起這項責任，你會有很大的可能性可以改善工作成效，並且影響整個工作團隊。

【本文翻译仅为外语学习及阅读目的，原文作者个人观点与译者及译言网无关】