アジャイルジャパン2019で発表させていただいたスライドです。 時間が余ったら話そうとしていたおまけスライドも付けてあります。
LeSSでつなぐビジネスとIT
アジャイルジャパン2019で発表させていただいたスライドです。 時間が余ったら話そうとしていたおまけスライドも付けてあります。
RSGT2019のスライドまとめ #RSGT2019 - スクラムマスダーの日記
2019/01/09からRegional Scrum Gathering Tokyo 2019が始まりました〜。 2019.scrumgatheringtokyo.org 発表スライドまとめてみました。 個人的に見つけたスライドだけですので、他にもあればコメントいただけると嬉しいです。 3日目分まで、更新しました。 1日目 Keynote Outcome Delivery: delivering what matters www.youtube.com HALL-A チームワークの会社で最高のプロダクトを目指すチームができるまで -強くてスケールするチームの作り方- speakerdeck.com 運用中のモバイルゲーム開発チームに、並行バージョン開発を導入してみた スクラムチームを辞めて20人でカンバン運用してきた半年間の軌跡 speakerdeck.com 東名阪をまたいだLeSS H
“ふりかえり”をふりかえろう～意見が活発に出るよい”場”とはなんだろう
2018/09/08 XP祭り2018で実施した、ふりかえりの場を考えるワークショップです。 http://xpjug.com/xp2018-session-e-7/ セッションID：E-7 時間：16:00～16:50（50分） 会場：E（5F 504室） カイゼンを行うなかで、とても重要なのが「ふりかえり」です。 働くなかでの日々のふりかえり、アジャイル／スクラムチームのなかでのふりかえり、また、節目ごとに皆で行うふりかえりなど、さまざまな場面でふりかえりを行うことがある方も多いと思います。 日々のふりかえりで、こんな悩みはありませんか？ 普段のふりかえりがうまくいっていない アイデア・アクションがなかなか出てこない 愚痴大会になってしまう ふりかえりの”場”を醸成することで、コミュニケーションが活発になり、期待する100%以上のアクションが生まれやすくなります。 皆さんが思う、よい”
チームリーダーになりたくない - えりつぃんのにっきちょう
って最初に言ったんですけど任されてしまいましたね。 リーダーを任されて数ヶ月、いろいろ考えた話。 そもそもチームリーダーはいないはずでは？ スクラム開発にいるのはプロダクトオーナーと、スクラムマスター、チームメンバー。 スクラム開発にはチームリーダーはいない。 が、スクラムやってるはずのうちの会社、なぜかチームリーダーがいる。 リーダーの仕事はスクラムマスターの領域が近いけれど、実際の作業もやっているのでチームメンバーでもあるかんじ。バックログはチームで出している。POは誰だかよくわかんない。 なので実際、リーダーはただのスーパーマン。 要件からバックログのタスクにする。調整して、みんながタスクに集中できる環境をつくってあげられる。コード書いてタスクを燃やせる。なんでもできる。リーダーすごいよ。スクラムの全役ひとりでやってるのでは？ というわけでうちのチームリーダーはなんかすごい。 模索、
ScrumMasterWay - スクラムで卓越した成果を収めグレートスクラムマスターになるための方法
ユニークなコンセプト #ScrumMasterWayはユニークなコンセプトです。アジャイルとスクラムの第一線に立つエキスパートであるZuzana 'Zuzi' Šochováが提唱しているもので、スクラムで卓越した成果を収める方法、グレートスクラムマスターになるための方法です。15年以上に渡るアジャイルとスクラムの経験、そしてグレートスクラムマスターになるための彼女なりのやり方もカバーしています。 #ScrumMasterWayのコンセプトは、優秀なチームや組織を作ったり、アジャイルな環境における変化に対応したり、非常に強力なスクラムマスターの道具箱を活用したりするのに役立ちます。 #ScrumMasterWayのコア要素 このコンセプトはスクラムの長所に焦点を当てています。メタスキル、学習、心理、 リーダーシップが4つの要素です。
駅すぱあとと未来と組織と
2017年02月09日 関デジDAY2017基調講演スライド 「駅すぱあとと未来と組織と -カンバン・見える化・カイゼンで活気に満ち溢れた組織へ- 」
アジャイルメトリクス実践ガイド
9. （例）DevOpsのメトリクス 9 開発・CI QA デプロイ リリース 運用 開発の リード・タイム 非稼働時間 デプロイの リード・タイム リリース頻度 MTTR 欠陥・ビルド失敗・シス テムダウンに 伴う再作業 検出・見逃した欠陥の 割合、および 欠陥の影響度合い デプロイ頻度と かかる時間 リリース毎の 時間とコストの割合 システムダウン時の コストと頻度の割合 非稼働時間 MTTD (検知にかかる時間) （システム）変更の 成功率 （リリース成功の） 予測可能性 営業時間後の 緊急呼び出しの頻度 進行中の作業と 技術負債 MTTR 性能と利用時間の 割合 サイクル・タイム Wallgren Anders, Measuring DevOps: the Key Metrics that Matter, Agile2016 10. （例）DevOpsのメトリクス 10 開発・CI
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
スクラムガイドを読む（第２回） - Intelligent Technology's Technical Blog
こんにちは、斎藤です。 「スクラムガイドを読む」の第２回目です。 「スクラムガイドを読む（第１回）」はこちらです。 第２回目は、スクラムガイドの下記の内容に関して書いていきます。 スクラムイベント スプリント スプリント計画ミーティング デイリースクラム スプリントレビュー スプリントレトロスペクティブ スクラムの成果物 プロダクトバックログ スプリントバックログ インクリメント 「完了」の定義 結論 スクラムイベント スクラムでは、イベントを設けて規則性を作り出し、スクラムで定義されていないミーティングの必要性を最小化している。イベントには、時間に上限のあるタイムボックスを使う。これは、計画プロセスで時間を無駄にせず、必要な分だけ時間を使うようにするためである。 スプリント以外のすべてのスクラムイベントは、何かを検査・適応する公式の機会である(スプリントはその他のイベントの入れ物である)
スクラムのためのNexus Guideを公開
Nexusは，大規模なソフトウェア開発プロジェクトを展開，維持するためのフレームワークである。Nexus Guideは，スクラムをスケールアップする上でScrum Guideの次段階として，複数のソフトウェア開発チームを統合した活動のサポートとして使用することができる。 InfoQは今年初め，Scaled Professional ScrumとNexus Frameworkに関して，Gunther Verheyen氏にQ&A形式のインタビューを行っている。そのGunther Verheyen氏がAgile Greece Summit 2015で，Scaled Professional Scrumフレームワークについて講演する。カンファレンスの様子はInfoQでもお伝えする予定だ。 InfoQはNexus Guideの著者で，アジャイル宣言(Agile Manifesto)の原作者で署名者の
自己組織的なScrumチームの目指し方
Regional Scrum Gathering Tokyo 2015での講演資料です。Read less
どのようにScrumをスケールするか
大きな組織はScrumをチームを超えた大きさに適用したいと考えている。この記事では、Scrumを拡大適用して組織全体にアジャイルを導入するための方法についていくつかの例を紹介する。 maximizing scrumと題した記事で、Gunther Verheyen氏はScrumの拡大の仕方について書いている。氏はScrumをスケールする場合に組織が考えることについて説明する。 長年の間、既存の仕事では、質と量を増加させることによってのみ成長(例えば‘スケーリング’)を達成できるという考えが浸透しています。‘Scrumをスケールさせたい’という考えは、成長は数を大きくすることでのみ達成できるという過去の考えを反映しています。 氏は組織がこのような考えに基づいてScrumをスケールするときに直面する課題について説明する。 組織は既存の構造に手をつけるのを嫌がり、既存のオペレーションを維持したがり
Scrum Patterns : スクラムを構成する要素を分解し、組織パターンに対応づける - kawaguti’s diary
組織パターンのジム・コプリエン(James O Coplien)氏と、スクラムの共同開発者のジェフ・サザーランド(Jeff Sutherland)さんが中心になって、スクラムを組織パターンで説明する取り組みがありました。その成果であるパターンの概要を日本語にしてみました。内容に変なところ等がありましたらぜひご指摘ください(GitHubにホストしました)。 原文はこちらにあります。 スクラムパターン概要 スクラムが効きそうにないところを除いたパターン これらのパターンがスクラムそのものだ。2008年6月、スクラムの創立者(訳注:ジェフ・サザーランド氏)と組織パターンの開発者(訳注: ジム・コプリエン氏)が、数名のエキスパートとともに、組織パターンの本に記述されたパターンを、スクラムフレームワークの中で適用する際の、全体像(マップ)を作成した。これらのパターンは、スクラムフレームワークの代表的
ジェフ・パットン Passionate Product Ownership「認定スクラムプロダクトオーナー研修」（同時通訳付き） - アギレルゴコンサルティング株式会社
ジェフ・パットン氏が春に再来日します。 ジェフ・パットン氏の考えるアジャイル時代の要件定義は、ビジネス・ユーザ中心設計・開発者 の３条件を揃えた "全部入り" のチームで行います。そのため、どの担当でも意図が分かり、かつ軽量に作成できるドキュメントを壁などを使って作り上げていきます。大事なのは共通理解。そして、より早くフィードバックを受け、プロダクトの方向性を修正していく「探索」にあります。プラグマティック・ペルソナ (pragmatic personas)ユーザーストーリー・マッピング (user story mapping)デザイン・ステューディオ (design studio)協調ワークショップ (collaborative workshop) 尚、本コースは、Scrum Alliance 認定スクラムプロダクトオーナー(CSPO)研修として行われますので、受講者にはCSPO資格が授
Kanban and Scrum 〜 デブサミ2013 OpenJam で発表してきました。 - kawaguti’s diary
デブサミ2013の Open Jam で発表をしてきました。 最近周りでカンバンについて整理してほしいという要望をいただいたので、作ってみた資料です。 今年も関さん( @m_seki )に鋭いご指摘を頂きました。「ScrumとKanban、入り口をあえて分ける必要がないのでは？」うーむそうかもしれません。どっちから入っても、Kanbanなら多能工が重要になってロールがオーバーラップしていくし、Scrumなら徐々にプロセスが安定化して列が増えていきます。関さんとは昨年のOpenJamでのSECIモデルの話を一緒にさせていただいたのですがすごく勉強になりました。 instagramで白羽さんに撮影していただいた風景です。( instagramからの貼付け方が分からず画面キャプチャです。) 結構、聞いてくださる方が多くて感動しました。(ほとんど技術と関係ないカンバンの話ですみません。) 長々と謝
ぐるぐる DDD/Scrum というワークショップをやってきました - haradakiro's blog
東北デベロッパーズコミュニティにお招きいただき、DDD/Scrumのワークショップをやってきました。 ワークショップは、DDD のモデリングのうずまきに、スクラムのワークショップでよく使うタイムボックス縛りを組み合わせて、Agile でいうところの Swarming という状態になれないかな、という目標で設計しました。 正直、１時間の枠組みで、シナリオ書いて、モデル描いて、コードも実装するのは、だいぶ大変だったと思います。ご参加いただき、ありがとうございました。 ただ、１時間を二回廻すだけでも、チーム内で駐車場を語る語彙、モデル、設計実装案は、だいぶ共有できたのではないでしょうか。そのまま、プロジェクトに突入できる訳ではありませんが、わからないことがわかっているというのは、プロジェクトを始めるときには非常に役に立つでしょう。 参加された方は、各チームの発表したモデルの中心(コアドメイン)が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
学習のためのアジャイルゲーム
The Ball Point Game : Scrumology Pty Ltd
アジャイルはエンタープライズへ － 「Regional Scrum Gathering Tokyo 2014」開催
