Recommended
More Related Content
More from Yoshida Hiroki
More from Yoshida Hiroki (6)
Recently uploaded
Recently uploaded (8)
Agile journey map introduction conbined
- 1. Agile Journey Map Introduction Hiroki Yoshida
- 2. Agile was started Let’s agile! YES!
- 3. National Audit Office review of literature
- 4. Team work I found the problem Your problem was not important We have to be faster Focus on business value
- 5. Issue
- 6. We have to focus on one thing
- 7. Existing solutions • チームで同じ本を読む • 1日で4スプリント回してみる • SCRUMなどのフレームワーク • ビジョンやロードマップを作る • 地道に改善を回していく
- 9. D&D like status 魅力 判断力 知力 耐久力 筋力 敏捷力 耐性
- 11. Exponential Curve Levels 極楽鳥 マスティコア デルレイッチ レベル28レベル1 レベル14 ・ゲーム序盤から使える ・どの局面でも活躍 ・アドバンテージを得る ・ゲーム中盤から使える ・強力な特殊能力 ・戦いを有利に運ぶ ・ゲーム終盤で使える ・圧倒的な強さ ・ゲームを終わらせる
- 12. ステータス「魅力」の例 製品は顧客が本当に求めている物か？製品は実際に使うまで価値は評価できない。 MVPから始めてより本質的な顧客のニーズに辿りつこう！ Detail チームのために INVESTなユーザー ストーリーを書い ている。チームは ビジネスとコミュニ ケーションを取り ながらユーザース トーリーを完成さ せる事ができてい る。 User Story ユーザー体験を ベースに顧客に与 える価値を一覧化 し、提供する製品 が時間と共に価値 を増していくような ロードマップを作 成している。 Story Mapping 提供する製品がも たらす価値を示す 資料があり、それ を使って様々な人 に魅力を伝えるこ とができている。 チームをWhyで牽 引している。 LEAN Canvas 実際に製品を使う 現場にチームで赴 き利用現場の調 査を行い共感する 事により課題を発 見する。定量デー タと定性データの 双方の利点を活 かすことができる。 Gemba Walk 要件を仮説と捉え 検証することで、 作る前に価値を見 定め、費用対効果 の高いバックログ をチームに提供す る事ができている。 Customer Development レベル28レベル1 レベル14
- 16. Visualization 魅力 判断力 知力 耐久力筋力 敏捷力 耐性 Sprint1 Sprint2 Sprint3 Sprint4 Sprint5 耐性 敏捷力 筋力 耐久力 知力 判断力 魅力
- 17. Let’s Play the Game of Agile! THANK YOU
- 18. Another Game • Agile Skill Map (for Collaboration) Contact: hiroki.yoshida@axa.co.jp
- 19. Agile Journey Map 製品 by LEAN 学習 by SCRUM チームワーク by XP 品質 by TESTING 自動化 by DEVOPS 設計 by ARCHITECTURE 管理 by KANBAN Charisma / 魅力 Wisdom / 判断力 Intelligence / 知力 Constitution / 耐久力 Strength / 筋力 Dexterity / 敏捷力 Resistance / 耐性 説明 製品は顧客が本当に求めて いる物か？製品は実際に使 うまで価値は評価できな い。MVPから始めてより本 質的な顧客のニーズに辿り つこう！ チームは自己組織化できて いるか？製品の為に最適な 道具を選択できているか？ プロセス中の課題を発見し チームで課題を乗り越えて いこう！ 全員でチームの目標達成能 力を高めよう！互いの専門 性を学び合うことでチーム の知識を底上げしSingle Point of Failureの克服に 取り組もう！ 製品の品質をチームは理解 しているか？品質を定義し 顧客が本当に欲しかった物 にチームが辿りつける道筋 を作ろう！ 単純作業に追われてない か？手作業を徹底的に自動 化し、開発体験を向上さ せ、より発想的な作業に集 中できる環境にしよう！ アーキテクチャは変化につ いてきているか？イノベー ションや変更に強い疎結合 なアーキテクチャを目指し システムを発展させよう！ ステークホルダーやマネジ メントと信頼関係は築けて いるか？信頼は能力よりも 透明性に起因する。安心し て任せられる友好かつ誠実 なチームを作ろう！ User Story Backlog Demo Culture Unit Test Git Flow Technical Debt Visualization チームのためにINVESTな ユーザーストーリーを書い ている。チームはビジネス とコミュニケーションを取 りながらユーザーストー リーを完成させる事ができ ている。 チームの全ての遂行すべき 仕事が含まれた一つのバッ クログが用意されており、 チームメンバーは自ら仕事 を選択し処理していく事が できている。 ステークホルダーに対して 開発者が自ら成果物のデモ を実施している。プロダク トオーナーは建設的なデモ の時間をプロデュースす る。 ユニットテストが書かれて おり、状況によりカバレッ ジの程度やカバレッジ基準 C0, C1, C2, MCCを意図的 に選択している。 ソースコードはGithubなど でバージョン管理されてお り、Git Flowなど一般的な ワークフローを活用してい る。 期間に適合させるために パッチワークしてしまった ものをリスト管理してい る。これの返済を開発計画 に組み込んでいる。 誰でも見えるようにバ リューストリームをボード に視覚化している。デイ リースタンドアップなどで 定期的に更新している。 Story Mapping KPT Board Code Review Test Double Integration SOLID Definition of Done ユーザー体験をベースに顧 客に与える価値を一覧化 し、提供する製品が時間と 共に価値を増していくよう なロードマップを作成して いる。 誰でも自由にチームの課題 を提起できるボードを管理 しており、定期的に課題を 整理しチームで解決してい く場を持っている。 コードレビューの視点を定 義し、メンバーは相互にレ ビューしている。コードの 責任はチームで共有してい る。 ソフトウェアのテスタビリ ティにフォーカスしてお り、下位システムのスタブ を用意し、上位システムの ドライバを作っている。 GithubにPushされる度にビ ルドが実行されている。コ ミット毎に全ての資材が一 つの成果物として生成さ れ、テストも実行されてい る。 オブジェクト指向の原則に より疎結合なソフトウェア 設計がなされている。 バリューストリームの移動 ポリシーを定義しており、 ボードなど見える場所に明 記している。ポリシーは簡 単に変更でき試すことがで きる。 LEAN Canvas Sprint Planning Skill Mapping Non Functional Configuration API Design Shared Risk 提供する製品がもたらす価 値を示す資料があり、それ を使って様々な人に魅力を 伝えることができている。 チームをWhyで牽引してい る。 開発を1～2週間の短い期間 で区切り、その期間で開発 する分量を決めコミットし 遂行する事ができる。 製品のデリバリーにおける スキルを一覧化しており、 単一障害点を作らないよう にスキルアップできる環境 を作っている。チームはス キルを活かした計画を実施 している。 非機能要件を定期的に洗い 出し、非機能要件のテスト 手法についてテスターを中 心にチームで計画してい る。 アプリケーションを動かす ための設定が全て自動化さ れており、簡単に商用環境 と同等の環境を構築する事 ができている。 APIはgRPCやRESTなど一般 的な設計を活用している。 Swaggerなどでドキュメン トが整備されており、提供 先が複数の場合はライブラ リーも提供する。 ステークホルダーはチーム のリスクを自分事として認 識している。チームはリス クは観測しており経験的プ ロセスにより経過と共に低 減させている。 Gemba walk Double Loop Pair Programming Agile Testing Release Bimodal IT Manage Flow 実際に製品を使う現場に チームで赴き利用現場の調 査を行い共感する事により 課題を発見する。定量デー タと定性データの双方の利 点を活かすことができる。 ダブルループ学習といった 方法で、現状の前提や枠組 みのあり方から見直し、今 までにない新たな改善を提 案できている。 チームで暗黙知を共有し新 たな専門性を得るためにペ アプログラミングが採択さ れている。出てきたアイデ アはチームで共有されてい る。 テスターと開発者は１つの イテレーション内で同じ ユーザーストーリーを作業 し完了させることができて いる。 リリースが自動化されてお り、ローリングアップデー トやブルーグリーンデプロ イメントやカナリアリリー スなど、リリースのリスク を低減させる手法を選択し ている。 チームはシステム毎に Record, Engagement, Insightなどの設計方針を 定義しており。システムに あった設計をすることがで きている。 フロー効率化のためにサイ クルタイムやスループット といった指標を計測してい る。ボードなどにグラフで 掲示されており改善に活用 できる。 Customer Development Pattern Language Benchmarking Test Engineering Monitoring Cloud Native Feedback Loop 要件を仮説と捉え検証する ことで、作る前に価値を見 定め、費用対効果の高い バックログをチームに提供 する事ができている。 チームで得てきた知見をKJ 法でまとめ、パターンラン ゲージなどの形式で文書化 している。ベストプラク ティス集を作成している。 社内外のチームの取り組み を学び、チーム内で活かす ことができている。異業種 こそ学べることが多いこと を理解している。 頻繁なリリースの中で品質 を支えるため、自動テスト を活用し品質を担保してい る。テスターは製品が要件 と適合している事より顧客 満足にフォーカスしてい る。 SLAなどから安定の定義を しており、各種ログやメト リクスをダッシュボードで リアルタイムに確認でき る。監視の基準は定期的に 見直されている。 各システムは疎結合に連結 しており、１つのシステム あたりのサービス継続に影 響するリスクが低くなるよ うに設計している。 製品やチームの持続可能性 を保障するために、全ての ステークホルダーに対して フィードバックを貰う時間 を定期的かつ必要なだけ用 意している。 Lv28 Lv21 Lv14 Lv7 Lv1