tuneの日記

アジャイル開発、組織変革、マネージメント、ファシリテーションについて学んだことの記録

Ques #14で「顧客価値を安定的に届けるために―Rettyにおけるアジャイル開発とQA改善の取り組み」を話してきました

勉強会 アジャイル

はじめに

QA界隈のエンジニアが集まる老舗イベントQues #14で登壇する機会をいただき話してきました。「Agile Testの今」というお題に対し、「アジャイルな開発」を実現するためのRettyにおける文化の変革について事例を交えて紹介しています。素敵なオフィスでの満員の会場に、事前のインタビューでの集客と、Quesの運営スタッフの皆様には大変感謝しております。

f:id:tune:20191118095512j:plain

quesqa.com

Twitterのハッシュタグ付き投稿をみるにそれなりに参考になる発表ができたのではないかと思います。以下、いただいたコメントについて簡単にフォローします。

Twitterでいただいたコメント

投稿内容のチェック、ハッシュタグなどの解析、表示する順番などなど面白要素がたくさんあると思います。

こちらをどうぞ → 【2019年最新！】新宿の合コンで今年人気のおすすめ30店 - Rettyまとめ

QAは無くならないし、弊社もQA見てくれる人がいるなら大変心強いです。 QA組織が必要(そしてリリースのブロッカーとなっている)、テスト自動化だけをやるエンジニアがいる、手動テストだけをやるエンジニアがいる・・・というのはだんだん変わっていくかもしれませんが。

プロダクトオーナーの判断に委ねています。重要度と優先度を元に考えることが多いと思いますが、最後は誰かが決めないといけないので。

ABテストは結構やっています。

名前を付け替えてスクラムイベントを形式的に取り入れるとわりかしありますよ。 - 責任者→プロダクトオーナー - プロジェクトマネージャー→スクラムマスター - 進捗定例→スプリントレビュー

xUnit系テストは十分にないです。あればもっと改善早く進むのですが。

創業者が書いたコードの大半は書き直されていると思いますが、どこかに残っていると思います。

システム思考はこのブログも参考にしてください→ LeSS Study LeSS本読書会 第7回 実際にワークショップやってみよう会 - tuneの日記

型は表面的に守られているけど、なぜやるのかの目的を腹落ちしないまま続けていた感じです。

それも含めてプロダクトオーナーが決めるものですが、やりやすいものばかり手掛けていると「へろへろバックログ」になってしまいます→ Agile Product Management - Speaker Deck

開発期間をストーリーポイントという単位に換算していた、大きくても分割しなかったというのがそもそもの問題です。

正しくは"stg-natsuka"という検証環境ですが、名前の由来は間違い無いかと。創業者によるQAとかではないです。

なかなか定着しなくて・・・→ アジャイル開発に使う文房具の使い方・選び方 - tuneの日記

大変です。これは私が入社してからの半年ではなく、入社前から1年ぐらい時間をかけてやったことです。やり切ってくれたメンバーには感謝しかありません。

対象が小さい方がテストはやりやすい。ただしマイクロサービスは相互の依存があるからそこを含めたテストは難しいというお気持ちです。

ビジネスロジックを整理するには型ありが向いているのかなと最近感じています。

開発メンバーが愚直に書いてくれました m(_ _ )m

マイクロサービス化の準備は私の入社前から1年ほどやっていて、現在もテスト展開中の状況です。

QAチームはあるに越したことはないけど、ビジネスロジックが不明瞭という一番重要な問題に対してQAチームを作ることはその直接的な解決になっていないということです。

ユーザー観点のテスト項目出しなので他社のQAエンジニア/テストエンジニアが作るテスト項目よりもずっと洗い粒度です。作る工数はかかりますが、プロダクト全体視点で仕様の漏れがないかを考えるメリットがまさっている状態です。

ある程度溜まったら整理して次の段階にいくんだと思います。今はテスト項目を洗い出すのも辛い状態なので観点の集積から始めたというお話です。

ドメイン知識を蓄積する→仕様を押さえたい→仕様の前に観点がよくわかってない の状態でした。ドメイン知識を蓄積するための前段階ぐらいです m(_ _ )m

一緒い働いているメンバーがイケていることは否定しませんが、「きれいなウォーターフォール」をやっているときと同じメンバーなので人の問題ではないと思っています。変わっていくことに不安を感じるメンバーがいるのはどの環境でも起きうるので時間をかけて少しずつ変えていきます。

信頼貯金が無い状態からのスタートなので、少しずつ少しずつ変え続けるしか無いですね。

指摘されて気がつきました。確かにそうですね！

そんなことはないと思います。ただ開発プロセスの末端にいてゲートキーパーをしているのではなく、全体に関与しプロセスで品質を高めるように関与する方が活躍している印象を受けます。

マイクロサービスを導入する話をするとサービスごとにチームを作りがちですが、1チームが複数のサービスにまたがって手を入れることができればドメイン知識が散在する問題は起きないのかなと思っています。