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

認定スラクムマスター研修 受講報告

認定スラクムマスター研修 受講報告

2021年10月に認定スクラムマスター研修を自腹で受講した時の報告書です。

SSSSSSSSSSSSHHHHHHHHHH

July 16, 2022
Tweet

More Decks by SSSSSSSSSSSSHHHHHHHHHH

Other Decks in Technology

Transcript

  1. プロジェクト が難航する 理由 プロジェクトが難航した要因 回答者の割合 ユーザーが非協力的(Lack of User Input) 12.80%

    不完全な要件定義&仕様書 12.30% 要件定義&仕様書の変更 11.80% 経営層のサポートの欠如 7.50% 技術力の無さ 7.00% リソース不足 6.40% 現実離れした期待感 5.90% 不明確な目標 5.30% 非現実的なスケジュール 4.30% 新技術 3.70% その他 23.00% The Standish Group CHAOS Reports (1994)
  2. スクラムとアジャイルの関係 アジャイルソフトウェア開発宣言と宣 言の裏にある原則 スクラム XP(Xtreme Programming) クリスタルク リア カンバン マインドセット

    (抽象クラス) マインドセットを実践 するための フレームワーク (実装クラス) プロジェクト管理 あっさり GitHubも採用 開発スタイル
  3. アジャイルソ フトウェア開 発宣言で重 要視 されているマ インドセット ✤対面コミュニケーション 個人同士の対話を通じて相互理解を深めること で、よりよいチームが作られる。 ✤実働検証

    動くソフトウェアを使って繰り返し素早く仮説検証を し、その結果から学ぶことがよりよい成果を生み 出す。 ✤顧客とのWin-Win関係 お互いの立場を超えて協働することにより、よりよ い成果と仕事のやり方を作ることができる。 ✤変化を味方に 顧客のニーズやビジネス市場の変化は事前計画 を狂わす脅威ではなく、よりよい成果を生み出す 機会と捉える。
  4. スクラムマスター ✤ スプリント計画会議の進行 ✤ スタンドアップミーティングの開催 ✤ 問題の解消 ✤ 振り返りの実施 ✤

    プロダクトバックログのサポート refs. https://asana.com/ja/resources/scrum-master →かっこよく言えば: サーバントリーダー ※スクラムチームに奉仕をしながらスクラムを伝授する →悪く言えば: チームの雑用係? ※直接チームの利益に結び付く役割ではない →支援職 →開発(プログラミングや設計)は行わない ※レビューなどは参加
  5. プロダクトバックログには何が書いてあるか? ある企業では、以下のような内容をプロダクトバックログアイテムに含めて いるそうですが、チームよりまちまちです •解決すべき課題 •ユーザーストーリー •プラットフォーム •KPI •リリース希望日 •見積り •リスク

    •関係者 •参照情報 システムがユーザーにどのような価値をもたらすのかを示 したもの。顧客目線を維持しつつ、開発するために利用す る。 『<ビジネス価値>のため<役割>として<機能や性能>がし たい』といったテンプレートであらわされる。 例えば、ダイエットアプリでは… refs. https://www.ryuzee.com/faq/0029/ 「夜食を防止するために、深夜に冷蔵庫を開閉するとユー ザーに警告する。それによって深夜にご飯を食べる罪深さを ユーザーに思い出させる」
  6. refs. SCRUM MASTER THE BOOK p.190を改変 スプリント プランニング 毎日の作業 リリース判断可能な

    インクリメント デイリー スクラム (朝会) 要求 プロダクト バックログ スプリント バックログ ステークホルダー スプリント レビュー レトロスペクティブ (振り返り) 開発 プロダクト バックログ リファインメント スプリント(2週間) リリース
  7. • 設計の肥大化 • 見積り精度 • 後半ほど高リスク (テストで問題が生じた場合直せない) • 計画の柔軟性がなくなる •

    機能統合が終わらない • スプリントの途中で開発が終わった分だけ リリースしたいと思ってもリリースできない し、ユーザーからのフィードバックも受けら れない refs. スクラムマスター研修資料
  8. 現代のシステムはあらゆるものに抽象化レイヤーが入っている ハイパーバイザ
 (VMWare ESXiなど)
 ハードウェア ハイパーバイザ型
 ホストOS (Linux Kernel)
 ハードウェア

    コンテナ型
 ゲストOS
 (Kernel)
 ミドルウェア
 bin/libs
 VM
 App
 App
 ゲストOS
 (Kernel)
 ミドルウェア
 bin/libs
 VM
 App
 App
 ゲストOS
 (Kernel)
 ミドルウェア
 bin/libs
 VM
 App
 App
 ミドルウェア
 bin/libs
 コンテナ App
 App
 仮想ハードウェ ア 仮想ハードウェ ア 仮想ハードウェ ア ミドルウェア
 bin/libs
 コンテナ App
 ホストOS
 VMならハイパーバイザー、 コンテナなら Container Runtimeが OS等の影響に 1クッションを挟むことで ハードウェアとソフトウェアを 分離している container runtime

  9. 旧来の方式なら… ユーザー数の増加に伴い、 システムの増強を考えています。 下記リソースを新しく追加してください ・HTTPサーバーのNginx x 3台 ・APIサーバーのKong x 3台

    ・アプリケーションサーバー(Spring Boot) 多数 ・ベアメタルサーバー x 3台 →インフラチーム&アプリケーションチームの折衝 →サーバーリソースの準備、環境設定 →サーバー間のネットワーキングの調整 →アプリケーションのセットアップ等
  10. Nutanix AHV + OpenShift(Kubernetes)なら… Manifestファイル(構成ファイル)の準備で終わります apiVersion: v1 kind: Pod metadata:

    name: dns-example spec: containers: - name: test image: nginx # (中略) searches: - ns1.svc.cluster-domain.example - my.dns.search.suffix # (中略) • アプリチームはインフラチームに慮ることなく、 リソースの増強を行える • OpenShiftの仮想ネットワーク(CNI)&DNS機能により、 どのサーバーにアプリケーションがあるかをデプロイ時 に意識しない • コンテナ作成時にセットアップはほぼ完了 • 旧来のインフラチームはNutanixの物理レイヤー部分 にのみ、責任を持つ(責任分界点が変化) ※Manifestファイル側にcpuコア数やメモリ数の設定があり、 この辺はインフラ→アプリに責任を委譲したとも言える Manifestファイルの一例 圧倒的にスピードが向上
  11. ・Big Tech(GAFAやUber等情報産業の巨大企業)とその他のユーザー 企業の開発プロセスやチームにおけるロールの違いを解析した記事 • Big Techには… “How Big Tech Runs

    Tech Projects and the Curious Absence of Scrum” (Big Techの技術プロジェクトの進め方とスクラムの不思議な欠如) • アジャイルのマインドが成熟したチームにはスクラムというプロセスすら重い ので、kanban等のさらに軽量なプロセスを使用する • エンジニアリングチームにPMという役職はない (スケジューリングなどはエンジニアの自己管理が鉄則) • 技術部隊へのサポートはTPM(テクニカルプログラムマネージャー)が担当。Uber の場合、技術者50人に対して1人の割合らしい(間接部門が小さい)
  12. “How Big Tech Runs Tech Projects and the Curious Absence

    of Scrum” (Big Techの技術プロジェクトの進め方とスクラムの不思議な欠如) ・スクラムの欠点を指摘するものではない  メンバにアジャイルマインドが浸透しているので技術に全振り • Big Techではない従来企業の下記のケースでは依然有効 • kitchen sink(台所の流し)チーム: 要件定義を最初から全て見出そうとして、 その結果、要らなくなった要求を捨ててしまうチーム ※アジャイルの原則は優先度によって粒度にメリハリをつけること/Agile サムライが出典 • タックマンモデル(チーム形成のためのモデルで、アジャイルマインドが”形成 期”や”混乱期”にあるチーム • デプロイの頻度を(数か月に一度から)数週間に一度に上げたい • 統一されたプロジェクト進捗報告(ex. JIRA)を上げたい
  13. “How Big Tech Runs Tech Projects and the Curious Absence

    of Scrum” (Big Techの技術プロジェクトの進め方とスクラムの不思議な欠如) FacebookのPMとして1年以上働いてるけど、チケットも タスクも作成したことはない。スプリントもしてないな。 FacebookのPMは、ビジョン、戦略、パートナーシップ に重点を置いている。プロジェクト管理やタスクにはあ まり力を入れていない。 エンジニアがほとんどのプロジェクト管理責任を負い、 自分でタスクを作成してるよ。 いいね! …PMとは?
  14. Q. 将来的には全部アジャイルになるの? A. そのようなことはないが、前向きに捉えよう • 内閣官房情報通信技術(IT)総合戦略室(政府CIOポータル)が出してるアジャイル開発実践ガイドによれ ば向いてない領域もある • 業務内容が明らかになっており、作って確認するという余地が少ない領域。 ※ただし、業務内容が明らかになっている領域であっても、具体的な

    UI(ユ ーザインタフェース)の部 分は、利用者からのフィードバックを得ながら構築するアジャイル開発が向いている場合もあり。 • 大規模な情報システム、業務内容等が極めて複雑、あるいはミッションクリティカルな(業務、サービス 提供上ほぼ一切の障害や誤作動が許されない) ケース • (個人的には最もミッションクリティカルなF-35戦闘機の内部システムでさえ、C2D2というアジャイ ル形式の開発形態を採用しているので、マインドの問題なだけも…) • ベンダ企業、ユーザー企業間のシステム開発に関する契約が障害になるケースもある • 基本的には準委任契約が大前提 • https://www.publickey1.jp/blog/20/ipa_1.html • 「アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと」と厚労省が疑義応答 集を公表してるぐらいなので、外堀は埋まりつつある • https://www.publickey1.jp/blog/21/agile_japan_2021.html →アジャイル開発に向いている・不向きな領域を留意した視座の広い開発方針 の採用を。