利用する開発環境を使って作ったゲームを公式サイトなどから見つけます。
見つけたゲームの中から、これから開発するゲームに近いジャンルのゲームを見つけます。
そのゲームを実際にプレイし、この開発環境を使うとどの様なゲームを作れるのかを確認します。
ソースコードも配布していたら、参考にするためダウンロードしておきます。
代表者はそのゲームのへのリンクをプロジェクトフォルダ内に作成して下さい。
リンク名は「参考ゲーム.url」とします。

こちらの演習1-3を参考にして、代表者は GitHub 上に新規でパブリック・リモートリポジトリを作成します。

※ リポジトリ名は「team(チーム番号)」としてください (例) 1班なら team1

※ パブリック・リモートリポジトリなので著作権等に注意して下さい

代表者は端末を開いてリモートリポジトリを clone します。
代表者はローカルリポジトリ内にある .gitignore (もし無ければ作成して下さい。先頭のドットを忘れずに)を開き、テンプレートの内容をファイルの下部にコピーして上書き保存して下さい。

※ .gitignore は git の管理から外すファイルを指定する設定ファイルです

代表者はローカルリポジトリの中に移動し、以下のコマンドを実行して .gitignore を add/commit して下さい。

git add .gitignore
git status
git commit -m "gitignore 更新"
git push

※ git push でIDとパスワードを聞かれたら入力して下さい

再び GitHub に戻り、 こちらを参考にして代表者は他のチームメンバーにインビテーションを送ってコラボレーターとして登録をします。
各メンバーはリモートリポジトリを clone します。
代表者はリモートリポジトリへのリンクをプロジェクトフォルダ内に作成して下さい。
リンク名は「リモートリポジトリ.url」とします。

A〜Dさん役を決めます。
AさんはGreenfootを起動して新規シナリオを作成します。

シナリオの保存先として演習 2-2 で作成したローカルリポジトリを指定してください

※ シナリオ名は「game(チーム番号)」としてください (例) 1班なら game1

Aさんは「World」のサブクラスとして「MyWorld」を作って下さい。キャンパスの大きさ、背景画像等の設定は後で変更出来ますので今の所は任意の設定で構いません。
一度 Run して下さい。
Aさんは端末を開き、ローカルリポジトリの中に移動します。
AさんはGreenfootを閉じてから ※ 一度 Greenhoot を閉じないとGreenfoot の設定ファイル(project.greenfoot)が保存されない様です

git status
git add .
git status
git commit -m "新規シナリオ作成"
git push

の順にコマンドを実行してローカルリポジトリとリモートリポジトリを更新して下さい。
B〜Dさんも端末を開き、ローカルリポジトリの中に移動します。
B〜Dさんは

git pull --no-edit

を実行してローカルリポジトリを最新状態に更新して下さい。

※ --no-edit オプションを付け忘れると端末の画面が切り替わってコミットのメッセージを求められる場合があります。
その場合は「適当にコメントを入力する → ESC 押す → :wq と入力する → Enter 押す」の手順でコミットメッセージを入力して下さい。

提出物はありません。

全員 Greenfoot を起動し、演習 2-3 で作成したシナリオを開いて下さい。
全員 Actor のサブクラスとして適当なキャラを作って下さい。名前、画像は適当で構いませんが、打ち合わせて他の人と同じ名前にならないようにして下さい。ソースの中身は空で構いません。
一度 Run して下さい。
Greenfootを閉じてから ※ 一度 Greenhoot を閉じないとGreenfoot の設定ファイル(project.greenfoot)が保存されない様です

git status
git add .
git status
git commit -m "(自分の記号(A〜D))がキャラ追加"

の順にコマンドを実行してローカルリポジトリを更新して下さい。
他のメンバーの更新内容を取り込むために

git pull --no-edit

を実行して下さい。
git pull した際に、もし端末に

CONFLICT (content): Merge conflict in project.greenfoot

と表示された時は Greenfoot の設定ファイル(project.greenfoot)に衝突が生じましたので Greenfoot を再起動して下さい。
すると Greenfoot が自動的に設定ファイルを修復します。
衝突を修正したら (4) に戻ります。

※ 時々キャラ画像の指定が外れている場合があります。その場合は右クリック → Setimage から画像を指定し直して下さい。

衝突しなかったら

git push

を実行してリモートリポジトリを更新して下さい。
全員の git push が終わったら、最後に全員が

git pull --no-edit

を実行してローカルリポジトリを最新状態に更新して下さい。
提出物はありません。

全員は再びGreenfootを開き、Aさんが作ったキャラに対して同時編集をします。
A さんは↑を押したら上に移動する処理を書いて動作確認して下さい。
B さんは→を押したら右に移動する処理を書いて動作確認して下さい。
C さんは↓を押したら下に移動する処理を書いて動作確認して下さい。
D さんは←を押したら左に移動する処理を書いて動作確認して下さい。
Greenfootを閉じてから

git status
git add .
git status
git commit -m "(自分の記号(A〜D))がキャラ移動処理を追加"

の順にコマンドを実行してローカルリポジトリを更新して下さい。
他のメンバーの更新内容を取り込むために

git pull --no-edit

を実行して下さい。

git pull した際に、もし端末に

CONFLICT (content): Merge conflict in (衝突ファイル名)

と表示された場合は衝突が起きました。
設定ファイル(project.greenfoot)は自動で修復されますが、それ以外のファイルは手作業で修正する必要があります。
まず

git status

を実行し、衝突しているファイル( both modified マークが付いているファイル)を確認します。
次に Greenfoot を起動し、衝突しているファイルを開いて衝突箇所を修正し、Run ボタンを押して動作確認します。
衝突を修正したら (6) に戻ります。

衝突しなかったら

git push

を実行してリモートリポジトリを更新して下さい。
全員の git push が終わったら、最後に全員が

git pull --no-edit

を実行してローカルリポジトリを最新状態に更新して下さい。
提出物はありません。

代表者は要求仕様書のテンプレートファイル(yokyu.docx)をプロジェクトフォルダ内にアップロードして「要求仕様書.docx」に名前を変更して下さい。
メンバー各自は要求仕様書を開き、班名と氏名を記入して下さい。
開発チーム(自分達)がユーザー(自分達)に対してヒアリングを行い、どういうゲームをユーザーが作って欲しいと思っているのかを理解して箇条書きやイラスト等にまとめて下さい。なお

• フォーマットは任意です。
• 大雑把な内容で構いません。
• 実際に出来るかどうかはこの時点では考えなくて良いです。

ユーザー(自分達)にゲームの名前を決めてもらい、要求仕様書に記述して下さい。

代表者は全体仕様書のテンプレートファイル(zentai.docx)をプロジェクトフォルダ内にアップロードして「全体仕様書.docx」に名前を変更して下さい。
メンバー各自は全体仕様書を開き、班名と氏名を記入して下さい。
全員で話し合い、要求仕様書を元に全体仕様書を作成して下さい。

• 要求定義で出てきた荒唐無稽な内容が実現可能か吟味し、無理そうなら除外します。
• ウォーターフォールと違って細かい仕様まで決める必要はありませんが(※)、要求定義の時よりは具体的な内容にして下さい。
• キャラクターやステージ等のイラストは簡易的なもので構いません。

※ プログラムする際に必要となる細かい仕様はスプリントに入ってから決めます。

代表者は企画書のテンプレートファイル(kikaku.pptx)をプロジェクトフォルダ内にアップロードして「企画書.pptx」に名前を変更して下さい。
全員で話し合い、全体仕様書を元に企画書を作成して下さい。
発表者と記録係を選びます。
発表者はプロジェクタに映した企画書をプレゼン参加者に 1 分以内で説明します。
2 分間ディスカッションします。ディスカッション内容は記録係が記録します。
全てのチームのプレゼンが終わったら、ディスカッションで出た質問や意見を全体仕様書に反映させます。

こちらを参考にして、代表者はリモートリポジトリの Projects タブを開き、「プロダクトバックログ」という名前でカンバン(プロジェクト)を新規作成します。
他のメンバーもプロダクトバックログを表示し、 全体仕様書を元にチーム内で話し合いながらバックログアイテムを作成・登録していきます。

※1 担当者名は入れなくて良いです。
※2 「オンラインマニュアル作成」をアイテムに含めるのを忘れないで下さい

代表者はプロダクトバックログへのリンクをプロジェクトフォルダ内に作成して下さい。
リンク名は「プロダクトバックログ.url」とします。

代表者はプロジェクトフォルダ内に「スプリント(スプリント番号)」というフォルダを作成します。(例) スプリント1なら「スプリント1」
代表者は最新の全体仕様書をスプリントフォルダ内にコピーします。
代表者はコピーした全体仕様書の名前を「全体仕様書(スプリント番号).docx」に変更します。(例) スプリント1なら「全体仕様書1.docx」
全員がコピーした全体仕様書を開き、話し合って全体仕様書を見直します。
スプリント2以降なら前のスプリントで実施したレトロスペクティブやユーザーからのフィードバックも参考にして下さい。
「プロダクトバックログ」のToDo列に含まれるバックログアイテムの修正も合わせて行います。

みんなで話し合ってこのスプリントで実施するバックログアイテムを選択し、Doing列に移動します。

代表者はスプリントフォルダ内に「詳細仕様書(スプリント番号).docx」を作成します。フォーマットは任意です。(例) スプリント1なら「詳細仕様書1.docx」
みんなで話し合って今回のスプリントで実装予定の内容を文章や箇条書き、クラス図、表、グラフ、イラスト等で詳しくまとめて下さい。

• フォーマットは任意です。
• 画像のサイズとかキャラクターの画像や移動スピードなど、かなり細かい数値まで具体的に決めて下さい
• 仕様は逐次見直し可能なので、深く考えず素早く仕様を決めて下さい
• クラス図やシーンの遷移図、画面等のイラストがあると今後の開発が楽になります
• イラストは再利用可能な様に手描きではなくてドローツールやイラストレイター等を使って作成して下さい
• ネットにある素材を使用する場合は必ずライセンスを確認して下さい。もしフリー素材を使用する場合は必ずアドレスも貼り付けて下さい

こちらを参考にして、代表者はリモートリポジトリの Projects タブを開き、「スプリントバックログ(スプリント番号)」カンバンを新規作成します。(例) スプリント1なら「スプリントバックログ1」
他のメンバーも作成したカンバンを表示し、 詳細仕様書を元にチーム内で話し合いながらスプリントバックログアイテムを作成・登録していきます。
その際に作業担当者も決めて名前(個人特定されないように要注意)も記入して下さい。
代表者はプロダクトバックログへのリンクをプロジェクトフォルダ内に作成して下さい。リンク名は「スプリントバックログ(スプリント番号).url」とします。(例) スプリント1なら「スプリントバックログ1.url」
スプリントバックログの ToDo の中にある作業の中から、各自が最初に実施する作業を一つ選んで Doing 状態に変えます。 ※ 依存関係に注意

相互に現状報告をしあってください。
相互にスコープ確認しあってください。
今後のスケジュールを確認しあってください。
もし詳細仕様の変更が必要なら、全員で話し合って詳細仕様書とスプリントバックログを更新して下さい。
もし全体仕様の変更が必要なら、全員で話し合って全体仕様書とプロダクトバックログを更新して下さい。
スプリントバックログを見て相互に本日自分が担当する作業の内容を確認しあってください。

各自はスプリントバックログで選んだ担当作業を行います。
適当なタイミングでローカルリポジトリを更新します。

Greenfootを閉じてから

git status
git add .
git status
git commit -m "(適当なコメント)"

の順にコマンドを実行してローカルリポジトリを更新して下さい。
担当作業が終わったら、他のメンバーの更新内容を取り込むために

git pull --no-edit

を実行して下さい。
もし衝突が起きたら演習 2-5 の手順で修正してください。

衝突しなかったら

git push

を実行してリモートリポジトリを更新して下さい。 ※ マナーとして git push するときは他のメンバーに「これから push する」と一声かけましょう。

対応するスプリントバックログのアイテムを Doing から Done 状態に変えます。
対応するタスクが全て終わったらプロダクトバックログも Done 状態に変えます。
スプリントバックログの ToDo の中に残っている自分の作業を一つ選び Doing 状態に変えて作業を再開します。
もし予定していた自分の作業が全て Done になっていたら他の人の手伝いをして下さい。

以下のチェック項目が全て満たされている事を確認して下さい。

スプリントバックログが全て Done 状態になっている(※)
今回のスプリントで実施する予定だったプロダクトバックログが全て Done 状態になっている(※)
リモートリポジトリにあるプロジェクトにはビルドエラーが起きない
リモートリポジトリにあるプロジェクトにはバグが無い
ライセンス違反をしていない
人格権違反や個人情報の漏洩をしていない

※ 時間内に Done 状態まで辿りつけなかったタスクは次のスプリントに回して下さい。

代表者はスプリントフォルダ内に「レトロスペクティブ(スプリント番号).docx」を作成します。フォーマットは任意です。(例) スプリント1なら「レトロスペクティブ1.docx」
全員で反省点や全体仕様書の見直し(※)などを話し合い、話し合った内容を記述して下さい。

※ ちゃんとした見直し作業はユーザーレビューも踏まえて次のスプリントのプランニングミーティングで行いますので、ここでは見直し項目を挙げる程度の簡単な作業で結構です。

代表者は Code → Download ZIP で最新リポジトリをzip形式で保存します。
zipファイルのファイル名を「(班番号)班-(スプリント番号).zip」に変更します。(例) 1班、スプリント1なら 「1班-1.zip」
スプリントフォルダ内にzipファイルをアップして下さい。

各チームのゲームをプレイし、スクラムマスターが用意したアンケート項目に答えてください。

github pages を使ってオンラインマニュアルを作成して下さい。フォーマットは任意です。
プロジェクトフォルダにリンクを張って下さい。リンク名は「オンラインマニュアル.url」とします。

代表者はプロジェクトフォルダに「クロージング.docx」を作成します。フォーマットは任意です。
全体を通した振り返りを書いて下さい(1人1行程度、名前も記入)