9
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

株式会社オープンストリームAdvent Calendar 2019

Day 21

脱:なんちゃってスクラム物語(プロダクトバックログ編)

Last updated at Posted at 2019-12-21

この記事は :christmas_tree:オープンストリーム Advent Calendar 2019:christmas_tree: の21日目の記事です。

0.登場人物

image.png父:ワシ
48歳 / 職業:システムエンジニア(20年)
ステータスimage.png

image.png息子:コタロウ
26歳 / 職業:システムエンジニア(2年)
ステータスimage.png

1.プロダクトバックログアイテムの粒度と完成の定義

image.pngコタロウ:
はぁ〜 父ちゃん、おはよう〜 メシ〜

image.pngワシ:
なんだ午前様か?

image.pngコタロウ:
そーなんだよ、またリリースしたばかりの機能でトラブル、

image.pngコタロウ:
前々回のスプリントから作ってるバックログアイテムもいつまでたっても終わらなくて踏んだり蹴ったりだよ

image.pngワシ:
(終わりってなんだ?完成のことか?)
トラブルって?

image.pngコタロウ:
ほかの人が作ったものは問題ないんだけど、
ある人(俺だけど)が作ったやつは必ずリリース後に障害がでるんだ・・・

image.pngワシ:
そうか・・・(おいおいテストしてるのか?先月も同じ事言ってたな、レトロスペティブやってないなコイツラのチーム・・・)
そのプロダクトバックログアイテムはどんなものなんだ?なんで完成にならないんだ?

レトロスペティブ(振り返り):イテレーションの終わりに行う改善プロセス

image.pngコタロウ:
えっと、
【<プレミアム会員>として、<プレミアム会員向けの素敵なキャンペーン商品を購入>したい、なぜなら<優越感を満喫したい>からだ】って言う、ユーザーストーリーなんだけど、
完成したから、スプリントレビューでプロダクトオーナーに見せたら、我々が求めている価値ある動くソフトウェアじゃないって言われた・・・

image.pngワシ:
(ちょっとまて、スプリントレビューで初見? てか、そのPBIデカすぎ・・・これエピック・・・何を作ればいいかチームみんな見解バラバラなんじゃないのか?)
(多分フィーチャーしか定義していないな・・・)
おいおい、チームでどうなったらプロダクトバックログアイテムが完成になる取り決めなんだ?

エピック:大きなユーザーストーリー、具体的に求められている要求が不明瞭なもの
フィーチャー:ソフトウェアの機能、特性や特徴、性能目標、見た目や使い勝手

image.pngコタロウ:
ユニットテストがOKだったら、
気合でアドホックテストをやって問題がなかったらリリース可能なソフトウェアの扱いにしてる

アドホックテスト:テスト仕様などは存在せず、場当たり的にソフトウェアを操作して不具合や不自然な挙動を発見しようとする肉体系テスト

image.pngワシ:
うゎ、アジリティ(敏捷性)低っく・・・
そもそもウォーターフォールでもアジャイルでもソフトウェアのVモデル(v-model)は存在するし、プロダクトバックログアイテムを構成する要素は【フィーチャー(要求される機能)】以外に【完成の定義】と【受入条件】は、必須
そしてイテレーション(スプリント)で開発するためにはエピック(大きなユーザーストーリー)をリファインメントで事前に小さな具体的なユーザーストーリに細分化(最小単位のプロダクトバックログアイテム)することが必要
これから説明するから耳の穴かっぽじってよく聞いとけよ

リファイメント:次のイテレーション(スプリント)に向けてエピックを具体化(詳細化)ること

1.1.ソフトウェアのVモデル(簡易版)

image.png

1.2.プロダクトバックログの構成要素

image.png

  • 受入条件:受け入れテスト仕様書(場合により機能/結合テスト仕様書)
  • 完成の定義の例(動くソフトウェアの場合)
    • 設計書のお客様レビューが実施されており、指摘事項の是正が完了合意していること
    • 単体テストが実装されてること(仕様通りに動いていること)
    • ログの方針に則った内容のログが出力されていること
    • 性能は取り決められた範囲内であること
    • セキュリティイドラインに沿った実装が行われていること
    • ソースコードの静的解析と単体テストがすべて問題がないこと
    • ソースレビューが実施され指摘事項を全て是正しいていること
    • テスト環境にデプロイされていること
    • テスト環境で、受け入れ条件をクリアしていること(変更対象の機能に関連する結合テストを含む)

1.3.プロダクトバックログの構造

image.png
PBI:プロダクトバックログアイテム

1.3.1.PBI:エピック/テーマ

動くソフトウェアが提供するサービス(人/他システムへ)
PBIの開発優先順位が低く要件が明確でない場合はエピックとして扱われる
優先度が上がり開発の必要性が増してきたら最小単位のユーザーストーリーを定義する。その状態になるとテーマとして扱う
テーマに属するう最小単位のユーザーストーリーが完成した場合、受け入れテストは結合テストレベルで実施する

例:受注機能

1.3.2.PBI:最小単位のユーザーストーリー

下の視点で親PBIを細分化したもの
もっとも多いのは、エンド・ツー・エンド(人もしくは他システムから処理の要求が発行され、コンピューターで処理が行われレスポンスが戻るまで)、システム境界線の利用者側(人もしくは他システム)の意味のあるテスト可能な粒度、リリース可能な最小単位
ソフトウェアの構築が完了した場合、機能テストを行う

例:テーマPBIは受注⇒初期表示、受注検索、商品検索、在庫引当、受注登録、受注更新、受注削除

下にそれ以外に作成指針を記します
image.png

image.pngコタロウ:
・・・なんとなく分かった気がするけど具体的にどうやってスプリントまわせばいいんだ?
って、遅刻!父ちゃん、行ってきま~す


明日は @anzoo さんです!

9
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
9
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?