スクラム研修

スクラムのガバナンス

プロダクトオーナー
- What, When に説明責任
開発者
- How に説明責任
スクラムマスター
- 成功のための環境に責任を持つ
PO と SM を兼任してはいけない理由
- 権利が集中してしまうのを防ぐため
- 絶対的な権力は必ず失墜する
スプリントごとにロールを入れ替えるのはありか？
- 役割が全く違う
- PO は顧客側に立っている
- SM は組織をぬって動くようなスキルが必要

スクラムの役割

プロダクトバックログは生きたスクラムアーティファクトであり常に変化学びを適応するので常に変化する
プロダクトロードマップはスクラムの一部ではないが、一般的に用いられる戦略的方法を決めるために利用これ以外にもある
SM の役割は可能にすることであって、指示ではない
開発者はシャドウイングによってスキルを向上させることができる英語と意味は一緒で真似をしながら学ぶ
スクラムは戦術的に障害を排除する。ただしこの役割の目的は障害を防ぐことである
スプリントバックログは毎日進行中の作業ステータスに透明性を提供する
明確な完成の定義はスクラムチームによって作成される
成功する SM は組織内での影響力が必要である専門領域について深い知識があることで影響を与えることができるあとはカリスマとか長く勤務しているとか他の人を知っているとか
品質管理は開発者の責任である。タスクペアリングは製品の品質を向上させる 1 つの方法
品質保証、プロダクトが作成時のニーズを満たしていることを保証することはプロダクトオーナーの責任
PO の最も重要な素質は決断力である
スクラムでは漸進的精緻化によって、PO が後期段階でのステークホルダーからのフィードバックを拒否しないことを保証している
スプリントレビュー時にはプロダクトオーナーが成果を発表し、開発者がデモし、スクラムチームがフィードバックを受ける
開発者が成功するために最も重要な素質は汎用性である
スクラムはフレームワークあって、方法論ではない方法論は Step by Step でしっかりやることが決まっている

プロダクトゴール

市場と顧客のニーズに合わせた長期目標
灯台の明かりのような向き先を示すもの
年単位で更新

プロダクトゴールステートメント

ジェフリー・ムーアによるテンプレート

<潜在的なニーズを満たしたり、潜在的な課題を解決したり>したい <対象顧客>向けの <プロダクト名>というプロダクトは <プロダクトのカテゴリ>であるこれは<重要な利点、対価に見合う説得力のある理由>ができ <他の代替手段>と違って <差別化の決定的特徴>がある

--- (講師による追加) --- それは私達の<企業理念>を支えるものである

例

外出中に銀行の業務機能にアクセスしたい XYZ 銀行の顧客向けの MyXYZ というプロダクトはモバイルアプリケーションであるこれは 24 時間オンデマンドバンキングを利用でき、自宅や PC からのオンラインバンキングとは違ってユーザが即時アクセスできる可能性が備わっている

それは私達のいつでもどこでも迅速かつ便利な銀行サービスを提供する企業理念を支えるものである

アジャイル

アジャイルは形容詞迅速とかそういうことで手法ではないタスク明確化のためのスクラム品質管理であればテスト駆動開発などリーン開発は市場や顧客の開発を目的とする経営手法

アジャイルソフトウェア開発宣言

私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも 個人と対話 を、包括的なドキュメントよりも 動くソフトウェア を、契約交渉よりも 顧客との協調 を、計画に従うことよりも 変化への対応 を、

価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

アジャイル開発 12 の原則

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供する
要求の変更はたとえ開発の後期であっても歓迎する
動くソフトウェアを、2-3 週間から 2-3 ヶ月というできるだけ短い時間間隔でリリースする
ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働く
意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすること
動くソフトウェアこそが進捗の最も重要な尺度
アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持する
技術や設計をレベルアップさせる意識が、俊敏（アジャイル）さを高める
シンプルさ（ムダなく作れる量を最大限にすること）が本質です
自己組織化したチームのメンバーが協調して動く方が、パフォーマンスが高い
定期的な「ふり返り」により、開発チームのパフォーマンスをより高めるようにする

漸進的精緻化

プロジェクトの進捗に伴い、プロジェクトの仕様がより明確かつ詳細になること

スクラムロール

デイリースクラムその日やるやつの調整をする会であってステータス報告会ではない
スクラムマスターはチームの衝突を解決する責任はないファシリテーションをする責任はあるが解決する責任はないチームメンバーが自分たちで解決する
プロダクトオーナーはいつでもフィードバックできるスプリントレビューに限らない
スクラムで同じ場所で働くことを推奨しているのはコミュニケーションのためで管理のためではないスクラムマスターはマネージャーではない
スクラムマスターはスクラムのバリューとプラクティスが守られることを保証する責任がある体現するのはチーム全員でやる必要があるが PM が責任を持つ
スクラマスターは優れたソフトスキルを保つ必要があるソフトウェアスキルではないソフトウェアスキルは必ずしも必要ないソフトスキルは対人コミュニケーションや社交性といったスキル

Getting to Yes

講師が解決するときの例

PlanA 付箋に解決するアイディアを書いてもらう（ただしお互いに話をしない）話をすると反論が出てしまう場合がある
PlanB (ドット投票)
PlanC (レジスタンスポイント) ググっても出てこない

プロダクトロードマップ

プロダクトオーナーが責任を持つ
ぱっとみでわかるようにする
そのために粒度はあまり大きくしない
優先度を決めるのは価値とリスクをみる
最初にリリースしたときが機能が少ないのでリスクが 1 番小さい
そのためリスクが大きいものから処理したほうが幸せ
書き換えることもあるが、プロダクトバックログを作ったあとは変えるべきではない

プロダクトバックログ

プロダクトオーナーが責任を持つ
ToDo リスト
優先度だけでなく順番もつける
ここでも価値とリスクで優先度と順番をつける
このリスクは何に対してもでもよい
- リスクが高いものからやっつけるという意識を持つべき
- リスクは失敗する確率で考えるとシンプル
種類
- 要件顧客に価値を提供する
- 技術的負債
- オーバーヘッド内部文書作成など
- 改善コードの改善ではないこれだと要件になるスキルの向上など

プロダクトバックアップリファインメント

プロダクトバックアップの漸進的精緻化と分解
必要なときに行ういつでもやっていい
プランニングではスケジュールが立てれなくなるのでやらない
定期的にやってもよい
見積もりに関してはチームメンバー全員で行う
それ以外に関しては PO 1 人でやったり、数人でやったりする

ユーザストーリー

送金の例 #+begin_notes

タイトル: 口座間送金ユーザ: 個人のユーザアクション: 送金したい利益: 送金したお金が使えるこれを行うと次のようになる: 選択肢を開くと送金の選択肢があって、口座選択→金額入力→送金ボタンを押す→完了 #+end_notes>

ストーリーを分割できるかもしれない例
- 接続しがたくさんある

バックログの見積もり

見積もりはいつでもやる
いつでもやるけど以下のときは必ずやる
- プロダクトロードマップ
- リリース計画
- スプリントバックログ
メンバー全員でやる
SM はファシリテーター

見積もり

相対見積もり
- 精度より正確性
- 例
  - ビルの 2 つの高さ
    - 絶対値の場合は大きく異なってしまう場合が多い
    - 相対（もう一方は 2 倍高い）の方が合っている確率がたかい
フィボナッチ数列
- ユーザーストーリー
  - 1
  - 2
  - 3
  - 5
  - 8
- エピック（リリース）
  - 13
  - 21
  - 34
- 機能（ロードマップ）
  - 55
  - 89
  - 144
開発者が行う
5 であるだろうというのを基準にきめていく
- この 5 というのは時間ではない
- 1 スプリントになんベロシティ（コストの合計）ができたという感じで時間ははかる
- このベロシティは評価に使ってはいけない
  - チームによって 5 の評価基準が全く違うため
コストが大きかった場合見積もりの時点で分割する必要はない

スクラムの役割

左が既存の PM の役割

関係者との調整 -> PO
要件定義 -> PO
プロジェクト計画を決める -> PO（ただしファシリテーターの役割は SM）プロダクトゴール・プロジェクトロードマップを決めるのがスクラムでの対応役割
タスクアサイン -> D PO や SM が手を動かせという指示はしない
進捗に合わせて人を追加する -> PO もしくはその他予算が増えるので PO が予算管理する人事部門がアサインするという場合もある
工数管理 -> D
（技術的）品質管理 -> D
リスク管理 -> PO or SM or D リスクによる市場による場合は PO 技術的リスクによる場合は D 組織的リスクによる場合は SM
ペンディング管理（このスクラムでやらないストーリーの決定） -> PO
体制の構築 -> PO ただし人事部門がアサインするという場合もある
コスト管理 -> PO

リリース計画

市場性のある機能の最小セットを対象とする
- 優先度の高いものからリリースする
- 最小にすることで複雑さとリスクを小さくする

スプリントプランニング

スプリントが 1 週間なら 2 時間くらいが目安
なぜこのスプリントが価値があるか
- ゴール設定
何ができるか
- D と PO が PBI（ユーザーストーリー）を選択
それはどのように行うのか
- D がユーザーストーリーを細かいタスクに分割する
  - 開発者の独自の裁量
SM はファシリテーターをする
- 質問しながら何をすべきか何が目標かを明確化する
みんなで同じユーザーストーリーを実施する
- スクラムが終わったときに全部中途半端ということにならないため
見積もりで見積もり時間のバッファはつけない
- そのかわり余暇をもたせる
  - 例えば全体で 100 時間あるとしたらタスク見積もりは 50 時間分とする
  - 最初は 50%、のちのちどんどん増やしていき Max は 90% までとする
例えば全体のフレームワーク作成など全体に関わるタスクついてはどうするか
- スクラムの答えとしては最初の画面表示のためのユーザーストーリーでやれば良い

デイリースクラム

15 分間
スプリントゴールに向けた進捗状況に焦点を当てて当日の計画を決定する
- ステータス報告ではない
- ステータスはスプリントバックログを見ればわかるため
問題解決ではなく調整
開発者のために実施
- SM に説明するのではなく開発者同士での共有
- SM は短い時間でデイリースクラム終わるようにしたり、障害を調整する場合がある
- PO は開発者の要求に応じて説明する

チームタスクボード

自分が Task が終わって TODO にものがなくて進行中のものしかない場合
- 進行中でペアプロで早く終わらせるものがないか
- 進行中でシャドウイングで学べるものがないか
- 最終手段として次のユーザーストーリーに進む

スプリントレビュー

PO はスプリントの成果物をプレゼンテーションする
D がデモする
- ステークホルダーからフィードバックをもらう
- PO はフィードバックを受けてバックログをアップデートする
- ステークホルダーが実際に使ってみるというのもあり
  - これが理想的
時間はスプリントが 1 時間なら 1 時間
プレゼン準備は 20 分くらいの最小のものにする
スライドは使わない
Q: 継続的デリバリーをしてると常に本番環境にデプロイされる状態になっていると思いますこの場合スプリントレビューでは何を話すべきでしょうか
- A: スプリントレビューはスプリント全体で見返してステークホルダーから FB をもらう場です。そのため、スプリントレビュー時にデモをしなければならないわけではありません。

スプリントインクリメント

完成の定義を満たしリリース可能な成果物
- 価値がある
- 開発・テスト・ドキュメント
リリース可能と本番環境にリリースするは別でよい
実際のリリースはリリースプランに応じる

レトロスペクティブ

有効性と品質を向上させる方法を計画
PO ・ SM ・ D 全員が参加
プロセス・ツール・環境・コミュニケーションなどについて話し合う
- 何がうまくいったのか
- 何を変えたいか
- その変更をどの用に実装できるのか
文句を言う会ではない
時間は 1 週間のスプリントあたり 45 分
スクラムは問題を見える化してくれるが、「解決」するわけではない
- 解決するのはチームで行う

この場合？

PO が複数人の委員会によって果たされるか？
- 意思決定が難しくなってしまう
- D からみても様々な意見を言われて混乱してしまう
- PO は個人で意思決定ができる人であるべき
プロダクトはスクラムでよく使われるが、スクラムで規定されたものではない
エクストリーミングプログラミングはスクラムでよく使われるが、スクラムで規定されたものではない
反復型およびインクリメンタル型アプローチの利点は何か
- 早い段階で価値を提供できる
- 迅速に学習できる
- リスクを最小限にできる
D と PO が要件を明確にしている間 SM がするべきことは何か
- SM はファシリテーションする
一方のチームは 10 ストリーポイント実行し、他方は 25 ポイントどちらが優れているか
- どちらが優れているというのはない