【勉強会メモ】スクラム道関西 第115回オープン・ジャム
いつもどおり Lean coffee 方式でテーマを決めて話し合いました。今回は参加者が出したテーマをDot投票で同時に3つ選んでグループ分けをし、自分が興味を持ったテーマのグループに加わって議論をしました(途中で別のグループに移ってもOK)。30分経つと別の3つのテーマに切り替えてまたグループ分けします。これを3回くりかえしました。
RSGT2019の感想
Regional Scrum Gathering Tokyo 2019に参加した人から感想を聞きたいというテーマでした。
- 初めてでも参加しやすい雰囲気で次も参加したいと思える内容だった
- セッションだけでなくワークショップ形式もあってよかった
- ワークショップは心理的安全やふりかえりなどについて考える内容
- 来年の参加に向けて会社に話を通すために実績を積みたいと思った
- 登壇を目標に1年間取り組むのが良いかも
- プロポーザルに応募すれば採用されなくても参加する理由になる
- トレンドを感じたテーマは「サーバントリーダー」
- 印象に残ったセッション
- スクラムならできる プロダクトバックログの戦略
- 現場の取り組みや試行錯誤に共感
- 東名阪をまたいだLeSS Huge(大規模スクラム)においてスクラムマスターとして実践したこと
- 大規模スクラムの事例が参考になった
- 学習する/Unlearnするチームへ ー 新卒研修とスクラムとモブプログラミング ー
- よなよなエール流 熱狂を生むチームづくり ~8年連続赤字から13年連続増収増益までの軌跡~
- 会社も取り組みも個性的で変わっていて面白かった
- スクラムならできる プロダクトバックログの戦略
- 資料は id:scrummasudar さんのブログが参考になる
開発ドキュメントを残すか?
スクラムに取り組むようになって仕様書などを何も残していないが属人性の不安などがある場合にどこまでドキュメントを残すのが良いか?
- そもそも必要か?ドキュメントが無くても問題になっていないチームもある
- 何が必要かチームで話し合ってみる
- ドキュメントが無いことがふりかえりで問題になった時に改善する
- 仕様が複雑な機能など、必要な時だけ作る
- ドキュメントがある事よりもコードを見れば容易に理解できる状態を目指すこともできる
- テストや静的解析の自動化によって人に依存しないチェックも可能
見積もりやる?やらない?
基調講演の中で「見積もりはしない」という話が話題になっていた。
Regional Scrum Gathering Tokyo 2019 - Learning to Experiment | ConfEngine - Conference Platform
- 開発するものや事業にもよる
- 受託の場合は求められたら見積もる必要がある
- 自社開発は細かく見積もらない場合が多い
- 自社内でも事業側への説明のために見積もりが必要になる
- 見積もりしても当たらない
- 幅で見積もる(最大〜最小)
- 不確実性コーン を意識する
- 見積もりが約束になる
- 断定的な伝え方をしない
- バッファをもたせすぎても見積もりが相手に信頼されなくなる
- 最低どのくらいか?正直ベースでどのくらいか?
- CCMPという手法もある
- Tシャツサイズの見積もり
- すべてがSサイズになるように分割できれば見積もれる
- 開発者は細かく見積もりたい
- 見積もりを求めるとコードを読み始める
- コードを追いかけないと不安
- 「既存システムの制約上これ以上分割できない」という議論が起こる
- 見積もりを実績と比較するか?しないか?
- 比較しないなら細かく見積もる意味がない
- チームの健康状態程度の把握程度にする
- 若手社員に「見積もりは無駄」と教えるのは抵抗がある
- 計画的な業務実施、見込みのたて方など見積もることによって学ぶことも多い
- 実績との比較ではなく若手とベテランのコミュニケーションの手段として見積もる
※参考