2024.04.15 Scrum Developers Night
1st Discussion ~20:50
ディスカッション1
デイリースクラムのアジェンダどうしてる？
なやみ
15分で終わらない
開発チームにアジェンダの改善も任せているが、方向性が迷子
意見がでるのはそれ自体素晴らしいこと
15分で終わらない、意図した方向に進まない、ことへの対応
どのコンテンツでどれだけの時間を使っているかを可視化する（透明性）
デイリースクラムにふさわしくない話題は別に切り出す
デイリースクラムで使っているツール
Slack, Miro
ディスカッション2
スクラム初期にプラクティスからはずれる内容を開発チームから提案されたらどうするか
スクラムに絶対に従わなければいけないわけでもない
ビジネスサイドからの要求もある
やってみてどうなるか自分たちで考えてみる
派生話題：スクラムマスターとしてどこまでチームに干渉したいか/どこで手を離したいか
チームから手を離していいサインが見えるといいんだけど、そういうものがわかりやすくあるわけでもない
2nd Discussion ~21:25
ディスカッション1
リリーススプリントのやり方がわからない！
毎スプリントやるのが難しいものをリリーススプリントへ
理想は、毎スプリントでやりきれること、そうするとリリーススプリントは不要に
なぜリリーススプリントと名づけるのか
大事なことを忘れない
ビジネスなどステークホルダーと開発チームをつなぐものとして
リリーススプリントに寄せすぎると、個々のスプリントでshippableなものができなくなってしまう
トランクベース開発だとデプロイとリリースが分離する、戦略次第
ディスカッション2
ストーリーポイントを設定するときのコツと、やらないほうがいいポイント
フィボナッチ数列・プランニングポーカー
3ポイントは1営業日以内、という制約をつけたり
1スプリントでどれくらいできるのかを見えるようにする
思ったより進まなかった場合は何が悪かったのかを考えて改善する
毎回改善すると言うのがウォーターフォールとの違う部分
失敗例
プランニングポーカーで人との間でずれる、そこの埋め合わせに時間を使ってしまう
フィボナッチ数列を使うことで軽量化できる
スクラムガイド、SCRUM BOOT CAMP THE BOOK
3rd Discussion ~22:10
ディスカッション1
進捗の報告方法などはどうしているのか
ウォーターフォールの場合との比較
バーンダウンチャートやバーンアップチャートを見せたりする
途中でやることが増えたりもするが、、スコープが調整できるならプロダクトバックログアイテムを落としたりもする
要件定義を最初に全部やり切らない、プロダクトバックログを育てながら開発する
請負だと難しい
ディスカッション2
トランクベース開発についての知見
懸念や課題
QAエンジニアがテストをするのはどこでやる？
エンジニアと二人三脚でやっていくといいのでは
ジュニアエンジニアがいると品質に信頼ができずに難しい？
レビュー、ペアプロでスキルアップを図ることで解決できそう？
人数が少ない時はブランチを切る方が複雑なのでペアプロモブプロでトランクベースにしちゃった方がいい？
人数が増えてきた時は逆に難しい？
リポジトリを分けたりする必要がある？
フィードバック
ありがとうございました みなさんのご意見伺って自分の現在地がつかめたような気がします
参加者の自己紹介があったほうがいいのかも
得てして発言が偏りがちなのがそうならなかったのがびっくりでした
各テーマごとにスレッド切ったほうがよさそうです
学びが多かった
同じような悩みや課題感を共有できてよかった
実際に悩んでいる人との会話は学びがあってとても良かったです。また、参加したいです。
developerの集まりは貴重なので、開催いただいて嬉しい
MIRO,Discord,Scrapboxの使い分けは気になりました（何に書くのが正しいのか？)
色々と学びがあり、実際に携わっている人の話を聞けることが出来たので良かったです
もうちょとMiroを活用できると議論の論点などわかりやすいかも？
テーマ内容がもっと数が出てやることを絞れるようになるとボッチにはならなかったのかなと感じました(（笑）)