スクラム関連のメモ

プロダクトバックログ(成果物1)

創発的かつ順番に並べられたプロダクトの改善に必要なものの一覧

コミットメント

プロダクトゴール
将来の状態
長期的な目標

PBI(プロダクトバックログアイテム)の書き方

PBIはユーザーストーリーベースでよく書かれる
実現したい順に一列に並べる
- 順番はリファイメントやプランニングの際に見直す
下位にある時は詳細でないくても良い。
　-　次のスプリントでプランニングができるように詳細かをする必要がある
想定しうる全てのストーリーを書き出す
　-　到底期日に間に合わない分量でも良い(後からでも入れ替える余裕を持つ)

スプリントバックログ(成果物2)

構成

プリントゴール: なぜ
スプリント向けに選択されたPBI: 何をするのか
インクリメントを届けるための実行可能な計画: どのように

開発者による、開発者のための計画書

スプゴを達成するために開発者が行う作業がリアルタイムに反映
デイリースクラムで進捗で検査できる程度の詳細さが必要

スプリントバックログのコミットメント(確約)

スプリントゴール
- スプリントの唯一の目的
- 開発者が確約するもの
  - スプゴ達成のために必要な作業は開発者が柔軟に考えても良い
    -　スプリントゴールがあることで一貫性と集中を生み出し、スクラムを一致団結させる

スプリントバックログの書き方

スプリントで実現するPBIについて完成させる計画を立てる

PBIが主で具体的な方法論をタスク化していく。
PBIが細かい粒度だとPOが優先度を決める負荷が上がりエンジニアが仕分けてPOが雰囲気で確認する感じになる。

タスク分割をすることが多い
スプリント中に変更したり減ったりすることもある
1タスクは1日以内のサイズにすると良さそう

Tamtam 2023/06/24

インクリメント(成果物3)

プロダクトゴールに向けた具体的な踏み石
これまでの全てのインク面と+今回のスプリントのインクリメント
利用可能にする
- 犬種推して正しく動作することを保証
スプリントでは複数のインクリメントを作成可能

コミットメント

完了の定義(DoD)
- プロダクトの品質基準を満たすインクメントの状態を示した正式な記述
- PBIが完成の定義を満たした時にインクリメントが誕生する
  - 満たしていない場合
    - リリースできない

完了の定義の例

カバレッジ75%
受け入れテスト
ドキュメント
セキュリティ
性能

スクラムイベント

規定通りに運用しなければ、検査と適応ができない → これ大事
規則性を生む
スクラムで定義されていない会議の必要性を最小限に抑える
同じ時間と場所で開催されることが望ましい

スプリント

アイデアを価値に変える心臓の鼓動
1ヶ月以内の決まった長さ
進捗の見通しを立てる有用なプラクティスが存在する
スプリントゴールが役に立たなくなったときにスプリントは中止される
-　POが中止する権限を持つ

バーンダウンチャートを書く→ 残っている数。タスクが残っている遅れている。

スプリントのルール

スプリントのゴールを危険に晒すような変更はしない
品質を低下させない
プロダクトバックログに必要に応じてリファイメントする

スプリントレビュープランニング

POは参加者に対して最も重要なPBIとプロダクトゴールの関連性について話し合う
アドバイスを得るためにチーム以外の人をプランニングに巻き込むとかも可

プランニングのトピックス

なぜこのスプリントは価値があるのか

スプリントゴールを定義

スプリントで何ができるのか
　- POと話し合いPBIを選択しスプリントに含める
選択した作業をどのように成し遂げるのか
- PBIを一日以内の小さな作業アイテムに分解する

デイリースクラム

やること
　- スプゴに対する進捗の検査　など
開発者のための15分のイベント
POやSMはスプリントバックログのアイテムに積極的に取り組んでいる場合に開発者として参加
デイリースクラム以外でも計画は調整しても良い

スプリントレビュー

スプリントが1ヶ月の場合、タイムボックスは最大4時間
スプリントの成果を検査し、今後の適応を決定する
ステークホルダーに作業の結果を提示し、プロダクトゴールに対する進捗を話し合う
など
環境の変化を確認:

スプリントレトロスペクティブ

スプリントが1ヶ月タイムボックスは最大3時間
目的: 計画すること
個人、相互作用、プロセス、ツール、完成の定義に関して、今回のスプリントがどのように進んだかを検査
話し合うトピックス
- スプリント中に何が上手くいったのか
- どのような問題が発生したか
- どのように解決されたか解決されなかったのか
  など

イベントのタイムボックス(目安)

スプリント１週間
プランニング 2時間
デイリースクラム 15分
スプリントレビュー 1〜2時間
レトロスペクティブ 1時間

スクラムの原典

スクラムの原典を読み解く(1)

type-Cのチームの6つの共通点

1.不安定な状態を保つ

- 。ソフトウェア開発はプロジェクトの開始時にすべての要求を固定することができないという特性を持つ。だから、アジャイル開発では、要求を固定するよりも、人を中心にしたコミュニケーションと協働でプロジェクトを前に進める。

2.プロジェクトチームは自ら組織化する

- 自己組織化されたチームの状態には、(1)チームが自律しており、(2)常に自分たちの限界を越えようとし、(3)異種知識の交流が起こる、という特性がある。
    - 「スクラムマスター」はメンバーに指示を与えるのではなく、チームが自分たちで決定できる環境を支援するのが役割　→　自立性を尊重
    - チームは１つの部屋に集まることが基本

3.開発フェーズを重複させる

- 専門部隊の垣根を取り払って１つのチームとなる
    - 自己組織化されたチームは独自のリズムを作り出す。開発と製造では、もともとスケジュールの考え方が異なっているのに、それが一体となって全体のゴールを目指すことになる
- 情報をオープンに保つ仕組みも、アジャイル開発に積極的に取り入れられている
    - チームの状況はバーンダウンチャート、バックログ、タスクかんばん、等々によって顧客にまで透明に共有される。
    -

4.マルチ学習

- メンバーはグループ全体として学習し、さらに専門を超えて学習する。
    - アジャイル開発では、顧客の要望を「仕様書」という形ではなく、「ユーザーストーリ」という読みやすい形でカードに書き出す
        - これには、コミュニケーションを発生させる意図がある。詳細に書かれていないからこそ、そのカードを壁からはがして手にとり、それを持って顧客のところに行き、実際に質問をする。「カードは会話のチケット」でもある。詳細に書かれた仕様書という形態ではなく、実際に顧客と対面で会話をすることによって、要望についてのより深い理解を得るのだ。

5.柔らかなマネジメント(subtle management)

- ７つのポイント
    - 正しいメンバー
    - 専門を超えて対話が起こるような、オープンな仕事環境
    - エンジニア自身がフィールドに出て行きって聞くように仕向ける
    - 個人ではなくグループ評価を基本: チームに還元する
    - リズムの違いをマネジメントする
    - 失敗を自然なこととして受け入れる
    - サプライヤにも対しても、自己組織化を促す
        - 課題を提示してどのように解決するかは任せる
    - スクラムマスターの役割
       - 協調型のリーダーシップを取る。特に、2.のオープンな仕事環境づくり、5.リズムのマネジメント、などが仕事となるだろう。
       - 3.のフィールドへ出かける姿勢、6.の失敗に対する考え方は、アジャイルの価値観や原則の中で言及されている。
    -

6.学びを組織で共有する

- 過去の成功を組織に伝える、もしくは、捨て去る。
    - キーパースンを、次のプロジェクトに入れることによって、やり方を浸透させるのである。あるいは、プロジェクトのやり方を組織標準へと昇格させる

Tamtam 2023/06/26に更新

スクラムの三本柱

透明性
- 伝達する。オープンにする。やっていることを周りの人が理解する。
- 透明性のないの検査は誤解を招き、無駄になる
検査
- 頻繁かつ熱心に検査する
  → 問題を検知する。4つのイベントでリズムを提供
  
  スプリントプランニング
   デイリースクラム
   リファインメント(任意でこれはやらなくても良くなった)
  スプリントレビュー
   レトロスペクティブ
適応
- できるだけ早く調整
- 自己管理されていない時は適応が難しくなる

Tamtam 2023/07/08に更新

スクラムチームの特徴

機能横断型
- ステークホルダーのコラボ、検証、保守、運用実験、プロダクトに関して必要になり得る全ての活動に責任を持つ。
自己管理型
- 何が、何を、何時、どのように行うかはスクラムチームが決定する。

Tamtam 2023/07/01

タイムラインのハピネスレーダー

スプリントレトロスペクティブで話すべきこと

スプリントゴールをどの程度達成できたか
チームで改善したいこと
個人で改善したいこと

スプリントレトロスペクティブでスクラムマスターが考えること

スクラムマスターが、レトロスペクティブが意味のあるもの（メンバー全員が改善に向かうように意見を言えてエイルか）をか考える

改善点が出ない時: ハピネスレーダーなどの『思い出す」プラクティスを使う
改善点がありすぎる時: 一番大切そうなテーマを取り上げて議論する

Tamtam 2023/07/01に更新

チームの文化をベースに意思決定

エンジニア総動員してスプリントゴールタスクを終わらすようにコミットすることは良いこと?
-> チームの文化や共通認識による。

例えば、
総動員することで長期の生産性や収益性を下げる(スプゴのコミットメントを優先するとリソース効率性が下がる新規プロダクトのリリースが遅れる的な)のであればオーバーコミットメントしすぎかもしれない。
それであればコミットメントの緩みを考えるか、自己管理ができているのであれば、しょうがいない。スプリントでできる量を考える。制度をする。すぎなのであれば、考えている。コミットメントをする。

チームの文化をベースに考える

Tamtam 2023/07/01

ケーススタディ_何かしら調査し、新たに冗長性のためにサーバー構築のコストが発生した場合

PO: コストを受け入れるかを意思決定する
スクラムマスター: こすとをもとにぷロダクトバックログアイテム作る
開発者: コストの情報を作る

Tamtam 2023/07/01に更新

プロジェクト憲章(PMBOK)

ステークホルダ（利害関係者）に対してプロジェクトの存在を正式に認可してもらうことを目的

・プロジェクトの目的または妥当性
・プロジェクトの目標及び成功基準
・要求事項概要
・プロジェクト記述概要（プロジェクトの方針）
・リスクの概略
・要約マイルストーン、スケジュール
・要約予算（概要見積り）
・プロジェクト承認要件（実施承認の判断基準や担当者）
・プロジェクトマネージャ（責任と権限）
・プロジェクト・スポンサー（プロジェクトの最終責任者）

Tamtam 2023/07/01

デイリースクラムを複数会やる是非

教科書的にはデイリースクラムを２回行うのは聞かない。

分けても同じことを話す場合があるため、ムダが増えるようにおもえる。が、上手く回るチームもあると思うので、やっても良いとかもしれない。(それでも、時間は合わせて15分以内にするのが良いのが一般的な意見)

Tamtam 2023/07/01に更新

アイデア出しのサポート

プロダクトオーナー

プロダクトオーナの作業は委任するが、最終的な責任はプロダクトオーナーが持つ
プロダクトオーアナーはスプリントレビュー前にプロダクトバックログアイテムの完成を確認する
プロダクトオーナーは開発者と常に話ができる存在である

スクラム開発で推奨されている人数についての見解 (3〜10 人)

人が多いと
- コミュニケーションコストが増える O(N^2)
- 主体的に動かない人が出てくる
- 役割が分かれやすくなる
現在のスクラムガイド(通常は10人以下)
- 人数の指数関数的に難しくなる

アジャイルプラクティスガイドブックチームで成果を出すための開発技術の実践知

やらないことリスト

やること
やらないこと
あとでやること

インセプションデッキ

「ご近所さんを探せ」: 関係者が意外と多い
解決案を描く: 技術的な課題や解決策が実現手段として適切か確認する
- スコープにもなりえる
- リスクも考える
夜も眠れなくなるような問題
- リスクを明確化
- 課題についてチームで話し合う
俺たちのAチーム
- ミッションをやり遂げるためのチーム編成を考える
- スクラムチームであればスクラムの役割を入れる
  - プロダクトの特性に合わせて具体的に何を期待するのか書くと良い
期間を見極める
- 大体の期間を提示する
トレードオフスライダー
初回のリリースに必要なもの
作って終わりにしたい

ゴールを統一するためのインセプションデッキ

「我々が取り組んでいるのは、何かをこなせば成果が出るという簡単な物ではなく、正しい道を探りながら作らなくてはならない。そのために、無駄に見えるかもしれないですが、これらの点を抑えておくことが大事なのです

https://www.mobiusloop.com/

プラグラティック・ペルソナ

具体的な対象ユーザーを決める
何名か作っても良い
ターゲットと違ってきたら見直す

共感マップ(エンパシーマップ)

いきなりペルソナを作るのも大変なので前準備
順番に考えてみる
- 後から追加しても良い

Tamtam 2023/07/17

振り返り方法の取捨選択

ふりかえりの目的がちがうので、チームの問題点をみて、ふりかえりの方法を変える

KPT.. 最後にTRYを出すので、「何か行動する」のが大事な時に使う
+/ΔやFun Done Learn... 現状認識だけでその後の対応はお任せ。そのため、強制力を持たせるのではなく、共通認識を持たせるのに使う

Tamtam 2023/07/17

Output(生産高)よりもOutcome(成果)

プロダクトの成功には、成果にフォーカスすることが必要

Mobius Loop(メビウスの輪): (結果ではなく)成果に着目したFW

成果を仮説検証をしながら発見し続けていく

アジャイルでは素早い開発に優れていますが、チームの開発パフォーマンスを指標としているのもあり、間違えたものまで素早くリリースできてしまいます。Mobius Outcome Deliveryは、"What/How＝何を/どのように作るか？"だけでなく、"Why/Who＝なぜ/誰のために作るのか？"についてチームで見通せること、発見と提供のバランスをみながら検討できるのがメリットです。

Tamtam 2023/07/22に更新

作成物:プロダクトバックログ

一つ一つをプロダクトバックログアイテム(PBI)と呼ぶ
1スプリントで完成可能なサイズ
- 理想は最低でも3つぐらいのプロダクトバックログアイテムをスプリントで選択できるようにする
創発的かつ順番に並べられている
作業を行う開発者は、作業規模の評価に責任を持つ
上位になるほど詳細になる • 最初から全てを詳細化しない
すべてのプロダクトバックログアイテムをストーリー形式にする必要はない
- ログなどのシステム的な物、リファクタリングやバグ
- 最初からすべてのプロダクトバックログアイテムをストーリー形式で書く必要もない
  - 手段は後から考えてもよい

ストーリーの3C

カード (Card)
- ソフトウェアに望むことをインデックスカードに書く
- カードの初期バージョンは会話が始められるぐらいの最低限のものにする
会話 (Conversation)
- チームやステークホルダーが集まって、どのようなソフトウェアを作るか会話する • 言葉や絵を使って会話を促進する
- 会話中にストーリーの内容は変わったり、ストーリーは分割されたりする
- 「会話する約束」
確認 (Confirmation)
- 開発に入る前に、完成の定義やデモシナリオを決める • 合意した記録を残す

ユーザーストーリーは要求ではない

要求・要件=必ず実装しなければならないもの、ではなく交渉可能な意図の表現
- やって欲しいこと、やったらよいと思うこと、妄想
数日~数週間で開発可能な価値ある機能の小さなインクリメントを表す
比較的容易に見積もれるサイズ

ユーザーストーリーはINVESTにする

良いプロダクトバックログの定義とも言える

Independent (独立している)
- 一つのストーリーがそれだけで開発・テスト・潜在的な納品ができる
  - 単独で価値がある
  - 他のストーリーに依存しない(とはいえ依存性があるものは仕方がない。依存性を無くすためだけに依存する部分を切り取ってタスク化はユーザー価値に紐づかないためダメ)
- 順番の入れ替えが簡単にできるようになる
Negotiable (交渉できる)
- 常に変更する柔軟性を持たせる
- 完全に完了するまでは書き換え可能
- 会話の中でコスト(実装やテスト)と価値のトレードオフを調整
Valuable (価値がある)
- プロダクトのユーザー・顧客・ステークホルダーに実際の価値を提供できる(=何かしら使える状態になっている)
  - 一部の機能だけできていても価値提供やFBを得ることができないならだめ(曳光弾的に作ってFBもらえるようにするとか)
Estimable (見積もりができる)
- 1スプリントに納まるサイズにする
  - 1スプリントで複数プロダクトバックログアイテムが選択できる状態が望ましい
  - チームがストーリーを見積もれない場合は、ストーリーが大きすぎるか、不確定性が大きい時
    - 不確実性を減らすために、技術的調査(スパイク)を行う
Small (小さい)
- ユーザーストーリーが小さい
Testable (テストできる)
- テスト可能な内容であること
- ストーリーには完成するために合格すべきテストが書かれている
- 先にテストを書くこともある
  - ATDD(Acceptance Test Driven Development: 受け入れテスト駆動開発)の考え方
  - このシナリオが取ったらOKというのをストーリーに記載しておく
    - ATDDはシナリオをテストコードとして実装する
    - 完成時にはテストがパスしていなければならない

プロダクトバックログの分割方法

アンチパターン
- 技術レイヤーで分ける
- 例:1フロントエンドを作る 2 バックエンドを作る
- 工程で分ける
  - 例:1設計する 2 開発する 3 テストする
    → Valuableでないため
分割方法
- スパイク(技術検証)と機能実装で分割
- ハッピーパスとそれ以外で分割
  https://www.servantworks.co.jp/posts/5-strategies-product-backlog-refinement/
  - 顧客として、自分のアカウントでログインすることができる（ハッピーパス）
  - 顧客として、ログインに失敗した場合、自分のパスワードをリセットすることができる（アンハッピーパス）
- 入力パラメータで分割
  - 抽象的な機能ではなくより入力値ベースで細分化
- 利用者の役割によって分割
- 最適化の度合いで分割
- プラットフォームで分割
- ビジネスルールで分割
- ワークフローのステップで分割
- 操作(CRUDなど)で分割
- ブラウザの種類やバージョンによって分割 • テストシナリオ、テストケースで分割

Readyなバックログ

プロダクトバックログアイテムが用意されている
プロダクトバックログアイテムの価値が明確である
開発を進める上での大きな疑問や決定すべき事柄がない
チーム全員が何を作ればよいか理解できている
受け入れ基準が明確である
他のアイテムとの依存関係が明確である
開発チームによって見積もられている
デモの手順が明らかになっている → POレビュー時にイメージできるようにしたい

https://scaledagileframework.com/wsjf/

PBIの優先順位決め

プロダクトバックログは必ず一意な順番を付けなければならない
プロダクトオーナーは状況に応じて順番を決める必要がある
• 先2~3スプリントぐらいは考えられているとよい

遅延コストの定性的評価

価値が高く、緊急性の高いものが一番優先順位が高い
リリースから得られる価値の総量とリリースまでにかかる時間のトレードオフを考慮する
リリースまでに時間がかかってしまうと稼げたはずのお金を失う
検証の結果、回収のインパクトが大きいものは優先順位を高くする

顧客満足の狩野モデル

製品品質の品質要素について主観的側面と客観的側面の二側面の対応関係を提案

客観的側面 = 物理的な充足
主観的側面 = 満足感

分類は人によって異なるので、アンケート調査を行う

2つの質問をする
- 充足の質問(=あったらどうか)
- 不充足の質問(=なかったらどうか)

Tamtam 2023/07/17

Tamtam 2023/07/22

555(triple nickels)

ジャストアイデアで思っていたことを言語化していく。

思い出して、ブラッシュアップする。

Tamtam 2023/07/22に更新

レトロスペクティブでの振り返り時に、KPTの前にスプリント中でやったことを想起するためにスプリントバックログを見てやったことを振り返る
or 思い出しの手法(ハピネスレーダー)などを先にやる

Tamtam 2023/07/22

インペディメントリストに積み残したいものを入れておく
- 例:
  - PBIとスプリントのチケットの粒度が同じためPOの認知負荷が高い印象(つまりPBIが詳細すぎる)
  - PBIの優先順位が低いものを大雑把にする(リーンにやる)
  - スクラムイベントのマスターを定期的に交代しているが、外部との折衝は完全に切り離されていない
    - 外部との折衝の内容を折衝した以外の人がログをとる(?)。カテゴリ分けして対応策をまとめる

Tamtam 2023/07/22に更新

ユーザーストーリーマッピング

プロダクトバックログはただのリスト
- 全体像や全体フローが掴みづらい
Jeff Pattonが提唱
- プロダクトのユーザーワークフロー、設計、リリース計画を見えるか化

構成

ペルソナ
大きなアクティビティ
各アクティビティのステップ
各ステップの紹介(ストーリー)

Tamtam 2023/07/22

MRF: リリース可能な最低限のフィーチャー (Minimum Releasable Features)
- 顧客に対して価値有する機能群。実際に使うには機能が十分にそろっていない場合もある
MVP: 実用最低限の製品 (Minimum Viable Product)
MMF: 市場性のある(顧客がいて使い始められる・本番運用できる)最小限のフィーチャー (Minimum Marketable Features)

スクラムマスターがーがイベントのファシリをする必要はない。->スクラムがうまく回れば良い。

ベロシティ

以前のスプリントにおいて完成できた見積もりのポイントの合計

予測に使う
- 直近3回分の平均をとって推測する
- 前回のベロシティから推測する

スプリントビューの事前準備

誰を招待するのか決める
スケジュールを調整する
- 重要なステークホルダーの固定の予定に合わせる
- １週間スプリントで最大1時間
スプリントの成果が完成したことを確認する
デモを準備する
- プレゼンのスライドは不要
誰がするのかを決める