Agile Software Development and Quality : Case Study

ソフトウェア品質シンポジウム2013
http://www.juse.or.jp/sqip-sympo/2013/program/list_01.html#D4

D4 【パネルディスカッション】
11:10～12:50
「アジャイル開発とソフトウェア品質」

Transcript

1. 楽天 : 社内ITシステム開発の事例 Vol.01　Sep/13/2013 Yasunobu Kawaguchi Information Technology Department, Rakuten Inc. http://www.rakuten.co.jp/
2. 2 >whoami Yasunobu Kawaguchi Agile Coach
3. 3 アジャイルの歴史 Toyota Production System Lean Lean Software Development Kanban Lean Startup Agile Scrum XP The New New Product Development Game Four steps to the epiphany Agile and Lean Startup Patterns Manufacturing Industry in Japan 2013 Yasunobu Kawaguchi
4. 4 アジャイルの構成要素 Scrum, Kanban チーム活動 技術プラクティス CI, TDD 開発者テスト 内部品質 Delivery スムーズなリリース ビジネス/ユーザー Lean プロセス UCD, UX 利用者満足 ATDD, BDD テスト自動化 仕様明確化 Metrics 効果計測
5. 5 アジャイル適用のADAPTモデル トレーニング コーチング コミュニティ Awareness 知る Desire 望む Ability できる Promotion 成果 Transform 変える Succeeding with Agile By Mike Cohn (Salesforce.comさんの事例ものってます) 本日はここのお話
6. 6 アジャイル適用におけるチーム選択 第３章 自分でやってみる : パイロット 1.  チームメンバー全員が近くで 　　働けるような作業スペースにする。 2.  作業スペースにあるフリップチャート やホワイトボードは、チームメンバー が選択肢を可視化したりアイデアを探 したりするのに役立つ。 3.  チームメンバーはフルタイムで作業に あたるべきだ。 4.  全員が定時内で作業する。
7. 7 プロジェクトA PO Dev Dev Dev Coach [プロジェクトの目的] ある分野のＩＴ系業務に関する、
 システム間のデータ受渡しや 作業を効率化するためのサポートシステム。 各種ベンダー提供の複数のシステム間を効 率的につなぐ糊付け部分。 Webアプリケーション開発で培った技術を フィードバックして社内システムを改善する。 [進め方] 要件定義から開発チームで行う。 社内インタビュー調査から分析し、 システム化の難易度やアーキテクチャを 検討して、優先順位をつけ、四半期単位のマ イルストーンを提案。順に実装していく。
 実装中に新たな課題が見つかった場合の
 マイルストーン変更は適宜行うことができる。
8. 8 社内向けシステムでやってみる場合 よい点 (Pros) よくない点 (Cons) 要件の優先順位の変更のための調整 コストが低い。 マネジメントのサポートが得られないと 兼務や突発イベントなどで状況が変化 しやすい。 スケジュールは比較的柔軟に調整でき る。(もちろん、対話や根回しは必要) エグゼクティブのサポートがないとエン ジニアが稼動するコストの正当化が難 しい(かもしれない)。 利用者にアクセスしやすいため、インタ ビューがとりやすい。ユーザーテストも 行いやすい。 社内システムはKPIとしての「売上」が たたないため、それに変わるようなKPI を探していく必要がある。 外部向けと比べれば、利用技術選択 のしがらみが比較的少ない。(社内標 準しだい) ステークホルダーや業務の関連性が 徐々に明らかになってきやすい (計画 変更や要件変更の可能性が高い。) 契約やプレスリリースなど、マイルス トーンにかかわるスケジュールの制約 が少ない。 事例を社内共有した場合の有効性が、 顧客向けサービス/システムに比べて 弱い。
9. 9 スプリントとリリース Jeff Patton 漸進的なデリバリー リリース (マイルストーン) 毎日の仕事 スプリント プロダクト/サービス 漸進的なデリバリー
10. 10 要件定義: マイルストーンの変化 0 1 2 3 4 5 6 7 8 要件定義 要件定義 リリース1 リリース2 month リリース1 (管理者用のみ) リリース2 (デモ) リリース3 (ベータ) 想定 実績 環境構築 全体像 ステークホルダ調査 インフラ調整 スコープ分割 スコープの変更 漸進的 要件絞り込み
11. 11 初期のスプリント 昇龍拳 (スコープの変更) かかと落とし (伏線回収) 持ち越し バーンダウンチャート (スプリント内の残作業量を毎日プロット)
12. 12 チームの熟成 (4ヵ月後) 結合テストで 課題が発見される 作ってみることで
 追加要件が見つかる 完了 完了 完了 やってみてはじめて 得られる情報を 最大限に活用する
13. 13 徐々に全体像を明らかにする Jeff Patton アートに完了はない。 いつか諦めるだけだ。 - レオナルド・ダビンチ
14. 14 開発者とQA担当の協業方法の模索 PO Dev ユニットテストの網羅性が
 不安 テスターの技術と視点 によるアドバイスがほしい システムテスト大変なので なるべく効率化、自動化したい 無理のない協業をめざす QA
15. 15 QA担当との協調 0 1 2 3 4 5 6 7 8 要件定義 当初のQA支援予定 QA担当の早期協力 リリース1 (管理者用のみ) リリース2 (デモ) リリース3 (ベータ) 要件定義 リリース1 リリース2 month POがシステムテストを設計 Dev が自動ユニットテスト 想定 実績
16. 16 アジャイルテスト 要求 設計 実装 単体テスト 結合テスト 受入テスト 　要件定義・品質保証 (自動化、共通理解、探索テスト) テスト駆動開発 (バージョン管理, xUnit, CI)
17. 17 テスト自動化ピラミッド Janet Gregory
18. 18 テスタビリティと環境構築 開発環境 ステージング環境 本番環境 できる限り環境を合わせないと テストが信頼できなくなる 一番テストされている リリース前のテスト 運用監視、障害報告 構成管理と自動化が重要 : 継続的デリバリー、DevOps
19. 19 まとめ ・アジャイル適用として、社内向けシステム開発の 　チームの事例を紹介しました。 ・社内向けシステムの場合は、柔軟性や調整コストの低さという 　メリットはあるものの、根回しや効果測定に注意が必要です。 ・チームが熟成していくと、バーンダウンチャートが変化します。 ・品質保証担当との協業関係も変化しそうです。