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

13章以降の、第三部に属する箇所に関していくつか記載。

 

13章

従来のソフトウェア開発では、Product Requirement DocumentやSoftware Requirement Documentなどの要求仕様書を用意し、開発を行っていた。これらのドキュメントは重く、リーンな開発では特に、小さく始める、Just In Time、動くものをより素早くというところがあり従来のように重たいドキュメントは歓迎されない。また、リーンソフトウェア開発の原則にある「決定を送らせる」ことを実現するには、やはり従来のように重たいドキュメントは歓迎されない。

一方、AgileやLEANではビジョンを伝え、共有することが必須である。そのため、それらの共有に力を入れる。これは以下のような問いに対する回答であり、一般的に5〜10ページ程度の文章となる。

  • このシステムはなぜ構築しているのか?
  • これがどのような問題を解決するか?
  • どのフィーチャーと恩恵(価値)を提供するか?
  • 誰に対してフィーチャーと恩恵(価値)を提供するか?
  • どのような性能/信頼性/スケーラビリティで提供しないといけないか?
  • プラットフォームなどのサポートは?

ひな形は本書の付録にあるので、そちらを参考に。

フィーチャー

  • 1人以上の利害関係者のニーズを満たすことができるようにシステムが提供するサービス

フィーチャーは以下のようなビラミッド型で表現される。通常、複雑なシステムでも25~50個以内のフィーチャーで表現される。
要求ピラミッド
※from http://scalingsoftwareagilityblog.com/agile-requirements-information-model-4-for-agile-programs-a-features-and-feature-backlog/

フィーチャーは、User Storyのようにユーザの声形式でまとめていく。

フィーチャーのテスト

フィーチャーテストは、アジャイルテストの4象限において第2象限に区分される。そして、それらは自動化されることが望ましい。

 

見積もり

ユーザ価値、時間値、リスク軽減値を見積もる必要がある

  • ユーザ価値: ユーザからみた、フィーチャーの潜在的な価値。何らかのフィーチャーと比較した相対価値で十分。
  • 時間値: ユーザ価値が時間経過とともにどのように減少するかに基づく相対見積もり。フィーチャーが一般化すると価値が低くみられるようになる、というもの。
  • リスク軽減値: 常にソフトウェアは研究と開発を行っている。そのため、我々はリスクをとって新しい挑戦が必要な機会を得るが、それも見積もる必要がある。

※狩野モデル
kano-model

 

ロードマップ

  • ビジョン、フィーチャーに沿って優先順位を決め、順に解決していく必要がある

 

第14章

プロダクト管理者の知識体系

  • ライフサイクル
    • 発見フェーズ
    • 開発フェーズ
    • 商業化フェーズ
  • 知識領域
    • 顧客と市場調査
    • 技術と知的資産
    • 戦略、計画、意思決定
    • 人々、チーム、文化
    • プロセス、実行、メトリクス

ビジネス上の責務に関しては、BABoKが6つの知識体系と8つの土台を定義している。
以下は6つの知識体系。詳しくはBABoKを読んでください。※結構面白いですよ

  • ビジネス分析の計画とモニタリング
  • 抽出
  • 要求管理とコミュニケーション
  • 企業分析
  • 要求分析
  • ソリューションの評価と妥当性確認

 

ビジョンとリリースに責任を持つ

ビジョンは堅苦しいものである必要はなく、フィーチャーに対する優先付けを理解する程度で十分。ただし、非機能要求に関してもビジョンの一部として認識、伝えなければいけない。

リリース内容の管理

継続的で頻度の高い小さなリリースを進める。また、その為に複数のサブシステムを開発するチームがアジャイルリリース列車モデルで開発を進めることが大事。
リリースのマイルストーンに何を入れるか等、権限を持つものが上手くコントロールする必要がある。

 

15章

アジャイルリリース列車は、プログラムレベルのリズムと同期を提供することで、足並みを揃えリスクを管理する。この列車の運用原則の一部は以下。

  • 頻繁で定期的な計画とリリース
  • 継続的なシステムインテグレーションが、フィーチャー、コンポーネントのみならずシステムレベルでも実装されている
  • リリースレベルの妥当性検証とテスティングのための時間を提供するためにシステムレベルの硬化反復を用いる。

プロダクト開発フローの制度化

  • 経済的な視点をもつ
  • 待ち行列の管理を積極的に
  • ばらつきを理解して利用する
  • バッチサイズを減らす
  • WIP制約を適用する
  • 不確定性の下の制御フロー
  • 可能な限り早くフィードバックを得る
  • 制御を分散する

AgileReleaseTrainAgile列車

リスクと障害に対応していくことはやはり大事。
Resolve/Owned/Accepted/Mitigatedのそれぞれでリスクや障害に対して状態を持たせて認識させていく。

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
 —Tom Cargill, Bell Labs

非機能要求

ソフトウェア開発の有名な言葉に90対90の法則がある。これは、90%の開発は全体の10%で終えるが、残る10%で全体の90%の開発時間を使う、というの。
その1つが非機能要求に対する内容。

非機能要求に関しても、ユーザの声形式で表現していく。
例:
非機能要求:すべてのメッセージは1分間以内に表示されなければならない
ユーザストーリー:顧客として、電力事業者のメッセージを1分以内に通知してほしい。それにより、私は適切な行動をとることができる。

他の具体的な非機能要求含む例は本誌をご参考ください。

いくつか重要視されやすいもの
– 使いやすさ
– 信頼性
– 性能
– 保守性

機能要件同様、非機能要件のUser Storyは終われば不要になる。テストが振る舞いを説明するための道具となるため。

ここでも、アジャイル4象限が使われるが、そこは省略。

すべての品質テストは何らかの非機能要求に関連し、システム品質テストにより最低1つの非機能要求を満たしていることを確認できるようになる。

ホワイトボックス/グレーボックス/ブラックボックス・・・

要求管理のツールはここでは省略。

ユースケース

ユースケースは必須ではないし、積極的に推奨されるわけではないが、理解を促進させるためなら使う。

なぜなら、ユーザストーリーとバックログ項目は、設計者に作業を着手する文脈を与えない。そこで、ユーザストーリーの拡張によりそれらを補完する。

ユースケース: アクターと、そのアクターにとって価値のある結果を生むようなアクターとシステム間のアクションの系列を記述する

そして、新たなユースケースがサブシステムに触れる度に、そのサブシステムに対して開発しなければいけないユーザストーリがおそらくある。

複雑さを管理するために発達した過去のツールを使わないことは愚かだ!!

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中