SCRUM BOOT CAMP THE BOOK スクラムチームではじめるアジャイル開発

# SCRUM BOOT CAMP THE BOOK スクラムチームではじめるアジャイル開発 ###### tags: `スクラムチームではじめるアジャイル開発輪読会` ## 概要 --- ## 進め方 - 読んで疑問点や感銘を受けた点を、当日までに箇条書きで良いので書き出しておいてください。 - 本の内容を引用するのであれば、 **ページ数** も一緒に書いておいて頂けるとよりスムーズです - 誰かが書いた疑問について共感する場合は末尾に:+1:をつけてくだい。 - :+1: が多い質問を当日のディスカッションで拾おうと思います - チャンネル上での発言も余裕があれば拾っていこうと思います。 > ※書き方参考 > 以下のHackMDは、実際に輪読会を行ったときのHackMDになります。 > [エバンスドメイン駆動設計輪読会HackMD](https://hackmd.io/6JyudJcoTNqUqlzDlA91cQ) > [実践ドメイン駆動設計輪読会HackMD](https://hackmd.io/6JyudJcoTNqUqlzDlA91cQ) ## 予定 2023.03.31 - 基礎編：スクラムってなに？ 2023.04.07 - 基礎編：スクラムってなに？(続き) 2023.04.14 - 実践編：どうやればうまくいくの？ Scene No.00～03 2023.04.21 - 実践編：どうやればうまくいくの？ Scene No.04～05 2023.04.28 - 実践編：どうやればうまくいくの？ Scene No.06～07 2023.05.12 - 実践編：どうやればうまくいくの？ Scene No.08～09 2023.05.19 - 実践編：どうやればうまくいくの？ Scene No.10～11 2023.05.26 - 実践編：どうやればうまくいくの？ Scene No.11～12 2023.06.02 - 実践編：どうやればうまくいくの？ Scene No.13～14 2023.06.09 - 実践編：どうやればうまくいくの？ Scene No.15～16 2023.06.16 - 実践編：どうやればうまくいくの？ Scene No.17～18 2023.06.23 - 実践編：どうやればうまくいくの？ Scene No.19～20 2023.06.30 - 実践編：どうやればうまくいくの？ Scene No.21～22 2023.07.14 - 実践編：どうやればうまくいくの？ Scene No.23～24 2023.07.21 - 実践編：どうやればうまくいくの？ Scene No.25 --- # 基礎編：スクラムってなに？(2023.3.31) ## 目安の時間 - 10分 ## 感想・気づき - アジャイル開発とは？一度にまとめてではなく少しづつ作り、早い段階から実際に動作するモノを届け続けて評価を繰り返す - 早い段階から動作するものを提示することでニーズをつかみやすくしていると感じている。 - 動作するプロダクトを開発する: 開発するチームは3人から9人までで構成される。(略)開発チームは、プロダクトを作るために必要な全ての作業ができなければいけません。(略)あくまで開発チーム全体で責任を持って作業を進めます。これを自己組織化と呼びます。 - 多くても少なくても良くないらしい - 機能横断的なチームのためには個人が複数の事をできるようにあることが望まれる。 - ソフトウェアを作るのは簡単ではありません。最初にどんなものを作るかきちんと考えて作り始めても、いざ進めてみると途中でほしいものが変わったり、さまざまな要望が出たりします。 - 確かにそうだなと思いました。このプロジェクトを始めてから数か月経っていますが、これに関しては実感している。 - アジャイル開発の進め方３つ目の「利用者の反応や関係者からのフィードバックを継続的に得ながら、作っている物自体や計画を調整する」 - 現在では開発チーム＋POでしか定期的にレビューをしておらず、部署内の他の関係者（プロモなど）を含めてのMTGが特にないため商用リリースの数か月前に色々と意見が出て大幅に変更がでるかもしれないところを心配。 ## 疑問 - プロダクトバックログリファインメントの開催タイミングもある程度定めてほしかった - タスクのアサインなどは誰が行うのでしょうか？ --- # 基礎編：スクラムってなに?(2023.4.7) ## 目安の時間 - 10分 ## 感想・気づき - スプリントプランニングに使える時間は１か月スプリントであれば８時間、スプリント期間が短ければそれに合わせて短くするのが普通です。 - 今までだと１か月でスプリントプランニングにかかった時間が８時間かかっていないことにきづいた - すごくわかりやすい本で、最初にこれを読めばよかった（上田） - まとめの「確約・勇気・集中・公開・尊敬」　本当に大切だと思います。 - p18. スプリントプランニングの時点で、全ての項目の担当者を決めると言ったこともありません。 - あくまでも機能横断的チームのため、特定のメンバーにタスクが偏らないようにする - p20. プロダクトオーナーと開発チームが「完成」の指す内容について共通の基準を持つ必要がある。 - 次のページにあるような項目では現状にぎれてないので、握った方がいい？ - p.21 デイリースクラムは、開発チームの人数に関係なく、15分間のタイムボックスで行い、延長はしません。 - 到達することが重要ではなく、決められた時間内でどこまでイケたかが重要 ## 疑問 - 開発チームはスプリントプランニングで合意した内容を完成させるように全力を尽くす必要はあるものの、計画したことをすべて完成させることを約束しているわけではないという点です。（ｐ18） - 完成できなかった場合は、どうなるのか？ - プロダクトバックログの良い管理方法とは？（ｐ26） --- # 実践編：どうやればうまくいくの？ Scene No.00　開発したいものの概要と人物紹介 ## 目安の時間 - 10分 ## 感想・気づき - p40. プロダクトオーナーは{略}熱心に考えてくれるひと - プロダクトに対して熱い想いがないと務まらない - 私はスクラムでの開発が初めてなのですが、他の会社のアジャイル・スクラムのPOはどんな感じなのか、見てみたいです（上田） - p.43 プロダクトオーナーとスクラムマスターを兼任するのは絶対に良くない ## 疑問 --- # 実践編：どうやればうまくいくの？ Scene No.01　ロールを現場にあてはめる ## 目安の時間 - 10分 ## 感想・気づき - 初心者プロダクトオーナーでも遠慮せずにチームと接しよう - 経験が浅くても遠慮せず意見を開発チームに言うこと - プロダクトオーナーの作業 - ただ要件を伝える人、ではない。実際にこれだけの作業を一人でできるひとはそうそういない気がする。 ## 疑問 --- # 実践編：どうやればうまくいくの？ Scene No.02　どこに進んでいくの？ ## 目安の時間 - 10分 ## 感想・気づき - p.48 どういうことを実現するのか(ゴール)・絶対に達成したいことはなにか(ミッション) - ゴールとはチームに掛けられている期待。ミッションとはチームで絶対に達成したいこと。 - p.50 スクラムチームの周辺にいる人達はそれぞれ思い思いの期待がある。その期待全てに答えていくのはとても大変。 - 様々な期待農地どれを達成すべきなのかをあらかじめ宣言しておくのは、後々トラブルにならないために必要なこと。 ## 疑問 - ゴールとミッション - 我々のPJではミッションは明確にある（展示会やKPI）が、明確なゴールがなさそう。 - ゴールはどうやって見つける？ --- # 実践編：どうやればうまくいくの？ Scene No.03　プロダクトバックログを作る ## 目安の時間 - 10分 ## 感想・気づき - スクラムチームがプロダクトバックログについて十分理解しておかなければならない - そうでないと作業はうまく進められない ## 疑問 ## 疑問 - ゴールとミッション - 我々のPJではミッションは明確にある（展示会やKPI）が、明確なゴールがなさそう。 - ゴールはどうやって見つける？ --- # 実践編：見積もりをしていく Scene No.04　正確に見積もれません ## 目安の時間 - 10分 ## 感想・気づき - 見積もりは作業の量を数字にする　　-　数字化するには、相対見積もりで基準となる数字を決める　　-　基準はプロダクトバックログの項目の一つ - ウォーターフォールの人月という見積もりには、ずっともやもやしていたのですが、アジャイルの作業量の見積もりを体験して、なるほど！と思いました - 見積もりをするとき、基準タスクは簡単すぎてはいけない - 重いタスクが100倍などになり、把握しづらくなる可能性があるため - 基準が適切でなければ基準タスクを見直すべき ## 疑問 --- # 実践編：見積もりをより確実にする Scene No.05　僕なんかでいいですか？ ## 目安の時間 - 10分 ## 感想・気づき - 見積もりは開発チームが行う - 対話をすることで、認識のずれを確認する - 様々な経験を持つ人が見積もりに参加することで、１人では見落としていたことに気づけて、効果的だと感じています。:+1: - p.76 項目が詳細だと、見積もりは正確な気がする。けれど、実はこれは良くない兆候である場合が多い。 - どんなに見積もりをがんばっても推測でしかないのでちゃっちゃとやっちゃった方がいい的な。 - たださすがに数百人のプロジェクトでこれをやっちゃうと大変な事になりそう。 - ただ大規模になればなるほど、先の方の見積もりの信用度は落ちるのも事実 ## 疑問 --- # 実践編：この先の計画を立てる Scene No.06　いつ何が手に入るのか？ ## 目安の時間 - 10分 ## 感想・気づき - 先の見通しを立てるリリース計画を行うが、リリース計画は何度も見直す必要がある。 ## 疑問 - リリースに関する作業については外部サービス連携、全体テスト、セキュリティ診断などのタスクがあり、開発チーム以外の方々が入ってくるため、先を予測することが難しそう。また、どれぐらいの期間で見積もっておけばいいのか、リリース日までにどれぐらい予備日を取っておけばいいのかが気になります。（福田） --- # 実践編：詳細な計画を立てる Scene No.07　ちゃんと計画できたかな？ ## 目安の時間 - 10分 ## 感想・気づき - スプリントゴールとは本当に達成したい目標で、それを理解することが重要。 - タスクの洗い出し・分解を漏れなくするのが、なかなか難しい。やってみて気づくことが多々あります。 - 「スクラムチームが判断できる量でないと、うまくいかないんだな」期待されているリリース日までに～～逆算した計画を作るのが目的ではない - PBIだけではすべては伝えられないので、よりうまく伝えられるように資料を用意するとか… スプリント計画の前にPOに確認するべき - 「終わった」ことをどうやって確認するかを決めておこう終わりの条件を以前定めた。 ## 疑問 --- # 実践編：素早くリスクに対処する Scene No.08　スプリントは順調かな？ ## 目安の時間 - 10分 ## 感想・気づき - "開発チームが"プロダクトオーナーや他の誰かに今の状況を聞かれても、すぐに答えられるようになっていれば、デイリースクラムは終了だ。 * 開発チームメンバー全員が毎日同じ目線になっているのが重要と感じた。 - 目的を理解していないと進捗報告会になってしまう - デイリースクラムはただの進捗報告会とせず、何か問題があるかどうかを見つけるために行う。 - 小さく見える問題でも、早いうちに見つけて解決しておく ## 疑問 --- # 実践編：状況をうまく把握する Scene No.09　これって間に合うのかな？ ## 目安の時間 - 10分 - 軌道を微修正していく・・・透明性を大切にしている。 - 毎日検査することで見つかった問題をその都度処理していくことで微修正をおこなう。 - なかなかみつけにくいようなことは色々な人の視点を使わないといけない。それぞれが気づく事を集めれば、問題になる前に見つけることができるんだ。 - とにかくゴール達成に向けて障害となりそうな課題をみんなで共有することが大切と感じた。:+1::+1: - スプリントのタスク進捗具合をグラフ化すると、より理解しやすく、問題を見つけやすくなる。 - 何かがうまくいっていないと感じるときは、スクラムチームが見落としている事があるかもしれない。まずは、それを透明にすることから始めて見よう。 - どんな課題であってもとにかく把握することが大切と感じた。:+1: - どんなにささいなことでも、なにかに気づけば必ずチームに共有すること。個人で判断しない。もしかしたらそのささいなことがプロジェクトに大きな影響を与える可能性があるかもしれない。:+1: - スプリントの期間は思っている以上に短いので、どんな些細なことでも見逃さないようにして、スクラムチーム全員で対処しよう。 - 自分で何とかしようとしがちなので、報告・相談するのが大切。:+1: ## 感想・気づき ## 疑問 --- # 実践編：何が完成したかを明らかにする Scene No.10　だいたい終わってまーす!! ## 目安の時間 - 10分 ## 感想・気づき - スプリントレビューの前に動作確認をすることの大切さ:+1: - 説明するのはプロダクトオーナーの役割らしい - プロダクトバックログに書かれていることは、あくまでも書いた時点でのプロダクトにとって良いと仮定したものであり、それを検証するイベントがスプリントレビュー:+1::+1: - デモができるだけではなく、中身も完成しているかどうか担保するための完成の定義 - 完成の定義は実際のリリースで求められる品質基準とは分けて考えても良い。 - 何が完成したかは二つの視点で明らかにする。開発チーム目線とプロダクトオーナー目線。:+1: - 何をもって完成したのかは、人によって認識が違うので、スクラムチームで合意のもと、完成の定義を決める - 実際にできあがったものを触ってみると、とても使いにくいものだと気づいたりする。これがプロジェクトの方向を修正するための手がかり - POレビューは、ただの実績報告ではない。方向を定めるもの。 ## 疑問 --- # 実践編：先を予測しやすくしておく Scene No.11　あともう1日あれば…… ## 目安の時間 - 10分 ## 感想・気づき - タイムボックスは譲れない！ - さまざまなイベントがあるが、今後は時間を意識したいなと思った。 - タイムボックスの考え方は、"終わるまで何時間かかる"と言った考え方とは逆:+1: - はるか先のリスクまで考え抜いたりするのはとても大変なこと。 - 扱うものが小さくなれば、確実にこなすことができる。そうすればプロジェクトは確実に前にすすんでいくんだ。 - １～３スプリントでは小さな一歩だったが、慣れていくにつれて徐々にスピードも上がってきた気がする。:+1: ## 疑問 - 1日の作業時間を毎日大幅にオーバーするような場合は、タイムボックスを守っているといえるのか？ - スプリントの期間とは、一般的にはどこからどこまでを指すのでしょうか？ --- # 実践編：次にやることを明確にする Scene No.12 少し早く終わったぞ!! ## 目安の時間 - 10分 ## 感想・気づき - 順序をつけるときは、直近の数スプリント分ぐらいに注力。早く実現したいものが漏れていないか気をつけてさえいれば、順序はそこまで厳密に考えなくてよい。 - 少しでも良くしようとするのが、スクラムの原動力。プロダクトバックログに誰も追記しなくなっていたら良くない兆候:+1: - プロダクトバックログとはすべてが記載されている一覧でなくてはならない。:+1::+1: - 予定より早く終わった場合は普段できていないことを充実させるのもいいし、次のプロダクトバックログの項目をやればいいとのこと。 - プロダクトバックログに追記するのに気兼ねをする必要はない。プロジェクトにとって大事だと思うことは追記していこう。:+1: ## 疑問 --- # 実践編：みんなの自律を促していく Scene No.13 全員揃っていないけど... ## 目安の時間 - 10分 ## 感想・気づき - チームでの合意の元、うまくスクラムを回すためのルール作りを行うといいらしい - 自律した状態が良いスクラムチーム - 人は無意識のうちに問題点や欠点を探してしまうが、なるべくうまくいったことを見つけることが重要:+1::+1::+1::+1: - それにしたがって行動し、守れないときは何のためにその規律が必要なのかを何度も考えてみよう。～～～何度も何度も考えていけば、自然と身についていくものなんだ。 - チーム全員でお互いの状況を同期しながら進めることが重要:+1::+1: - チーム内でルールを決めたほうがいいとのこと。 ## 疑問 --- # 実践編：ベロシティを上げていく Scene No.14 もっと早くできないの！？ ## 目安の時間 - 10分 ## 感想・気づき - ベロシティに求められるのは安定していることなんだ。 - ベロシティが安定しているスクラムチームは、全員が協力して作業を進めているからだ。:+1: - 我々のチームはだいたい32～33くらいで安定している。 - 早いマシンを提供する、無駄な会議を減らすなど、ベロシティを上げる方法はある - ベロシティはあくまでも安定していることが重要であり、上昇であってもそれが良いとは限らない:+1::+1: - ベロシティはそれ自体を操作して"どうこう"するものではない - どのように教育して立ち上げていくかを考える必要がある。 - ベロシティを上げてほしいという声に惑わされることはよくない:+1: - ベロシティは勝手にはあがらない ## 疑問 --- # 実践編：問題を見つけやすくする Scene No.15 え？POがいないの！？ ## 目安の時間 - 10分 ## 感想・気づき - スクラムイベントには必ずPOは参加、忙しく予定が空いていなければ都合のいい時間に変更する - POレビュー以外にスプリント振り返りやプランニングにも参加する必要があるみたいだが、現状はPO抜きでやっている - プロダクトオーナーを支援するのもスクラムマスターの大事な仕事 - ＰＯがＯＣＬの開発以外で何をやっているか知らないし、そこまでＰＯと距離が近くない気がする - 問題がどこにあるかをすぐ把握するためにロールはある - 現状OCL開発では、プロダクトオーナーがチームの一員感が低い ## 疑問 - POを途中で変えるのはアリか？ - POを１人ではなく、複数人というのはアリか？ --- # 実践編：意図を明確にしておく Scene No.16 うまく伝わってるのかな？ ## 目安の時間 - 10分 ## 感想・気づき - PO・開発チーム間で齟齬を生じさせないためにユーザストーリー形式で書く - 我々のＰＢＩでは「～～～として」「それは～～～したいからだ。」が無いため、デザインや実装の段階で悩むのかな - 同じものについて話しあっているようで実は考えていることが違う - うまく伝えるために、エレベーターピッチやユーザーストーリーなど、フレームワークをもっと活用したいと思いました。 --- ## 疑問 # 実践編：スクラムチームを支援していく Scene No.17 何かがおかしいぞ！？ ## 目安の時間 - 10分 ## 感想・気づき - うまくいかなくなる原因で一番多いのは、扱いにくいコードが増えてしまうこと。どこかで日々の作業で対応できなくなってしまったら時間を取って対応する必要がある。 - タスクをどんどん進めるだけでなく、たまにはコードの手入れも必要。なるべくきれいなコードを書くのを日々意識する（なかなか難しいかもしれないが。。。。） - 納期を守るためなら仕方が無いと見過ごしてしまうのは、スクラム以外のやり方に慣れた人が陥る - 無理に進めても傷口がは広がっていくので、対処は早い方がいい。 - APIの入力値チェックのところなど、問題点は早いうちにわかっていたのに機能を作ることを優先したので、現在かなり大きめの問題になっている・・・ - 無理に進めても傷口は広がっていく。～問題に対処するための項目をバックログに追加して時期を調整しよう - これまで書いたコードをいつも開発しやすい状態にしておくのも開発チームの仕事 ## 疑問 - 問題だと思うことはデイリーやスプリント振り返りである程度出てくるが、改めてみんなで集まって話し合う方がいいかなぁ --- # 実践編：よりよい状態にしていく Scene No.18 すぐに解決できないよ・・・・・ ## 目安の時間 - 10分 ## 感想・気づき - 問題を把握しておくことが大切。 - "プロダクトオーナーが他の業務の影響でプロダクトバックログをみる時間すらないなら、その問題を生む原因の法を障害と考える" - オーナーの問題を解決することも視野にいれる - 開発を進めるうえで問題はつきもの。～問題を把握する機会として、デイリーなどのスクラムイベントがある - 問題を見つけたらタスクシートに張って、全員で見えるようにするといいかも。:+1: -　根本的な問題を障害と考え、それを取り除く必要がある - 使いにくいツールを文句も言わずに使っているのもそうだ。～「こうすればもっと良くなるのに」と思うことを見つけよう。 - 妨害リストは今思いつくだけでも１０個くらいある - その問題を生む原因の方を障害と考える。 ## 疑問 --- # 実践編：先のことをいつも明確にする Scene No.19 今後のことがわからない！？ ## 目安の時間 - 10分 ## 感想・気づき - プロダクトバックログを常に整理すること(現在ファイル自体をスプリントのタスク洗い出しの時にしか触っていないような・・・) - 現在の開発チームには常にPBIをグルーミングする文化がないのでPOレビュー時にPOに確認してもらい進めている - 今後のことは最新の情報をもとに考えるべき。ゴールを達成していくための最善の方法を見つけていこう - 慣れていないのもありますが、最新の情報の確認ができていない。（今後の予定を明確にしていない。） ## 疑問 - プロダクトバックログでPOからの直接指示がないような。 - グルーミングのイベントを作るならPOレビュー時ではなく、スプリントの半分あたりが良い？ - PO中心にプロダクトバックログに記載されている項目順序の見直しを取り込んでいくとのことだが、POも普段オーナーレビュー以外のタイミングでバックログアイテムを見ることがあるのだろうか - バックログの順序を見直す基準はどういうものか --- # 実践編：手戻りをなくしていく Scene No.20 本当に着手していいのかな？ ## 目安の時間 - 10分 ## 感想・気づき -　次回の準備まで手がなかなか回らない。（スクラムマスターに任せすぎ？） -　前回のステークスホルダーとの共有が大きな一歩だった。 - 手戻りが起きやすいのは、何を実現したいかがあいまいなときだ。 - ７月以降で実現したいPBIがまさにその状態。そのため、ステークホルダを集めてヒアリングを実施する旨を伝えた。 - プロダクトオーナーは、理解を助けるための準備をしておこう。例えば～～イメージできる資料を用意するといい。 - この本のプロダクトオーナーがスーパーマンすぎる。現実的にはオーナーひとりでは難しそう - ステークホルダーの能動的な協力があって目指すべきゴールが明確になる ## 疑問 -　システム以外の展望（売り上げ目標・競合・ペルソナ）などが共有できているのかな？ --- # 実践編：ゴールに近づいていく Scene No.21 あれ⁉　間に合わない‥‥‥ ## 目安の時間 - 10分 ## 感想・気づき - 品質は下げれない。予算は少なめがいい。＝仕事の進め方やスコープの見直しがゴールに近づく方法。「仕事の進め方は慣れている方法」でやりがちになっていそうなので、詰まった時ほど見直すことが必要。 - 実現する方法で調整するのもスコープの調整 - 管理者用の機能をイチから画面を作るのではなく、ノーコードで実現するなど - 開発を進めるうえで調整できるものは4つのみ（品質、予算、期間とスコープ）、この中でもスコープをまず調整していこう。 - 最初に決めたスコープを守ることより、ゴールを達成することが重要 - 周りからリリースに含めてほしいといわれていても、削れるものは削る - なぜならゴールは常に動いていくものだからだ ## 疑問 --- # 実践編：さまざまな状況に対応する Scene No.22 この作業は苦手です‥‥‥ ## 目安の時間 - 10分 ## 感想・気づき - 特にバックエンド開発はほとんど携わってこなかったので、いい機会だと思いもっと関わりを持って自分のスキルにしたい。開発スキル以外でもっと役に立てることもあるのでは。 - 状況に応じて誰かがリーダーシップを発揮する - みんなで助けあって、苦手を克服していく。「私はここまで担当」といったことを発生させないのが理想。:+1: - 誰かが困っていたら、ほかの人が助けるんだ。その状況で、苦手だからとか自分の役割はこうだとか考えていては手遅れになってしまう。 - 機能横断的なチームが理想 - 一人ひとりが全部を完璧にこなせるようなスキルを持つことじゃない～～一人ひとりではなく開発チーム全員でうまく協力できていれば十分だ。 ## 疑問 --- # 実践編：より確実な判断をしていく Scene No.23 それぐらいはできるよね⁉ ## 目安の時間 - 10分 ## 感想・気づき -責任を持つということは自分の実力をきちんと把握すること。チームで行っているのだから少しでもわからないことは相談する。思い込みも失敗のもと。（失敗も大事だが、少しでも失敗を回避する） - デイリースクラムでは今日何を終わらせるかを約束する。 - 今後は意識して報告したい。 - 最初は失敗してもいいから自分たちでやれるかどうか判断する - 最初からうまくできるわけではない。失敗したら、その経験を次に生かす - 失敗したらなぜ間違ったかを考え、次につなげることが大事 - 約束を守るために無理はしない　　- 責任をもって守れる約束をする ## 疑問 --- # 実践編：リリースに必要なことをする Scene No.24 やり残したことはないかい？ ## 目安の時間 - 10分 ## 感想・気づき -リリース時に思わぬエラーが出ないようにするには、どの段階で「確認」「テスト」をするのか決めておく事が必要。 - リリーススプリントまでになるべく作業を残さないほうがいい - やれそうなことはリリーススプリントまで持ち越さずにどんどん前倒しで取り組んでいこう。 - やるべきことが分かっていて、リリースまでにやらなくてはいけないことは取り組んでいく。 - リリースに必要なことはできる段階で早めに行っておく - リリースにはどんな準備が必要かわかっている必要がある - 開発以外のリリースに必要な作業（既存ユーザーへのお知らせ文など）も、プロモや営業チームと相談してじわじわ準備を進めなないといけなさそう - 自分たちにあったリリーススプリントのやり方を定義して進める ## 疑問 --- # 実践編：実践編で伝えたかったこと Scene No.25 ここからが始まりさ⁉ ## 目安の時間 - 10分 ## 感想・気づき - 常に改善をする意識が大事。(失敗体験・成功体験の共有) 本ではスプリントが終了しているが、このチームでのリリースはまだ先なので改善点を見つけていくようにしたい。途中からだったので初期の経過や開発の日程の詳細はわかりませんが、下記項目は改善点の一つだと思います。１，設計図の作成（画面仕様書・インターフェース仕様書）など。２，テストは小さい規模のうちにした方がエラー個所も見つけやすい。（単体→結合→総合） - スクラムは毎日の経験を通じて体験して学んでいく仕組み - 毎日デイリープランニングやチーム内での情報共有があり、またWebexがつなぎっぱなしになっているため他の方のノウハウだったり色々と学ぶことができる - スクラムを経験したチームをたくさん用意できないようであれば大人数での開発はやめた方がよい。 - 大規模開発においてとりあえずアジャイルでやっている開発現場があったが、中身は中途半端なウォーターフォールになっていた。やはりある程度スクラムを経験した要員が集まらないと厳しいと思った。 - スクラムはうまくいっていないことを見逃さず、対処しやすいように以下のことを提供してくれている - スクラムは開発の状況を見える化し、改善するためのプラクティスだとおもった。 - スクラムはどこがうまくいっていないかを特定しやすいなどの特徴を提供するだけで、これを活用するためにはチームにあったカイゼンが必要 - スクラムの本質は、チームで学んでいくための仕組み ## 疑問 - スプリントレトロスペクティブは問題解決のイベントではなく、今回は詳細を省いたとあるが、どこかで紹介されているのかな？ --- END

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.