2012年も沢山の組織や会社さんにお声がけをいただき、AgileやScrumについて基礎を習得していただくための研修を実施させていただきました。 研修用の資料は随時加筆修正しているのですが、来年からは新しいコンテンツを使う予定ですので、今年主に使っていた研修用のスライドを公開します。200ページ程ある巨大な資料で、研修では一日かけて説明している内容です（ワークショップを研修時間の半分ちかくおこなっています）。個人や組織内での学習のためにご利用ください（お約束ですが営利目的では使わないでくださいね！）。 今年研修で主にやったワークショップは、紙飛行機ゲーム、マシュマロチャレンジ、自己組織化ゲーム、マネージャー・ワーカーゲーム、ピンポン玉ゲーム、プロダクトバックログ作成、プランニングポーカー、ボールゲーム、マルチタスク適性診断あたりだったのですが、来年用には新しいネタをいくつか仕込んでいますの

みなさんこんにちは。@ryuzeeです。 よくスクラムで初期見積りってどうやるの？って聞かれますので、思ったことをツラツラと書いておきます。 ちなみに見積りはあたらないので（もちろん当てる努力はしますし、当たった方がいいのは勿論ですが）、そのつもりで考えたほうが良いでしょう。 例えば競馬で一点買いして毎回的中すると思う幸せな人はあまりいませんが、一方で開発の見積りは毎回当たると考えちゃうのはどうかしてるということです。 1. 開発初期に全体を見積もるそもそも一発であたる見積りをするのは不可能であるのは不確実性コーンのグラフ等を見れば分かります。 だからといって見積りをしなくてよいわけではありません。 この時点では、分かっている要求をプロダクトバックログに落として、それぞれのプロダクトバックログアイテムをラフに見積もっておきます。 もしプロダクトバックログがないようであれば、そもそも何のため

An Agile Game - Management by Walking Aroundより。以下に紹介するワークショップは認定スクラムマスター研修などでもよく行われるもので、自分の会社でも簡単にできるので是非やってみていただきたい。 コーチやトレーナーやスクラムマスターがチームを教育するための簡単なゲームを紹介しよう。このゲームは時間もかからず簡単な体を使うもので、単純なルールやタイムボックスによって自己組織化された環境がつくられる様を示している。自己組織化された環境はリスクを軽減し、エンゲージメントやスピードや柔軟性を向上させる。 概要と事前準備所要時間：感想や報告を含めて10分〜15分対象人数：10人〜50人準備：テーブルや椅子等の物が置かれている十分に広い部屋、部屋の中にゲームの参加者が十分動けるだけのエリアの境界線を引くためのマスキングテープ。そしてタイマーラウンド1のやり方参加

みなさんこんにちは。@ryuzeeです。 アジャイル開発のコーチングやトレーニングでスクラムの全体像を1枚の絵を使って説明することが多いのですが、以前作成したものを最新化したので公開します。 スクラムの本質的な価値やスクラム以外でも日々のプロセスに組み込んだほうが良いこと（テスト自動化や継続的インテグレーション）は含めていません。 あくまでスクラムの概要のみを書いています。 PDF版はこちらにおいておきます。 ※改変なしで引用元併記の上であれば自由に使っていただいて結構です。著作権自体は私に留保します。 内容の誤りや足りない事などがありましたらTwitterなどでお知らせください。 自分のスライドに入れて使うためのパワーポイント版はこちらになります。 著作権表示なしでご利用いただけます（ただしこのファイルを含んだパワーポイントの再配布および販売はできません）。 それでは。 SCRUM BO

著作 SCRUM BOOT CAMP THE BOOK 著者／訳者：西村直人 永瀬美穂 吉羽龍太郎 出版社：翔泳社( 2013-02-13 ) 定価：￥ 2,520 スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。 CakePHPで学ぶ継続的インテグレーション 著者／訳者：渡辺 一宏 吉羽 龍太郎 岸田 健一郎 穴澤 康裕 出版社：インプレス( 2014-09-19 ) 定価：￥ 4,320 Webアプリケーション開発における継続的インテグレーションについて、CakePHPのサンプルをベースにして、その概要から使用ツール解説、導入方法、メンテナンスまでを解説 Chef実践入門 ~コードによる

(顧客) そのシステムを作った結果に対して、顧客自身が結果責任を背負っていない場合は、ウォーターフォールの方が楽。最初に仕様合意して最後に「納品」されれば良い。場合によっては、システムによって得られる価値が目的なのではなく、「システムを作る」こと自体がアリバイ的に目的であるケースすらある。こういう場合は、顧客自体のプロジェクトへの参画が必要なアジャイルは面倒だと思うだろう(顧客) また、顧客が開発部隊に対して政治的に極めて強い力を持っている場合なんかは、基本的に全てのリスクを政治的な力によって移転できるので顧客側が大きくコミットする必要性はなく、ウォーターフォールの方が彼らにとっては楽かもしれない(顧客) その一方で顧客自身が結果責任を背負っている場合やそのシステム自体がビジネスの中心を担っているような場合、肉体的ではなくリスクマネジメントとして楽なのは圧倒的にアジャイルであると言える。市

みなさんこんにちは。@ryuzeeです。 他所の現場のデイリースクラムを見る機会は普通の人はなかなか無いと思うのでご紹介します。 この動画はシアトルのマイクロソフトでTeam Foundation Server（TFS）のアジャイル対応部分を作っているチームとのことです。 動画を見ていただくと分かるがいくつか特徴があるので解説しておきましょう。 スクラムでプロジェクトを行なっており、スクラムマスターやプロダクトオーナーというロールがちゃんと存在するデイリースクラムの基本に則り、スタンドアップで行なっているこれも基本通り、昨日やったこと、今日やること・・・のフォーマットで行われているタイムボックスも守られている（動画の時間から推察するに）スクラムボードの前で行うのが基本だが、そのかわりにTFSの画面を大きく写して行なっているすなわち、マイクロソフトといえども、守破離の守を行なっていることが分

みなさんこんにちは。@ryuzeeです。 How to hire an Agile consultantより。 アジャイルコーチの雇い方について分かりやすい記事があったので抜粋・意訳にてご紹介します。 名もない人を雇ってはいけない地理的な理由や金額的な理由でコーチを選定してはいけない推薦してもらう計画をたてるコンサルタントを調査する私はしらない、と喜んでいうコンサルタントを探す契約の前にフェイスツーフェイスで会って話す初期のアセスメントをリクエストする1. 名もない人を雇ってはいけない端的に言えば、大きいコンサルティング会社に相談すると、「彼が適任です」といって人を割り当てたりすることがあるが、それが、雇う側にとって本当に適任かどうかはそもそも分からない（ひどい言い方をすれば、ただ単にその時に稼働があいていたから適任だと言って売っているだけかもしれないし、そもそも○○メソッドみたいなのを売

Agile Buffet Cardとは、Agileに関する主なプラクティスを集めたカードのことです。現在34個のプラクティスが含まれています。 元ネタとしては、2011年9月に@tomohnさんと@qooh0さんとXP祭りでAgile Buffetというワークショップから来ています。 このワークショップでは自分たちのプロセスをコンテキストに応じて設計してみよう、というワークショップで、ScrumやXPやKanbanなどから自分たちが使うべきプラクティスを選択してプロセスを組み立てます。（プラクティスの都合のよい単なるつまみ食いは問題なのですが、コンテキストを理解した上でより良いプロセスを目指して取り組むのは悪いことではありません。守破離の破以降の取り組みだと思ってください） カードはここからダウンロードできます。再配布や販売は禁止ですが、ここからダウンロードして使う限りは好きに使ってくださ

みなさんこんにちは。@ryuzeeです。 http://kaji-3.hatenablog.com/entry/2012/04/05/072641 にてこれから導入を検討されているkaji_3さんが悩みを書かれていたので、プロのコーチとして感想を書いてみたいと思います。 新プロダクト作成にアジャイル開発が有益ではないかと組織が興味を持ってきているため、会社にどのように導入していくか提案予定です。 しかし、社内にアジャイルコーチなどいるはずもなく、テストの自動化すらできていない状況でどう進めていけばいいか悩み中です。 ゴールは来年、から開発する新プロダクトにスクラムを適用する。。です。 まず新プロダクトにアジャイル開発が有益だと考えた理由をはっきりさせた方が良いでしょう。 従来型の開発では難しいと思った理由や、それが本当にアジャイルで解決できる(可能性が高い)ものなのか？ そもそも現状の開発

みなさんこんにちは。@ryuzeeです。 Free Intro To Scrum Wallpaperにて、マイク・コーン氏作のAn overview of Scrumの絵を格好良くしたものを作られたそうなので紹介します。 なお日本語化は僕のほうで行いました。 元のサイズは1600x1200で、ここにおいておきます。 ライセンスは元の画像にしたがって、Creative Commons Attribution 2.5 Licenseで、右下の著作者の名前を消さない限り商用・非商用問わず再配布自由です。 それでは。

かわぐちさんが簡単ガイドを作られていたので僕も普段研修とかコーチングで使っているマテリアルを晒しておきます。 色々なやり方があるので、どれがあってるとか間違っているとかは無いですし、認定スクラムマスター研修なんかでも講師によって若干やり方が違ったりします。一例ということで。 なお、僕が普段コーチをする上でよく言っている点を以下に書いておきます。 大きすぎると見積り精度はどんどん落ちる。ストーリーがでかいと思ったら分割するそれに関連して僕は1,2,3,5,8,13,?くらいしか使わない。20は使う必要ないなぁみんなが似たような数字出したからといって中身の完成イメージが同じとは限らない。見積もる際の議論大事タイムボックス大事。だらだら時間かけてやらないプロダクトバックログの見直し（リファインメント）同様に、見積りも定期的に見直す追記 いま日本でプランニングポーカーを入手する方法は以下の通りです

みなさんこんにちは。@ryuzeeです。 今度翔泳社さんから発売される、「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」という本に明らかに場違いな感じ(まわりの人凄過ぎる)ですが、寄稿させていただきました。 100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊著者／訳者：出版社：翔泳社発売日：2012-02-22単行本（ソフトカバー）：216ページISBN-13：9784798126005ASIN：4798126004 原稿を公開して良い、ということなので、公開しておきます。他の寄稿者の方は本当にすごい方ばかりで、いままでにないタイプの本だと思いますので、本当にオススメです。 僕が選んだ本は、あえてアジャイルプラクティスです。 アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣著者／訳者：Venkat Subramaniam、Andy Hunt

以前に作っておいた大きめなリリースをする際にチェックしておくべきことのリストが役に立ちそうなので公開しておきます。 僕の場合は普段はワンクリックデプロイが多いんだけど、かなり大掛かりな変更をするケースが年に数回あったりするので、その際にこういうリストを使ってリリース計画をチェックしています。(もちろん大掛かりなリリースでもワンクリックでできるのに越したことはないし、そもそもビッグバンリリースにならないようにできるだけ小さい単位で頻繁にリリースできるに越したこともない) 体制当日の体制は決まっているか夜間立会いの場合、日中の営業時間の対応体制は決まっているか翌営業日以降の体制は決まっているか連絡担当と作業担当は分離されているか作業担当はペア作業になっているか。作業者と確認者を定めているか顧客の連絡先を抑えているか顧客の連絡順番を抑えているか、お客様の当日の所在を抑えているか顧客への連絡タイミ

みなさんこんにちは。@ryuzeeです。 よく一緒に議論したり大学行ってワークショップをしたりしている原田さんが、スクラムでのコードレビューについて書かれましたので、僕も過去数年コーチとして色々な現場に行った際のことや、自分で受託開発をスクラムでやった際のことを踏まえてスクラムにおけるコードレビューのやり方を書いてみます。 レビューのやり方早期から頻繁に僕自身は小規模で頻度の高いインクリメンタルなレビューを好んでいます。 かつて大きなSIerにいてウォーターフォール型の開発をしていた際に、パートナーさんから出てきたソースコードを見ると、コピーペーストの嵐だったり、変数名がデタラメすぎたり、インデントがぐちゃぐちゃだったり（以下思いつく全ての「えーーー」を適当に想像してください）して、かつ工程の後半にレビューしていたので、直すに直せないというような悲惨なことも経験しました。 （注）ウォーター

みなさんこんにちは。@ryuzeeです。 このタイトルで記事を書く約束を@katzchangと約束したので、書いてみたいと思います。 前提として、スクラムマスターはいないが管理職がたくさんいて、日々現場のメンバーが悩まされているようなシチュエーションを想像しています。 （かなり）現実の管理職を悪くステレオタイプ化していますが、スクラムマスターとの対比のためにあえてそうしています。 うちの管理職はもっとまともだ！とか言わないようにしてください。 管理職は部下を育てる責任、もしくは勝手に育つような環境を用意する責任がありますが、もう1つの大きな責任である「数字（※1）をあげる」というテーマが優先されてしまう。 （※1：ムリと分かっていても勝手に経営が決めて部門目標とかいう名の元に押し付けてきた売り上げと利益目標のこと）。→スクラムマスターはコーチ・ファシリテーター・メンターとして、チームの成長

アジャイルサムライ−達人開発者への道− 著者／訳者：Jonathan Rasmusson 出版社：オーム社( 2011-07-16 ) 定価：￥ 2,808 Amazon価格：￥ 2,808 単行本（ソフトカバー） ( 288 ページ ) ISBN-10 : 4274068560 ISBN-13 : 9784274068560 アジャイルサムライは、Jonathan Resmusson氏が昨年書いた本で、日本語監訳は永和システムマネジメントの西村さん(@nawoto)と角谷さん(@kakutani)。 僕は僭越ながら翻訳原稿のレビューに参加させて頂いたのだが、本当に素晴らしい本で、出版を心待ちにしていました。 これからアジャイルな開発に取り組もうとしている人にとっても、既にアジャイルな開発に取り組んでいる人にも役に立つ必携図書であること間違いなしです。 この本の特徴 ScrumやXPやLe