リーダーにおくるDevOps実現のためのチームづくり2. 吉羽龍太郎 @ryuzee ✤ 株式会社アトラクタ取締役CTO/アジャイルコーチ ✤ 野村総合研究所、Amazon Web Servicesなどを経て創業 ✤ アジャイル開発/DevOps/クラウドのコンサルティングとトレーニングを提供
Nexusの概要
2. 概要 ✤ Nexusは3∼9個のスクラムチームのためのフレームワーク ✤ Nexus は、役割・イベント・作成物と、スクラムチームの作業をまとめる技法で構成さ れたフレームワーク ✤ 複数のスクラムチームが、ゴールを達成するインクリメント(出荷可能な製品の増分)を構 築するために、1つのプロダクトバックログに取り組む ✤ 開発はスクラムの父の一人Ken Schwaberと彼自身の会社scrum.org 4. 背景 ✤ ✤ 複数チームで協力してスプリントごとに統合済みの製品を作ろうとした場合、それぞれの 作業で多くの依存関係が生まれる。これは以下の影響 ✤ 要求のスコープの重なりや実装方法の相互影響。プロダクトバックログから項目を 選択する際にこれらを考慮する必要 ✤ ドメイン知識が欠如していると進まないので、適切な知識を持つ人をスクラムチー ムに適切に配置しないといけない ✤ 要求は
LeSS (Large-Scale Scrum) の概要
1. LeSSの概要 (Large-Scale Scrum) 2016/11/25 Ryuzee.com 吉羽龍太郎 (@ryuzee) 2. LeSS概要 ✤ 大規模用のスクラムフレームワーク。まぁまぁ十分という程度を目指している ✤ 8チームまで用とそれ以上のチーム用(LeSS Huge)の2バージョンがある ✤ LeSSはスクラムなので以下はそのまま適用される ✤ 製品は1つでプロダクトバックログも1つ ✤ 完了(完成)の定義も1つ ✤ スプリントの最後には出荷判断可能な製品の増分を作る ✤ 1人のプロダクトオーナー (スクラムマスターは複数でOK) ✤ クロスファンクショナルチーム ✤ スプリント期間は固定期間 (各チーム共通で同じ日に開始・終了) 3. 歴史 ✤ ✤ CraigとBasによって2005年から開発。多くの事例 ✤ 通信機器 - Ericsson & Nokia Ne
Infrastructure as Codeと組織構造
2. 吉羽龍太郎 / Ryuzee.com ✤ アジャイル開発/DevOps/クラウドに関する従量課 金型コンサルティングサービスを提供 ✤ http://www.ryuzee.com @ryuzee 3. コンテキスト設定 複雑な領域 探索 理解 反応 カオスな領域 行動 理解 反応 込み入った領域 無秩序 な領域 理解 分析 反応 明白な領域 理解 分類 反応 ✤ 1チーム〜数10チームくらいの規模を想定 ✤ とてもお硬い領域というよりは変化の大き い領域の話 4. Infrastructure as Code (1) ✤ なんらかのアプリケーションを動かすためのインフラをコードで記述すること ✤ コードで書くことで再現性を高められる (はず) ✤ コードで書くことによって、ソフトウェア開発のプラクティスがインフラにも適用可能 になる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
