<style>
/* basic design */
.reveal h1, .reveal h2, .reveal h3, .reveal h4, .reveal h5, .reveal h6,
.reveal section, .reveal table, .reveal li, .reveal blockquote, .reveal th, .reveal td, .reveal p {
font-family: 'Meiryo UI', 'Source Sans Pro', Helvetica, sans-serif, 'Helvetica Neue', 'Helvetica', 'Arial', 'Hiragino Sans', 'ヒラギノ角ゴシック', YuGothic, 'Yu Gothic';
text-align: left;
line-height: 1.6;
letter-spacing: normal;
text-shadow: none;
word-wrap: break-word;
color: #99999;
}

.reveal h1, .reveal h2, .reveal h3, .reveal h4, .reveal h5, .reveal h6 {font-weight: bold;}
/* .reveal h1, .reveal h2, .reveal h3 {color: #2980b9;} */
.reveal blockquote {width: 90%; padding: 0.5vw 3.0vw;}
.reveal table {margin: 1.0vw auto;}
.reveal code {line-height: 1.2;}
.reveal p, .reveal li {padding: 0vw; margin: 0vw;}
.reveal .box {margin: -0.5vw 1.5vw 2.0vw -1.5vw; padding: 0.5vw 1.5vw 0.5vw 1.5vw; background: #EEE; border-radius: 1.5vw;}
/* font size */
.reveal h1 {font-size: 4.5vw;}
.reveal h2 {
font-size: 3.5vw;
padding: 0 1.5vw;
margin: 0.0vw 0 2.0vw -2.0vw;
border-left: solid 1.2vw #2980b9;
border-bottom: solid 0.8vw #d7d7d7;
}
.reveal h3 {font-size: 2.3vw;}
.reveal h4 {font-size: 2.1vw;}
.reveal h5 {font-size: 1.9vw;}
.reveal h6 {font-size: 1.7vw;}
.reveal section, .reveal table, .reveal li, .reveal blockquote, .reveal th, .reveal td, .reveal p {font-size: 1.7vw;}
.reveal code {font-size: 1.6vw;}
.reveal .slides section {
text-align: left;
vertical-align: top;
}

</style>

## アジャイル開発とは

- 関係者は目的達成のためにお互い協力し合いながら進める
- 一度にまとめてではなく少しづつ作り、早い段階から実際に動作するものを届けて評価を繰り返す。
- 利用者の反応や活計者からのフィードバックを継続的に得ながら、作っているもの自体や計画を調整する。

[Agile programming for your faimly](https://www.ted.com/talks/bruce_feiler_agile_programming_for_your_family?language=en)とかもあるよ。

---

## 今回

以前のプロジェクト(旧ロボチーム)は、SCRUMでプロジェクトを回していました。
普及も兼ねて本を読み返して、ドキュメントにまとめてみました。

[Sacrum bootcamp the book](https://www.amazon.co.jp/-/en/%E8%A5%BF%E6%9D%91-%E7%9B%B4%E4%BA%BA/dp/4798163686/ref=pd_lpo_sccl_1/355-1670060-6858935?pd_rd_w=szH80&content-id=amzn1.sym.d769922e-188a-40cc-a180-3315f856e8d6&pf_rd_p=d769922e-188a-40cc-a180-3315f856e8d6&pf_rd_r=S099PYFD9ES2S10PGZAA&pd_rd_wg=avmVJ&pd_rd_r=2dc55142-14c0-4cfd-bf43-86c83864c056&pd_rd_i=4798163686&psc=1)

---

## スクラム

スクラムは、アジャイル開発手法の一つです。
アジャイル開発は、何か単一の開発手法を示すものではなく、似たような開発手法に共通した価値観と行動原則に名前がついたものであり、様々な手法があります。

---

## 最低限のルールセット

- ５つのイベント
- ３つのロール
- ３つの作成物

ツールは、JIRAを使用していました。

---

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

- 機能や要求を並べる
- 実現したいことをリストにする
- 項目の追加、削除されるもの
- 順番を考える(優先順位ですね)

※各項目が実現させることで価値、リスクや必要性をなどによって決定する

ゴール:どういうことを実現するのか。
ミッション:絶対に達成したいこと。

---

## 3つのロール(役割)

1. ロール1 : プロダクトオーナー(1人)
- 何のために何をどういう順番で作るか考える人。
2. ロール2 : 開発チーム(3人〜9人)
- 要求を聞き出したり、見積もり、設計、画面デザイン、テストを行う。
3. ロール3 : スクラムマスター(1人)
- なにかうまく行かないことがあって仕事が円滑に進んでいないのなら、それを取り除く役割。

9人以上の場合は、ラージスクラムってのになるみたい。(城口さんが言ってました。)

---

## ロール1 : プロダクトオーナー

- 開発していくもののビジョンを伝える。
- スクラムチームで達成していきたいゴールを伝える。
- 具体的に何を実現してほしいかを伝える。
- 優先順位を決めて実現していくと、いいものになるかを決める。

樺沢さんとか勝さんみたいな人かな、営業ぽいこともする人ですね。

---

## 続き ロール1 : プロダクトオーナー

- どう実現するといいものになるかを考えて、最終的な判断をする。
- 決定に問題がないか関係者と合意しておく。
- 予算や期間のような制約を守るために必要なことを調整する。
- 関係者の協力を取り付け、調整する。

---

## ロール2 : 開発チーム

- ものを作る。
- 3人〜9人の規模。
- 全員が揃えばプロダクトが作れます。
- 肩書、サブチームとか無い。みんなでなんでもやるマンって感じですね。得意不得意はあるけど。そこは話し合う感じでした。

※3人以下は個人のスキルに依存、9人は、コミュニケーションコスト高くなる。Ristって3人以下とかよくある？
スクラムがほんとにあってるかは、わからないです。

**自己組織化**
チーム全体で合意して、責任を持つ。

---

## イベント1 : スプリント

- だいたい2週間、1ヶ月だとおおい。

一ヶ月前にどんな作業をしたか覚えてる？
一ヶ月分の報告ってだるくない？

---

## イベント2 : スプリントプランニング

- で2週間でなにやるの？

- スプリントで何を達成するかを決めること。
- プロダクトバックログからスプリントバックログの抽出して具体的にどう作業をするか洗い出し。

2週間でなにするのか決める。開発項目の選択、実装方法なども検討する。具体的に何するの？

~~**工数見積もり**をここでする~~

[Hajitsu](https://hatjitsu.toolforge.org/)

---

## 作成物2 : スプリントバックログ

- 選択したプロダクトバッグログ項目リスト。
- 具体的な作業に分割されたもの。
- あとから増えることもある(見積もりより早く終わることあったりするよね？)
- 1タスクが一日で終わるサイズにする。

見積もりによっては、1.5日とか2日とかもあったけど。
プロダクトバックログから2週間分の作業を切り出したもの。

---

## 作成物3 : インクリメント

- 出来上がったもの一つにする作業。

※最初のスプリントでログイン機能、ユーザー登録、パスワード再設定機能ふぁ実装されて、次のスプリントでは、商品検索機能、商品詳細表示、カートに追加機能...

今まで出来上がったもののリストができる

JIRAにこれに似た画面あったか覚えてない・・・

---

## 完成の定義

- どこまでやるのか？
- コードレビュー通ったら完成？
- ユニットテスト問題なかったら完成？
- 結合テストが問題なかったら完成？
- デプロイしたら完成？

何をもって完成とするのかの基準をきめるべき。
まー皆さん普段やってることです。

---

## イベント3 : デイリースクラム

- 毎日検査
- スプリントのゴール達成のために、自分が昨日やったことは何？
- スプリントのゴール達成のために、自分がきょうやることはなにか？
- スプリントのゴール達成のために、障害とか懸念点とか心配してることは何？

この時間はあまり時間かけない。15分から30分。
問題解決の場ではないのでその場合は別途、場を用意すべき。
まーこれも皆さんやってると思います。

---

## イベント4 : スプリントレビュー

- 2週間何やってたんですかってことを共有する場です。

- 成果物をを関係者にデモする。
- フィードバックを得て、プロダクトバックログを見直す。
- 全体の残作業や進捗をトラッキングする。
- 今後の予定や見通しを共有する。
- プロダクトオーナーが主催。
- 利害関係者に参加してもらう。

プロジェクトの初期は、見せるものがなかったりしますが。
ハードがあると動いてるものがあるので、自然とみんな集まって議論したりとかもありました。

---

続き　イベント4 : スプリントレビュー

- スプリントで完成しなかったプロダクトバックログの項目について説明する。
- スプリントでうまくいかなかったことや直面した問題点、解決した方法について議論する。
- プロダクトオーナーがプロダクトの状況やビジネスの環境について説明する。
- プロダクトバックログに追加すべき項目の有無について議論する。
- プロダクトの開発をすすめる上で問題となる事項について議論する。
- 現在の進捗を踏まえて、リリース日や完了日を予測する。

---

## KPT法

全員に書いてもらう

KPT法
続けるべきこと
抱えてる問題
次にトライしたいこと

[参考](https://bizx.chatwork.com/business-efficiency/kpt-method/#:~:text=KPT(%E3%82%B1%E3%83%97%E3%83%88)%E6%B3%95%E3%81%A8%E3%81%AF,%E3%81%A8%E8%AA%AD%E3%81%BE%E3%82%8C%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%80%82)

---

## イベント5 : スプリントレトロスペクティブ

- もっと仕事をうまく進められるように改善を繰り返す。
- バグを直すのではなく、バグが生まれるプロセスを直す。
- 人、関係、プロセス、ツールなどの観点で今回のスプリントを検査する。
- うまくいったこと、今後改善すること整理する。
- 今後のアクションプランを作る。
- 一度にたくさんの変更をしようとしない。

---

## ロール3 : スクラムマスター

- このフレームワーク・仕組みがうまく使われるよにする。
- 妨害の排除
- 支援と奉仕(サーヴァントリーダーシップ)
- 教育、ファシリテーター、コーチ、推進役
- マネージャーや管理者ではない。

妨害の排除って意外にに重要ですね。
開発チームが開発に集中できるように立ち回る方ですね。
経験豊富な方がやったほうがいいのかな？

---

## まとめ

スクラムの5つの基準

確約(Commitment) : それぞれの人がゴールの達成に全力を尽くすことを確約する。
勇気(Courage) : 正しいことをする勇気を持ち、困難な問題に取り組む。
集中(Focus) : 全員がスプリントでの作業やゴールの達成に集中する。
公開(Openness) : すべての仕事や問題を公開することに合意する。
尊敬(Respect) : お互いを能力ある個人として尊敬する。

---


---

旧ロボチームでは、SCRUMで開発してました。
ご覧の通りみんな去ってしまいましたが。。。

SCRUMでうまくまわってないなと思ったのは、強化学習系のプロジェクトですね。実機でやってたので、学習が長すぎて最後の方は、SCRUMがグダグダだった気がします。

---

基本的に質は別の話として、プロジェクト当初に考えてたものとは違うものが出てきたとか。。。

プロジェクトスタート時に言ってたことと今全然違うことしてるとか。非常に素敵ですね。。。

このフレームワークを回せば、そんなことありえないと思います。

---

シンプルにPDCAを回してるだけっす。
でも、それをできない人が結構います。

上から言われたからすぐに動かなきゃいけないみたいな~~輩~~方々が世の中にいます :exploding_head:

~~完全に狂ってますよね。カオスですね。本当に実現できます？~~

---

## 前回の続き...要は

みんなで共通認識(実現したいこと、もの、機能)をもって、開発を進める。
人それぞれ能力の差はあるとは思いますがお互いに助け合って開発を進めて行く。

今回の話は、下記からもスクラムマスターの記事
- [RistのQiita](https://qiita.com/3panda/items/1f8b40186a50bd01f89d)

---

## プロダクトオーナーの作業

- 開発するもののビジョンを伝える。
- スクラムチームが達成したいゴールを伝える。
- 具体的に何を実現してほしいか伝える。
- どれを実現するといいものになるかを考えて、最終的な判断を下す。
- 決定に問題がないかを関係者(ステークホルダー)と合意する。
- 予算や期間のような制約を守るために必要なことを調整を行う。
- 関係者の協力をとりつけ、調整する。
<br>

要求、仕様、計画にかかわる人？

以前のプロダクトオーナーは、毎回**RFP** ?、**企画書** ?のようなものや実際の絵みたいな物を作成していただいた気がします。
それを元にプロダクトバックログを作成していたような。

---

## プロダクトバックログ

プロダクトバックログ = どういうことを実現するのか(ゴール)、全体に実現したいことは何か(ミッション)のリスト
<br>

プロダクトバックログの項目をユーザーストーリーという形式で書くスクラムチームが多いみたいです。
ユーザーストーリーは、実際に使うユーザーに何を提供して、その目的は何なのかを簡潔に書くやり方。
<br>

いままで私がよくあったのは、とある受託のプロジェクトでこういうものを作って欲しいって作ります。
技術的なことわからないので打ち合わせに出てほしいって言われて打ち合わせ出ます。
お客さんと打ち合わせしたら"ちがーう"って言われて、作り直しの繰り返しで全然プロジェクトが終わらないとか。前職ではよくありました。

~~まーおじいちゃん上司が四六時中ポケモン捕まえてたんで仕方ないです。シニア採用ってマジで悪だとそのとき思ってた。だってどこかの元事業部長だった人なので誰も何も言えない雰囲気でした笑~~

---

## プロダクトバックログの作り方

**開発者側の視点**
- 何かしらの企画書や作成したいドキュメントから出発し、Miroの付箋を使って必要と思われる機能を全員で書き出す打ち合わせを行います。
- 既存のシステムの改修であれば、現状の機能一覧があると便利かもしれません。
<br>

**ユーザーストーリーは、実際に使う人側の視点**
- 実現したいものを実際に使う人たちの立場で表現する。これってみんなの共通認識になるはずです。
- <どういったユーザーや顧客>として、<どんな機能や性能>がほしい、それは<どんなことが達成したい>ためだ。って感じで意図を伝えるとわかりやすいみのか。※ここは以前はあまり意識してなかったかもしれません。
<br>

[JIRAでのプロダクトバックログ](https://qiita.com/3panda/items/1f8b40186a50bd01f89d#epicstorytask%E3%81%AE%E4%BE%8B)

---

## 見積もり

プロダクトバックログができたら次は見積もりです。

[SCRUM BOOT CAMP](https://www.amazon.co.jp/-/en/%E8%A5%BF%E6%9D%91-%E7%9B%B4%E4%BA%BA/dp/4798163686/ref=pd_lpo_sccl_1/355-1670060-6858935?pd_rd_w=szH80&content-id=amzn1.sym.d769922e-188a-40cc-a180-3315f856e8d6&pf_rd_p=d769922e-188a-40cc-a180-3315f856e8d6&pf_rd_r=S099PYFD9ES2S10PGZAA&pd_rd_wg=avmVJ&pd_rd_r=2dc55142-14c0-4cfd-bf43-86c83864c056&pd_rd_i=4798163686&psc=1)で紹介しているのは、相対見積もりというものです。

ある作業を基準にして、それより時間がかかるか、かからないか。３種類くらいに分けられる。

- 簡単に終わりそう
- 少し大変そう
- 結構大変そう

---

## フィボナッチ数を使う見積もり

1，2，3，5，8, 13, 21, 40....

基準として比較的大きなものは、13や21のように数字が大きくなります。
大きな見積もりになるということは、見積もり対象が不確実な要素を多く含む作業であることがわかります。
したがって、何がわかっていて何がわからないのかを明確にすることが重要だと思います。

[ストーリーポイントの例 : Qiita](https://qiita.com/3panda/items/1f8b40186a50bd01f89d#202111%E7%8F%BE%E5%9C%A8%E3%81%AE%E5%8F%82%E8%80%83)

---

## プランニングポーカー

SCRUM BOOT CAMPでは、**見積もりポーカー**と紹介されています。

**ポーカーするために**

- [専用のカード](https://www.amazon.co.jp/Agile-%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0-%E3%83%97%E3%83%A9%E3%83%B3%E3%83%8B%E3%83%B3%E3%82%B0-%E3%83%9D%E3%83%BC%E3%82%AB%E3%83%BC%E3%82%AB%E3%83%BC%E3%83%89-%E3%82%B5%E3%82%A4%E3%82%B8%E3%83%B3%E3%82%B0%E3%81%AB%E6%9C%80%E9%81%A9%E3%81%AA%E3%82%AB%E3%83%BC%E3%83%89/dp/B078S8LBYN)
- [Hajitsu](https://hatjitsu.toolforge.org/)
※こちらを使ってましたが、これはあくまでボランティア的な感じで用意しているだけなのでルームを作成しても時間が経つとルームが消されるのでちょっと使いにくい。
- [ソースコード](https://github.com/richarcher/Hatjitsu)があるので社内にサーバー立ててもいいかもしれません。

---

## プランニングポーカーのやり方

- 見積もる項目を一つ選び、次に各自がどの数字が適切かを考えます。
- 自分が適切だと思う数字のカードを1枚選びます。
- 合図に合わせて一斉にカードを公開します。
- 全員が同じ数字を選ばなかった場合は、その数字について簡単に話し合います。（詳細な話し合いは時間がかかるため）
※数字が一番小さい人と数字が一番大きい人の意見を聞くという方法もあります。

なぜそのように考えたのかを聞くことで、様々な視点が明らかになります。
その人の意見に同意することができたり、認識を合わせることができます。

---

## なんでするのか

- プランニングポーカーを行う理由は、開発チームの意見を集めやすくするためであり、現状のチーム全員で知恵を絞り、さまざまな視点から意見を出し合いたいからです。
- ポーカーを行うことで、時間を無駄にせずに要点に集中し、大まかな合意を形成する効率的な方法となります。
- 意見が異なるあいまいな項目について議論することで、問題の発見や解決が可能になることもあります。
- 疑問が解消されず見積もりができない場合は、その旨をプロダクトオーナーに報告することも適切だと思います。
- 数字で見積もることで、プロダクトバックログの総ポイントも算出されます。これにより、チームが1回のスプリントで何ポイント消化できるか、またプロジェクトがいつ頃終わるかがわかります。

※リリーススプリントを別途設ける場合もあります。また、スプリントで対応することも可能です。（ユーザーテストのスプリントや本番環境構築スプリント、受け入れテストスプリントなど）

---

## 本当に正確か

そもそも、最初に見積もりを立ててそれ通りに実現するのは無理ゲーです。

- 特に新しいことを試みている場合、予想外の事態は常に発生します。そのため、バッファを適切に設けることが重要です（わからなかったらストーリーポイント x1.2 x1.5など）。
- 問題に遭遇した際には、全員でミーティングを開くこともあります。ハードウェアをどこからか購入していたら使い方の相談とかもあります。その時間もバッファとして考慮に入れるべきです。一回のスプリントでは数時間は必要となるでしょう。

トータルの見積もりを上に報告して文句を言われるなら、そこは、プロダクトオーナーなりスクラムマスターが説得してよ。

---

## タスクを考える

[タスク](https://qiita.com/3panda/items/1f8b40186a50bd01f89d#task-1)

- ストーリーの見積もりができ、スプリントプランニングで担当が決まった後、担当者はタスクを考えてリスト化します。
- タスクを考えている間に、予想以上に時間がかかると感じた場合は、スクラムマスターに相談すると良いでしょう。ポイントの調整が必要かもしれません。
- リファインメントにばかり時間を費やすと、元々のゴールから逸れる可能性があるので注意が必要です。
- 最終的にはEpicの実現、つまり完成の定義を達成することが重要です。

---

## なんでJIRAなの

- タスクボード
- 未着手(ToDo), 着手(Doing), 完了(Done)※ここは追加、変更できた気が。
- スプリントバーンダウンチャート([グラフ例](https://www.google.com/search?sca_esv=568110489&q=%E3%82%B9%E3%83%97%E3%83%AA%E3%83%B3%E3%83%88%E3%83%90%E3%83%BC%E3%83%B3%E3%83%80%E3%82%A6%E3%83%B3%E3%83%81%E3%83%A3%E3%83%BC%E3%83%88&tbm=isch&source=lnms&sa=X&sqi=2&ved=2ahUKEwjrvu_cmMWBAxV3lFYBHdPRBZAQ0pQJegQIDBAB&biw=1070&bih=820&dpr=1))

※JIRAを見に行けば、どういう進捗状況で、何ができてて、何が終わってるか、見ればわかる。誰が何をしているのかってのがわかって透明性がある。お互いにわかってるから問題が起きた時に助けられる。

---

## 完成の定義

やっぱりここをしつこくやる。

- デモ手順の通りに動作する。
- publicメソッドのテストコードがある。
- 調査した内容をWikiにまとめてある。
- 最新の仕様がWikiにまとめてある。
- リポジトリからいつでも最新にデモ可能でテスト済みのソフトウェアが取得できる。

JIRAのストーリーチケットに完成の定義を以前は書いてました。

---

## 手戻りについて

手戻りは必ず発生する、ゴールを曖昧にしない。
- GUIなどがあると手戻りとかよくある気がします。([ペーパープロトタイピング](https://www.uxpin.com/studio/jp/blog-jp/%E3%83%9A%E3%83%BC%E3%83%91%E3%83%BC%E3%83%97%E3%83%AD%E3%83%88%E3%82%BF%E3%82%A4%E3%83%97%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E8%A7%A3%E8%AA%AC%EF%BC%81/))
- 実現したいことは先に深く理解しておく
- 決めるべき仕様を決めておく
- 技術的にどういうふうに実現するといいかを確認する

~~そういえば、最近GUIの設計書見たけど、正常系しか書いてなかったけど問題ないのかな~~

---

## タイムボックス

- スプリントの期間は1ヶ月以内
- デイリースクラムは15分以内
- スプリントプランニングは8時間まで(スプリント期間が1ヶ月の場合)
- スプリントレビューは4時間まで(スプリント期間が1ヶ月の場合)
- スプリントレトロスペクティブは3時間まで(スプリント期間が1ヶ月の場合)

**スプリントの期間は、延長しない。**
そんなこといったって、、、無駄にだらだら打ち合わせしないってことだと思います。

---

## 全員参加のイベント

- スプリントプランニング
- スプリントレビュー
- スプリントレトロスペクティブ

それぞれの役割には特定の責任があります。

- 開発チームは、どこまで作成できるかを判断し、どのように実現するかを説明します。

- プロダクトオーナーは、何をどこまで実現してほしいか、完成したものがゴールを達成できそうかを考える必要があります。

代理人を立てることは意味がありません。

どうしても参加できない場合は、動画やドキュメントで情報を保存しておくことも一つの方法です。

---

## 得意な作業と不得意な作業
開発チーム

- スキルマップを作成してみる
- プログラミング言語、利用するミドルウェア、開発環境、スクラムについての知識、TDD、ペアプログラミング、モブプログラミングの経験等
- 教えられるくらい得意、得意、経験有り、未経験とかに分類
<br>
- これまでどんな開発をしていて、何が得意なのか。
- どういうふうに仕事をするタイプなのか
- 自分が大切に思う価値はなんなのか
- 自分はどうやって貢献できそうか

**スウォーミング**
- 完了までのリードタイムが短縮
- 手戻りがなくなる
- 知識の移転が進む
※属人化をやめるってことですね。

一人でやることには限界があるってことです。

---

## 失敗から学ぼう

- スクラムでは、コミットメントという価値を重視しています。デイリースクラムやスプリントプランニングで行う確認作業は、ゴール達成のためのコミットメント表明を繰り返すことです。これにより、メンバーに責任感を持たせる意図があります。
- コミットメントには注意が必要な部分もあります。期日を守ろうとするあまり、プロダクトバックログの項目を消化することばかりに集中し、取り扱いが難しいコードを書いてしまうこともあります。
- 毎日のデイリースクラムやスプリントを通じて、小さな失敗を繰り返しながら修正していくことで、大きな失敗につながらないようにすることが重要です。

カイゼン
もしチーム全体の知識や技術が不足して失敗している場合は、スプリント内で勉強時間を確保することも一つの方法です。みんなで集まって現在起きている課題や失敗に対して最善の解決策を考えることが大切です。