QAエンジニアがAcceptance Criteriaを書いてみんなで読んだら、 いい感じに開発ができているよ

Transcript

1. 1
   QAエンジニアがAcceptance Criteriaを書いて
   みんなで読んだら、
   いい感じに開発ができているよ（公開用）
   Scrum Fest Fukuoka 2023
   @____rina____
   

   View Slide

2. 2
   Souzoh　

   QAエンジニア、スクラムマスター

   福岡うまれ福岡そだち

   @____rina____

   

   View Slide

3. 3
   今日のおはなし
   1 Acceptance Criteriaを読みあわせること
   2 Acceptance Criteriaを充実させること
   3 QAがAcceptance Criteriaを書いてみたこと
   

   View Slide

4. 4
   Acceptance Criteria(AC）を読
   みあわせて共通認識が改善した
   共通認識を持つのはむずかしい？
   

   View Slide

5. 5
   前回（ブログ）からのアップデート
   スクラムチームが発足
   QAはひとり
   QAとSM
   https://engineering.mercari.com/blog/entry/20220912-cf3da857e5/
   

   View Slide

6. 6
   わたしたちについて
   わたしたちのスクラムチーム
   

   View Slide

7. 7
   わたしたちのチームについて
   PO/PM 　デザイナー エンジニア QA/SM
   EM
   

   View Slide

8. 8
   Acceptance Criteriaについて
   

   View Slide

9. 9
   Acceptance Criteria（AC）ってなに？
   https://www.bing.com/　
   

   View Slide

10. 10
    今日のおはなし
    1 Acceptance Criteriaを読むこと
    2 Acceptance Criteriaを充実させること
    3 QAがAcceptance Criteriaを書いてみたこと
    

    View Slide

11. 11
    テストするなら
    https://www.bing.com/　
    ユーザー名？
    ユーザーIDじゃなくて？
    ID？メールアドレス？
    パスワードの桁数は？
    使用可能な記号は？
    エラーメッセージの文言は？
    ログイン処理のトリガーは入力？
    ユーザーは迷わない？
    

    View Slide

12. 12
    なんでQAがACを書いてみたの？
    ● プロジェクトごとにテスト設計をしていた 

    ● テスト設計するのも実行するのも私 

    ● 他の人が見る機会がでてこなかった 

    ○ テスト実施に入ってからフィードバックすることがあった 

    テスト設計しても私しか見ない問題
    

    View Slide

13. 13
    なんでQAがACを書いてみたの？
    ● QAが何しているかわからない 

    ● どの辺でQAに渡せばいいかわからない 

    

    

    

    

    QAって何をテストしているの？
    

    View Slide

14. 14
    なんでQAがACを書いてみたの？
    ● POはP(d)M兼任

    ● 要件定義するときにACはある 

    ● プロジェクトとか複数抱えている 

    ● 各関係者とも色々やることある 

    ● 詳しく書いてもらうには負担すぎる 

    PO忙しい問題（と、わたしが勝手に思っている）
    

    View Slide

15. 15
    そうだ
    ACとして書いてしまおう
    

    View Slide

16. 16
    ACの書き方
    ACを書くまでにどんな作業成果物があるのか
    

    View Slide

17. 17
    P(d)Mが作成
    プロジェクト
    単位に作成
    デザイナーが
    作成
    チームがつくっている作業成果物
    エンジニアが作成
    プロジェクト
    単位に作成
    Spec UI Design
    Doc
    

    View Slide

18. 18
    1. Specを作成
    2. デザインを作成
    3. ユーザーストーリーマッピング
    4. ユーザーストーリーからプロダクトバックログアイテムを書き出す
    全体の流れ
    

    View Slide

19. 19
    1. Specを作成（PO）
    2. デザインを作成（デザイ
    ナー）
    3. ユーザーストーリーマッピン
    グ（みんな）
    4. プロダクトバックログアイテ
    ムを出す（PO/みんな）
    ACをつくる前の流れ
    PO
    デザイナー
    みんな
    エンジニア
    QA
    PO
    

    View Slide

20. 20
    ACの書き方
    rinaの場合
    

    View Slide

21. 21
    ACのつくりかた
    １ ユーザーストーリーマッピングを見る
    2 Spec、デザイン、Desgin Docを集める
    3 ACを書く
    4 プロダクトバックログアイテムの順番を見直す
    

    View Slide

22. 22
    ● Spec
    ● デザイン
    ● ユーザーストーリーマッピン
    グ
    ● Design Doc
    ACを書くためにつかうもの
    PO
    デザイナー
    みんな
    エンジニア
    QA
    PO
    

    View Slide

23. 23
    2. Spec、デザイン、Desgin Docを集める
    

    View Slide

24. 24
    チケットを並び替える
    4. プロダクトバックログアイテムの順番を見直す
    ユーザーストーリー 2
    バックエンドタスク2
    フロントエンドタスク1
    ユーザーストーリー 1
    フロントエンドタスク2
    リリース
    ユーザーストーリー 2
    バックエンドタスク2
    フロントエンドタスク2
    リリース
    フロントエンドタスク1
    ユーザーストーリー 1
    

    View Slide

25. 25
    ACのよみあわせ
    ここがよかった
    

    View Slide

26. 26
    ■
    ACよみあわせてよかったこと
    Epic（やそれにちかい大きな単位）でまとめてQAがくることが
    ほぼなくなった
    ■ 待ち状態が減った
    ■ 受け入れ条件が明確になるのがよい（エンジニア）
    ■ 要求にブレがないか、整合性がとれているかを確認できる時間
    になっている（PO）
    

    View Slide

27. 27
    ACよみあわせてよかったこと
    ACなしじゃ開発できない（しめしめ）
    

    View Slide

28. 28
    ACを読み合わせて、共通認識を持って開発しよう
    まとめ
    ACを充実させて、あんしんして開発しよう
    02
    01
    

    View Slide