5.1.8
- P40の3段落目(A paper prototyping session is...の直前)まで
A key problem for any sort of user-centered design, including agile methods, is how to get accurate feedback from users.
アジャイルメソッドを含め、ユーザー中心設計のキーとなる問題は、どのようにしてユーザーからの正確なフィードバックを得るかです。
Users are not designers.
ユーザーはデザイナーではありません。
They do not normally articulate their work practice and cannot envision how a proposed change would affect them on a day-to-day basis.
彼らは、通常彼らの仕事の実態を明確に表現することはしないし、ある提案された変更がどのように彼らの日常に影響するのはを想像することはできない。
How can they know how to advise the development team?
どうすれば彼らは開発チームにアドバイスできるでしょうか。
An agile process allows the team to do the wrong thing and fix it more quickly-but we would like to do the right thing in the first place.
アジャイルプロセスは、チームが間違ったことをして、それをより素早く修正することを容認しますが、私たちは一度目で正しいことをしたいと思います。
Paper prototyping provides an answer that has been widely and successfully used.
ペーパープロトタイピングは、広く、うまく使われている答えを提供します。
Rather than describe a solution, show it.
解決策を説明するのではなく、それを示します。
Rather than ask users how they like it, ask them to work with it.
ユーザーがどのようなもの好むかを尋ねるよりも、一緒に働くように依頼します。
Rather than give them a task to do, ask them to do their own task in the prototyped system.
やらなければいけないタスクを与えるのではなく、プロトタイプシステムではユーザー独自のタスクを行うように依頼します。
Prototyping can validate the system concept-that it is something people want, can refine the overall structure of the system, can ensure that the right functions are provided, and can refine the detailed behaviour of individual functions.
プロトタイピングはシステムコンセプトを検証することができます。システムコンセプトは、ユーザーの望んでいるものであり、システム構造全体を改良することができ、正しい機能が供給されていることを確実にすることができ、個々の機能の詳細な挙動を改良することができます。
The prototype represents the system as a whole, so it helps to keep the design coherent across the system.
プロトタイプはシステム全体を表すので、システムのデザインの一貫性を保つのに役立ちます。
User stories tend to break the system into independent bits, so this coherent view is especially important to maintain in agile project.
ユーザーストーリーは、システムを独立した小さな物に分解する傾向があるので、この一貫したビューはアジャイルプロジェクトで維持されることは特に重要です。
Paper prototypes are quick to build.
ペーパープロトタイプは迅速に構築されます。
A designer can have a simple UI mocked up in half a day or so.
デザイナーは、半日かそこらでモックアップされたシンプルなUIを得ることが出来ます。
Paper is easy to transport and,once at the user's workplace, easy to work with.
紙は持ち運びが容易で、ユーザーの職場に持って行って一緒に仕事することも簡単です。
Paper prototypes are also easy to modify.
ペーパープロトタイプも変更するのが簡単です。
When user or designer suggests a change, they can mock up the change and put it into the prototype immediately.
ユーザー又はデザイナーが変更を提案しているとき、変更をモックアップし、プロトタイプにそれを組み込むことをすぐに行うことができます。
The user can experience it and decide whether they like it as well as they thought they would.
ユーザーはそれを経験でき、彼らが思っていたようにそれを好むかどうか決定できます。
A paper prototyping session is
論文のプロトタイプのセッションはデザインとユーザの間のパートナーシップとして働く。
The first thing the designer
設計者のする最初のことはユーザの仕事の詳細について発見やプロトタイプの修正をする。
それにより、ユーザ自身のデータや状況を表す。
By using their own known information us
どのようにシステムは構成されるかを手掛かりとして彼ら独自の情報を使用する。
ユーザはあたかもそれが本当かのように反応することができる。
したがって、彼らはシステム内での彼ら自身の仕事のタスクを追求することができる。
デザイナーは必要とされる新しいシステムの要素を持ち出すことができる。
When there is a glitch、
グリッチがあるとき、ユーザとデザイナーは問題を議論し問題を解決できるように
一緒に決定する、彼らは（紙の上では）すぐに実装できる。
Paper prototyping is done at two
論文のプロトタイプはアジャイルプロセスの２つのステージでされる。
最初に、フェーズ０の間中、論文のプロトタイプはヴィジョンを検証するのに使われる。
Any vision represents aguess
いくつかのヴィジョンはチームの一部をあらわすと思われる。－
データに基づいた良い推測として、しかしそれにもかかわらないものもある。
By mocking it up and
論文中でそれをでっち上げテストをすることにより、チームは時間と（ヴィジョンセッションの）デザインを
作ることとユーザによる検証間のラグを減らすことができる。
Two rounds of paper
論文のプロトタイプの第二段階はチームに自信のある彼らが書いた要求を与えるのに十分で、
ユーザの問題にとって合理的かつ貴重な解法である。
However , paper prototypies and user
しかしながら、論分のプロトタイプとユーザの要求は高いレベルでの解法の説明では大まかには似ている。
They do not specify exactly
彼らはどのようなインタフェースにするかを正確には指定されていなく、
レイアウトの詳細と相互作用を探します。
Nor , by agile principles ,
また、アジャイルの原則では、それらをする必要があります。
YAGNI advises that
YAGNIはもしあなたのデザインが遠く離れているときにアドバイスをする。
あなたは使われないであろう設計の特徴に似る。
So instead , the detailed design is done immediately before implementation ,
using the best practice of designing one sprint ahead of implementation.
そうではなく、デジタルデザインは実装の前にすぐにされる。
あるスプリントの前に実装される最も良いプラクティスの使われるデザイン。
That gives the UX designers enough time to work out and iterate the details
with users before the developers come asking how a story is to be done.
これは、UXのデザイナーにうまくいかせる（もしかして捻り出す）ための十分な時間と開発者がどのように
要求がなされるかの方法を尋ねに来る前にユーザにとっての反復の詳細を与えます。
This UI testing is also done with paper prototypes , which are now more
highly rendered , closer to the actual UI.
このUIのテストは今ではより高度にレンダリングされた実際のUIに近い論文のプロトタイプのようになされる。
If two rounds of prototyping were done during phase 0, a single round of
prototyping is generally enough during sprints.
もし、プロトタイプの二つのラウンドがフェーズ０の間になされたら、
プロトタイプの単一のラウンドはスプリントの間で一般的に十分である。
5.2
5.2
THE RELEASE PLANNING SESSION
リリースを予定しているセッション
Agile development starts with a release planning session .
アジャイル開発は、リリースを予定しているセッションから始めます。
Together , but driven by the product owner or custmer representative , the team writes user stories to represent the key elements of the release .
一緒に、しかし、製品のオーナーまたはカスタマーの代表によって駆動されて、チーム はリリースの鍵となる要素を表すために、ユーザーストーリーを書き ます。
UX designers and others who participated in user research during phase 0 with them act as the customer representative .
彼らとフェイズ0の間にユーザー研究に参加したUXデザイナーと他の人は、カスタマー代表の役をします。
They should act directly in that role on the team , and support the product owner with their knowledge of user work practice .
彼らはチームの上でその役割で直接行動すべきであり、またユーザーの作業の実践についての知識で、製品のオーナーを支えるべきである。
5.2.1
- 3段落目(The level of...の直前)まで
5.2.1
WRITING USER STORIES
ユーザーストーリーを書くこと
Each user story captures an element or feature of the design .
各々のユーザーストーリーは、設計の要素または特徴を捕えます。
Stories are written on cards for the same reason that visions are written on flip charts :
ストーリーは、ビジョンがフリップチャートに書かれた同じ理由のために、カードに書かれ ます：
to keep the team from over specifying and over designing .
チームがもう一度明記して、もう一度設計しないようにすること。
All that will fit on a card is a simple , high-level description of the function or behavior .
カードに収まる全ては、機能またはふるまいの単純な、高レベルな説明です。
The team writes stories by walking through their design ( as represented by their vision , UED , or prototype ) , identifying each design element , and writing a story card to capture that element .
チームは彼らの設計（彼らビジョン、UEDまたはプロトタイプで表される）を通して書く、各々の設計の要素を特定して、その要素を捕獲するためにストーリーカードをカードを書くことによって。
A user story should provide value to the user ;
ユーザーストーリーは、価値をユーザーに提供しなければなりません;
if several functions work together to provide desired user behavior , they may grouped into a single user story .
いくつかの機能がユーザーに対する理想的なふるまいを提供するために連携するならば、彼らはシングルユーザーストーリーに集めかもしれません。
User stories are written from the users point of view to emphasize the value that the card will deliver .
ユーザーストーリーは、カードが届ける価値を強調するために、ユーザーの観点から書かれ ます。
Take the example user story , "As a network monitor , I want to see a warning when a communications line reaches 90 % of capacity , so I can prevent network outages or slowdowns . "
ユーザーストーリーの例 ”ネットワークモニターのように、通信回路の能力が90%に達するときに私は警告を見たいので、私はネットワーク停止期間または減速を防ぐことができます。”
This specifies the feature , ties it to value , and specifies which users will be supported by the card .
これは特徴を指定して、それを価値に結んで、どのユーザーがカードで支えられるかについて指定します。
It does not specify every detail :
それが、すべての詳細を指定するというわけではありません ：
how the warning is to be delivered , whether the warning will be delivered no matter what the user is currently doing , or how to show the warning so users have enough context to interpret it immediately .
警告が届けられる方法、警告がユーザーが現在何をしているかと関係なく届けられるかどうか、またはユーザーがすぐにそれを解釈出来るように、警告を示す方法。
- 6段落目(Additional story cards...の直前)まで
The level of detail written ...
カードに書かれる詳細の度合いは、UXデザイナーの信頼の度合いに依存する。
The number 90%, for example ...
90%という数字、たとえばユーザとのイテレーションに基づいて、デザイナーの信念を指し示す。その90％は適切な出発点である。
If they were less ...
もし、信頼や明確な知識が足りないなら、あとからカスタマーの仕事を付け足すことが決めれるよに、彼らは明確な出発点から出発するだろう。
Either way, inquiries ...
一度このカードが実装するために選ばれたら、ユーザとテストする人、尋ねる人の両方が、出発点を変えるだろう。
Story card are intended to ...
ストーリーカードは実際的なユーザ価値を提供するつもりである。また、ひとつのスプリントで全体を実装するつもりである。
This means that complex function ...
これは複雑な機能がいくつかのストーリーに分割されることを意味する。なぜなら、それぞれはひとつのスプリントにフィットさせるのに十分小さい。
This is to be expected.
これは期待される。
It may well be ...
ひとつのカードに具体的に示された機能の一部はユーザを満足させられないであろう。しかし、それは完全で自身によって実装可能なものであるべきである。
Returning to our example, ...
私たちの例に戻ると、初期のストーリーカードは実装されなければならない警告しか明細に述べないざろう。
The implementation team would ...
実装チームはそれを可能なかぎり、最もシンプルな、基礎的で機械的なやり方で、実装することを期待するだろう。しかしユーザーはプレゼンテーション（別訳：提案・提示）にはまったく努力を費やさない。
The team might ...
そのチームはひとつの簡単なアラートボックスを実装するでしょう。
（Additional story cards ...）
追加のストーリーカードは、機能を完全なものにするために書かれるだろう。
（One might specify ...）
その機能のひとつは、ネットワークマップを表すための視覚的アイコンを明示する。
（Another might specify ...）
もう一つの機能は、マウスのポインタをアイコンに合わせる（hovering）ことで追加の詳細を明らかにする。
（Another, that clicking ...）
さらにもう一つ、そのアイコンをクリックすると、トラブルに対応するためのツールが現れる。
（Another, that when ...）
加えてもう一つ、ネットワークマップが見えない時、ペイン（ウィンドウの一区画）をスライドさせることで、スクリーンので右下の角でフェードインや、その瞬間の後でフェードアウトさせることが出来る。
（Each story is separately ...）
それぞれのストーリーは別々に実装出来、別々に試験することが出来る。（しかし、その全ては最初に実装された初期のストーリーに依存する）
（Implementation teams new ...）
アジャイル開発に慣れていない実装のためのチームは、この試みが厄介なものであると思うかもしれない。
（It requires that ...）
それは、いくつかのスプリントを超えた数回の同じ機能と同じセクションに彼らが立ち戻ることを要求している。
（This runs counter ...）
これは、伝統的な開発の訓練のためにカウンターを起動させる。
（Traditionally, developers would ...）
伝統的に、開発者は全ての関連する機能を一度に実装したがり、創り出し、獲得し、そのモジュールを公開し、そして開発において後で立ち戻る必要はない。
（The upside of the ...）
実装のためのアジャイルアプローチの上部は、柔軟性と予測性である。
（Each story is ...）
それぞれのストーリーは信頼して見積もられるほど十分小さい。すなわち、もしその見積もりがありそうもないなら、そのストーリーが小さいので、数週間や数カ月ではなく、数時間か数日で休みになってしまうだろう。
（And it allows ...）
そしてそれは、チームが進路を変えることを可能にする。
（For example, if ...）
例えば、もし一度に任せきりであるネットワークマップを好むユーザーを一度に実装されて作り出すのなら、分割されたペインにおける警告の表示に関するストーリーは、その全てが実装される必要はないだろう。
（The time this ...）
このストーリーが実装するために使用されるであろう時間は、その他より重要であるストーリーに割り当てることが出来る。
5.2.2
5.2.2 estimating cost
コストを見積もる
As story cards are …..
ストーリーカードに書かれているように、チームはそれらを実装するためのコストを見積もる。
This may be done …..
これは、“理想的なプログラマー日”で行うことができる。プログラマーの日数は彼らが中断していない時とこのタスクのみに集中している時に行うことが出来る
This is a useful …..
これは、新しいチームがストーリーの推定を開始する時に便利な方法です。
By referring back to ….
実際の（理想的な）時間に戻って参照することにより、チームは番号を割り当てるための｢概念的な枠組みを持っています。
But experienced teams …..
しかし、経験があるチームは“ポイント”をストーリに割り当てるのがより便利であることを発見します。
A point has no unit, …..
ポイントはユニットを持たず、現実世界を参照しない。
But a story estimated …
しかし、４ポイントで推定されたストーリは８ポイントのストーリに必要な時間の半分の長さで実装することが出来る。そして、それは２ポイントのストーリの２倍かかるでしょう。
An experienced team …..
経験豊富なチームは新しいものを見て、それらが過去にした仕事とそれを比べることによってそれを得られるように、十分なストーリを実装し、実行しました。（おかしいかも）
Again, this ….
繰り返しになるが、これは古い開発の視点からは奇妙に思える。
It works in ….
それは、アジャイルチームで動作します。何故なら彼らは速度の面で進捗状況を測定するためです。：チームのストーリポイントの数は単一のスプリントで実装することが出来ます。
That number is ….
ナンバーはスプリントからスプリントへトラックされ、チームは次のラウンドでは変更されないことを前提としています。
The team commits to ….
チームは反復内の特定の記事を実装するためにコミットします。そして、それらのストーリのためのポイントはその速度以上に追加され、チームは全てのストーリを完了させることが出来ると合理的に確信している場合がある。（おかしいです）
A brand new team, …..
真新しいチームはもちろん、速度が先へ進む測定方法を持たない。
For such a team, …
そのようなチームは、最初の数回の反復のための理想的なプログラマ日によって推定されたものは彼らは相当な数が思いつくのに自分たちの勘を使用してしまう。
Velocity can be ….
速度は反復の中の全プログラマー日が利用することによって最初に推定される。そして、ミーティングとオーバーヘッドのための通常の方法で縮小される。
After a few iterations, …..
数回の繰り返しの後、チームの測定速度は引き継ぐことが出来ます。
UX designers should ….
UXの設計者はUI設計の実装コストを議論するための準備をする必要がある。
Remember that ….
コストは終わっていないストーリーの全ての仕事を含み、UXチームによって行われている作業を含むことに注意してください。
So a story card ….
それで、大規模なUXの作業を必要とするUIの複雑な部分を参照するストーリーカードは実装コストにその仕事を分解することが必要です。
5.2.3
- 4段落目(The release is...の直前)まで
Once stories are...
一度ストーリーが書かれて見積もられると、それらはスプリント内で組織される。
Each sprint needs to...
毎スプリントはいくつかの可能性のある矛盾した方法で意味を成す必要がある。
It should be...
それは実装可能であるべきで、それは、ほかのストーリーが必要な、あるいは基礎となるモジュールを実装するかどうかを意味し、彼らはそれを最初に計画するべきである。
Each sprint should...
毎スプリントはユーザーテストをサポートするべきであり、それはまとまったUIを提供する。
Risky stories depending...
リスクのあるストーリーは、早期に実装されるべき未知の、あるいはトリッキーなテクノロジーに依存するので、リスクは出来るだけ早期に排除、あるいは軽減されるべきである。
High-priority stories...
高優先度のストーリー、カスタマーおよびステークホルダーにとって重要なそれは早めに実装されるべきである。
In addition, of cource...
加えて、もちろん、毎スプリントの合計ストーリーポイントは能力よりも下回ってないといけない。
In fact, the team...
実際、チームはスプリント1に続くスプリント、あるいは定期的な「プログラマーの休日」の中で20％あるいはそれ以上の中のバッファを認めるべきである。
There will be bugs to fix;...
それらは直さないといけないバグになるであろう。つまり、ユーザーフィードバック中の応答中でやるべき修正になるであろう。
If this time is not...
もしこの時間が最初から計画されたものでなければ、プロセスの後の段階で混沌としだすだろう。
Either there will...
これらは、開発ストリーム中で組み込まれたやり直しのための毎スプリントでの大規模な再度の優先順位づけが必要になるか、やり直しが延期されたり(技術的責務は増える)、残業しないといけなくなるだろう。
It is often...
それはいつも、組織のテーマを持つためのスプリントには便利である。そのスプリントは、ベアボーンのUIと一緒にすべてのモニタリングを実装するかもしれないし、システムを通してリモートアクセスを提供するかもしれない。
The first two...
最初の2スプリントは、選択された正確なストーリーと一緒に注意して計画しないといけない。
The following sprints...
続くスプリントはラフに組織してもいい。
Careful planning of...
全体のリリースの注意深い計画は、一般的に逆効果となる、というのも、スプリントが始まったよりあとのほうになる前にかなりたくさん変更される可能性があるからである。
Therefore, once users...
それゆえ、一度ユーザーが初期のベースレベルを体験すると、続くストーリーの優先順位は変更される可能性がある。そして、ビジネスは方向が変わり、優先順位を調整したり納期を変更したりする。そして、チームの能力は変わってしまう。
The release is a trade-off between function and date. Each sprint takes a fixed, known time; the velocity is known or estimated and determines the number of story points in each sprint.
リリースは機能と日数のトレードオフです。各スプリントは一定の既知の時間がかかります。つまり、速度は既知または推定されていて、各スプリントのストーリーポイントの数を決定するということです。
Therefore, the team can calculate how many sprints will be needed to deliver the critical function for the release.
そのため、チームはリリースの重要な機能を提供するためにどれだけのスプリントが必要とされるかを計算することが出来ます。
That sets the release date.
これにより、リリース日を設定します。
UX designers should be prepared to argue for features to include in the release to support users' work practice.
UXデザイナーは、ユーザーのワークプラクティスをサポートするためのリリースに含める特徴について議論をする準備をするべきです。
The business and marketing people may have requirements for what must be in the release for business reasons, and those are legitimate considerations.
ビジネスやマーケティングの人々は、ビジネス上の理由によりリリースに含めなければならない要件を持っていて、それらは理にかなった考慮事項かもしれません。
But it is the UX designers (and any other team members who gathered data with them) who understand the real impact of the proposed system on the end-users.
しかし、それはエンドユーザーに提案するシステムの実質的な影響を理解しているUXデザイナー（及び彼らと主にデータを集めたほかのチームメンバー）です。
The release date can be adjusted by moving stories between releases; where a function has been split across stories, the stories that make the function more elaborate might be moved out of the release altogether to make room for more important stories.
リリース日はリリース間でストーリーを動かすことにより調整することが出来ます。つまり、ここで機能はストーリーに分割されていて、機能をより精巧にするストーリーはより需要なストーリーを確保するために、完全にリリースの外に移動される可能性があります。
What must not happen is to jam more stories into the sprints.
起きてはならないことは、スプリントにストーリーを詰め込みすぎることです。
This is a hard discipline for newly agile organizations.
これは新しいアジャイル組織にとって厳しい訓練法です。
The traditional dynamic often has management pushing developers to “do more,” insisting on an unrealistic delivery date for business reasons.
伝統的な動力は多くの場合ビジネス上の理由により非現実的な納期を主張し開発者に「もっと働け」と仕事を押し付けるマネジメントを持っていました。
The agile tools help reveal that this is planning that creates chaos: it is planning for the team to execute at a speed the team knows and can demonstrate it cannot achieve.
アジャイルのツールはこれがカオスを創りだすプランニングだと明らかにする手助けになります。これはチームが知っているスピードで実行し、それが実行できないことを示すためのプランニングです。
This release plan should not be taken as cast in stone.
このリリースプランは確固な計画として受け入れられるべきではありません。
It shows how the team can deliver certain functionality by a certain date, but it is expected that as the team learns more about its users and as users learn more about how the new system will affect their work, the plan will change.
それはチームが特定の日付に特定の機能を提供する方法を示していますが、チームがユーザーについてより深く学び、ユーザーは新しいシステムが彼らの仕事についてどのように影響を与えるかを学ぶに連れて計画が変更されるよう期待されています。
Each sprint planning session may change story priorities, rewrite stories, and introduce new stories.
各スプリントのプランニングセッションでは、ストーリーの優先順位が変更されたり、ストーリーが書きなおされたり、新しいストーリーが追加されるかもしれません。
This is expected, and one of the reasons agile teams delivers useful results.
これは期待され、アジャイルチームが有用な結果を提供できる理由の一つとなっています。
If any stories are critical to the business for external reasons, it is up to the team to know and represent those constraints.
もし外的な理由によりビジネス上不可欠なストーリーがある場合は、チームはそのことを知り、それらの制約を明らかにしておくべきです。
The team is in close contact with its users via continual testing and feedback.
チームは継続的なテストとフィードバックを介して、ユーザーと密接に接触しています。
Any adjustments the team makes along the way should meet user needs more precisely.
チームが行う調整のいくつかは、ユーザーとより正確に連絡を取って行われるべきです。
On the other hand, management may have made commitments to important customers.
一方、マネジメントは重要顧客と約束をしているかもしれません。
Product marketing may feel that the product must have a certain feature to compete in the marketplace, whether or not that feature is actually useful. (This happens more often than you might think.)
プロダクトマーケティングはそれが実際に有用であるかどうかに関わらず、製品は市場で競争するためにある特徴を持つべきだと感じているかもしれません。（これはあなたが思っているよりも頻繁に起こります。）
Or other parts of the organization-manufacturing, or training-might be gearing up in parallel, expecting and depending on certain features to be present.
もしくは、製造部門や研修部門のような組織の他のパートは、ある機能を期待しそれに依存するのと並行して準備を進めているかもしれません、
Such commitments to stakeholders other than the end-user must be understood by the team, so they can be honored.
このようなエンドユーザーを除いたステークホルダーとの約束は、チームによって理解されているべきであり、そうすればうまくいくでしょう。
5.3
With the release plan in place , agile development proceeds in aseries of sprints.
代わりにリリースプランでは、アジャイル開発ではスプリントの系列として進められる。
Each sprint implements a set of user stories.
どのスプリントでもユーザの要求の設定を実装する。
Where these stories define user interaction , the visual design has not yet been done -
rough wireframes and paper prototypes are enough to test the concept.
それらの要求ではユーザの相互作用として決められ、視覚的なデザインはまだ行われていない。
大まかなワイヤーフレームとペーパープロトタイプは概念のテストには十分である。
Any further design is put off until needed.
いくつかの更なるデザインは必要とされるまで延期される。
To give the UX designers time to develop final UIs and test time with users ,
the best practice is to work one sprint ahead of developers and test one sprint behind.
UXデザイナーには最終的なUIの開発と彼らとユーザが一緒にテストをする時間が与えられる。
その最も良い例があるスプリントが先に開発者を働かせ、他のあるスプリントでは後ろでテストをするというものだ。
So in sprint 1 , the UI people develop and test the final screen appearance for a user story;
in sprint 2, they work with development to implement it; and in sprint 3,
they test the implementation to ensure nothing was lost in the translation.
なので、スプリントの１では、UIの人々はユーザの要求による最終的な画面の開発とテストが行われ、
スプリントの２では実装するための開発をするために働き、そして、
スプリントの３では実装されたものに翻訳の中で失われたものがないことを確認するテストを行う。
The first sprint may be treated specially.
最初のスプリントはたぶん特別に扱われるだろう。
Often , there is a fair amount of work necessary to get the team up to speed.
しばしば、チームのスピードを上げるために必要な公平な仕事の量があるだろう。
On the implementation side , such activities include defining the development practices,
putting together an automated build and test mechanism ,
and deciding on and implementing a source code control system.
実装のサイドでは、そのようなアクティビティには開発プラクティスを決めることや
自動化されたビルドとテストメカニズムをまとめること
そして、ソースコードの決定をすることと実装することが含まれているとしている。
On the UX side there are detailed interaction designs and final visual designs to
work out and test for the initial user stories.
UXのサイドでは、デザインの相互作用の詳細や提出される最終的なデザインや初期の
ユーザの要求テストがアクティビティに含まれているとされている。
↓以下訳注意↓
So , the first sprint may not deliver actual user value ,
but it may put all the building blocks in place for the project.
だから、最初のスプリントは実際のユーザが求めるものを引き渡すことはできないだろう。
しかし、これはたぶんそのプロジェクトの場所にあるビルディングブロックをおくだろう。
This is especially important for a new team
that has to set up its tools and procedures for the first name.
それは、新しいチームがそれ自身のツールや手順をセットアップするのに必要であるため特に重要である。
It is also important for the UX team , who need to provide detailed visual designs
to developers before the developers start cording.
開発者がコーディングを始める前に開発者に外観のデザインの詳細を提供する必要があるUXのチームにもまた重要である。
5.3.1
The team meets to...
チームは、スプリントの作業の計画を立てるために顔を合わせる。
This starts with...
これは、リリース計画の間に識別されたストーリーをセットすることから始まる。しかし、これは、プランが意味を成し続けるかどうかを考えるための時間である。
Do these stories...
それらのストーリーは、最も重要で、便利で、リスキーな、行わなければいけないことの残りのストーリーのセットの隣りあわせを反映しますか？
Is there other...
いつプロジェクトが始まったか測れない、計画されなければならないほかの仕事は存在しますか？
In that case...
そのケースでは、ストーリーは描かれ、見積もられ、スケジュールで優先される必要がある。
Is there rework to do...
ユーザーフィードバックに基づいたやり直さないといけない箇所、あらゆる直さないといけないバグや実装しないといけない再デザインはありますか？Then stories need to...
その時ストーリーは書かれ、スケジュール内で優先順位をつけられる必要がある。
The specific stories for the current and...
現在および次のスプリントのための特定のストーリーは定義される必要がある。
Then most teams...
その時ほとんどのチームが現在の実装内での毎ストーリーのためにタスクカードを書くだろう。It is a...
それは、タスクカードを実装するためのものでもない限り誰も作業しない委任のための、便利な規律である。
(And task cards... )
(そして、タスクカードはユーザーストーリーを実装するためだけに作られる。だから、すべての作業は顧客へ価値を提供する)
Task cards can...
タスクカードは実装するタスクを表す、書いているコード、デザイン中のデータベースのように。
They can represent...
彼らは、UXタスクを、ユーザーテスト、紙のプロトタイプ、UIデザインと表す。
They can represent...
彼らは、タスクを、ドキュメントとQandAのようにチームのほかのメンバーによって実行されるためのものであると表すことができる。
The UX team...
UXのチームは、最終・現在・次のスプリントのストーリーのためのタスクカードが必要である。
Their task carsd...
これらの、UIデザインを指定した現在のストーリーでのタスクカードは、低レベルのレイアウトを行うことと、ストーリーをコーディングを始める前に開発者をサポートするビジュアルデザインである。(？)
But the UX team...
しかし、UXチームはまた、次のスプリントを見通す必要がある。
They write task...
彼らはこれらのストーリーでUIデザインを始めるためにタスクカードを書き、(ここから怪しい)そのストーリーは、ビジョン、ストーリーボード、UEDからの高レベルをとり、最終的なレイアウトをデザインし、このUIを見ることである。
If several paper
もしいくつかの紙のプロトタイプの周辺がフェーズ0で行われていたなら、彼らは直接完了したUIをデザインし、テストしたかもしれない。さもなくば、彼らは最初に紙のプロトタイプの1～2個のラウンドが必要かもしれない。
These designs are tested with...
これらのデザインは、次の実装のための現在のスプリントの間にユーザーとともにテストされる。
And the UX team...
そして、UXチームはまた、最後のスプリントで完全になった仕事のためのタスクを書く。(... ,to以下)最後に人々のための作業を正確に実装することを確実にするために作業中のコードを受け取り、ユーザーと一緒にテストする。
5.3.2
5.3.2 WORKING WITH DEVELOPMENT
開発とともに行われる仕事
During the sprint, developers ...
スプリントの間、開発者はストーリーを実装する間。
The UX team has three jobs ...
UXチームは、３つの種類のカードを反映した、並行した３つの仕事を持っている。
First, they support ...
１つめは、開発者のサポートである。
They provide detailed ...
彼らは詳細なUIデザインを与えたり、詳細なふるまいやロックについて開発者と相談したりする。
Remember, in an agile team, ...
あるアジャイルチームについて思い出すと、それらの相談は実際の決定事項が作られたり、詳細な振る舞いが話し合われた。
There is no functional ...
そこにはの機能的な詳細の記述はない。：UXデザイナーはスプリント期間中、正確に言うなら彼らの望む間、開発者と共に働く。
It is up to the UX people ...
それはUXに関わる人々を、開発チームとしてより結束させ、ガイダンスや質疑応答を近づくことによって行うようにさせる。
Daily discussions between ...
毎日の開発者とUXデザイナーとの協議は、いつものことである。
The UX team also ...
UXチームもまたイテレーションの期間中、実際のユーザーのフィードバックを開発プロセスに持ち帰るために、カスタマー訪問に駆けつける。
These visits accomplish ...
これらの訪問は、以前のイテレーションで作られたものと、次のスプリントで完成される仕事の低いレベルのデザインと、のテストをする、２つの目的を成し遂げる。
The team dose this ...
チームはこの仕事を、CI（contextual inquiry 前回の訳：文脈上の質問？）や文書のプロトタイプ（paper prototyping 紙の模範？）とを併せて、カスタマーのインタビューに駆けつけることによって終わらせる。
最終更新：2011年06月10日 14:24
