『スクラムを活用したアジャイルなプロダクト管理』第3章のコメント・疑問
第3章 プロダクトバックログの使い方(P.45)
3.1 プロダクトバックログのDEEP特性(P.45)
P.45 DEEP特性は初耳かもですね・・・。(You&I)
Detailed appropriately
Estimated
Emergent
Prioritized
P.45 ScrumPrimerのVersion2.0ではDEEP特性が紹介されていました。 (You&I)
3.1.1 適切な詳細さ(P.46)
3.1.2 見積り(P.46)
3.1.3 創発的(P.47)
3.1.4 優先順位付け(P.47)
3.2 プロダクトバックログの手入れ(P.47)
P.47 「プロダクトバックログの手入れ」は幾つかの別な表現がありますね・・・。 (You&I)
バックログ グルーミング(backlog grooming)
プロダクトバックログ リファインメント(product backlog refinement)
プロダクトバックログの見直し
3.3 項目の発見と記述(P.49)
3.3.1 項目の発見(P.49)
P.50 「フィードバック」構築~計測~学習のフィードバックループが大事ですね。 (You&I)
3.3.2 項目の記述(P.51)
3.3.3 プロダクトバックログの構造化(P.51)
3.4 プロダクトバックログの優先順位付け(P.52)
P.53 「最後の可能な瞬間(last possible moment)」 意味不明な単語ですね。引用元のLean Software Developmentでは、最終責任時点(the last responsible moment)という言葉も出てきます。(You&I)
3.4.1 価値(P.53)
P.54 「より少ない~代替手段」改善マインドの話。(You&I)
3.4.2 知識・不確実性・リスク(P.54)
P.55 「リスクは、スクラムチームの作業場所、もしくは設置されていないビルドプロセスを含むインフラや環境に潜んでいる場合もあります。」 設置されていないビルドプロセスとは?訳がおかしい。(You&I)
P.55 「早く失敗」アジャイル開発は早期に失敗を経験する為の仕組みになっている。開発の終盤で失敗するのはとてもコストがかかるので。(You&I)
3.4.3 リリースの実現可能性(P.55)
P.56 「初期リリースは、部分的な実装で十分」 最近ではインターネットがあるので、これが成り立ちますね。(You&I)
3.4.4 依存関係(P.56)
P.56 「ユーザーストーリーをまとめる」 細かくしようと考えてしまって、なかなかまとめるという思考にならないですね。(You&I)
3.5 スプリント計画の準備(P.57)
P.57 「スプリントゴール」 必ず決めるものではないようです。(You&I)
3.5.1 スプリントゴールの選定(P.57)
3.5.2 適切な量の項目を適切なタイミングで準備する(P.58)
3.5.3 項目の分割(P.59)
P.61 「ケーキのスライス(slicing the cake)」 機能縦断的に分けると言う事ですね。(You&I)
3.5.4 明確性、テスト可能性、実現可能性を保証する(P.61)
P.62 「使い捨ての試作品」 プロトタイピングでは通常作ったものは破棄しますね。スパイクで作ったものも同様かなと。(You&I)
3.6 項目の規模の把握(P.62)
3.6.1 ユーザーストーリーポイント(P.63)
P.63 「基準ポイント」 基準と小さい基準、大きい基準の三角測量の容量で見積もります。(You&I)
3.6.2 プランニングポーカー(P.64)
P.65 「POとSMは見積もってはいけない」 見積もるのは開発チームのみ。POも見積もるイメージでした。(You&I)
3.7 非機能要件への対応(P.66)
3.7.1 非機能要求の説明(P.66)
3.7.1 非機能要求の管理(P.67)
3.8 プロダクトバックログのスケーリング(P.68)
3.8.1 1つのプロダクトバックログの活用(P.68)
3.8.2 プロダクトバックログの手入れの拡大(P.69)
3.8.3 別のプロダクトバックログのビューの提供(P.69)
P.69 「バックログのビュー」 ビューって何でしょうね?あまり説明がありませんが。(You&I)
3.9 よくある間違い(P.70)
3.9.1 偽装した要求仕様(P.70)
3.9.2 サンタへの要望リスト(P.70)
3.9.3 チームへの要件の強要(P.71)
3.9.4 プロダクトバックログの手入れの放置(P.71)
3.9.5 複数のプロダクトバックログの競合(P.72)
3.10 おわりに(P.72)