みなさんこんにちは。@ryuzeeです。 2024年1月10日〜12日開催のRegional Scrum Gathering Tokyo 2024の登壇資料を公開します。 「ベロシティ Deep Dive」ということで過去のDeep Diveシリーズの続きになっています。 過去のDeep Diveシリーズはこちらからご覧ください。 プロダクトバックログ Deep Dive スプリントプランニング Deep Dive スプリントレビュー Deep Dive セッション資料は以下になります。 結論から言うと、「ベロシティなんかにDeep Diveせず、もっと重要なところに集中しろ」です。 スクラムチームの状況を何らかの数値で表したいという考え自体は尊重しますし、それが役に立つこともあります。 ただし、数字遊びをしたところでプロダクトの価値を生み出せるわけではないので、ほどほどにしましょう。 ス

みなさんこんにちは。@ryuzeeです。 スクラムの全体像を表す絵は多数出回っています。コーチングやトレーニングを生業にしている人であればだいたい何度も作ったことがあるのではないかと思います。 今日はスクラムの全体像を表す絵のうち、比較的新しいものをいくつか集めてみたので紹介します。 見出しの行か画像をクリックすると、それぞれオリジナルを公開しているページにアクセスできます。 The Scrum Framework Poster | Scrum.org ケン・シュエイバーが設立したScrum.orgのサイトで公開されているもの極めてシンプルなので汎用性は高い一方で、スクラムマスター、プロダクトオーナー、開発チームの記述がでてこないなど、要素がすべて網羅されているわけではないことに注意が必要Visual AGILExicon Essential Scrumの著者Ken Rubin氏作のもの。

みなさんこんにちは。@ryuzeeです。 DevOpsGuysというサイトのTwelve DevOps Anti-Patternsという記事が秀逸です。 作者の方に許可を頂き翻訳しましたので公開します。 原文も軽妙なタッチで読みやすいと思いますのでぜひご参照ください。 また本文で様々なスライドや資料へのリンクがありますので、そちらも見ていただくと理解が深まるんじゃないかと思います！ えっとDevOpsを始めたいのかな？おっけー。ただ始める前に、やってはいけないいくつかのことについて見ておこう。 古き良き時代には単に「良くないアイデア」って呼んでいたんだけど、外交やポリティカル・コレクトネス運動の結果、ブレストやアイデアシャワーをして、最近は「アンチパターン」と呼ばれるようになった。 パターンが絶対的に正しいのであれば、すなわち「アンチパターン」は間違いということになる。そして間違いを避ける

みなさんこんにちは。@ryuzeeです。 2017年11月7日(現地時間)にスクラムのルールブックであるスクラムガイドが更新されましたので、Webinarの資料をもとに変更点をご紹介します。 なお、スクラムガイド自体はこちらからダウンロード可能です。日本語訳はさまざまな書籍の翻訳で有名な角征典さんです。以下の紹介に際して、スクラムガイド日本語版の記述を引用しています。 実践に際して、大きな影響はあまりないと思いますが、とくに以下の2点が注目だと思います。 デイリースクラムで3つの質問を使うかどうかはチーム次第となった。大事なのはスプリントゴールが完成しそうかどうかを毎日検査して適応することレトロスペクティブ（ふりかえり）で出た項目を、次のスプリントのスプリントバックログに含めること以下、詳細です。 更新内容 スクラムの用途についてスクラムマスターの役割の定義を洗練させたデイリースクラムはス

みなさんこんにちは。@ryuzeeです。 2016年9月16日に行われたDevelopers Summit 関西で表題のテーマで登壇してきましたので資料を公開します。 カイゼンについては1日のトレーニングコース（バリューストリームマップ作成含む）を[@haradakiro](https://twitter.com/haradakiro)と提供していますのでご興味のある方は[ご連絡](https://www.ryuzee.com/contact.php)ください。 アジャイルコーチングやトレーニングを提供しています株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。 詳細はこちら

チームでの開発って大変だけど楽しいと思ってるみなさんこんにちは。@ryuzeeです。 チームは共通の目標に向かって日々の仕事に取り組んでいくことになりますが、そのためにはメンバーそれぞれが必要なスキルをもっている必要があります。このスキルを見える化するテクニックの1つとしておすすめなのが、スキルマップです。 作り方は簡単で以下の図のように横軸に必要なスキルを、縦軸にチームメンバーの名前を入れます。それぞれのマスでは、その人のスキル度合いを表す印を入れていきます。ここでは、★：エース、◎：得意、○：一人でできる、△：助けがあればできる、空欄：できない、・：今後習得したい、というようにしていますが、この記号はチームで好きに決めて構いません。 このスキルマップの効用と運用について見ていきましょう。 効果：スキルの見える化長い間同じチームで働いていれば、誰が何をできるのかはだんだん分かっていきます

今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス

2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。 アジャイルコーチングやトレーニングを提供しています株

全国1000万人の大トロ好きのみなさんこんにちは。 Hashicorpから新たにOttoと呼ばれるプロダクトがリリースされました。 OttoはVagrantの後継となるもので、開発からデプロイまで一気通貫で行うことができるソリューションでマイクロサービスでの活用も考慮されて作られているということで早速試してみました。 軽く触った印象としては、Vagrant、Packer、Terraform、ConsulなどいままでHashicorpが提供してきたツールを組み合わせて一気通貫で操作できるようになった、と考えるとわかりやすそうです。 インストール https://ottoproject.io/downloads.html にアクセスして自分の環境にあったバイナリをダウンロードして展開します。展開したら実行できるようにPATHに追加します。 僕の場合はアーカイブを~/tools/otto/に配置

みなさんこんにちは。@ryuzeeです。 2012年3月16日に実施されたAgile Japanの大阪メイン会場に登壇させていただきました。 発表の資料を以下に公開します。 会場の外まで立ち見が溢れるくらいの多くの方にお越しいただき感謝するとともに、ご不便をおかけした方にはお詫びしたいと思います。 僕が話した内容は、実は単に実際の現場で、現場を良くしたいと思っている皆さんの胸のうちを代弁しただけです。 アジャイルという単語、スクラムやXPといった手法の名前自体の認知度があがって、ともすればこれらを導入すれば全てうまくいくんだ、と誤解を生んでいるのではないかと感じています。 でも手法は手法でしかなく（したがってスクラムやXPを導入しているからといって自分たちのアジャイル度合いが高いとは限らない）、目的に応じてそれにあった方法、自分たちがゴールを達成するのに最適だと思う方法を脳みそ振り絞って考

みなさんこんにちは。@ryuzeeです。 昨年夏に同人誌として刊行された「Ultimate Agile Stories」に寄稿させていただいたのですが、昨日のJim Coplien氏の認定スクラムマスター研修でもコミットメントの話が出ていましたので、参考までに僕の考えを転載します。 なお、Ultimate Agile StoriesはIteration2として今年も刊行を計画されるそうなので、是非動向をウォッチしておいてください。昨年は平鍋さんをはじめとする日本のアジャイルコミュニティを牽引するすごい方たちがたくさん寄稿されていました。 システム開発をしていると「コミットメント」という単語をよく耳にするだろう。アジャイル、特にスクラムの文脈においては「コミットメント」は重大な意味を持っている。本稿ではシステム開発における「コミットメント」とは何なのかについて考察してみたい。 1. 辞書の定

10/19(水)と10/22(土)に日本で初めてのScrum Gatheringを無事に行うことが出来ました。 イベント会社を利用することなく、スタッフ一同試行錯誤しながら創り上げたので、実行委員としてはまずはほっとしているというのが正直なところです。 大きな事故は某氏がセッション中に講演者の前で派手に転倒するという一点だけで、その他は重大な問題が出ることなく実施することが出来たのは、参加者の皆様や講演者の皆様、スポンサー各社様、協力頂いた翔泳社様、早稲田大学様、野村コンファレンスプラザ日本橋のスタッフの皆様、プレスの皆様、裏方メンバーのみんなのおかげだと思っています。 本当にありがとうございました。 セッションの内容については、多くの方が既にブログ等を書かれているので、#sgt2011タグのツイートを参考に調べてください。 今回のScrum Gathering TokyoではHenrik

今やっている案件ではCakePHPを使ったアジャイル開発で、当然テストも自動化している。 テストの自動化を徹底的にやったので楽なんだけど、次回の案件のためにどういう観点でテストを組んでおくと良いか、またどこに嵌りがあるかメモとして残しておく。 CakePHPに限らない話 テストしやすい実装にする。例えばメソッドに複数の異なる役割を持たせない。引数と戻り値が明確。適切な行数など MVCの複数レイヤーにまたがる処理を書かない。例えばコントローラの中でSQLじゃぶじゃぶ投げたり、バリデーションチェックをぐちゃぐちゃやったりしない 自動でテスト実行できる仕掛け作り。例えばPHPならphpUnderControl。JAVAならCruiseControlとかHudson。 基本に返って、テストを先に書くという意識付け テストがいっぱいありすぎたら今度はテストのリファクタリング。似たようなテストがコピペ