distributed-agile-team.connpass.com
こちらのイベントに参加してきたので、会の様子と感想を書いていきます。
- フルリモート環境でスクラム開発を成功させる3つのポイントを見る
- DevOpsの時代を見る
- DBを使った自動テストってみんなどうやってるの？
- 品質問題から始まったWhole TeamアプローチとAgile Testingマインドセットの改善物語を見る
- 全体を通した感想
フルリモート環境でスクラム開発を成功させる3つのポイントを見る
まずは直近公開されたこちらの動画を見ていきました。
Azure DevOpsを中心とした具体的にフルリモート環境で使えるツールの紹介や、ドキュメントよりも会話でのコミュニケーションを重視していくための施策、コンテキストを揃えるための工夫の話をしてくれました。
マインド的な話ではなく、かなり具体的に、どういう取り組みをしたのか？どういうツールをどう運用したのか？という話をしてくれて、参考になる部分が多くありました。
DevOpsの時代を見る
続いて川口さんの話を聴いていきました。
川口さん味が激しいセッションで、川口さんが好きなDevOpsに関する話を(時たま時間を気にしつつ)時間が許す限りどんどんと語ってくれて、DevOpsの源流を辿れるようなセッションになっていました。
DevOpsのよさのみならずカンファレンスの良さについても触れられていて、全体を通して共感がすさまじいセッションで楽しかったです。
DevOps Tokyo2022の前に聞くことができて非常によかったです。
DBを使った自動テストってみんなどうやってるの？
DBを使ったインテグレーションテストが遅くて(30分ほど)困っているが、本番では同じようにDBを使っているのに遅くないため、皆がどのように自動テストをしているのか聞きたいというテーマでOSTをしていきました。
以下のような話が出ていました。(OSTなので、必ずしも本テーマに関わる話があるとは限りません)
- 遅いのが困っているならモックを使う手もある。ユニットテストはスピード第一(TDDを心地よくできるスピード感)でやっているのでモックを使っている。
- インテグレーションテストは本番と違ってテストを直列に実行させているからだという可能性もある。
- 並列にテストをした方が速く終わると思うが、並列にテストをすると、テストがフレーキーになってしまうリスクがあるので直列にテストをした方がいいと感じている。
- 並列にテストをする(処理が実行される)ことが本番ではありえないなら、並列でやる意味は薄いかもしれないが、並列に実行されることがあり得るならむしろ意図的に並列でテストをした方がよいのでは？テストがフレーキーになったら、プロダクションコードの設計が悪いんだよね、という話になるので嬉しい。意図的に処理を分散させたり意図的に並行にテストをすることがよくある。
- テスト環境とプロダクション環境でのスペック差を比較してみる。
- トランザクション数の差分を見るなど、パフォーマンスに寄与する定量的なデータを収集することで原因がわかってくるはず。
- テストのデータセットに時間がかかっている可能性があるので見直しする。
- 例外処理はユニットテストを使用している。ユニットテスト以外だとコストが高いので。
品質問題から始まったWhole TeamアプローチとAgile Testingマインドセットの改善物語を見る
最後にじゅんぺーさんの動画をみていきました。
非常に厳しい状況から実際にどのようにチームを立て直ししていったのか、という物語を聴いていったのですが、めちゃくちゃいい話でした。
まずは小さくてもいいので相手の問題を解決していって、徐々に信頼を勝ち得ていくというスタイルは共感できたと共に、じゅんぺーさんのスキルの高さもまじまじと実感しました。
全体を通した感想
今日は普段見ている動画とは毛色が違うものを見ていったので、いつもよりも技術寄りのテーマが多く、面白かったです。
また、DevOpsDays Tokyoの動画はDevOpsDays Tokyo2022の前に見返しておきたいと思っていたので、3本も消化できてありがたかったです。