プロダクトオーナーのアンチパターン
みなさんこんにちは。@ryuzeeです。 スクラムにおいてプロダクトオーナーは非常に重要な役割を果たしますが、一方でうまくやるのが難しい役割でもあります。 たとえばプロダクトオーナーには、ビジネス価値を最大化する、プロダクトのビジョンを周りに示して理解させる、プロダクトバックログを管理する、ステークホルダーをマネージする、開発チームの成果物の受け入れ可否を判定するといった多岐に渡る責任があり、限られた時間の中でバランスを取りながらやっていかなければいけません。 今回は、こういうのは避けようというアンチパターンを紹介します。 そもそも…多忙すぎるプロダクトオーナー不在のプロダクトオーナースクラムイベントに参加しないプロダクトオーナー単にマネージャーやリーダーという理由だけのプロダクトオーナーそもそも複数人で意思決定権限が分散されたプロダクトオーナープロダクトオーナーとスクラムマスターを兼任す
スクラムガイド2017での変更点の紹介
みなさんこんにちは。@ryuzeeです。 2017年11月7日(現地時間)にスクラムのルールブックであるスクラムガイドが更新されましたので、Webinarの資料をもとに変更点をご紹介します。 なお、スクラムガイド自体はこちらからダウンロード可能です。日本語訳はさまざまな書籍の翻訳で有名な角征典さんです。以下の紹介に際して、スクラムガイド日本語版の記述を引用しています。 実践に際して、大きな影響はあまりないと思いますが、とくに以下の2点が注目だと思います。 デイリースクラムで3つの質問を使うかどうかはチーム次第となった。大事なのはスプリントゴールが完成しそうかどうかを毎日検査して適応することレトロスペクティブ（ふりかえり）で出た項目を、次のスプリントのスプリントバックログに含めること以下、詳細です。 更新内容 スクラムの用途についてスクラムマスターの役割の定義を洗練させたデイリースクラムはス
【資料公開】Effective Retrospective (効果的なふりかえり)
みなさんこんにちは。@ryuzeeです。 2017年3月18日におこなわれたProductivity Engineering − Forkwell Meetup #4の登壇資料『Effective Retrospective』の資料を公開します。 登壇の時間が20分ですので基本的な内容になっていますが、これからふりかえりを始める方やなんとなくいまのやり方がうまくいかないと思う方には役にたつと思います。 もっと詳細が知りたい場合は、アジャイルレトロスペクティブズを一読することをお勧めします。2007年の本ですがまったく陳腐化していないので参考になると思います。 なにかご質問があればTwitterなどでお知らせください。それでは。 SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発著者／訳者：西村 直人、 永瀬 美穂、 吉羽 龍太郎出版社：翔
チームパフォーマンスモデルとは？
みなさんこんにちは。@ryuzeeです。 人が集まっただけでは機能するチームにならない、というのはみなさんご存知のとおりです。 そしてチームの形成過程をあわらすモデルの1つとして有名なものに「タックマンモデル」があります（こちらを参照）。 今日はもう1つ別のモデルとしてDrexlerとSibbetが提唱している「チームパフォーマンスモデル」を紹介します。 タックマンモデルでは、チームの形成過程は形成期・混乱期・統一期・機能期・解散期の5段階（初期は4段階）で構成されていましたが、このチームパフォーマンスモデルでは、以下の7段階で構成されます。 オリエンテーション信頼の醸成ゴールの明確化コミットメント実行ハイパフォーマンスリニューアルこれらのステージは前半上から下に向います（形成段階）が、この段階では、徐々に制約を感じるようになっていきます。一方で後半に下から上にあがっていく（持続段階）につ
採用とか退職とか評価に関するよもやま話
こんにちは。@ryuzeeです。 以前に、採用プロセスを真剣に考えろという話を書きましたが、ちょっと関連する話を書こうと思います。 採用に関するメトリクスを取ろう採用プロセスに真面目に取り組んでいる会社ならやっていると思われますが、採用活動をするにあたってはメトリクスを取ることが望ましいです。特に成長中の組織でたくさんの人を採用したい場合や、ある一定規模の組織でそれは顕著です。取るべきメトリクスには以下のようなものがあるはずです。 総応募者数採用媒体別応募者数エージェント別紹介者数社員の紹介によって応募が来た数自社の採用サイトから応募が来た数各属性で書類選考を通った数各属性で一次面接を通った数各属性で二次面接を通った数 (ここは各社によって何回面接があるか違いますが…)各属性で最終面接を通った数 (同上)プロセスの途中で辞退した数オファーを出した数オファーを受けた数オファーを辞退した数各採
こんなスクラムには気をつけろ!?
こんにちは。@ryuzeeです。 支援をしている際に、こういう兆候があったら注意して見る、というポイントがいくつかあるので共有します。 あくまで課題発見用のツールなので、マルバツ表を作ってどうこうする、という類のものでもないですし、そうすべきでもありません。 スクラムマスターの人、外部から支援する人は、自分用の確認ポイントを整理しておくと良いと思います。 なお、スクラムを実践すること自体は目的足り得ないので改めて言っておきます。 全体なんでもアジャイルでやろうとするそもそもアジャイルを採用することが目的化しているプロジェクト初期にマイルストーンやスケジュールを決めていない十分にトレーニングを受けていない認定資格をとればそれで十分だと思っている全体の要件やアーキテクチャを考えずいきなりコードを書く予定できることなのに、「アジャイルだから」と予定しないドキュメントを書かない文化や考え方を変える
マイクロサービスに関する資料のまとめ
世の中マイクロサービス・マイクロサービスうるさいのでちょっとこれ読んでおけという資料をまとめておきます。 はっきり言ってマイクロサービス化しようとすると、組織構造の話、エンジニアの責務の話など技術的な課題以外の領域にもいろんなチャレンジがあるので、普通のプロジェクトでも苦労する組織が取り組むとか、設計だけして開発を委託しているけどDB一極化がやばいので取り組むとかは止めておいた方がよいと思います。 概念Twelve Factor Appマイクロサービスの話ではないが、モダンなアプリケーションを作りたければ開発チーム全員に叩き込んでおくべき内容MicroservicesMartin Fowlerによるマイクロサービスの解説。2014年5月に公開Martin Fowlerのブログは翻訳が可能で、日本語訳を公開してくれている人がいる。こちら単純に言えば、「マイクロサービスとは単一のアプリケーショ
ChefのCookbookのベストプラクティス
OpsCode社のシニアコンサルタントであるJulianさんがChefConf2013で話された内容が参考になるので、簡単に紹介します。 スライドはこちらに公開されています。 また動画はこちらです。 ここで出てこない話として僕がやるべきだと思うことは「テストを書くこと」です。 test-kitchenとserverspecの組み合わせがおすすめです。 ばかでかいレポジトリをつくらないいろいろなものをまぜこぜにしない たくさんのレポジトリに分割するのを怖がらない (opscodeも昨年opscode/cookbooksの巨大構成から、opscode-cookbooks/個別cookbookに構成を変えています) 個々のCookbookの連携はBerkshelf使えば大丈夫 全員が共用するような会社用Cookbookをつくらない関係ないプロジェクトのものが含まれると見通しが悪くなる 大きすぎる
プロダクトオーナーの重要な役割トップ７
プロダクトオーナーはチームにビジョンを伝え、プロダクトバックログにおける作業を説明することでチームをリードする。 プロダクトオーナーは、チームと直接コミュニケーションをとって、プロダクトバックログアイテムの優先順位付けを視覚的に行うことでプロジェクトをドライブする プロダクトオーナーはビジネス価値に基づいて作業を優先順位付けする。 スクラムは開発の意思決定をエンピリカルなデータに基づいて行うという点でユニークである プロダクトオーナーはチームと作業について交渉を行う。 各スプリントの最初にチームとプロダクトオーナーはそのスプリントで何に取り組むかを決めるために会う。 しかしこの取り組む作業は、プロダクトオーナーが単に割り当てするのではなく交渉によって決められる。 そしてプロダクトオーナーはチームが出しているベロシティいついては尊重しなければならない プロダクトオーナーはチームの質問に答えた
Sensuを使って自由度の高い監視システムの構築を行う方法
SensuとはSensuはhttp://sensuapp.org/で公開されているオープンソース(MITライセンス)のモニタリングフレームワークです。 特徴以下のような特徴があります（公式サイトの記述を整理） シンプルで融通が効き拡張性があるモニタリングフレームワークエージェント、メッセージバス、イベントプロセッサーの機能を提供要件にあわせて他のツールとの組み合わせが可能クラウドを意識して開発自動でクライアント(監視対象）を登録コミュニティが活発RubyのEventMachineを使って作られているコードはGitHubでホストされ、テストコードは高いカバレージ。TravisCIで継続的インテグレーションを実施Nagiosのプラグインを再利用可能設定はすべてJSONファイルで行うRabbitMQを使ったメッセージ型のアーキテクチャーオムニバスインストーラーを提供個人的な見解としては、Sens
続報 PackerでVagrant用のBoxを作成する
Packerってなに？という人は前回のエントリを先にどうぞ 0.10と0.11だと作成されたVagrantのboxの中のディスクイメージの命名の問題があります(詳細はこちら)。ソースを持ってきてビルドしたPackerを使えばとりあえず問題ありません。→0.12で修正されました！ 前のエントリで紹介したPackerですが、Vagrantのboxの作り方が把握できたので紹介しておきます。 今回はUbuntuのboxの作成を例にして解説します。 なお、CentOSの例は以下に置いておきました。 まずは設定ファイルです。前の記事で紹介したものより長くなっています。 { "builders":[{ "type": "virtualbox", "guest_os_type": "Ubuntu_64", "iso_url": "http://releases.ubuntu.com/12.04/ubunt
veeweeを使ってVagrant用のboxを自分で作る方法
Vagrant用のbox(OSのテンプレート)はhttp://www.vagrantbox.es/などで多数配布されています。 とりあえず試してみる分にはこちらにあるものを使ってみるのも良いですが、実際に開発で使おうとするといくつか問題があります。 そのOSに怪しいプログラムがインストールされているかもしれない初期の設定が自分たちの環境と大きく乖離している。例えばyumのレポジトリが多数追加されたりしているVirtualBoxのGuestAdditionsなどのバージョンが古くてそもそも正しく動かないかもしれないこういったことを避けるためには、自分たちでセキュアなboxを作るのが良いと思います。ここではveeweeを使って、自分用のboxを作る方法を紹介します。 veeweeのインストールveeweeはrubyで書かれたツールで、vagrantをはじめとする多くの仮想化ツール用にOSの雛形
速報 Packerでさまざまな仮想マシンのテンプレートを作成する
続報で、VagrantのBoxの作り方について書きました。こちら Vagrantの作者であるHashimotoさんが新たにPackerというツールをリリースした(昨晩！)ので速攻ご紹介。 このツールは、Amazon EC2のAMIやVirtualBoxやVMware用のOSのイメージを一貫性のあるインターフェイスで簡単に作ってくれるものです！たとえばVagrantの場合は以前はPatrickさんが作成したVeeweeを使うことが定番だったのですが、今後はそれに変わるものになってくるかもしれません。 (現時点はまだバージョン0.1なのでこれからどんどん良くなると思います！) インストールhttp://www.packer.io/downloads.html からビルド済みのファイルを入手します。もしくは自分でビルドすることも可能です(ビルドにはgoなどのツールが必要です)。 ファイルはzip
アジャイル開発に組織が興味を持ったならどうすればいいか？
みなさんこんにちは。@ryuzeeです。 http://kaji-3.hatenablog.com/entry/2012/04/05/072641 にてこれから導入を検討されているkaji_3さんが悩みを書かれていたので、プロのコーチとして感想を書いてみたいと思います。 新プロダクト作成にアジャイル開発が有益ではないかと組織が興味を持ってきているため、会社にどのように導入していくか提案予定です。 しかし、社内にアジャイルコーチなどいるはずもなく、テストの自動化すらできていない状況でどう進めていけばいいか悩み中です。 ゴールは来年、から開発する新プロダクトにスクラムを適用する。。です。 まず新プロダクトにアジャイル開発が有益だと考えた理由をはっきりさせた方が良いでしょう。 従来型の開発では難しいと思った理由や、それが本当にアジャイルで解決できる(可能性が高い)ものなのか？ そもそも現状の開発
Ryuzee.com
AgileコーチングAgile開発については多くの誤解があり、また経験の無いチームが自力で行うのは難易度が高いものです。当方ではオンサイトでAgile開発での企画〜開発まで全工程を支援します。例えばプロジェクト立ち上げに際しての集合研修、ふりかえりや計画ミーティングのファシリテーションなど。 DevOps実践支援DevOpsには組織とツールの2つの要素があります。サイロ型の組織構造のDevOps型組織への転換(組織デザイン、採用プロセス、評価プロセス)、ツールによるデプロイ・プロビジョニング・運用・監視の自動化など幅広い側面で支援します。チームづくりのトレーニングも提供しています。 Cloud Architecting支援ビジネスの成長やシステムの利用状況に柔軟に対応できるのがクラウドの特性ですが、一方でシステムアーキテクチャがレガシーであればそのメリットを享受できません。本支援ではマイク
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【資料公開】強いチームの作り方(デブサミ2016版)
プロダクトオーナーの役割を1枚で紹介