RSGT2022

https://2022.scrumgatheringtokyo.org/

RSGT 2022 に参加してきました。今年は、年始早々に会社の PC が壊れるなどで情シス作業に追われて、聞けなかったセッションが OST に参加できなかったのが残念です。


今年もこっそり?シルバースポンサーで参加させてもらっていました (笑)


どれもこれも聞きたいセッションで困りましたが、職業柄、QA、テスト、プロセス改善を中心にセッションを聞いてきました。(あとは録画を見ます)


シン・モブ・プログラミング 第三形態

モブプロの効果と問題点。自分たちもモブ作業を実施していますが、効果的に実践していくことを模索中であり参考になりました。

特に、発生した問題点というかネガティブな意見は同じようなところに行きついているので、ある意味安心しました(笑)


QAなんなん?~みんなが納得できるQAのスタイルを見つけよう~

Sig-SQA の皆さまで考えているQAスタイルファインダーで、事例やフィクションなどを交えて、どのように使ってみたかの実例の発表でした。

私もメンバーの一人ですが、まだまだスタイルファインダーの使い方 (応用) が思いついておらず皆様の意見を聞きながらどうすれば利用できるかを模索中です。



ほっともっと・やよい軒の会社で始まるアジャイルジャーニー

非IT企業で DX を進める内容で、教育や育成をどのように進めていくのか、アジャイルな祖組織を構成していくのかの発表でした。

私たちの組織や開発スタイルでもなく、DX 出来ているわけでもないのでアジャイル的な組織にする序章で教育を考えて行動しているのは、同じような苦労されているなと感じました。

時間がオーバーして次のセッションに被ったのでスタッフが慌てていたので、こっちがドキドキました(笑)


きゅんです♪スクラムフェス新潟

Scrum Fest 新潟の話でした。

前のセッションが時間オーバーして、ほんの少ししか聞けませんでした。(後で見ます)

少しだけ聞けたのは、テストの組織について話されていました。


ブルシットプロダクトからチームを守れ! 「顧客が本当に必要だったもの」をいかに追求しつづけるか

さすが森さん、話が膨大すぎて一回聞いただけでは消化不良です(笑)

組織が大きくなるにつれて、分業されていき目的・目標がぼやけていく。そのうち、自分たちの目の前の作業だけをやるようになり歯車になってしまうという話でした。

でも、組織が大きい・小さいと関係ないんじゃないかとは思っています。

組織や製品のビジョンを示せず、業務だけをこなす人であれば、こういう組織になるよなと思いました。

どこかで見たような。。。おっと、だれか来たようだ


アメリカの超巨大クラウドの中の人に転生したガチ三流プログラマが米国システム開発の現実をリークする話

プログラムの才能がないと言ってましたが、おそらく相当ありそうな予感がしています(笑)

開発する組織で新しい挑戦と、その開発担当者を支援できる上司という存在が大事であることがわかりましたが、完璧超人は難しいとは思いました。

そんな完璧超人ではない自分が開発のどんな支援ができるのかなと考えさせられるセッションでした。


そして、今年は懇親会に参加させていただきましたが皆さまと楽しく対話ができました。

実際に会うのは初めまして何でしょうが、なんとなく既視感があって初めましてっぽくない。(笑)



最後に、期間中は皆さまに、オンライン区長として認知 (再認知) してもらえて楽しく参加できました。

来年に向けてプロポーザルも考え始めようと思います。



オンライン区民、SigSQA の皆さまにロゴ近くに名前を書いてもらいました!



閲覧数:13回0件のコメント

最新記事

すべて表示

前提条件 ゆるふわWeb系QAの戯言です。 きっかけ アジャイルでどうテストすればいいかという悩みの本質は、ほとんどテストではなく、それ以前の問題に起因するのでは?という話を聞いて、自分なり考えてみた。 アジャイル開発でテストが難しい理由はQAプロセス設計の難しいことが大きな原因では? たぶん、WFだとあんまり考えないで順序通りに実施してもそこそこ上手くいく。それは、WFの開発プロセスが確立してい

今週もテストアーキテクチャ設計をやっていた。 テストアーキテクチャ設計とはいかのあたりを参考にしてもらえればいいかと。 https://www.jasst.jp/symposium/jasst12tokyo/pdf/A2-3.pdf https://jasst.jp/symposium/jasst13tokyo/pdf/A2-4.pdf 特に機能性の部分ではあるが、製品の心臓部である。 というか、

ここ最近、機能性部分のテスト設計を行っているが、このテスト設計は開発設計書を補完するものだと思う。 (あくまで機能部分です) そして、実装した機能に対しての意味付け(理由)を可視化・明示するものほかにならないとは思った。 考え方、見え方次第になるが、バグがあったときに、なぜバグではないのかを説明する義務が発生する。 速度が遅いとかいうのもバグの一つだ。 開発担当者に、なぜこの実装となるのかをしつこ