為什麼我們要做Bug Bash

Why We Conduct Bug Bashes
http://blogs.msdn.com/steverowe/archive/2009/02/13/why-we-conduct-bug-bashes.aspx


什麼是Bug Bash
- A period of time where we tell all of the test developers to put down their compilers and simply play with the product.
- Bug bashes are a time when everyone on the team is asked to spend all of their time conducting exploratory testing.  
 
運作的經驗法則
- Usually a bug bash lasts a few days.
- This particular one was 2 days long.  
- We often make a competition out of it and track bug opened numbers across the team with bragging rights or even prizes for those who come out on the top of the list.
- Sometimes managers will influence the direction by assigning people end-user scenarios or features to look at.  
- Other times the team is just let go and told to explore wherever they desire.  
- Experience has shown me that some direction can be good.  
- Assigning people to explore an area they don’t usually work on gets new eyes on the product and with new eyes come new use patterns and new bugs.  

作者認為bug bash是有用的, 會抓到一些想不到的bug出現. 因為不同的人, 會有不同的想法, 因此會有不同的testing scenario出現. 或是相同的scenario, 看到原先沒有看到的問題.

但是bug bash的代價是昂貴的, 因為你必須停下手邊的工作, 全心來找product的問題. 因此會導致你手頭上, 會累積很多其他工作.

那為什麼還要做bug bash呢? 他的ROI是什麼呢? 作者認為理由有三
1. A bug bash flushes out a lot of bugs in a short period of time.
- Our most recent bug bash saw the number of bugs opened jump to 400% of the daily average.
- This is important because we frontload the finding of the bugs.  
- The earlier we know about bugs, the more likely we are to be able to fix them.  
- Knowing about more bugs also helps us make more informed triage decisions.

2. They are likely to find bugs on the seams.  
- Test automation can only find certain kinds of bugs.  
- Exploratory testing is a much better way to find issues on the seams—where functional units join up
- Sometimes these bugs are the most critical.  
- We obviously don’t find all such issues through bug bashes, but we do find a lot.

3. Get a sense of the product.  
- Most of the time we spend our days focused on one small part of the operating system or another.  
- It’s hard to get a sense for the state of the forest while staring at individual trees.  
- After spending several days conducting exploratory tests on the product, we can get a much better sense whether the overall product is doing well or if there are serious issues.


kojenchieh 發表在 痞客邦 留言(4) 人氣()

如何進行Sprint Planning (上)

How To Implement Scrum In 10 Easy Steps - Step #3: Sprint Planning (Requirements)
http://www.agile-software-development.com/2007/10/how-to-implement-scrum-in-10-easy-steps.html

Sprint planning meeting 對scrum來說是非常重要的一個步驟, 如果在一開始沒有先講清楚, 讓大家有一致的共識, 之後在這一個sprint就會很混亂.

因為他們會不知道要做的東西到底是什麼 ? 要做到怎樣才夠?因為在這短短的sprint中, 時間是很有限, 要做的東西應該是要十分清楚的.


1.  進行 Sprint Planning Workshop
(1) Make sure the meeting is attended by the whole team.
(2) Include all roles.
(3) The first thing you must do (in your first Sprint Planning meeting) is decide on your Sprint duration. This decision should be taken as a team.

2. 決定sprint的長度
(1) Scrum suggests 30 days.
(2) The optimum Sprint duration depends on many factors.
(3) A development team's 'cycle time' is a direct reflection of the maturity of their processes.
    - A team with immature processes will find the intensity of Scrum and the overhead of Sprint Planning, Testing, Deployment and Review quite onerous for a short Sprint cycle.
    - Whereas teams with very mature processes (for example automated testing, automated deployment, and teams who've become very quick at Sprint Planning), a short cycle might be very comfortable.
(4) Mike Cohn is one of the key exponents of agile development.
    - See here for Mike's article giving further advice about how to select the optimum iteration length.
    http://www.mountaingoatsoftware.com/article/view/30

3. 保持所有sprint的長度是一致的
(1) Whatever Sprint duration you choose to go for, my advice is to keep it consistent.
(2) Allows you to get into a rhythm.
(3) Makes your process very repeatable.
(4) Allows you to start understanding how many Product Backlog points you can typically do in a Sprint.
(5) Once you've decided, you can now set up a Sprint Planning Workshop as a recurring appointment before every Sprint.

4. 選擇這個sprint想要的backlog
(1) Looking at the top section of the Product Backlog,
    - What would seem to be a reasonable goal to set for the Sprint?
    - Can you express an objective that sums up the goal for the next Sprint, or
    - At least pick a section of items/features from the top of the Product Backlog that the team thinks can be achieved in the Sprint duration?
(2) Select your target backlog for the Sprint. Make this decision as a team.
(3) It's important to prepare more items during planning in case the team finishes early.
    - These items can be clearly identified as stretch tasks and the Product Owner should not expect them to be completed.
(4) In future Sprints, you will be able to use your Scrum team's previous Velocity to help with this decision.
    - Velocity is the number of Product Backlog Points delivered in a Sprint.
    - This tends to fluctuate wildly early on when adopting Scrum.
    - But it will settle down as the team get into a rythm, and in future provide you with a reasonable norm to base your target backlog on.

5. 釐清sprint的需求
(1) Take each item on the Product Backlog. It's important to go through them methodically, one item at a time...
(2) The Product Owner presents each item and explains how he/she sees it working from a functional perspective.
(3) The whole team discusses the item in detail.
    - The whole team asks questions about the feature in order to establish what it should do and how it should work.
    - The outcomes of this discussion should be captured on a whiteboard or flipchart, or someone could write notes on a laptop as the discussion progresses.
(4) Write requirements in a way that is lightweight and visual.
    - Agile requirements should be barely sufficient.
    - The fact the features will be developed and tested within the next few weeks, and by the team that were present, makes this possible.
(5) Consider writing 'User Stories'.
    - But the basic concept is to write features using this construct:
        As a [type of user], I want to [do whatever], so I can [achieve what goal].
    - The story can be backed up by a sketch of the UI, a wireframe or visuals.
    - Annotate the sketch to describe the functionality.
    - Backed it up with statements about how it will be confirmed (or tested).
    - This will help to identify scenarios up front, before it's developed.


kojenchieh 發表在 痞客邦 留言(0) 人氣()

Scrum是不夠的

Scrum is not Enough
http://practicalagility.blogspot.com/2008/06/scrum-is-not-enough.html

作者在scrumdevelopment Yahoo group上, 看到一篇post "Scrum and Architecture",
http://groups.yahoo.com/group/scrumdevelopment/message/29810

其中Ken Schwaber回應了一段話


    In order to employ emergent architecture, every Sprint must leave behind clean, commented, refactored work. Otherwise emergence hits the wall within six Sprints (or sooner, depending on how bad the morass is).

作者覺得很驚訝, 因為這段話相當於Kent承認Scrum 的practice, 除了short term以外, 是不足夠去處理每件事情. 當然啦, 不只Ken這樣講, 在這篇post中很多人也這樣講, 包括作者本身

Ken過去曾經不斷說明, Scrum已經有審慎考慮過很多事情, 因此不需要加入任何tech practices. (我個人認為像是TDD, refacotring, pair programming等等) 但是現在由這篇post看來, 如果沒有solid technical practices, Scrum是不足夠的

所以作者勸大家, 要考慮一下往agile process方向移動, 也就是考慮其他agile的process, 像是XP等等. 因為Scrum真的是不夠的


kojenchieh 發表在 痞客邦 留言(0) 人氣()

IDEO 的創新秘訣

上禮拜去外面上了四天的課程, 是由IDEO的大老(Bill Moggridge)來上課. 大家可能很好奇問IDEO是什麼東西, 它是依家非常有名的設計公司. 其最著名的設計作品是蘋果電腦和微軟的第一個滑鼠、和PDA的經典機種Plam V,以及Steelcase品牌下的Leap Chair.


或許你會問工業設計和我們有什麼關係? 我覺得IDEO厲害的地方不是在於它的工業設計, 而是他的創新流程. 在這幾天上課中, 我是覺得這樣的流程真的很精采, 是可以幫助team思考, 讓你容易有新的innovation出現.

他的CEO(Tom Kelley)還寫過ㄧ本書:
決定未來的10種人:10種創新,10個未來/你屬於哪一種?  The Ten Faces of Innovation
我想這本書很多managers都被要求看過, 如果你覺得她寫的不錯, 你更不能錯過他們公司的創新流程

此外, Bill Moggridge還寫了 一本書:
Designing Interactions
關鍵設計報告:改變過去影響未來的互動設計法則(附作者訪談精華中文片段DVD、設計大師親自示範互動設計)
內附的光碟, 可是當做入門的tutorial, 讓你很快知道什麼是design interactions以及IDEO做事的思考流程

以下是我在網路上, 找到有關IDEO的介紹, 可以讓你很快了解什麼是他們的創新流程.

==============================================
IDEO創新的3個秘訣

 

轉載-波酷網

創意是怎麼誕生的?是天才的靈光一閃,還是埋首於實驗室不斷地嘗試與錯誤的累積?我們從全球首屈一指的設計公司IDEO,發現了一些蛛絲馬跡。原來,創意也是可以被管理、被流程化的,只要你懂得這些技巧……。
對於全球首屈一指的設計公司IDEO的創辦人暨董事長大衛‧凱利(David Kelley)而言,設計師這個詞,不再像過去一樣,指的是美術課裡最靈巧的那個孩子,而是每一個人在思考的時候,都應該、也都可以像是一個設計師。因 為,「一切都和瞭解人類的需求有關。」

IDEO是一家產品及服務的設計公司,但創辦之初的設址地點,卻選在高科技產業雲集的矽谷所在地帕羅奧圖市(Palo Alto);IDEO是一家設計公司,但是卻逐漸扮演起企管顧問公司的角色,為許多企業提供產品及服務上的建議;不同的是,前者配戴著一副商學院思維的眼 鏡,而IDEO卻是透過人類學家、社會科學家、心理學家、工程師和圖像設計師的眼,帶領客戶重新觀察消費者的世界。

除了經營IDEO,同時也是史丹福大學工程系教授的凱利說,「對我而言,那就像是宗教一般,我真的相信,設計思維可以讓生活變得更好。」

1978年,取得史丹福大學(Stanford University)產品設計碩士學位的凱利,成立了大衛‧凱利設計公司(David Kelley Design),蘋果電腦的第一隻滑鼠,就是出自該公司。1991年,該公司與英國設計公司ID Two(第一台膝上型電腦Grid的設計者,如今收藏在紐約現代美術館)合併,成立IDEO。如今,該公司已有350名員工,年營收約7000萬美元,舉 凡微軟、寶鹼、惠普、百事可樂、三星等知名企業,都是他們的客戶。而除了帕羅奧圖之外,在舊金山、芝加哥、波士頓、倫敦、慕尼黑和上海等地,也都設有辦公 室。



祕訣1:訂出一套設計的流程
1999年,美國廣播公司(ABC)〈夜線〉(Nightline)節目,找上了IDEO。當時,IDEO的創新能力與影響力已備受肯定,但該節目卻想帶 領觀眾「親眼看看創新的產生」。於是,他們找來了美國消費者再熟悉不過的超級市場購物推車,要IDEO的設計師在5天之內,重新設計這項產品,結果拍成了 「深掘(Deep Dive):一家公司創新的祕密武器」這個專題報導。


第一天,星期一上午9點,召集人在公司裡組成了一支網羅各領域專長的專案團隊。在一聲「幹活吧!」之下,大夥分成了幾個小組,有的埋首觀察消費者採購雜貨 的行為;有的鑽研購物手推車和相關技術;有人跑去請教採購和維修推車的專家;有人則跑到超級市場去觀察人們的購物行為;有人甚至刺破了十幾部兒童座椅和娃 娃車,研究其中的構造。一天末了,訂出了3個目標:體貼兒童的購物推車、規畫更有效率的購物方法,以及提高安全性。

第二天,針對3項目標召開動腦會議,百無禁忌,即使是餿主意也沒人介意。上午11點,天馬行空的點子和構圖,寫滿了一大張海報。之後進行投票,決定模型製 造重點。下午6點,一部可供測試的原型車出爐,具備了車體外型優雅迷人、籃子可堆置在車架上的組合設計、一支可向客服人員詢問的麥克風,以及一個可以節省 結帳排隊時間的掃瞄器等功能。照例,還要針對原型最有特色的部分,再分派任務繼續改良。

星期三上午6點,一個靈巧、曲線優美的車體架構,已經由一位資深焊工打造完成。負責製造模型的設計師則辛苦地改良車輪。

第四天,就在眾人開始組裝車體,並將超市菜籃放到特別打造的車體時,凱利突然說:「你們不會要用這些籃子吧?」於是,工作房的人取出幾張樹脂板,開始扳折出幾個籃子。同時,每個環節的組裝測試工作也已完成。最後還得幫推車漆上顏色。

星期五早上9點,當工作人員在幾百萬電視觀眾面前掀起布簾的那一刻,週遭響起了一陣歡呼。一台拉風、亮麗的創新購物推車完成了,車體的主結構兩側傾斜成弧 線,有點流線型跑車的味道;開放式的車架設計,可以在上下兩層整齊排放五個標準化菜籃;推車上的兒童座椅有遊樂園裡的安全扣閂,還有趣味的遊戲板;車上還 附有掃瞄器可直接結帳;兩個咖啡架;以及靈巧轉動的後輪。


凱利在節目中表示,「其實我們並不是任何特定領域的專家,我們所擅長的是將一套設計的流程,所以不管產品是什麼,我們只是設法找出如何利用這套流程來創 新。」的確,舉凡寶鹼的Crest牙膏管、歐樂B的兒童牙刷、Palm Computing的Palm V、拍立得大頭貼相機I-Zone等等,都是IDEO的得意作品。



祕訣2:將設計思維引進商界學界

1990年代,網路及高科技產業的蓬勃興盛,讓IDEO迅速崛起成為全球最紅火的設計公司。當網路泡沫破滅之後,IDEO則是改變了營運模式,除了持續推 出酷炫的產品之外,也轉而聚焦於流程,為消費者營造更美好、舒適的體驗。換言之,IDEO漸漸地轉型成為一家非比尋常的商業顧問公司。

而上門尋求建議的大企業高階主管,可不是安坐在辦公室裡聽取簡報而已,還得進行角色扮演,穿上消費著的鞋子。例如,寶鹼的執行長曾被派去購物;食品集團 Kraft的高階主管為了改善供應鏈管理,被帶到某大城市的交通控制中心,觀看上百萬輛汽車每天停下和發動的過程;AT&T的高階主管則是要求使 用他們的行動電話服務軟體Mmode,找到自動提款機、藥房和某種罕見的日本點心。

結果證明,Mmode操作困難,有位主管還是打電話叫老婆上Google幫他找。於是他們瞭解到,他們的競爭對手不是Verizon(美國最大電信業 者),而是「真實的生活」。同樣地,大型健康照護中心Kaiser Permanente在請來IDEO協助其所謂的「長程成長計畫」後,發現原來要吸引更多患者上門,他們不需要大興土木,建造昂貴的病房設備,真正要做的 是「改善患者體驗」。

對於許多上過IDEO「身體激盪」「腦力激盪」的大客戶而言,赫然發現其很多事情都是常識,但人們往往因為習慣、惰性和制約的緣故,喪失了觀察細微之處的 能力。IDEO是十足的行動派,因為唯有實際付諸行動,才能激發創意。目前正在史丹福大學推動「設計學院」創立事宜的凱利說,「我一點都不擔心創意會被客 戶學走,因為就算他們學會了這禮拜的創意,我們下禮拜還會想出更好的創意。」


 

祕訣3:將設計和開發的機會視覺化、具象化

在IDEO,創新是根植於一套集體合作的方法,同時考量使用者的需求、技術上的可行性,以及商業獲利能力。這套創新的機制採用了一系列的技巧,將設計和開發的機會視覺化、具象化,以利於評估和修正,茲列舉如下:


1.觀察。觀察使用者是每一項設計方案的起點,並由IDEO的認知心裡學家、人類學家和社會學家等專家所主導,與企業客戶合作,以瞭解消費者體驗。所有IDEO的設計師都非常善於觀察人,以及他們是如何與這個世界進行互動。在這部分的技巧包括:

˙追蹤使用者:到人們生活和工作的現場去,觀察人們如何使用產品、購物、到醫院看病、搭乘火車和使用行動電話等。

˙勾勒使用行為:將人們的活動記錄下來,包括在醫院候診室進行兩、三天的觀察與記錄。

˙消費者的使用歷程:追蹤消費者與某項產品、服務或空間的所有互動。

˙用相機寫日誌:請消費者把他們對於產品的使用情形和印象,記下影像日記。

˙極端用戶訪談:和對於產品或服務非常瞭解,或一無所知的人聊天,並且評估他們的使用經驗。

˙說故事:促使人們就個人的使用情形,說出親身體驗的故事。

˙非焦點團體:訪問各種不同群體的人或專家;例如,為了探索有關鞋子的創意,IDEO會探詢藝術家、健身運動者、足科醫師、乃至於對鞋子有戀物癖的人的意見。

˙親身使用產品或服務,以找尋細微的線索。

˙鼓勵遊戲和惡作劇,讓工作者有掌控命運和超越自我情感的感覺。


2.腦力激盪。這是一個緊湊密集、蒐集靈感和創意的過程,將觀察人們所得的資料進行分析,每一次都不超過一個小時。而且在會議室的牆壁上,還印著腦力激盪的重要原則:

˙暫緩進行判斷:不要動輒駁斥任何構想。

˙以別人的構想為基礎,再提出己見:不要說「但是」,要說「還有」。

˙鼓勵瘋狂的構想:擁抱最跳脫框架的概念,因為它們很可能就是關鍵的解決方案。

˙多多益善:儘可能找出最多的點子。一場好的動腦會議,應該可在60分鍾內,蒐集到上百個點子。

˙具象化:使用黃色、紅色和藍色的筆,在五顏六色的便利貼條上寫下點子或畫下構圖,並貼在長寬各30英吋(約76.2公分)和20英吋(約50.8公分)的海報上,最後還可以用貼條投票表決出最好的幾個構想。

˙專注討論,不要偏離主題。

˙一次進行一場對話:不打斷別人的對話,不駁斥,不輕蔑,不得粗魯無禮。


3.快速製作原型。如果一張照片勝過千言萬語,那麼在IDEO,一個原型勝過千張照片,因此製作原型不但是一種創新的語言、一種生活方式,更是溝通與說服的工具。重要的是,原型是一次次趨近於成品的「不良品」,愈早失敗,愈早找出問題所在,成功的速度就愈快。

˙製造可操作的模型:將可能的解決方案視覺化,除了容易創造驚奇,更容易改變想法,促使接受新觀念,幫助客戶或決策者在面臨昂貴和複雜的功能時,加速決策制定和創新。最好的原型材料是泡棉、塑膠或木材。

˙什麼都可以製作原型:無論是產品或服務,網站或空間,都可以製造出模型,例如醫療中心或博物館大廳等。

˙善用攝影機:透過像是電影預告片的形式,將構想或是消費者在產品及服務推出後可能的使用體驗呈現出來。如果你負責和服務或人因工程有關的專案,有時候夠過即興安排劇情中的虛擬人物,有助於組員甚至是客戶表達他們的易見。

˙追求速度:以快速和廉價的方式製作模型,絕不要浪費時間在複雜的概念上。

˙不求細緻花俏:製作原型只是為了展現設計概念,切勿花費太多心力、時間在細節上。

˙創造情節:展現各式各樣的人如何以不同的方式使用產品或服務,以及如何透過各式各樣的設計,以滿足使用者個別的需求。

˙身體激盪:即興安排劇情,虛擬出不同類型的消費者,並且實地模擬他們的角色。例如,在老人安養中心,拿著柺杖或行動支架實際走一趟。


4.重複評估和改良原型。在這個階段,IDEO會將諸多選項過濾到只剩幾個可能的解決方案。做法為:

˙腦力激盪:以非常快速的議程,剔除不可行的構想,鎖定剩餘的最好選項。

˙專心製作原型:就少數幾個重要的構想,專注打造原型,以達到問題的最佳解決方案。

˙加入客戶觀點:主動地邀請客戶參與這個流程,以過濾選項。

˙展現紀律:毫不留情地做出選擇。

˙專注於流程的結果:達到最佳解決方案。

˙達成協議:取得利害關係人的大致認可。愈多高階主管拍板敲定了哪項解決方案,成功機率就愈高。


5.執行。完成了構思的過程之後,就進入了將概念打造出成品的最後階段。

˙集結IDEO的工程、設計、社會科學專家,發揮所常,實際創造出產品或服務。

˙選擇製造夥伴。

˙廣泛測試成品。

˙必要時還可協助客戶推動及時與成功的產品上市活動。

 
=======================
 
IDEO的創新修練 - 利他主義的服務設計與創新
 

但以理

談及服務創新,一定得提到IDEO這間擁有超過350名員工的國際設計公司。IDEO成立於1991年,Apple、Microsoft、 Nike等國際知名品牌,都曾是它的客戶,目前更是全世界得過最多國際設計大獎的公司之一。其員工來自不同領域,包括人類學、心理學、工程學、設計、商學等背景,是一個名副其實的跨領域設計研究單位。

有些人會將IDEO定位為工業設計公司。但和其它一般的設計公司不同之處在於: IDEO更擅長於提供創新的設計思考 (Design Thinking) 策略,協助客戶開發出真正的內容創新,創建品牌差異化。因此,IDEO 和其它的設計公司差異不在於設計的類型,而在於其設計的思考方法。也因此IDEO承接的設計案件橫跨產品、建築、展場、企業識別形象、商業模型等。其作品都能夠反映出不同於傳統的設計創新,並滿足最根本的需求。

通常企業來找IDEO,未必是要請IDEO協助設計出一個外觀炫麗的產品或高科技化的服務,而是希望透過IDEO獨特的設計思考方法,提出全方位的創新方 案──挖掘出潛藏在使用者內心的渴求,藉而設計出真正能夠滿足使用者需求、且擁有最佳市場定位、同時在技術上可行的產品。

全球最大的辦公家具公司Steelcase或Intel 都曾委請IDEO提出概念性的未來商品,不只在於IDEO是富有想像力的公司,更在於IDEO的設計乃奠基於紮實的質性研究,使他們較能清楚掌握哪些創新 是有用的且有機會能夠影響人類的生活文化。市場上亦有知名案例如Nokia N95的N-Gage遊戲平台、PRADA美國旗鑑店的智慧型更衣室等,亦是IDEO將創新設計研究成果落實在設計案當中的例子寫照。

IDEO創新的四個步驟

那麼IDEO到底如何創新呢?根據IDEO公司網頁上的描述,IDEO的創新概分為四個主要步驟: 1) 觀察、2) 腦力激盪、3) 雛型設計、4)實作。

簡單來說, 觀察的目的是要找出產品的現存問題。研究員透過觀察使用者的居住或工作環境,他們日常行為、使用科技方式,以及各種細微的線索,最後,歸納出一系列亟待解決或改善的問題。

在腦力激盪的部分,則是讓不同背景的研究員共處一室,針對觀察到的問題一起提出富創意的可能解決方案。在 IDEO裡面有各種不同領域的人,大家各自從不同背景的角度提出想法,發掘各種可能性。

值得一提的是,在此階段,不論想法可不可行,皆盡可能都用視覺化的方式把各種想法呈現出來,並鼓勵跨領域的討論。經過討論,幾個有趣的方案浮現之後,進入雛型設計階段,研究員們透過劇本、腳本,以及各種圖面來形塑產品的使用方式以及造型,並不斷修正與改進,直至最後定稿。

至於實作階段,則是以各種可行技術去實現設計,製作出第一個產品,反覆測試及細部修正。最後,還有最重要的一關,就是找潛在使用者實際試用這個產品以獲得實質的反饋做為改正方針。

圖:IDEO的創新研究流程

為了讓更多的人認識創新設計思考,IDEO創辦人之一的David Kelly,也於近年在美國史丹佛大學成立創新設計的學程d.school (http://dschool.stanford.edu),將這種創新設計思考的實務方法向學界推廣。同樣秉持著跨領域研究的精神,d.school 招收來自史丹佛各個學院──電機、醫學、工程、設計、管理等的師生,創造一個讓不同背景的人能夠在一起交流與相互激盪設計思考的學習環境。透過工作坊、實驗室以及課程,參與者能夠學習到設計思考及設計管理的知識。

驅動創新的互動設計

在創新設計的思考上,很重要的一個概念就是讓使用者認同你的設計不只是好用,同時是一種前所未有的使用的過程經驗。因此,在IDEO的創新思考當中,也非常強調互動經驗設計 (Interactive Experience Design),演變到後來成為互動設計 (Interaction Design)。

IDEO是第一個提出互動設計這一名詞的公司。國際上一些互動設計學系和研究單位的成立乃受其影響,使互動設計成為一設計專業學門。

在互動設計研究中,i-Pod是一個經常被討論的案例。許多人認為i-Pod成功之處,便在於它簡易而直覺的操控介面以及使用情境的塑造,而這正是互動設計所專注的議題──如何讓人與科技產品或服務的互動經驗更美好、更友善。

創新其實有許多面向,從IDEO的經驗我們可以發現,真正關鍵的創新指的不止是單純技術上的創新而已,而是包括設計上與互動經驗上的創新。

但台灣的科技業者往往多專注在技術面上的創新,忽略了其它相對重要的面向。

創新是否有意義,取決於終端使用者的感覺。IDEO的創新設計思考方法幫助企業設計出榮獲大獎且使用者喜愛的優良產品,例如MUJI的CD掛鐘,簡單的設計,完美詮釋了MUJI的日式極簡風格,獲得了2002年的iF 設計金獎、Design Week、D&AD等獎項。

簡單的CD播放器外觀讓人們容易理解且便於做為日用品與環境搭配,沒有讓使用者感受到操作CD播放器的複雜技術,此款乾淨的設計深深地觸動人們日常生活的情感與記憶,因而大獲好評。

結語:利他(使用者)主義的中心思想

台灣有很強的技術研發能力,但是對終端使用者(亦即消費者)而言,因為和消費者的生活經驗未必相關,這些產品未必構成意義。唯有直指使用者的根本需求,將焦點置於設計互動經驗上的創新,才會創造有意義的差異。

總而言之,創新的一個基本概念,就是「以使用者為中心」──從使用者最根本的需求和渴望出發,然後藉由設計出產品、服務或環境,來滿足這些需求及渴望。

科技人必須無條件地先放下各種以科技或市場利潤為本位的主觀觀念或個人偏好,靜下心去觀察人的生活細節,然後用心去體察他人一舉一動、所思所想之間,才能發現人類最根本的需要。

並且,在過程中不斷歸正,發現錯誤時即時改正,直到使用者最滿意的狀態。在這最根本的基礎之上,再用設計去解決和回應,才能達到真正所謂的創新。◇

 

 

Other References:
1. IDEO 方法圖卡的認知組織
http://taiwan.chtsai.org/2008/05/08/ideo_fangfa_tuka_de_renzhi_zuzhi/
2. IDEO Series & Design Thinking
http://janetyc.blogspot.com/2009/01/ideo.html
3. WiKi: http://zh.wikipedia.org/w/index.php?title=IDEO&variant=zh-tw


kojenchieh 發表在 痞客邦 留言(0) 人氣()

Technical Debt
http://www.scrumlabs.com/tag/technical-debt/


Technical Debt 是由Ward Cunningham 在1992中的一份experience report所提到的:

    Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

之後在agile的領域中常常出現這個term, 為什麼呢? 因為在agile中有iteration, sprint等東西, 因此你就會常常聽到engineer說, 這些東西下個iteration再做, 現在已經擠不進去. 以前不是agile的時候, 這個藉口也是常用, 只是因為周期較長, 以前在中後期比較會聽到這樣的事情. 但是現在會每次的iteration都會聽到一次:
    * ‘We’ll do it in the next release’ – that never comes.
    * The project got delivered – along with a maintenance team.
    * We did it for good business reasons.
    * “The architecture - let me see - I have a single power-point somewhere with a picture on it”.
    * “To get anything released to production is a nightmare - we have to regression test the whole system”.

以下有兩篇好的文章, 在探討Technical Debt, 作者推薦大家可以參考一下:
An excellent article on Technical Debt by Kane Mar :
http://kanemar.com/2006/07/23/technical-debt-and-the-death-of-design-part-1/

And another excellent article by Steve McConnell:
http://forums.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx

作者也提到, 有一個方法可以mitigate這個問題, 那就是在幾個business focused 的sprints後, 加一個technical debt, 這樣可以幫助你之後的velocity, 還可以維持一定的水準, 不會被日積月累的負債給拖垮. 需知道當你有巨大的債務時, 即使光付利息也是會讓你喘不過氣來.

當然啦, 如果可以在每個release中減少technical debt, 那還是比排一個做refacoring 的TD sprint. 因為每天運動, 一定比假日或是有空運動, 效果要好的多, 代價也不會太多. 很多道理就是相通的.

kojenchieh 發表在 痞客邦 留言(0) 人氣()

Close

您尚未登入,將以訪客身份留言。亦可以上方服務帳號登入留言

請輸入暱稱 ( 最多顯示 6 個中文字元 )

請輸入標題 ( 最多顯示 9 個中文字元 )

請輸入內容 ( 最多 140 個中文字元 )

reload

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼