とあるチームの1週間
2022年11月10日 木曜日
CONTENTS
今回はとあるチームの1週間をご紹介します。
スクラムの時間割
時間割の紹介です。
スプリント
スプリント(※1)を簡潔に表現すると “期間” のことで、スプリント(期間)内に仕様の決定、設計、開発、テストなど、システム開発に必要なほぼすべてのことを実施します。
スプリントはスプリントプランニング(計画)から始まり、スプリントレトロスペクティブ(期間のふりかえり)で終わります。
このチームでは1週間を1スプリントとしています。
(本来であればスプリントレトロスペクティブの後にスプリントプランニングを実施することが理想ですが、諸事情によりこのチームはスプリントプランニングを先に実施しています)
余談ですが、始業と終業はMicrosoft Teamsで宣言しています。
詳細は以前の記事をご覧ください。『Power Automateで祝日名を出力する』
金曜日
スプリントプランニング
スプリントの始まりです!
スプリント(1週間)の計画を立てます。
優先順位順の高い順に1スプリントでできる量のバックログをスプリントバックログに移動させ、タスクの最終確認や、1スプリントの詳細な計画を立てます。
月~水曜日
デイリースクラムで計画や進捗の確認をしながらスプリントゴールに向かって進めていきます。
開発以外にも、今後に向けてのバックログを整えたり、スパイク(※2)(技術検証)を実施したりしています。
開発はペアプログラミングをしていて、リモートワーク時も基本的にカメラONの状態でペアプログラミングしています。
わいわい雑談もしたり、出社していてもリモートワークしていても変わらない環境なので楽しいです。
木曜日
LT(ライトニングトーク)
毎週1チーム(4~5人程度)がひとり10分程度好きなことを話します。
“対話” を大切にし、役割問わず全員話す機会が多いので、話す練習として実施しています。
また、自分のチームの外にはどんな人がいるのか、どんなことが得意なのか、を知ることができるので “知らない人がいない” 状態になり、相談や雑談もしやすくなっていると感じています。
Masters会
スクラムマスターズ会です。
各チームのスクラムマスターが集まり、チームであったことや、アジャイルなマインドについてなど、様々なことを話す会です。
知見をためることができ、新しい気づきも多く、とても勉強になっています。
LTも同じですが、狭い世界で悩まず、多くの人と会話して理解を深めたり、問題を解決していくことができる環境がとても好きです。
金曜日
レビュー
1週間でできたものをプロダクトオーナーへレビューします。
動くものをベースに最終チェックをし、リリース可能か判定します。
リファインメント
日々整えているバックログの全体を見て内容のチェックや優先順位のチェックをし、今後の進め方を確認します。
共有会
Masters会での内容や、セキュリティについての啓蒙活動、会社として伝えたいこと、チームで共有しておきたいことなど話します。
品質や効率の話になると白熱した議論をしたりと、チームで会話する時間になっています。
スプリントレトロスペクティブ
1週間をふりかえります!
KPT方式でふりかえったり、話したいテーマを決めてふりかえったり、スプリントやチームによっても方法はさまざまです。
ホワイトボードやふせんを自由に使ってワイワイしています。
スプリントレトロスペクティブが終わると、1スプリントの終わりです。
そしてまたスプリントプランニングから新たなスプリントへ続いていきます。
最後に
1週間の流れをご紹介しました。
何かひとつでもご興味を持っていただけましたら嬉しいです。
それではまた次回お会いしましょう~伊藤でした~
注釈
- スプリント[↑]
スプリントはスクラムにおける心臓の鼓動であり、スプリントにおいてアイデアが価値に変わる。
一貫性を保つため、スプリントは1か月以内の決まった長さとする。前のスプリントが終わり次第、新しいスプリントが始まる。
スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブを含む、プロダクトゴールを達成するために必要なすべての作業は、スプリント内で行われる。
スプリントによって、プロダクトゴールに対する進捗の検査と適応が少なくとも1か月ごとに確実になり、予測可能性が高まる。スプリントの期間が長すぎると、スプリントゴールが役に立たなくなり、複雑さが増し、リスクが高まる可能性がある。スプリントの期間を短くすれば、より多くの学習サイクルを生み出し、コストや労力のリスクを短い時間枠に収めることができる。スプリントは短いプロジェクトと考えることもできる。
2020-Scrum-Guide-Japanese.pdf - スパイク[↑]
リリース可能なプロダクトを作るのではなく、質問に答えたり情報を収集したりすることを目的とした作業。 開発チームが技術的な質問や設計上の問題を解決するための実際の作業を行うまで、見積りができないようなプロダクトバックログアイテムが出てくることがあります。 解決策は、「スパイク」を行うことです。 目的は、質問に対する回答やソリューションを見つけることです。
スクラムにおける技術的スパイクの進め方