Upgrade to Pro — share decks privately, control downloads, hide ads and more …

アジャイルでの品質の進化 Agile in Motion vol.1/20241118 Hir...

アジャイルでの品質の進化 Agile in Motion vol.1/20241118 Hiroyuki Sato

2024/11/18 アジャイルでの品質の進化 (Agile in Motion vol.1)
https://shiftevolve.connpass.com/event/335708/
株式会社SHIFT ソリューション本部 ソリューション事業部 アジャイル推進部 アジャイルエバンジェリスト 佐藤 博之

SHIFT EVOLVE

November 20, 2024
Tweet

More Decks by SHIFT EVOLVE

Other Decks in Technology

Transcript

  1. 7 #SHIFT_EVOLVE どんなふうに1週間のサイクルで動くの? ロール Day1 Day2 Day3 Day4 Day5 プロダクトオーナー

    ス プ リ ン ト プ ラ ン ニ ン グ デ イ リ ー ス ク ラ ム デ イ リ ー ス ク ラ ム デ イ リ ー ス ク ラ ム プ ロ ダ ク ト バ ッ ク ロ グ リ フ ァ イ ン メ ン ト デ イ リ ー ス ク ラ ム ス プ リ ン ト レ ビ ュ ー レ ト ロ ス ペ ク テ ィ ブ リ リ ー ス 作 業 開 発 者 デベロッパーの活動 要件定義 設計 実装 テスト 実装 テスト 実装 テスト 実装 テスト スクラムマスターの活動 2 H 1 H 1 H 1 H 1 H テスト活動のSTEPとイベントとの関係の詳細は次頁 15 m 15 m 15 m 15 m 目安時間
  2. 8 #SHIFT_EVOLVE まずは簡単にアジャイル開発の説明。今回はスクラム プロダクトオーナー 製品に対して責任を持ち、 機能に優先順位をつける ステークホルダー 製品の利用者、出資者、 管理職などの利害関係者 スクラムの活動の流れにおいて実施するイベント

    製品 プロダクト スプリント バックログ スプリント プランニング デイリー スクラム 1日 スプリント (〜4週間) スプリント レビュー レトロスペクティブ リリース 作業 プロダクトバックログ リファインメント プロダクト バックログ 開発者 スクラムマスター スクラムの活動の流れ イベント お客様 SHIFT ユーザー フィード バック
  3. 9 #SHIFT_EVOLVE 大事なポイント① 短いサイクルを構築する サイクルを構築することで一定の期間で、仕事を完遂することになるためメリハリがつく。 が、ゴールという締め切りが日々迫るので緊張感も生まれすぎてしまうことも プロダクトオーナー 製品に対して責任を持ち、 機能に優先順位をつける ステークホルダー

    製品の利用者、出資者、 管理職などの利害関係者 製品 プロダクト スプリント バックログ スプリント プランニング デイリー スクラム 1日 スプリント レビュー レトロスペクティブ リリース 作業 プロダクトバックログ リファインメント プロダクト バックログ 開発者 スクラムマスター スクラムの活動の流れ イベント お客様 SHIFT ユーザー フィード バック スプリント (〜4週間)
  4. 10 #SHIFT_EVOLVE 大事なポイント② ユーザーフィードバックを得る 要件がユーザーに受け入れられるているかを確認しながら進めることで、一発屋にならないようにする 狙いを明確にすることによって、顧客への価値を開発チームも認識しながら進める事ができる すぐに効果が出る部分と出ないものがあるので注意を プロダクトオーナー 製品に対して責任を持ち、 機能に優先順位をつける

    ステークホルダー 製品の利用者、出資者、 管理職などの利害関係者 製品 プロダクト スプリント バックログ スプリント プランニング デイリー スクラム 1日 スプリント レビュー レトロスペクティブ リリース 作業 プロダクトバックログ リファインメント プロダクト バックログ 開発者 スクラムマスター スクラムの活動の流れ イベント お客様 SHIFT スプリント (〜4週間) ユーザー フィード バック
  5. 11 #SHIFT_EVOLVE 大事なポイント③ 多能工になるために興味を持とう 従来の視点から、エンジニアの視点を「ソフトウェアクラフトマンシップ」へスイッチする必要がある 意欲溢れるソフトウェアクラフトマンとして、我々は、技能の習得を支援し、 自らも実践することにより、プロフェッショナルとしてのソフトウェア開発が到 達すべき水準を高める。この活動を通じて我々は、次のことを尊重する。 すなわち、左の項目を追求することにより右の項目が不可欠であること ソフトウェアクラフトマンシップ

    動くソフトウェアではなく、精巧なソフトウェアも 変化に対応するだけではなく、確実に付加価値も 個人と対話だけではなく、プロフェッショナルのコミュニティも ユーザとの協力関係だけはでなく、生産的パートナーシップも 業務ができる 部署が使える 正常フローが回る 改善効率が上がる ・・・etc… 価値 ログインができる エクスポートができる インポートができる 一覧が見れる ・・・etc… 機能 個別の機能を正確に作りこむことだけが重要なのではなく、機能 の集合体であるソフトウェアによって、どのような価値提供ができる かがを考え、そのためにどのようなプロセスが必要かを深く考える必 要がある。 開発者のマインドセットを「機能」から「価値」へ転換することとは
  6. 12 #SHIFT_EVOLVE 大事なポイント④ いつでもテストができるように ミニウォーターフォールになっていませんか? 設計 障害対応 実装 テスト設計 テスト実行

    開 発 テスト ・コードFix後にコードの追記、変更ができない。 ・テスト実行が占める割合が多く、設計、実装の時間が少なくなるため、 作れる機能が少ない コードFix 5日 ※Sprint 1weekの場合 3日 2日 3日 2日 忙しい 暇 開 発 Q A プランニング & テスト計画 テスト レポート レビュー & リリース デプロイ 静的解析/簡易な脆弱性診断 単体テスト/結合テスト 単体テスト/ 結合テスト テスト実装 テスト実行 自動テスト実装 テストチャーターの作成 テスト実行 ※タイムボックス 実装 実装 実装 実装 実装 実装 開発する リファクタリング 自動テスト 開発 手動テスト 自動テスト 探索的テスト 開発の進行 • ストーリーテスト • 機能テスト • シナリオテスト
  7. 15 #SHIFT_EVOLVE 自己紹介タイム! teyamagu氏 品質周り何でもする係。メーカー、大手WEB企業やフィンテック企業を経て、 現在は、SaaSの品質周り何でもする係をおこなっています。社外活動では、 ソフトウェアテスト自動化カンファレンスやRegional Scrum Gathering Tokyo

    などの実行委員。 ぱいん氏 QAエンジニア。SIer、検証会社を経て、現在は、モバイルアプリのソフト ウェアテストを含む品質管理に従事。社外活動では、JaSST Review、及び JaSST Onlineの実行委員。 SNS: https://x.com/pineapplecandy
  8. 16 #SHIFT_EVOLVE アジャイル開発のQAってなにするんだろう? ① • 品質への向き合い方の違い テスト 計画 テスト 設計

    テスト実行 ▪ウォーターフォール開発のテスト活動 障害 障害 障害 設計 実装 壁 テスト計画 + 設計 テスト設計 テスト 実行 ▪アジャイル開発のQA活動 リリースまで 期間の短縮 障害 障害 障害 障害 障害 障害の早期発見 実装 リリース 信頼度成長度曲線 リリース
  9. 17 #SHIFT_EVOLVE アジャイル開発のQAってなにするんだろう? ② • QAって役割は必要?どんなマインドが必要?どんな人が向いている? • 専門分野のメンバーは必要 スクラムにおける構成 ロール

    主な役割 人数 プロダクトオーナー (PO) 製品に対して責任を持ち、機能に優先順位をつける 1名 スクラムマスター (SM) スクラムプロセスが円滑に進行するように、外部から支援する 1名 デベロッパー(Dev) プロダクトの開発を行う 複数名 テックリード プロダクトにおける技術面をリードする 1名 QAリード • スクラム内でQA活動が円滑に進行するように、リードする • プロダクトの特性、リスクを考慮し、テスト戦略を策定する 1名 QAエンジニア • デベロッパー、QAリードと連携しながら、 プロダクトをテストし、品質保証する • テストタイプ、テストアプローチごとにスプリント内での優先順位を検討し、 スプリントで実施すべきテストを完了させる • テスト結果・リスクを正しく共有する 複数名 スクラムチーム 開発者 スクラムマスター(SM) プロダクトオーナー(PO) QAリード デベロッパー (Dev) QAエンジニア テックリード
  10. 18 #SHIFT_EVOLVE アジャイル開発のQAってなにするんだろう? ③ • 様々なアプローチを駆使して、テストを効率的に実施していく テストの タイプ 手動テスト 探索的テスト

    自動テスト テストベース 仕様書 業務フロー 仕様書 メリット • 曖昧な仕様でも補完してテスト実施がで きる • デザインや挙動に対しても確認ができる • ユーザーの心理を想像しながら実施でき る • ブラックボックス、グレーボックスのテストが 中心 • 業務フローを洗い出し、網羅的に実施 • 正常、準正常、異常の業務フローをベー スにテストを検討 • 準正常、異常の復帰を行う業務フロー を実施する • 学習&ふりかえりを短いサイクルで実施す るため業務知見がなくても実施可能 • 決められた手順に沿ったテスト • 繰り返し実施するテスト • 単体テスト〜総合テストまで各種テスト レベルに適用できる • いつでも実施ができ、短時間でレポートを 出力できる デメリット • 単体テストや結合テストには向かない • 実施には時間がかかる • 人によって能力に差がある • タイムボックスが存在するのでシステムの 品質に左右されやすく十分なテストを行 うことができないことがある • 実行速度が他のテストに比べて遅い • 開発の進め方によっては壊れやすい • プログラムの作りによっては壊れやすい • 失敗時に切り分けが必要