第6回Ques「KDDI Bussiness IDにおけるアジャイル開発と検証フロー」

勉強会 技術 ques

はじめに

発表者のプロフィール

なぜアジャイル？

与えられたミッション

  • マネージャ「テストとかどうなの」
  • 鈴木さん「テストやってますよ」
  • マネージャ「じゃあ、テストコードやってくれ」
  • 鈴木さん「分かりました」（テストコードをいっぱい書いて業務を知ってほしいんだな…）
    • 検証作業だった
  • ミッション：受入試験を改善すること

改善のための現状分析

開発の体制

  • 企画(3人)：スクラムマスター含む
  • 開発(15人)
  • テスター(2人)：別グループからのレンタル

ヒアリング

  • 開発から企画への不満
    • 早くレビューをしてくれ
  • 企画の反省
    • 早くレビューをやらなくちゃ
  • テスターから企画への不満
    • スプリント計画でのインプット情報が少ない
  • テスターから企画への不満
    • 知らないうちに仕様が変わっている
    • 期待する受入試験ができているか不明（FBが無かった）

改善前の問題点

  • 担当が曖昧
  • 受入試験対象のインプット情報の不足
  • 仕様変更に気付けない
  • テスターと他メンバーとの距離感

受入試験改善のためにスプリントサイクルを改善する

  • 企画は受入試験をやらない（テスターがやる）
    • POとしての時間をとる
  • 十分なインプットを与える
    • スプリント計画終了時点で十分な仕様の議論ができている状態にする
    • 開発途中の変更には共有する場を設ける
    • 受入試験表をPOがレビューする
  • テスターを専任にする→失敗
    • 2week/月の稼働で調整

スプリントスケジュールと検証フロー

1スプリントの進め方

  • 1スプリント=2week
  • 初日：前スプリントの振り返り（成果物の全体レビュー、外からの評価、KPT）
  • 2〜6日（企画）：ドキュメントの整備
  • 2〜8日（開発）：ユーザストーリー実装を詳細にタスク分割（ペアプロ＆TDD）
  • 7日目：6日目までの仕様変更の共有(7日目以降は都度共有)
  • 7〜9日目（テスター）受入試験表作成
  • 8〜9日目（企画）：受入試験表のレビュー
  • 9日目（開発）ソースレビュー、リグレッションテスト
  • 最終日：受入試験実施

チケットの管理方法

  • 不具合チケット及び要望チケットの管理もしている

品質保証は誰がしている？

今後の展望

  • 受入試験が最終日に来ているので、テスターがもっと前段で出てくるようにしたい
  • 前衛的なQAを目指したい

質問

現場からの摩擦はあったのか？

  • あった

「受け入れテストを解決してくれ」という課題は解決したのか？

  • 解決はできていないが改善はできた

今QAがやっているのはどの範囲なのか？

  • QAという立場の人間はいない（テストは開発、障害報告は企画が行っている）

テスターはQAではないのか？

  • 自分が考えているQAはもっと多くのことをやっているイメージがあるのは、あくまでもテスター

仕様が変わった時にきちんとドキュメントに書けているのか？

  • その部分はルール化を徹底している
    • それがないと信頼関係が成り立たなくなる

前衛的なQAの具体例は？

  • 企業秘密です

スプリントの改善の実現は、ヒアリングから吸い上げたのか、トップダウン形式で行ったのか

  • たたき台は作ったが、スプリントを実施するたびに見直していった