Agile skill map introduction conbined
- 1. Agile Skill Map Introduction Hiroki Yoshida
- 2. Phase Gate Process Requirements SRS Architecture Develop
- 3. Install the Agile When you complete?US began to smell Tested?This API is not good 距離は近い しかし壁がある
- 4. Issue
- 5. We have to learn other phases skill The New New Product Development Game Time to Market
- 6. Existing solutions • Team Building • Motivated People • IPA i コンピテンシ ディクショナリ • トレーニングや認定資格 • Team Competency Matrix
- 8. Pick up 7 jobs from Dragon Quest スーパースター 賢者 魔物ハンター 海賊魔法戦士バトルマスターパラディン
- 9. Exponential Curve Levels 極楽鳥 マンティコア デルレイッチ レベル28レベル1 レベル14 ・ゲーム序盤から使える ・どの局面でも活躍 ・アドバンテージを得る ・ゲーム中盤から使える ・強力な特殊能力 ・戦いを有利に運ぶ ・ゲーム終盤で使える ・圧倒的な強さ ・ゲームを終わらせる
- 10. 「バトルマスター」の例 プログラミングなしにソフトウェアは作れない。スピーディーかつ高品質なコードを生み 出すのがバトルマスターの得意技だ！ Detail 利用している言語 やフレームワーク の入門講座を受 ける、または書籍 などで学習してい る。コード変更の プルリクエストを送 ることができる。 Programming 書いたコードのテ ストを書く事ができ る。必要なカバ レッジやカバレッ ジ基準C0, C1, C2, MCCを意識して書 いている。テスト不 可能な部分につい てチームに相談で きる。 Unit Test Acceptance Criteriaをテスト コードに書く事で、 コードレベルで要 求が満たされてい る事を保障してい る。 Acceptance Test ユースケースをテ ストコードに書い ている。E2Eテスト は実行時間が長く なりやすいので、 テストスイートをわ けている。テストが 不安定にならない よう注意している。 E2E Test テストの無いコー ドはレガシーコー ドであると理解し ている。TDDや BDDといった手法 を活用しバグの少 ない高品質なコー ドを生み出してい る。 Test Driven レベル28レベル1 レベル14
- 11. Agile Skill Map
- 14. Summarize 5 5 4 3 1 5 2 3 2 2 3 1 1 1 1 1 1 3 0 1 0 1 1 1 2 0 1 0 0 0 0 0 0 1 0
- 15. Using Weighted Point 10 points 8 points 6 points 4 points 2 points
- 16. Visualization GL PA SA ARLU PI MM Sprint1 Sprint2 Sprint3 Sprint4 Sprint5 ToBe AsIs 2050
- 17. Let’s Play the Game of Agile! THANK YOU
- 18. Another Game • Agile Journey Map (for Agile) Contact: hiroki.yoshida@axa.co.jp
- 19. Agile Skill Map Gladiator Paladin Sage Armamentalist Luminary Pirate Monster Masher バトルマスター パラディン 賢者 魔法戦士 スーパースター 海賊 魔物ハンター 説明 プログラミングなしにソフ トウェアは作れない。ス ピーディーかつ高品質な コードを生み出すのがバト ルマスターの得意技だ！ チームは機能開発に集中で きているか？パラディンは 開発環境を整備し、開発を 円滑にすすめる為の用意を する、開発体験にフォーカ スしたキャラクターだ！ 一人でできる事には限りが ある。書籍やチームから知 識を吸収しよう！賢者は実 際に経験することで知識が 身につくことを心得てい る！ 全てのケースを網羅したテ ストを作る事は不可能だ。 魔法戦士は少ないテスト ケースで多くのリスクを取 り除く事ができるぞ！ スーパースターは設計技法 に精通しており、顧客の要 求やチームの意見からグラ ンドデザインを提案すると ても頼れるキャラクター だ！ 海賊はシステムの海原を航 海するための地図やコンパ スが武器だ！システム構成 やインターフェース仕様な ど各システムについての深 い知識を持っている！ ステークホルダーやチーム と建設的なコミュニケー ションが取れるスキルは見 逃せない！プロセスをゲー ムのようにみんなで楽しも う！ Programming Code Review Self Learning Happy Path Test SOLID Technical Writing Visualization 利用している言語やフレー ムワークの入門講座を受け る、または書籍などで学習 している。コード変更のプ ルリクエストを送ることが できる。 コードレビューをしてい る。チームでコードを共有 する重要なプロセスと理解 している。コメントで成長 や努力を称賛している。提 案では重要性を丁寧に説明 している。 自らの専門領域を伸ばすこ とができる書籍を見つける 事ができている。安定した 基盤があれば、新たな技術 の本質を捉える事ができ る。 User Storyの目的を理解し ており、要件から正常系の 確認項目を書き出し、テス トを実施できる。 オブジェクト指向の原則で あるSOLIDを理解してス テートレスな設計をしてい る。PubSubなどのデザイン パターンを駆使する事がで きる。 技術資料はシステムを開発 における成果物の一つであ ると理解している。保守コ ストを見極めチームに見 合った資料をそろえメンテ ナンスすることができる。 信頼は透明性から生まれる 事を理解している。チーム 自ら仕事をマネージメント しながら進む事ができるよ うに、KANBANなどでチーム のタスクを見える化してい る。 Unit Test Testability Pair Work Negative Path Test Modeling Dependency Feedback Loop 書いたコードのテストを書 く事ができる。必要なカバ レッジやカバレッジ基準 C0, C1, C2, MCCを意識し て書いている。テスト不可 能な部分についてチームに 相談できる。 テストを書く事が何より時 間短縮になる事を理解して いる。テストダブルなどの 方法を活用しコードのテス ト容易性を確保している。 知識は経験する事で身に着 くことを理解している。一 つのタスクをペアで担当す ることでチーム全体の能力 を高める事ができている。 知恵は経験から生まれる。 正常系以外の条件を洗い出 し、できる限り少ないテス トケースで多くのリスクを 取り除く事ができる確認項 目を書き出し、テストを実 施できる。 業務のヒアリングからプロ セスモデルやデータモデル を作成し、クラス図やシー ケンス図などによってシス テムの設計ができる。 単独でシステムが構成され る事は少なく、マッシュ アップなどの手法がとられ る事が多い。User Storyに 依存する物事を関連付け バックログを管理する事が できる。 Daily, Weekly, Monthlyの 期間やTeam, Project, Productの視点で適切なス テークホルダーからフィー ドバックを貰う機会を設け ファシリテートしている。 Acceptance Test CI/CD Pipeline Guru Test Metrics API Library Business Process Retrospective Acceptance Criteriaをテ ストコードに書く事で、 コードレベルで要求が満た されている事を保障してい る。 ツールを活用しコミットさ れる度にシステムが統合さ れテストが実行される。自 動的にリリースまたはリ リースできる状態まで資材 が用意される。 目指すべき達人が身近にい ると成長が早くなる事を理 解している。身近な達人を 発見し、達人から技術を学 び実践することができる。 テストの結果や状況をグラ フ化しチームにソフトウェ ア品質の客観的データとし て提供できる。他のチーム との比較などを通して、 チームの指標にできてい る。 APIのように複数のシステ ムから利用される事が見込 まれ再利用性の高い部分に ついて、全体最適を考えて ライブラリーを提供できて いる。 ビジネスプロセスやワーク フローなどを定義し、ユー スケースをUser Storyに書 き起こす。必要に応じて User Storyに期待する結果 を定義する。 YWTやKPTなどのツールを使 いながら、チームが使う ツールやプロセスを最適化 している。チームがより上 手くいく方法を発見できる メトリクスを提供してい る。 E2E Test Configuration Community Test Management Technology Sharing Coordination Team Building ユースケースをテストコー ドに書いている。E2Eテス トは実行時間が長くなりや すいので、テストスイート をわけている。テストが不 安定にならないよう注意し ている。 新しいメンバーは簡単な操 作で他のメンバーと同様 の、限りなく商用環境に近 いローカル開発環境を構築 できる。 一人で学べる事には限界が ある事を理解している。同 じ分野を学ぶ人々を発見 し、コミュニティに参加し たり設立する事ができる。 ISO 25000などで品質の概 念を正しく理解している。 ISO 29119などを参考にテ スト戦略を考えテスト計画 を立案することができてい る。 システムの新たな要素技術 や結合のイントロダクショ ンを計画し実施できてい る。クイックスタートガイ ドやハンズオンが効果的で あると理解している。 リリースに関わる準備やレ ビューの実施、チーム外と 足並みをそろえる部分を調 整する。インシデントがあ れば5WHYで全てのレベルで 対策を立てる事ができる。 創造的な仕事はチームワー クが重要である事を理解し ている。チームに心理的安 全性を提供し、開放性と協 調性を発揮できる環境を構 築している。 Test Driven Full Scratch Learning Organization Test Engineering Cloud Native Product Vision Inner Work Life テストの無いコードはレガ シーコードであると理解し ている。TDDやBDDといった 手法を活用しバグの少ない 高品質なコードを生み出し ている。 ビジネスの要求やロード マップを参考にして、時間 あたりの提供する価値が最 も高くなる言語やフレーム ワークを選定し、数週間で アルファ版を提供できる。 チームで一人だけ学習して いれば良い時代ではない事 を理解している。チームに 共有ビジョンを構築し、シ ステム思考を促すことで、 チーム学習を推進してい る。 テストを計画する時に自動 テストがオプションとして 存在している。自動テスト のコードを継続的に保守し ており、持続可能な計画を 立てている。 コンウェイの法則を理解し ている。組織はアーキテク チャより柔軟なので、組織 が先行する事が多い。組織 の将来像を見据え疎結合な 設計ができる。 顧客ニーズとプロダクトの 意義を明確にして、長期的 ビジョンを作る事ができ る。ビジネスのアウトカム とUser Storyの関係を明確 にして意義を末端まで浸透 させている。 戦略的目標を細分化し、 チームや個人が毎日少しで も進捗できるようなメトリ クスを作る事ができる。小 さくとも成功の体験がチー ムや個人を強くする事を理 解している。 Lv28 Lv21 Lv14 Lv7 Lv1