Scrum Guide Reordered（日本語版）
みなさんこんにちは。@ryuzeeです。 スクラム実践者のバイブルとなるのがスクラムガイドです。 本文は、日本語版の場合で12ページと分量は少ないですが、多くの人のフィードバックを受けて何度も改訂しているだけあって必要なことが凝縮されています。 チームで定期的に読み合わせをすると学びがあって良いのではないかと思います（安定の角さん翻訳で読みやすさも抜群です）。 一方で、スクラムでは責任とイベントと作成物が密接な関係を持つため。どの順番に説明しようとしても、まだ説明していない他の要素に依存したり、説明が分散したりします。 これは構造上仕方がないことですが、初学者にとってはとっつきにくさもあるかもしれません。 例えば、スプリントレビューの内容に関する記述は、スクラムガイド日本語版では、7ページ、10ページ〜11ページ、13ページに分散しています。 10ページから11ページがスプリントレビューそ
新刊『チームトポロジー』発売のお知らせ
みなさんこんにちは。@ryuzeeです。 言いたいことはタイトルに書いたとおりなのですが、2021年12月1日に、新刊『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』が発売になります。 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計著者／訳者：マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎出版社：日本能率協会マネジメントセンター発売日：2021-12-01単行本：280ページISBN-13：9784820729631ASIN：4820729632 原著はMatthew Skelton、Manuel Pais氏の『Team Topologies: Organizing Business and Technology Teams for Fast Flow』で、翻訳は株式会社アトラクタのアジャイルコーチ（いつ
なぜスクラムチームの開発者が複数チームを兼任しないほうがよいのか
みなさんこんにちは。@ryuzeeです。 よく受ける相談の1つに、「スクラムチームの開発者は複数のチームやプロダクト、プロジェクトを兼任してもよいのか」というのがあります。コーチ業をしている人ならみんな受けたことがあるものだと思いますが、詳しく見ていきます。 まず最初に結論ですが、タイトルにもあるとおり、「スクラムチームの開発者は複数チームを兼任しないほうがよい」です（スクラムガイドには書いていないですが、スクラムガイドは全てを詳細に記したハウツーではありません。あくまでゲームのルールです）。 理由を順番に見ていきましょう。 1. 開発に使える時間がかなり少ないスクラムチームの開発者はスプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブといったイベントと、プロダクトバックログリファインメントのような活動に一定の時間を使います。 チームによって時間は変わ
【PDF公開】Scrum Starter Guide
みなさんこんにちは。@ryuzeeです。 以前、「スプリント1を始める前にどんな準備をするか」という記事を公開したのですが、この記事に内容を加筆修正してPDF化したものを用意しましたので公開します。 スクラムは非常に軽量なフレームワークで、Howについてはほとんど触れられていないため、これから立ち上げるときにどんなことをやればよいのか困ってしまう人も多いようです。 何も準備せず、いきなりスプリントで開発を始めようとしたり、逆に何か月もかけて事前準備をしてしまい、ウォーターフォールと変わらないやり方をしている例も見かけます。 本書では、スクラムを始めるときにどんな準備をしてから始めればよいかを整理しています。あくまで筆者の経験を整理したものですので鵜呑みにせず取捨選択しつつ活用ください。 PDFをダウンロードする 最初は同人誌などで出そうかなと思ったのですが、色々大変そうなので、無料でご利用
スクラムを1枚で説明する資料7選（2019年版）
みなさんこんにちは。@ryuzeeです。 スクラムの全体像を表す絵は多数出回っています。コーチングやトレーニングを生業にしている人であればだいたい何度も作ったことがあるのではないかと思います。 今日はスクラムの全体像を表す絵のうち、比較的新しいものをいくつか集めてみたので紹介します。 見出しの行か画像をクリックすると、それぞれオリジナルを公開しているページにアクセスできます。 The Scrum Framework Poster | Scrum.org ケン・シュエイバーが設立したScrum.orgのサイトで公開されているもの極めてシンプルなので汎用性は高い一方で、スクラムマスター、プロダクトオーナー、開発チームの記述がでてこないなど、要素がすべて網羅されているわけではないことに注意が必要Visual AGILExicon Essential Scrumの著者Ken Rubin氏作のもの。
誰がプロダクトオーナーをやるとよいのか？
みなさんこんにちは。@ryuzeeです。 最近立て続けにプロダクトオーナーを誰がやるとよいのか聞かれることがあったので、パターンとメリット・デメリットを整理しておきます。 なお、組織のサイズや業種、扱っているプロダクトによっても変わってくるので、考え方のロジックとして読んでいただければと思います。 プロダクトオーナーとは？まず最初に前提として、プロダクトオーナーの責任ややるべきことをスクラムガイド（2017）で確認しましょう。 5ページ：プロダクトオーナー プロダクトオーナーは、開発チームから生み出されるプロダクトの価値の最大化に責任を持つ。組織・スクラムチーム・個人によって、その方法はさまざまである。 プロダクトオーナーは、プロダクトバックログの管理に責任を持つ1人の人間である。 (中略) プロダクトオーナーは1人の人間であり、委員会ではない。委員会の要求をプロダクトバックログに反映する
スプリントのキャパシティを明らかにする方法
みなさんこんにちは。@ryuzeeです。 スプリントを始めるには、スプリントプランニングを実施します。 プロダクトオーナーはあらかじめプロダクトバックログの並び順を最新にしておき、プロダクトオーナーはどれを実現したいのかを提示するとともに、開発チームは実際にどれくらい実現できそうなのかを考えた上で、対象となるプロダクトバックログアイテムを選択します。その上で、選択したプロダクトバックログアイテムを実現する方法を開発チームは検討し、作業計画をたてます。 このときに考慮が必要になるのが、スプリントのキャパシティです。 キャパシティとは何かスプリント期間が1週間の場合で考えてみましょう。 1週間スプリントの場合、休日を抜くと5日間になります。その間毎日8時間働くとするとスプリント期間中の総時間数は40時間になります。 しかし、この40時間に人数をかけ合わせたものがキャパシティになるわけではもちろ
スクラムで削除された5つのトピック
みなさんこんにちは。@ryuzeeです。 スクラムのフレームワークの中身はスクラムガイドで定義されていますが、登場以来ずっと同じ内容なわけではなく、何度か改定が行われています（2010年版、2011年版、2013年版、2016年版、2017年版）。過去の改定内容はこちらに記載されています。 過去の変遷においてよく議論になる5つの項目についてWillem-Jan Ageling氏が5 controversial topics that were removed from Scrumという記事にまとめています。 御本人から快諾いただきましたので和訳にて紹介します。 スクラム再発見の時間です。 5年かそれ以上前にスクラムを適用した場合、現在のものとは異なる情報源を元にしていたはずです。 しかし、スクラムとして定義されてスクラムガイドで言及されたものの、ある時点で削除されたものが多数あります。 ま
Scrumプロジェクト開始のベストプラクティス #RSGT2018
みなさんこんにちは。@ryuzeeです。 2018年1月11日から13日まで開催されているRegional Scrum Gathering Tokyo 2018で登壇いたしましたので、資料を公開します。 今回は、実際にスプリント1を開始する前にどのような準備をしておけばよいかがテーマです。 スクラムでは、プロダクトバックログが用意されていて、それを元にスクラムチームでスプリントプランニングを実施し、スプリント期間中毎日デイリースクラムを行い、最後にスプリントレビューとレトロスペクティブを実施することになっています。またスプリント中の次以降のスプリントの準備としてプロダクトバックログのリファインメントを実施します。 つまりプロダクトバックとスクラムチームが存在するところがスタート地点になっています。 では、これらはどこから出てくるのか、どのように作っていけば良いのか、という話になります。 資
【資料公開】Effective Retrospective (効果的なふりかえり)
みなさんこんにちは。@ryuzeeです。 2017年3月18日におこなわれたProductivity Engineering − Forkwell Meetup #4の登壇資料『Effective Retrospective』の資料を公開します。 登壇の時間が20分ですので基本的な内容になっていますが、これからふりかえりを始める方やなんとなくいまのやり方がうまくいかないと思う方には役にたつと思います。 もっと詳細が知りたい場合は、アジャイルレトロスペクティブズを一読することをお勧めします。2007年の本ですがまったく陳腐化していないので参考になると思います。 なにかご質問があればTwitterなどでお知らせください。それでは。 SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発著者／訳者：西村 直人、 永瀬 美穂、 吉羽 龍太郎出版社：翔
物理カンバンの写真10枚（＋勝手レビュー）
みなさんこんにちは。@ryuzeeです。 他の会社やチームで使っているカンバンを見れる機会はそう多くはないのではないでしょうか？ そこでFlickrでCreative Commonsライセンスで投稿されているカンバンの写真のうち、役立ちそうなものを10枚紹介します。 それぞれ写真に対して、写真から読み取れる良い点や改善点をコメントとしてつけましたので、自分のカンバンを改善する役にもたつと思います。 その1https://www.flickr.com/photos/drewm/369319379/こんなにたくさんの項目が貼られると制御しきれないので、タイムボックス等を導入して、定期的にクリアするレーンは線で区切った方が良い付箋が反り返っている。正しい剥がし方をしていないかも付箋の色の違いに意味をつけるその2https://www.flickr.com/photos/dinomite/3219
物理カンバンを作るときに用意しておきたい道具10選
みなさんこんにちは。@ryuzeeです。 今日は物理カンバンを作るときに役立つ道具を10種類紹介します。なお、実際のカンバンの例については、拙訳：アジャイルコーチの道具箱 – 見える化の実例集も参照してみてください。 1. 付箋紙 (3Mの強粘着を強く推奨) 当然のことながら物理カンバンを作るときに一番よく使うのが付箋紙です。 剥がれてなくなってしまってはまずいので強粘着を使うようにしてください。おすすめは当然のことながら3Mのものです。 なお、余談ですが、3Mの付箋紙だけを「ポスト・イット」と呼びます。 サイズは自分のボードに合わせれば良いのですが、よく使われるのは、75ミリの正方形です。なお、パックで買うと色々な色が含まれていますが、勿体無いからといって全色を闇雲に使わないようにします。 一般的には通常のタスクを黄色に、緊急をピンクに、といった形で色別に用途を定義しておいてください。で
組織やチームづくりに役立つ20冊
こんにちは。@ryuzeeです。最近、組織やチームのことを考えるヒントになる本を紹介してほしい、と言われることが多いのでダンプしておきます。あくまで自分で読んだ私見で選んだものなので、この定番がないのは何故だとかはあると思います。 定番 ピープルウエア 第3版著者／訳者：トム デマルコ；ティモシー リスター、松原 友夫；山浦 恒央；長尾 高弘出版社：日経BP社発売日：2013-12-24Kindle版：158ページISBN-13：ASIN：B00I96CJWO 「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」とあるように、ソフトウェア開発における問題点を人間の観点で整理している名著。第IV部では生産性の高いチームを育てるというテーマで機能するチームの特徴やチームの壊し方(守りのマネジメント・官僚主義・作業場所の分散・時間の分断・品質の削減・はったりの
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
デプロイ自動化を進めるためのチェックリスト | Ryuzee.com
いままで色々なところで言ってきたことをだらだらとまとめてみました。 計画および準備段階要求される品質の定義をおこなうDevとOpsの双方で情報が共有されるようにするいつデプロイを開始するのかを明らかにするデプロイの際にインフラを変更する必要はあるのかを明らかにするデプロイを行う時間帯、行わない時間をあらかじめ決めておく(休み前を避ける)ブランチ戦略、マージ戦略を決める継続的インテグレーションの戦略を決めるログの出力戦略を決めるビルドとリリースの自動化人的要素を減らす繰り返し可能にする自動作業と手作業を混ぜないビルドを自動化する誰のマシンでもビルドできるようにするユニットテスト、結合テスト、UIテストなどテストを自動化する本番にデプロイする際にコードを書換えなければならないといった実装を避ける毎回デプロイプロセスを設計するのではなく、毎回同じ方法でデプロイする毎回同じ方法が難しければ2パター
5分で分かるDockerのキホン
全国100万人のImmutable Infrastructure職人のみなさんこんにちは。 もう誰も彼もがDockerなので、あんまりブログに書こうという気にもならなかったのですが、知り合いからリクエストを貰ったので、5分くらいで分かるようにかいつまんで概略を説明します。 Dockerとは詳しくは本家サイト見ればだいたい分かる。仮想化技術コンテナ単位でパッケージングVirtualBoxとかと違って高速、オーバーヘッドが少ない。chrootに近い。LXCには依存しなくなっているコンテナごとにIDが振られるコンテナは差分保存なのでロールバックも簡単一回作ればどこでも動く。JavaっぽいDockerfileでコンテナを作成するDockerfileの1行ごとにコンテナIDがフラれる動作環境Linux Kernel 3.8以降 64bit OSMacの場合はVirtualBoxの中で動かす形になる→
2013年ふりかえり
もう大晦日ですが、2013年をふりかえっておくことにします。 1月 Scrum Alliance Regional Gathering Tokyoの実行委員(スクラムマスター)として、大忙しだった気がします。 半年以上かけてイベントの企画や準備を進め、事故なく無事に開催できて何よりでした。 このイベントでは、アジャイルな人たちが好き勝手に暴言を吐くScrum The Next Generationというセッションでお話しました。スライドは以下です。 2月 西村さんと永瀬さんと僕の3人で書いていたSCRUM BOOT CAMP THE BOOKが2/12に発売されました。直前に平鍋さんが書かれた「アジャイル開発とスクラム」 が発売されていたので初めての日本人が書いたScrumの本ではなかったのですが、Scrumの考え方や仕事の進め方を体系的に学べる書籍になったと思います。 ちなみに、この本の
【資料公開】ワンクリックデプロイ 〜いつまで手でデプロイしてるんですか〜
みなさんこんにちは。@ryuzeeです。 2013年2月15日に目黒雅叙園で行われたデブサミ2013で登壇してきましたので、その際の資料を公開します。 「いつまで手でデプロイしてるんですか？」ってキャッチーなタイトルにしたのは、公募セッションの申し込みの時に目につくようにしたかったためで、会場でアナウンスしてくださる方にこのセリフを言って欲しかったわけではないので念のため。 デプロイの自動化を進めていくのは正直なところ大変です。 今の現状からいきなり明日デプロイを自動化できるわけでもないし、誰かがいきなりデプロイを自動化してくれるわけでもありません。 その前に考えなければならないこともたくさんあると思います。 でも現実にAmazonやFlickrを始めとしてそれを実施している会社は多数あるし、日本にもそういう会社は多数あるわけです。ちょっとずつカイゼンしながら本当に利益に繋がるところに時間
プレゼン用の写真をFlickrでいい感じに探す方法
みなさんこんにちは。@ryuzeeです。 僕のプレゼンでは写真を一杯使います。写真が一杯あると、記憶に残りやすく伝わりやすいというメリットがあります。 また隠れメリットとして、写真を多めにして文字を少なくすると、時間に応じて聞いている人に悟られることなく内容を調節することも可能です（僕がいつも時間通りに終えられる理由です）。 写真はFlickrで無料のものを探すのと、iStockPhotoで有料の画像を購入するのとを組み合わせていますが、今回はFlickrでいい感じに探す方法を紹介します。 なお、FlickrのWebサイトはあまり軽くない感じなので、専用のツールを使います。 何個かツールを仕込んでおくと移動中の空き時間に画像を探しておいてあとで一括でダウンロードすることも可能です。 iPadで探すFlickStackrというツールを使います。無料版もありますが、機能制限が多いので有償版を使
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【資料公開】カンバンのキホン
