アジャイルソフトウェア要求を読んで_rev2

以前の5章までの続きです。

ポイント

1. 受け入れてスティングの自動化はチームの開発速度低下を抑制する。
2. 受け入れ基準を大事にするUser Storyの開発スタイルは、よりリーンな考え方を組み込んでおり、生産スピードを向上させる。
3. より良いストーリーと、それに対する受け入れ基準・テストを用意できることが重要

 

第6章のユーザストーリーから。。。

 

User Storyは要求ではない

• 詳細な要求仕様なのではなく、議論していくことが可能な最小の表現
• 短く、読みやすく、開発者やユーザに理解可能なもの
• 数日〜数週間で対応の終わる、価値ある小さな機能
• 大量の文書ではなく、新たな情報により並び替え、組み替え、一覧として把握することができるもの
• Just in timeベースで詳細化され、はじめから詳細なものではない
• User Storyから素早く作られたコードがドキュメント生成の情報源となる
• 実装後に破棄することも可能
  • 実際の詳細な振る舞いは、回帰テストであったり受け入れテストとして残されていく

User Storyの形式

• Storyが、プロダクトオーナーに受け入れられるための一覧
• ＜役割＞として、私は＜活動＞を行うことができる。これにより、＜ビジネス価値＞がもたらされる。
• ＜役割＞は、活動を行う人、それらの活動から価値を受ける人をさす。他システムの場合もある。
  • ＜活動＞は、システムにより行われる動作。
  • ＜ビジネス価値＞は、その活動によって達成される価値を表す。

ユーザストーリーの受け入れ基準

• ユーザストーリに対する受け入れ基準は機能テスト/単体テストの話ではなく、システムが満たすべき条件。※例に関しては本書を参考に。。。

良いユーザストーリー

以下のINVESTを満足するほうが良いユーザーストーリーといわれる。

• Independent: the stories can be delivered in any order
• Negotiable: the details of what’s in the story are co-created by the programmers and customer during development.
• Valuable: the functionality is seen as valuable by the customers or users of the software.
• Estimable: the programmers can come up with a reasonable estimate for building the story
• Small: stories should be built in a small amount of time, usually a matter of person-days. Certainly you should be able to build several stories within one iteration.
• Testable: you should be able to write tests to verify the software for this story works correctly.

Independent
個々のストーリーは独立しており、別のストーリーが異なるストーリーと依存関係が無い方が望ましい。※開発単位になるので、これはそうですね。

Valuable
チームが直面する典型的な課題は、価値を効果的に納品できるような小さなインクリメンタルなユーザストーリーを書く方法の取得、といわれるそうな。これは、以下の図のように技術的レイヤで作ることをやめ、縦型の横断的な単位で実装まで行わなければいけないというパラダイムに出会うから。

Small
小さなストーリーに落とし込んでいくことは、複雑さを減らすことにある。
テスティングを考えたことがある人であれば直感的に分かるかもしれないが、機能の検証に必要となるテストの組み合わせは機能自身の複雑さに対して指数関数的に増大する。

Testable
テストできないストーリーであれば、それは開発の対象に入れてはだめ。なぜなら、検証できないものを”開発した”ということはできないから。
迅速に、管理する、良い、奇麗な、というような曖昧な言葉を書くことは容易いがテストは非常に難しい。ここを落とし込むのにはスキル（Software Testingの）が必要。

ユーザストーリーを分割する10のパターン

1. 特定のワークフローを達成するためにユーザが撮るステップを識別し、ワークフローをインクリメンタルな段階を踏んで実装する
2. ビジネスルールのバリエーションの複雑さを簡潔にするためにストーリーを分割する
3. 労力の大半をストーリーの分割にあてるかもしれない
4. 単純/複雑の程よい（テストできて、開発できる）所を見つける必要がある
5. データのバリエーションを作り、適度に具体的なストーリにすると良い
   1. ※Specification by exampleみたいですね
6. データ入力方法に応じて分割が必要なUIなどの単位で分けると良いかもしれない
7. システム品質（システム全体に対する検証）は知識を積んだりすることが必要になる。そのため、ストーリーを「〜性」単位に分割するのも良いかもしれない
8. 操作に関する箇所なんかは、一部後回しにして同類となるストーリーはまとめてテストすると良いかもしれない
9. ユースケース毎に細かく分割した方が良いかもしれない
10. 途中、対応中ストーリーが予想以上に大きいものである場合、その結果に基づいてストーリーをより分割すると良いだろう（※スパイク）

スパイク
ユーザストーリーや、その他のストーリーのリスクや不確実性を取り除くためのストーリーのこと。技術的なスパイクと機能的なスパイクがあり、技術的なスパイクは実装技術など、機能的なスパイクはUIのフィードバックにより改善されるような話題に分類される。スパイクも見積もり、デモ、受け入れ可能な形である必要がある。

システムの利害関係者の把握

ユーザーペルソナ

ペルソナを用意することで、システムをより実装可能な形に落とし込む。
主ペルソナ: システムが対象とする、一番満足させたいユーザ
副ペルドな: ユーザががんばれば利用、もしくは満足することができるユーザ

このペルソナは、先のユーザストーリの要素になりうる。システムに関係する利害関係者が主ペルソナ、副ペルソナに区分されることがおおいと思う。その中で、特定のストーリーが主/副ペルソナの両方に関係する場合、主ペルソナを優先的に考えるべきである、という判断に使う。ここで注意したいのはペルソナはでっち上げるものではない、ということ。ペルソナはユーザストーリーや要求発見をおこなっているときに、だんだんと具体化され、発見されることがおおい。

3人よりも多くの主ペルソナが考えられた場合、そのシステムは複雑になりすぎている可能性が高い。

AgileでもUX開発は非常に大事。そして、UX開発の改善の上でチームの開発が大きく左右されて振り回されないように考えないといけない。
※別途、ユーザビリティ開発の本であわせて理解したい。

Agileでは、スコープが進行状況により変化していくスタイルの開発となる。一方で、やはり物事は考えただけにはならないこともおおく、確約した作業自体が確実にできない場合も想定する必要がある。
しかし、その作業の間に培った期間の知識が増えた所に価値を置く。

タスク

XPやスクラムでは、ストーリーから落とし込まれるタスクに厳格な確約を持たせている。
タスクに重要とされる要素は以下。
※タスクのSMARTから。

• Specific
  • タスクに含まれているものを理解することができるこは大事。このタスクを組み合わせると、それに紐づくStoryがどのようになるかを判断できるようになることが必要。
• Measurable
  • 計測可能であり、これに完了をつけることができることは大事。例えば、「テストが含まれている」なんかが含まれていることが必要。
• Achievable
  • 達成できる難易度である。
• Relevant
  • すべてのタスクはStoryに貢献できるものである。
• Timebox
  • タスクは時間枠を課せられるべきである。これにより、タスクに時間がかかっている場合は他の人にタスクの一部を任せたりすることができるよになる。

目に見える大きな情報発信板で進捗を追跡する
– 未着手/進行中/完了/受け入れ済みのようなタスクボードを用意し、そこでタスク状況を判断できるべきである。

リトルの法則

著者の経験上、チームが速度を最もあげることができるのは、コーディング前にストーリー自身を理解すること、二つ目はユーザストーリーの大きさを減らすことである。

大事なこと

– より良いストーリーを書くこと
– ストーリーに対する受け入れ基準を書き示しておくこと

受け入れテスティングの大事さ

– Agileな開発では、ストーリー（要求）、実装（コード）、検証（受け入れテスト、単体テストなど）は独立した作業ではなく、より深い理解へと継続的に洗練させていくもの

– Agile Testingはドキュメントの依存度をより少なく、変化をより受け入れプロジェクトが品質に対して継続的に会話をするというテスティングスタイル

Agileな開発では、ストーリーの受け入れ基準を明確にすることに時間を使う。これは、この受け入れ基準が最終的なシステムの振る舞いへつながるためである。

リーン思考に則ると、受け入れ基準を先に明確にし、受け入れ試験を定義することはより生産性を向上させる。
※リーン自体、”検証したい仮説”が存在し、その計測方法を決めてBuildしていくため、その解釈の延長線上がこれ。

自動化された受け入れてスティングの例がFITアプローチ。有名なツールとしてFitNesseが存在する。
自動化できないものはチームのスピードを低下させる。そのため、自動化可能な形に落とし込む努力が必要。
※有用な具体例は本書を参照してください。。。

User Storyの記述、受け入れ試験の自動化がこれからプロジェクトに有用そう。特に、Webのようにアップデートが頻繁に行うことができない環境に対しては特に、”検証”の側面が大事かもしれない。

テストエンジニアとしては、検証する方法、開発物のどこできり、どのような確認を行い、どこで検証して世にモノをリリースするか、という流れを考える必要があるのかもしれない。