冒頭
Fundamentally, agile development comes down
基本的に、アジャイル開発にはこれによって成り立つ。
短い反復による開発と実際のユーザのフィードバックによる各反復での進歩。
However, getting that real
しかしながら、そのような実際のユーザのフィードバックを得ることはUXコミュニティーによる
スキルとテクニックの開発なしではできない。
Integrating UX with agile development is not only
アジャイル開発によるUXの統合は可能なだけではない。それは、アジャイルメソッドの成功には重要である。
Already, we are seeing best
すでに私たちはそのようなプロセスの組み合わせが最もよいプラクティスとして現れると理解している。
These practices are being implemented
それらのプラクティスはアジャイルの仲間たちである工業の全体や
実行可能な開発プロセスのベースラインの供給によって実装される。
Many of these practices
それらのプラクティスの大半はマーチンやビーデルやノーブルのいくつかの会社全体のアジャイルチームの調査により識別された。
They reveal elemetns
彼らは統合へ近づくためには含んでいなければならない因子を明らかにする。
These best practices enable
それらの最もよいプラクティスはチームにアジャイル開発の潜在的な弱点について直接呼びかけることができる；
Providing space for
ユーザが理解しまとまった解法を明らかにする空間を供給すること
Collecting real,end-user
スプリント中実際の末端の利用者のフィードバックを集めること
Supporting real iteration
実際の反復をサポートするーユーザのフィードバックの反応をデザインにリワークすること。
4.1
For reasons...
私たちがこれから話す、UXコミュニティの体験は、私たちの職場において、提案された製品やシステムの実際のエンドユーザーと対話することとの代わりが存在しないことを示している。
Originally, ...
もともと、アジャイル法は、技巧的にこれを必要であるようにする傾向がある。顧客や製品オーナーが、たとえその役割が機能のためであろうと各自の役割を演じ、それ(各自の役割?)を定義しないままにしておくことによって。
This bias...
このバイアス(僻み?)はいくつかの早期のアジャイルプロジェクトからもたらされた。
They were...
彼ら(アジャイルプロジェクト)は、内部ユーザーのための内部システムであり、それは実際は、ユーザーのために飛び越えることも、それらの隣に座りこむことも、システムをどのように変えるべきか話し合うべきか話すことも難しすぎるわけではなかった。
But, on most...
しかし、ほとんどのプロジェクトにおいて、それはとても簡単なものではなくなっていた。
It is important...
組織のために、よいユーザーフィードバックの途中で得る現実的問題が存在することに気づき、プロジェクトがたびたび使うメカニズムの制限にも気づくことが重要である。
UX people...
UXの人々は、ユーザーの調査と共に、現存するメソッド(以下のもの)が必要であるかについて、組織とどのように話し合うか知っておく必要がある。
The following points...
ここで示すポイントは、UXプログラミングではおなじみである、しかし、私たちは彼ら(UXの関係者)が、かなり上級のアジャイル開発者としては新しい人々(新人?)であることを発見した。
Goguen, Greenbaum and Kyng...
GoguenとGreenbaumとKyngとWixonとRameyは、これらのことと、より多くの階層におけるよいユーザーフィードバック収集したその他の問題について議論する。
- User are not good at articulating what they do
User are not good at articulating what they do.
ユーザはどんな作業を行うのか、はっきり述べるのが上手ではない。
This is the problem of ...
これは「暗黙の知識」の問題である。
（「暗黙の知識」の説明）ユーザはどのように作業を行うのかの詳細を内面化（習慣化）してしまっている。
When asked questions ...
彼らにどんな作業をするか、どんな問題を持っているか、何が必要かを質問するとき、彼らの自信の作業の詳細を、彼らが思い出すのは難しい。
So the requirements ...
だから彼らが与える要求は不正確で不十分である。
User want to be helpful.
ユーザは手助けになりたい。
Agile methods attempt ...
アジャイル開発手法は引渡しを早く、頻繁にすることで暗黙の知識の問題に打ち勝つことを試みる。
When users attempt to use ...
ユーザが彼ら自身の作業のためにそのシステムを使うことを試みるとき、彼らは気づき、問題を報告する。
But user tend to assume ...
しかし、ユーザは手助けになろうと振舞う傾向にある、彼らはその与えられたシステムへの返答をするに違いない。（←should：べきである。？）。
They may report on ...
彼らはシステムのいくつかの些細な不便を報告するだろう。
彼らが、彼らが本当に必要なのは全く違うシステムであることや、彼らのタスクの大部分が違うタスクに移ってしまったことや、彼らが本当にしているのは、スプレッドシート内に彼らのすべてのデータを集めて準備してから、データを登録するためだけに設計されたシステムを使うことを、説明することはほとんどないだろう。
- Users are not available as team members
Real users have ...
現実のユーザーは実際の仕事を持っている。
It is not ...
日々のミーティングに参加するか、あるいは、UIの詳細についての質問を毎分中断するか予測することは合理的ではない。
Often, a business ...
しばしば、ビジネスの組織は、にインターフェースとして振る舞うユーザーの代表者を指名することによって、ユーザーを頑固な開発者から隔離する。
But the more ...
しかし、彼らが開発者とインターフェースで繋がるほど、現実の仕事をしなくなる。
Some organizations establish ...
いくつかの組織は、ビジネスのアナリスト（分析者）を設けている。しかし一般的に、ビジネスのアナリストはビジネスのルール、プロセス、そしてデータの要素を定義することに焦点を当てる。
They do not ...
彼らはたいてい、相互作用のデザインの技術は持っていない。
When making a ...
市場のための製品を作る時、ユーザーは同じ会社において平等ではない。
And, of course ...
そしてもちろん、内部だろうと外部だろうと、ユーザーはしばしば開発チームの近くにはどこにも位置していないのである。
Product development……
製品開発の組織は、通常、それらについて詳細に調べるために、チームにサロゲートユーザを入れたり、マーケティングメソッドを使用するかのいずれかの問題を処理します。
There is real value ……
両方のメソッドで価値があるが、彼ら自身によって不完全になっている。
Surrogate users are ……
サロゲートユーザは実際にエンドユーザの良い代役にはなりません。（stand-in＝代役）
The managers of end- ………
エンドユーザの管理者はどのように彼らが仕事の完了を望むか、彼らがどのように考えそれが実行されるか、どのように実際に組織で行われていないかを説明します。
A new system may ……..
新しいシステムでは意図的に変更され、作業の練習を簡素化するかも知れません。しかし、もしチームが実際の問題と実際の回避方法を理解してない場合―しばしばマネジメントには表示されない―彼らは新しいデザインのためにそれらを考慮することが出来ない。
Hiring users away from ……
彼らの組織から離れたユーザをフルタイムでチームに雇うことは試みられたが、限られた価値がある。（ちょっとよくわからなかったです）
Intentionally or …….
意図的かどうか、彼らは観点と開発チームの価値を取得する傾向がある。
“We found out ………
「私たちが見出したユーザの代表者は私たちにとって親切すぎるとわかりました。」は、これを試したひとつのチームのコメントでした。
Product owners as ….
Scrumによって定義された製品所有者も良いユーザサロゲートを作りません。
They may be ……
彼らは、システムのすべてのステークホルダー、エンドユーザ、購入の意思決定を行う顧客、内部ステークホルダーを表すために責任があるかも知れません。
But they are not ……..
しかし、彼らはこれらの人々の全てと彼らを理解するためのメカニズムを必要としている。そして、彼らのニーズは他のプロジェクトのチームメンバーと一致するでしょう
- Marketing methods do not collect design data
Marketing methods do not collect design data .
マーケティングメソッドは、デザイン（設計）データを集めません 。
Product development organizations attempt to use marketing methods such as surveys and focus groups to define products .
製品開発の組織は、マーケティングメソッドを使用しようとします。例えば、製品を定義する調査とフォーカスグループです。
But these methods provide high-level information about attitudes and desires .
しかし、これらのメソッドは、態度や欲求に関する高レベルの情報を提供しています。
They do not reveal how users do work , define what system they need , or what such a system should do .
マーケティングメソッドは、ユーザーがどのように動くかについて明らかにしません、それらがどんなシステムを必要とするか、あるいはそのようなシステムが何をしなければならないかも定めていません。
Neither do they provide low-level detail about the requirements of system function and behavior such as how a task is structured , interactions within a work group , detailed steps users perform , how they collaborate in accomplishing a task , or the context and constraints on how the work is done .
そして、彼らはシステム機能とふるまいの必要条件について、低レベルの詳細を提供しません、例えば、仕事が構築される方法、作業グループ内のインタラクション、ユーザーが行う詳細なステップ、彼らが仕事を達成する際に共同で働く方法、または前後関係と仕事がどのようにされるかという制約です。
Marketing methods are good at collecting sales points and market requirements ;they do not collect design data .
マーケティングメソッドは、セールスポイントとマーケット条件の収集が上手です;それらは、デザイン（設計）データを集めません 。
So , any effective user -centered agile process must include real user research :
だから、任意の有効なユーザー中心のアジャイルプロセスは、実際のユーザーリサーチ（研究）を含まなければなりません：
finding out who the end-users are and how they work ;
エンドユーザーが誰であるか、そして、彼らがどのように働くかを知ること;
analyzing the tasks they do and the strategics they use to achieve those tasks ;
彼らがする仕事と彼らがそれらの仕事を成し遂げるために使用する戦略を分析すること;
getting quick feedback on design ideas and on system baselevels to determine whether the project is on track ;
デザイン（設計）アイデアや、プロジェクトが順調かどうかを判断するシステムベースレベルの迅速なフィードバックを得ること;
and testing designs against success criteria .
そして、成功基準に照らし合わせて設計テストを行うこと。
The process must also support discovering the requirements of the users ' management and purchasers and of internal business stakeholders .
プロセスは、ユーザーの管理者とパーチャー（？）、内部のビジネスストックホルダーの要件を発見することもサポートしなければなりません 。
- Online data collection is incomplete
In this age of web-enabled apps ...
このウェブアプリの時代に置いて、アプリを自分たちで評価したり、開発を補助するために集めた
データを使うことは簡単である。
Different versions ...
異なるバージョンのデザインを出し、使用データを比較することができる。クリックスルーや停止時間などが
計測できる。
Quick surveys ...
クイックサーベイは正しいデータを瞬間的に出すことができる。
But although ...
けれども、これら種類のデータは有用な調査結果であるかもしれないが、これらはより伝統的な
市場調査手法のような同じ方法に限られている。
A survey can ...
サーベイはデザイナーが考えついた疑問に対するデータや、ユーザーが応答するのに
住人な認識をしているかのデータを集めることが出来る。
but much of...
しかし、多くの労働習慣は言葉にされることはない。
An instrumented ...
ある測定されたアプリケーションはユーザーが何にをしたかを報告してくれるが、何故したか、
何をしようとしていたのか、何か大きなタスクがしたのかは報告してくれない。
Any data collected ...
この方法で集められたデータのいくらかは、アプリケーションが正常だという仮定から始まっているだろう。
The team will ...
チームは彼らが知らない別の機会が存在することに気づかないだろう。
4.2
Much of the agile community,
アジャイル開発特にコーディングサイドでの多くは、前もって計画のいくつかの種類の強い懐疑によって運転されます。
"Big Design UP Front"
重要なデザインは前もって（BDUF）、と彼らは呼んでいる。
Also : YANGI
さらに、YANGI（あなたはそれを必要とするつもりではない）、あなたの頭の中にあるたいていの重要な計画は
かつてあなたがそれらを実装するポイントを得る有用または関連のあるものとして出ることはないことを意味します。
Bussiness direction will change,
ビジネスの方向は変わるでしょう、ユーザの要求も変わるでしょう、もしくはそれ自身のデザインの革新は
あなたのアイディアの不適合を引き起こすでしょう。
But successful projects that have
しかし、成功するプロジェクトは重要なインターフェースを持っていてさらに、重要なインパクトを持っていて、どのように
ユーザの仕事に前もってデザインにいくつかの基準が必要かを見つける。
(The Martin , Biddle,and ...)
マーチン、ビーデル、そしてノーブルの論文はこれをBPUFとして要求している。
Pratically,projects discover the need
実際に、プロジェクトは彼らが座ってストーリーカードを書くのと同じくらいすぐにBPUFの必要性を発見するでしょう。
Suppose a team is developing
チームをサポートするのは、オンラインのニュースリーダーを開発しています。
Think about the questions that
ストーリーカードの前に答えなければならない質問について考えることは書かれるべきであります。
何が可能なニュースのソースですか。
How should they be represented
彼らがユーザーから提案されるのになにをするべきか。
How should they be organized?
彼らがえり分けられるのに何をするべきか。
Can the System organize
そのシステムが彼らを選り分けるでしょうかまたはユーザーが選り分けることができるに違いないでしょうか、それとも両方でしょうか
What should the
最初の画面では何を含むべきでしょう
Should it show all
すべての新しいニュースの項目を見せるべきか、またはそれの優先順位で見せるべきか、そしてそれはどのように。
The questions are
その疑問はほぼ終わりがありません。
And each story...
それと、チームが書いたそれぞれのストーリーカードは、彼らが決して考えていない、決して具体的な方法で表現されていないデザインの要素をキャプチャしている。そしてそれは、完全に暗黙でデザインされていないほうほうでインパクトを与えた。
In theory,...
理論上は、ユーザーと一緒に行う繰り返しではどの問題も発生しない。
That is what...
製品活動までに、繰り返し続けて、修正し続けること、それがアジャイルのすべてである。
In fact, these...
実際、それらの問題は繰り返しを通して完全に解決することができない。
As mentioned above...
前述のように、最高の可能なシナリオにおいてでさえも、ユーザーは与えられたものを改修するだけであろう。
Unless a system is...
システムが完全に絶望的である限り、彼らはそれを外に投げ(出さ)ずに、開発者に何か違ったことを一緒に開始するように言うだろう。
So only about...
全体の約20％のシステムは変えることができる。
The base assumptions...
元となる仮定と中心的な構造は単純に、「実用的な製品タイムライン内において」段階的な変更に従順ではない。
To counter a common...
アジャイルサークルで聞いた共通の議論に対抗する、というのも、革命を生み出した人間が、何も利用しないが段階的に洗練されていく単細胞原子生物から来たことは事実である。
But evolution had...
しかし革命は、何百万年もそれをするために起こっていた。製品チームはやらなかったのだ。
And in the real world ...
また、実世界のスケジュールの制約が決定力を持ってくる。
Any engineering project ...
エンジニアリングのプロジェクトでは同じ設計要素を何度も我慢しながらリワークすることがあるだろう。
Any product or business manager ...
プロダクトマネージャーあるいはビジネスマネージャーは最初のプロジェクト範囲からの大きな逸脱をただ
我慢して扱うであろう。
Most agile projects struggle ...
ほとんどのアジャイルプロジェクトは、やり直し実装（リワーク）のすべてを彼らのスケージュールの中に盛り込むために足掻いている。
Once a user story is ...
プロジェクトプランには、一度ユーザの要求が実装されたら、それを見直しや修正する時間はない。
The rework could be written ...
そのリワークは次のスプリントプランニングミーティングで、新たな要求として書かれたり、改めて優先付けられたりできる。しかし、その場合は他の要求が実装されないだろう。
Unless the program ...
プログラムが実際に止まったりする動作を見せない限りは、改めて優先付けされるようなことはないだろう。
Furthermore,iterating an existing ...
その上に、既存のソリューションのイテレーションでは、必然的にプログラムの修正に焦点が当てられる。
What if the real opportunity is not in fixing problems with the crrent soution but recognizing that a different approach is needed ?
もし、現在のソリューションを修正する機会が実在しないのに、違ったアプローチが必要なことが認められたらどうしようか。
For example, the spreadsheet ...
例えば、ダン・ブリックリンがコンピュータ技術が従来の（紙の）スプレッドシートをうまく処理するプログラムに応用できると認識したとき、スプレッドシートが発明された。
Calculator technology ...
計算機技術はそのとき存在していた、しかしどんな量の一つ一つの計算の繰り返しも、数値の処理を、電子的なスプレッドシートへと導くことはできない。
If a team gets past ...
もしチームが過去に書かれたユーザ要求を全体像なしに得たとき、次に彼らが欠如を感じるときはスプリントの期間内である。
In theory, a developer can ...
理論的には、開発者はユーザにどのように要求が実装をされるべきか、の詳細な質問を聞きに行くことができる。
In practice, this is ...
実際は、この理論的なユーザはプロダクトオーナーかＵＸデザイナーである。
Instead, problems with ...
その代わりに、ユーザーストーリーのためのデザインにおける問題は、そのストーリーが実装され、反復によって組み上げられ、そしてユーザーに公開されるまで発見されない。
Even if the ...
その問題が発見されたとしても、それは既に間違った実装が行われている作業の大きな取り扱いではない。
This rework is ...
この再処理は不必要なものである。
Finally, but equally ...
結局、しかしながら、洗練されたユーザーインターフェースや、デザインされているコヒーレンス、そして全ての製品において一貫したユーザーエクスペリエンスの期日における重要性は、全体的なUIが一緒にデザインされなければならないことを意味している。
If one part ...
もし一部分が変更されると、システム全体における変更の影響を考えなければならない。
This is very ...
これは実装のデザインとは大きく異なるので、開発者は、それがどれほど重要であるか認識しない傾向がある。
When designing code ...
コードがデザインされている時、その目的は、それぞれのモジュールとそうでないものに隔離される。よって、それぞれのコードのモジュールは、他のモジュールに影響されることなく修正したり、再実装することが出来る。
Sometimes, his separation ...
時には、この隔離は破壊され、モジュールの関係をもう一度考え、いくつかのモジュールを一緒に再実装する必要がある。
This code refactoring is ...
このコードリファクタリングは有名なタスクであり、一般的なコードよりは難しいものと考えられている。
For all these ….
これらの理由により、効果的なアジャイルプロセスはいくつかのハイレベルな部屋を作ったり、アップフロントユーザがハイレベルな設計を調査する、ユーザとともにテストと反復を行う。
This is often …..
これは、多くの場合、フェーズ０または、スプリント０と呼ばれます。（私たちは、仕事の範囲をうまく伝えられるように以前の名前を好みます。）
User research grounds ….
ユーザリサーチは文化、ゴール、戦略、問題について実際のユーザ作業の練習の中でアジャイル顧客チームの根拠となっています。 （ちょっとおかしいかも）
The high-level design …..
高レベルの設計はユーザ作業の練習のためのシステミック反応、プロジェクトのために定義される範囲内、組織のビジネス会議のニーズをスケッチします。
It also defines the …..
また、ユーザ経験のための基礎を定義し、システム全体のコンシステントレイアウトとインタラクションパラダイムを定義します。
This design, itselr, ……..
このデザイン、それ自体、高レベルと暫定的な詳細は顧客とのテストと反復が必要とされる。
This realizes another ……
これは、前述したほかのアジャイル価値の中核を実現する。：決定が行われるときと検証されるときの間にタイムラグは削減される。
With a validated ……
手で検証された高レベルな設計では、ユーザストーリはユーザが望む彼らが作るセンスとシステムを提供することの信頼性について書くことが出来ます。（訳に自信なし）
We will discuss the …….
私たちは以下のチャプター5でphase0の構造について説明します。
4.3
4.3 UI DESIGN DONE ONE ITERATION AHEAD
前に 1つの 繰り返し をされる UI デザイン
It is hard for developers to appreciate how much work goes into a good UI design .
開発者にとって、どれくらいの仕事で良いUI設計に入るかを評価することは難しいです。
Accordingly , processes designed by and for developers-as most agile processes are-often do not allow enough time for UX work to be done .
したがって、開発者によって、開発者のために設計されたプロセス（ほとんどのアジャイルプロセスがそう）は、しばしばUXの作業が行われるための十分な時間を許可しません 。
Many agile proponents do not understand why it is hard to design the UI for a component , test it , do the graphic rendering , and communicate it to the developer , all within a few days , while still leaving enough time for the component to be coded , integrated , and tested within a two-week sprint .
多くのアジャイルプロポーネント（支持者）は、なぜ構成要素のためにUIを設計するのは難しいかについて理解しないで、それをテストして、グラフィックのレンタリング（翻訳）をして、それらを2，3日の間に開発者に通知します。まだ構成要素に十分な時間を残しながらコード化されて、集積されて、テストされる2週間のスプリントの間に。
Successful agile teams usually give the UX designers room to breathe by having them start on a component design one or more sprints ahead of coding .
成功したアジャイルチームは、通常UXデザイナーにコーディングより前にコンポーネント（構成要素）設計の上で一つ以上のスプリントを始めさせることによって息抜きする余地を与えます。
This way the UX team gets the whole of a sprint to do their UI design and user testing .
このように、UXチームは、スプリント全体に彼らのUIデザインとユーザーテストをさせます。
The testing can and should be iterative with users - which means that the resulting design is refined with users , even if there is little time to rework stories in the development process .
テストはユーザーと反復的にでき、反復的でなければなりません - 結果として得られる設計は、ユーザーと洗練されていることを意味します(？)、たとえ開発プロセスのリワークストーリーの時間がほとんどないとしても、
Then in the following sprint , the UX team member can communicate the detailed UI to the developer , who gets the whole of that sprint to do the implementation .
それから 次のスプリントにおいて、UXチームメンバーは詳細なUIを開発者に通知することができます。そして、その人はそのスプリント全体に実装を行います。
Meanwhile , the UX designers , in parallel , start on the UI design of stories for the iteration after that .
一方、UXデザイナーは、並列して、それ以降の繰り返しのためにストーリーのUI設計に着手します。
4.4
Agile methods tend to be structured as though the last thing that has to happen is integration testing.
アジャイルメソッドは最後に行わなければならないことは統合テストであるかのように構造化される傾向がある。
Code a story,unit test it,integrate it into the code base,show it to the product owner, and it is done.
コーディングやユニットテスト、コードベースへの統合、プロダクトオーナーへ見せることが行われる。
Quality Assurance or User Acceptance Testing is given a role in the process, but that role is limited by the short sprints.
品質保証、あるいは承認テストは開発プロセスの中である役割を与えられるが、その役割は短いスプリントによって制限される。
Generally, QA can do a reasonable job within the iterations by working closely and incrementally with developers as stories are checked in;generally,user acceptance testing cannnot.
一般に、ストーリーがチェックインされるように、品質保証は開発者と密接かつ段階的に作業をすすめることにより、反復の中で合理的に仕事を行うことができます。
また、一般に承認テストは行えません。
A short presentation at the end of the sprint is not a realistic acceptance test.
スプリントの最後に行う短いプレゼンテーションは、本当は承認テストとは言えません。
Doing real user testing necessitates, first ,bringing real users in or going out to them.
本当の承認テストを行うには、まずはじめに、実際のユーザーを連れてくるか、こちらから出向いていく必要がある。
It requires walking though the product with the user's own real-world examples.
これは、実際のユーザーが持つ実際の例を用いて製品のリハーサルを行うことを要す。
It requires that all the stories for the iteration be completed so that the interaction between new features can be investigated, It than pass/fail.
これは、OKかNGかを判断するためというよりは、新機能との間の対応を調査できるようにするために、その反復のストーリーが全て完了していることを要求する。
And it requires time to rework the parts of the system that have problems.
さらに、これは問題を抱えているシステムの一部を手直しする時間が必要です。
Realistically, it is
現実的にすでに短いスプリントで反復なしで作ることは、短すぎて有用な仕事をすることができなくとても難しいです。
Even if such testing were possible,
そのようなテストが可能な場合でも、それはすべてのチームに要求されてはいません、そして彼らはそれが
おきている間中何かをすることを必要とします。
So, successful agile projects have found
そう、成功するアジャイルプロジェクトは、実装の背後のユーザのあるスプリントと彼らの実際のテスト
することは効果的であると発見されている。
The sprint completes and
スプリントが完了するのと国際的なQA（品質保証）やUAT（ユーザ受け入れテスト）プロセスの確認、
プロジェクトチームの能力の一番よいものを決定することで、彼らはスプリントの要求に正しく実装されていました。
Then,during the following sprint,
その後、続くスプリントの中で、UXの人々はカスタマーに基準面を取ることができて、それを実際の例としてとおり、
修正をする問題を持ち帰り次のスプリントに対処する。
This practice also supports
このプラクティスもまた大規模なアジャイルプロジェクトにより支援されている。
In such efforts, the
そのような努力で、アジャイルチームの製品は大きなシステムに構成要素になるだけだ。
Time is needed to integrate
時間はすべての開発チームの構成要素の統合とテストに必要とされる。
All this work can also
すべての仕事は反復の背後で簡単に行うこともできる。
4.5
As mentiond above...
前述のように、製品の確実なユーザーエクスペリエンスはまとまりがあり、一貫性はフルタイムの仕事である。
Unlike refactoring...
リファクタリングとは違って、特別なケースでは、UXチームはいつも全体の整合性を心配する必要がある。
Futhermore, there are...
さらに、いつも製品のUIに大きな抑制/強制が存在する。
An individual agile...
個々のアジャイルチームは巨大システムの一部を実装するだけかもしれない。
It may be...
スイートや製品の1つのコンポーネント中の製品は、実装されるかもしれない。
The UI for...
彼らのチームパートのためのUIは、それ自身のなかのみならず、より大きい製品やスイートの中でもでまとまりがないといけない。
It must also...
会社が指示したどんなスタンダードやガイドラインにも従わないといけない。
So, the UX...
だから、UXチームはそのチーム自身によって製品を届ける(?)よりも大きい焦点を維持しないといけない。
They are always...
彼らはいつも、個々のスクリーンのデザインと、彼らが一部を構成していた、より大きなシステムの両方を見ないといけない。
Maintaining this wider...
より広い焦点を維持することはアジャイル開発での時間を節約した環境ではとても難しい。
There is barely..
行われたスプリントのタスクを得る時間は、かろうじて十分に存在する。というのも、より大きな建築問題を見ることは、トレードオフするのによく最初に行われることなのである。
To make sure...
より広い焦点が見落とされないことを確実にするために、多くの組織は分割UXの流れを作ることは便利であることを発見した。
This stream is...
この流れは、どのアジャイル開発の流れの一部でもない。というのは、そのために並行に行うが、キーポイントで彼らと同期をとらない。
This stream addresses...
この流れは、全体のシステムの不一致を(addresses->探し出し?番地付け?)、新しいストーリーとしてのアジャイル開発の流れの中でのそれらの不一致を修正するためにフィードする。
This UX stream...
このUXの流れは、特定のスケジュールと何らかの開発ストリームの成果物に縛られずに、追加のユーザーリサーチと、デザインと繰り返しを行うことができる。This stream maintains...
この流れは、全体のシステムのデザインのまとまりを維持する。
4.6
p23 4.6 PROGRAMMER/DESIGNER HORIDAY
One of the best practices ...
Martin,Biddle,Nobleらが発見したアジャイルの枠組みにおける、最も良い習慣のひとつは「プログラマーの休日」というアイデアである。
Agile experts recognize ...
アジャイルの専門家たちは、スプリントやプロジェクト開発における割り当て、設計の仕事や、コードを綺麗で維持可能に保つためのリファクタリングの仕事、の全てを行うための激しいスプリントのため時間は、十分にはありえないと理解している。
Technical debt tends to build ...
技術的な借金は、チームが最善の努力をしているにもかかわらず、常に積み上げ続けられる傾向にある。
They also recognize ...
彼らもまた短いスプリントによって、そのペースが要求され、心身を疲れ果てさせていくことを理解している。
When you elminate ...
あなたがプロジェクトプランニングや実地テストによって作られた、休憩時間？(the natural down time)を除いたとき、プロジェクトのペースは減速しない。
So a programmer's holiday ...
だから「プログラマーの休日」はひとつのイテレーションをコードのクリーンアップに捧げる。
Each developer can choose ...
開発者はそれぞれ、悪く実装されたモジュールのリファクタリングか、バグの処理か、あるいはすべてのサブシステムに作用するような大きな規模の再構造化か、なんの仕事をするか、選ぶことができる。
Such a holiday can be useful ...
このような「休日」は特に、並行したUXストリームがなければ、UXチームに便利である。
This can be an opportunity ...
これは一歩戻ったり、全体的な理論立てされたUIの見直しの好機になることができる。：基本的な構造化ができているか、それはユーザのタスクに適切であるか。
If there is a need ...
もし大きな規模での、UIの再構造化、同じときにいくつかのスクリーン全てに作用させること、が必要なら、これはこのようなクリーンアップを行う好機である。
A team working in two-week ...
２週間のスプリントで仕事しているチームは、このような「休日」を４半期に一度程度スケジューリングするだろう、十分に頻繁に行われるのは良いことである、しかし、そのように頻繁に行われないとそれは開発を著しく阻害する。
A team working in one-month ...
１月のスプリントで仕事をしているチームは、スプリントの半分を「休日」に充て、普通の仕事量の半分はそのスプリントで行うだろう。
4.7
Architectual spikes allow ...
アーキテクチュアルスパイク（建築上の釘？）は、開発者のチームが難しい、あるいは危険な開発の問題を取り扱うことを可能にする。
They might devote ...
それは、テクノロジーの問題を学習したり、代替案の解決法を試作したり、負担のテストを実行したり、そのリスクを理解しているか、あるいは最上の解決法を決められてるかを明らかにするということにスプリント全体を充てるかもしれない。
Such spikes happen ...
このようなスパイクは、開発における早期に、最も重要なプロジェクトの危険性を得るという事態が発生する。
But not all ...
しかし、全てのプロジェクトの危険が実装にかかわることから発生するという訳ではない。
Challenging UI problems ...
UIの問題への挑戦は、製品の成功のための十分なリスクを持ち出すかもしれない。
Consider Microsoft's ribbon ...
例えば、Office2007に新しく搭載された、Microsoftのリボンインターフェース（画面上部にある帯状のGUI）を考えて欲しい。
Would the ribbon ...
リボンインターフェースは、新しいユーザーにとって直観的であっただろうか？
Would it be ...
経験を積んだユーザーにとって挫折感を感じさせただろうか？
Could it present ...
一貫してOffice製品の多くの機能の全てを提供することが出来ただろうか？
Would users get ...
ユーザーは多様なリボンインターフェースの操作出来なくなっただろうか？
Use architectural …..
UIの問題に対処するためにアーキテクチャスパイクも使用します。
When a team ….
チームが主要なリスクとしてUIの問題を認識したとき、それはそのリスクに対処するための反復処理に専念することに適しています。
Remember, the risk ……
注意、リスクはチーム全体の問題です。
The team can use ……
チームはユーザと共に彼らが実際に実装することを確認するために、ブレインストーム（ひらめき？）を選択したり、モックを作ったり、テストしたりして時間を使用することが出来ます。
This can be ……..
これは重要なことが出来ます。：それだけでなく、リボンは理論的には直感的に動作しなければならず、実際には賢明な方法でリボンにOffice製品の本当の機能を配置することが可能となりました。
4.8
4.8 UX AS A FULL TEAM MEMBER
正式なチームメンバーとしてのUX
The discussion to this point has tended to treat the UX designers as separate from the development team .
開発チームと別であるように、この点への議論はUXデザイナーを扱う傾向がありました 。
But one key agile principle is that everyone is on the team , and the team is co-located .
しかし、1つのキーアジャイルの原則は、誰もがチームに所属するということです、そして、チームは同じ位置に配置され ます。
Being on the team means that every team member is responsible for the success of the whole product .
あらゆるチームメンバーが、すべての製品の成功に対して責任があることを意味します。
Everyone , including the UX designers , is a pig , not a chicken .
UXの設計者を含む誰もが、鳥ではなく、豚です。
It means that they participate in the work of implementing user stories and they are present for the daily meetings .
それは彼らがユーザーストーリーをインプリメントする職場に参加すること、そして、彼らが毎日のミーティングのためにいることを意味します。
It also means that if they are stuck or behind , it is the teams problem , not just theirs .
それは彼らが動けないか遅れているならば、チーム問題であり、彼らの問題ではないということも意味します。
This principle creates a tight , cohesive team when all the team members are developers .
この主義は堅く、すべてのチームメンバーが開発者であるとき、結合力のあるチームをつくります。
When some team members -like UX designers -have very different skill sets , it is less obvious how to make it work well .
いくつかのUXデザイナーのようなチームメンバーは非常に異なる技術セットを持っている、それはどのようにうまく動かすかは明らかでありません。
It is easy to move around developers to address coding problems ( and agile principles such as "no code ownership " arc intended to make it still easier ) .
コーディング問題（そして、それをさらにより簡単にすることを目的とする「ノーコード所有」のようなアジャイル主義（？））に対処するために開発者を回ることは、簡単です 。
Having a UX person help with a coding problem or having a developer help with a UI problem is more problematic .
コーディング問題でUXパーソンの手助けを受けるか、開発者にUI問題を手伝わせることは、より問題を含みます。
The UX part of the organization also has its own focus that transcends individual projects : for example developning common UI standards across the company, ensuring that the company's branding and image comes through in product UIs, ensuring that the company's UX professionals stay up to speed on the latest developments, and cross-fertilizing across UX professionals.
組織におけるUXパートもまた、個々のプロジェクトの上に独自の焦点を持っている。例えば、社内共通のユーザインタフェースの開発、企業のブランドやイメージを製品のユーザインタフェースにより確保すること、企業のUX専門家が最新の開発速度にとどまること、UX技術者たちを相互に交流させること、などです。
A UX professional always has a dual allegiance : to the team they are on and to the UX community they are a part of.
UXの専門家は常に二箇所（所属するチームと属しているUXコミュニティ）への忠節(良い訳が思い付かぬ、すまん）を持っています。
Successful UX team members
成功するUXのチームのメンバーたちは完全なチームの一員のように動作する。
They are co-located with the
彼らは彼らをもし可能ならばいつでもサポートするチームと同じ場所に配置されます。
If they support multiple team,
もし彼らが複数のチームに支援されるとき、彼らは各チームに開発室の机を持ち、そして、彼らは
可能な限りそこで働くでしょう。
They are present for the daily
彼らは彼らが衝突する限り、日々の懐疑に出席するだろう。もし、複数のチームが同じ時間に会議をしたとき、
彼らはそれぞれのプロジェクトで何が起こっているのかを基準にして、どのミーティングに出るのかを選ぶ。
They do based on story card ,
彼らはUXタスクが特定の要求に関連付けられているとして、一般的にストーリーカードに基づいて仕事をする。
As full team members,
完全なチームの一員として、UXの人々はチームの資源上で描くことができる。
Just as a programmer
プログラマーとしてただいうだろう、「私はこの要求のデータベースのエキスパートとしてこの仕事に必要とされるでしょう。」
UXの人々はいうだろう、「私はこの論文のプロトタイピングのカスタマーが訪れたとき私は必要とされるだろう。」あるいは、
「これは単純です重要でないUIです。私たちは開発者が私が自分の時間を他の重要なUIの仕事に使っている間
私がただ健全性チェックとしてみている基礎となる何かをデザインしていると理解することができるでしょうか。」
最終更新：2011年05月25日 21:23
