スクラムにおける技術的スパイクの進め方
みなさんこんにちは。@ryuzeeです。 スクラムでは、スプリントに投入するプロダクトバックログアイテムはReady（準備ができている）である必要があります （Readyとはどんな状態なのかについては以前に詳しく説明したので、そちらを参照してください）。 Readyにしておくことによって、成果の量が安定しプロダクトオーナーやステークホルダーにとっては予測精度が向上していきます。 Readyにする活動は単に受け入れ基準を用意したり、プロダクトバックログの内容を精緻化したり、並べ替えたりするだけではありません。 スプリント内でプロダクトバックログアイテムが完成する可能性を上げるために必要な活動すべてが含まれます。 そしてその中の1つが技術的な調査です。 スプリントでプロダクトバックログアイテムに着手してから実現方法を調べたり、技術的な制約によって大幅な方針転換したりするのでは遅い上に予測性が低
アジャイル開発やスクラムのトレーニングでよく聞かれる質問とその答え (1)
みなさんこんにちは。@ryuzeeです。 弊社ではアジャイル開発、スクラムのトレーニングを提供しているのですが、トレーニング中には多くの質問をいただきます。 今日はよくある質問とその答えについていくつかご紹介したいと思います。 好評そうだったら続編も書く予定です。 ■アジャイル開発において、ドキュメント作成の一般的な指針を教えてくださいどのようなドキュメントがいつ、どの粒度で必要なのかはプロダクトやプロジェクトに依存します。 プロダクトやプロジェクトにはそれぞれ固有の品質基準があり、それはアジャイルやウォーターフォールといった方法論の違いによって変わるものでもありません。 したがってプロジェクト冒頭でプロダクトオーナーやステークホルダー（品質管理部門や顧客など）と「なんのために」「どのようなドキュメントが」「どのような記述レベルで」「いつまでに必要なのか」を決定してください。 誰も使う予定
スクラムガイド2017での変更点の紹介
みなさんこんにちは。@ryuzeeです。 2017年11月7日(現地時間)にスクラムのルールブックであるスクラムガイドが更新されましたので、Webinarの資料をもとに変更点をご紹介します。 なお、スクラムガイド自体はこちらからダウンロード可能です。日本語訳はさまざまな書籍の翻訳で有名な角征典さんです。以下の紹介に際して、スクラムガイド日本語版の記述を引用しています。 実践に際して、大きな影響はあまりないと思いますが、とくに以下の2点が注目だと思います。 デイリースクラムで3つの質問を使うかどうかはチーム次第となった。大事なのはスプリントゴールが完成しそうかどうかを毎日検査して適応することレトロスペクティブ（ふりかえり）で出た項目を、次のスプリントのスプリントバックログに含めること以下、詳細です。 更新内容 スクラムの用途についてスクラムマスターの役割の定義を洗練させたデイリースクラムはス
スクラムで開発チームが自由な取り組みをするには？
みなさんこんにちは。@ryuzeeです。 スプリントをずっと回していると、「いつもスプリントに追われている気がする」「一回立ち止まってゆっくり考えたい」「情報共有ができていない気がするので整理したい」「技術検証をもっとやりたい」「勉強時間をとりたい」といった話を聞くことがあります。 それに対して、どのように対処していくべきか考えてみましょう。 考えられる対応策はいくつもあるので、まずはそれを列挙します（ダメなものも混ざっています） 複数回スプリントを実施したら、1回分のスプリントでは開発チームは好きに活動する（✕）スプリントとスプリントの間に休憩を入れる（✕）フィーチャー開発以外の取り組みを行うスプリントを必要に応じて用意する（△）スプリントのキャパシティを見直して、開発チームが持続可能なペースで働けるようにする（◎）それぞれを順番に見ていきましょう。 複数回スプリントを実施したら、1回分
【資料公開】カイゼンの基本
みなさんこんにちは。@ryuzeeです。 2016年9月16日に行われたDevelopers Summit 関西で表題のテーマで登壇してきましたので資料を公開します。 カイゼンについては1日のトレーニングコース（バリューストリームマップ作成含む）を[@haradakiro](https://twitter.com/haradakiro)と提供していますのでご興味のある方は[ご連絡](https://www.ryuzee.com/contact.php)ください。 アジャイルコーチングやトレーニングを提供しています株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。 詳細はこちら
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
採用プロセスを真剣に考えろという話
人材流動性の高まりを日々感じているみなさんこんにちは。 最近いろんな会社にお呼ばれしていて、その中でエンジニアの採用の話になることがとても多いのでちょっと整理しておきます。 ポイント▼「面白いプロダクトもないし、仕事内容は面白いとは思えないし、よい給与は払えないし、仕事環境にも自由はないけど、良い人雇いたいんだけど、どうしたらよいですか？」悪いが諦めろ。良い人は当然のことながら複数の会社が興味をもつことになるし、働く場所を自分で選択します。Pros/Consを見極めて選ぶことになるので、Prosがない場所で働く理由がありません…だとあまりに冷たいので、もしあなたが次に転職するとして、それでも今の会社に入るのであればあなたを惹きつける理由が何かあるはずで、それをアピールしよう▼「入社してから期待値にあっていないことが分かる、ってことが多いんだけどどうしたらよいですか？」期待値を明文化している
【我流】プレゼンテーション資料の作り方
全国100万人のブリよりワラサ好きのみなさんこんにちは。先日強いチームの作り方を公開したのですが、何人かの知り合いからこういうスライドの作り方教えてほしい、というリクエストを受けたので以下にダンプしておきます。 参考書籍以下にあげる本は一度読んでおいて損はないです。プレゼンテーションZenは、ピアソンが技術書の取り扱いやめてしまい絶版かと思ったけど第二版が出て何より。 ガー・レイノルズ シンプルプレゼンプレゼンテーションZEN 第2版プレゼンテーションZENデザインこれらの本の中でも出てきますが、「プレゼンテーション」と「ドキュメント」は明確に分けた方がいい。 よく会社で経営方針とか数字とかをパワーポイントで作って配りますが、単にデータや説明を見せるならそれこそワードでやった方が読みやすいしコンパクトです。 トヨタがA3用紙1枚でまとめる(最近そうでもないらしいですが)と聞きますが、それと
【資料公開】強いチームの作り方 | Ryuzee.com
2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。 アジャイルコーチングやトレーニングを提供しています株
オープンソースのAPI Gateway「Kong」
全国100万人のモノリシック巨大アプリケーションに苦しむみなさんこんにちは。 世の中猫も杓子もマイクロサービスだ!!とかAPIだ!!とか言っていますが、実際にマイクロサービス環境にしようとすると、どのようにしてAPIのサービスを取りまとめるかが課題になります。 一般的には以下のようなやり方になります。 複数のサービスに分散しているAPIを統合するゲートウェイを用意するそのゲートウェイでは以下のようなことをおこなうクライアントからのアクセスのシングルエンドポイントの役目を果たすAPIの実体へのルーティング認証アクセス記録の収集スロットリング(過度なアクセスの抑止)実体がダウンしている場合のデグレーションこのようなAPIゲートウェイの機能は既にAWSではAmazon API Gatewayとして提供されていますが、オープンソースでもいくつかのプロダクトがあります。今回はそのうち一番開発が活発そ
Hashicorpの新プロダクト「Otto」を試してみた
全国1000万人の大トロ好きのみなさんこんにちは。 Hashicorpから新たにOttoと呼ばれるプロダクトがリリースされました。 OttoはVagrantの後継となるもので、開発からデプロイまで一気通貫で行うことができるソリューションでマイクロサービスでの活用も考慮されて作られているということで早速試してみました。 軽く触った印象としては、Vagrant、Packer、Terraform、ConsulなどいままでHashicorpが提供してきたツールを組み合わせて一気通貫で操作できるようになった、と考えるとわかりやすそうです。 インストール https://ottoproject.io/downloads.html にアクセスして自分の環境にあったバイナリをダウンロードして展開します。展開したら実行できるようにPATHに追加します。 僕の場合はアーカイブを~/tools/otto/に配置
プランニングポーカーのやりかた | Ryuzee.com
かわぐちさんが簡単ガイドを作られていたので僕も普段研修とかコーチングで使っているマテリアルを晒しておきます。 色々なやり方があるので、どれがあってるとか間違っているとかは無いですし、認定スクラムマスター研修なんかでも講師によって若干やり方が違ったりします。一例ということで。 なお、僕が普段コーチをする上でよく言っている点を以下に書いておきます。 大きすぎると見積り精度はどんどん落ちる。ストーリーがでかいと思ったら分割するそれに関連して僕は1,2,3,5,8,13,?くらいしか使わない。20は使う必要ないなぁみんなが似たような数字出したからといって中身の完成イメージが同じとは限らない。見積もる際の議論大事タイムボックス大事。だらだら時間かけてやらないプロダクトバックログの見直し（リファインメント）同様に、見積りも定期的に見直す追記 いま日本でプランニングポーカーを入手する方法は以下の通りです
資料公開 ざっくりわかるScrum
普段あまりシステム開発に携わっていない人やアジャイルな開発の経験がない人向けに色々資料を作って説明しているのですが、今回のモノは個人的に結構しっくり来ているので参考までに公開します（7月くらいから何回か使って検証しました）。 エレベーターピッチ並とはいきませんが、ページ数をかなり削っているので、5分くらいでScrumのおおよその雰囲気は分かるのではないかと思います。 ご意見や感想等がありましたらページ下部のMessageLeafからお知らせいただけるとありがたいです（僕個人にしか見えません）
Robot Framework + Selenium2Libraryで簡単受け入れテスト | Ryuzee.com
Robot Frameworkは受け入れテストや受け入れテスト駆動開発(ATDD)に使えるテスティングフレームワーク。 http://code.google.com/p/robotframework/で開発が進められている。 プレインテキストやHTML形式でテストケースを記述できること、pythonまたはjavaによってテストライブラリを作って拡張できることが特徴だ。 ここではRobot FrameworkとSelenium2(WebDriver)を組み合わせて、受け入れテストを自動化する方法について説明する。 WebDriverを単独で使ってWebアプリケーションのエンドツーエンドテストを作る場合、どうしても画面ができてからしかテストケースが作れないというのが大きな問題だ。そのため例えばPHPであればBeHatと組み合わせしたりするのだが、今回の方法は更に簡単だ。 例えば、アジャイルな開
スクラムにおけるメトリクスの扱い | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 最近よく「スクラムではどんなメトリクスをどう取ればよいですか」と聞かれるので整理しておきます。 スクラムでよく登場する数値データスクラムでよく登場する数値データとしては、プロダクトバックログアイテムのビジネス価値や見積り、スプリントバックログのタスクの理想時間があり、スプリント中に完了したプロダクトバクログ項目の見積りポイント（相対見積りの場合）の合計がベロシティ、全プロダクトバックログアイテムの未完了分の合計見積り値の推移をプロジェクトバーンダウンチャート、スプリント期間中のスプリントバックログ項目の合計残時間の値の推移をスプリントバーンダウンチャートとして表現することができます。 最新のスクラムガイドでは見積りを相対ポイントで行うべきであるとか、これらチャートを書くべきであるとかは規定されておらず、またメトリクスをいつどのように取得するのかにつ
Scrum Boot Camp Premium開催(9/25)のお知らせ そして...!
2012年9月25日(火)にScrum Boot Camp Premium (第3回)を開催します。 おかげ様で大変好評をいただき、第3回目の開催となりました。今後も四半期毎を目処に定期的に実施していく予定です。 今回の研修も、前回同様有償コースということで、 研修資料のハンドアウト(約300ページの資料を印刷・製本したもの) PDU6ポイント スクラム用語集 推薦図書一覧 研修後のメールでの質問への対応 懇親会 がコース内容に含まれています。 なお、PDUもつきますので、所属される会社にご相談の上、会社の研修の一環として参加されることをオススメします。今回も平日開催ですので業務として参加しやすくなっていると思います。是非、受講をご検討ください。 講師は、僕(@ryuzee)と、Scrum Alliance Reginal Gathering Tokyo 2013の実行委員長であり認定スク
書評 Git ポケットリファレンス
著者の一人、Shibuya.tracの創設者でありTrac Lightningの開発者であるOかもとさんから献本いただきました。ありがとうございます！ Gitポケットリファレンス 著者／訳者：岡本 隆史 武田 健太郎 相良 幸範 出版社：技術評論社( 2012-07-10 ) 定価：￥ 2,604 Amazon価格：￥ 2,604 単行本（ソフトカバー） ( 272 ページ ) ISBN-10 : 477415184X ISBN-13 : 9784774151847 技術評論社さんから出ているポケットリファレンスシリーズはもう何冊も出ていて、そのコンパクトさとは裏腹に内容はぎっしり詰まっている感じで、何冊か愛用していました。今回のGitもまさにそういう感じで手元においておくと便利な一冊と言えそうです。 Oかもとさんの前書きをみると、Gitはツンデレで、戦隊ロボのツールと連携できて、Gitの
開発をより良くしたい人が読んでおくべき10冊
アジャイルな開発の導入支援の現場や色々な勉強会でよく「どんな本を読んだら良いですか」と聞かれたりします。 何のために本を読んで勉強するかは人それぞれですし、自分のおかれたコンテキストでどの本が役にたつかは分からないですが、以下にあげた本は個人的に強くオススメできる本です。人に聞くのも大事だし自分で試行錯誤するのも大事だけど、本を読んで体系的に学んだり先人の知恵を学ぶことは続けたほうが良い。 プロダクティブ・プログラマ -プログラマのための生産性向上術どうやったら自分自身の生産性を高くすることができるのか。PCの使いこなしから始まり、自動化やバージョン管理等にも触れている プロダクティブ・プログラマ -プログラマのための生産性向上術 (THEORY/IN/PRACTICE)著者／訳者：Neal Ford、島田 浩二 (監訳)、夏目 大出版社：オライリージャパン発売日：2009-04-27単行
大きなリリースの際にチェックすべき34のこと
以前に作っておいた大きめなリリースをする際にチェックしておくべきことのリストが役に立ちそうなので公開しておきます。 僕の場合は普段はワンクリックデプロイが多いんだけど、かなり大掛かりな変更をするケースが年に数回あったりするので、その際にこういうリストを使ってリリース計画をチェックしています。(もちろん大掛かりなリリースでもワンクリックでできるのに越したことはないし、そもそもビッグバンリリースにならないようにできるだけ小さい単位で頻繁にリリースできるに越したこともない) 体制当日の体制は決まっているか夜間立会いの場合、日中の営業時間の対応体制は決まっているか翌営業日以降の体制は決まっているか連絡担当と作業担当は分離されているか作業担当はペア作業になっているか。作業者と確認者を定めているか顧客の連絡先を抑えているか顧客の連絡順番を抑えているか、お客様の当日の所在を抑えているか顧客への連絡タイミ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プロダクトオーナーの役割を1枚で紹介
