意識の問題にしない
みなさんこんにちは。@ryuzeeです。 今日はTwitter経由で頂いた質問に回答したいと思います。 質問は以下になります。 スプリントで『自分が最初に取り組むプロダクトバックログアイテム（PBI）を終わらせば自分の仕事は終わり』という意識のメンバーが多いです。そのため、PBI每に担当を決めて複数のPBIを並列で進めているのですが、インクリメントが0になる可能性があるのでできればやめたいと思っています。スプリントプランニングで決まったPBIすべてをチームで協力して終わらせるという意識に変えるためにはどうしたらよいでしょうか？ 例えば、AさんとBさんとCさんが最初にPBI-1をやる場合、スプリントでPBI-1を終わらせればよい、PBI-2とPBI-3は自分たちのタスクではないという意識になってしまっているという感じです。 ということで考えていきましょう。 スプリントでの開発者の仕事は何か？
【翻訳】ハイパフォーマンスチームを作るためにプロダクトオーナーがすべき10のこと
みなさんこんにちは。@ryuzeeです。 スクラムにおいて、スクラムチーム全体のパフォーマンスをどのようにして上げていくかは難しいテーマですが、プロダクトオーナーの視点でこれを捉えた「10 things you must do to build high-performing Scrum Teams as a Product Owner」という記事が良い記事だったので、翻訳したものをご紹介します。 翻訳に際しては、著者のMaarten Dalmijnさんに快諾いただきました。 なお、著者のMaartenさんはほかにもプロダクトオーナーに関する有用な記事を書いているので、参考にするとよいかと思います。 プロダクトオーナーの開発チームへの関わり方は、開発チームのパフォーマンスにおいてとても重要です。ダメなプロダクトオーナーだと、ハイパフォーマンスチームを簡単に潰してしまう可能性があります。 私
ユーザーストーリーをうまく使えていない5つの兆候
みなさんこんにちは。@ryuzeeです。 Marc Löffler 氏が書かれた “5 Signs That Your User Stories Suck” という記事が分かりやすかったので抜粋・意訳にてご紹介しましょう。 以下にあげるようなことは、そもそも「何のためのユーザーストーリーなのか？」ということを考えずにプラクティスとして取り込んでしまっているが故に起こる問題であるとも言えます。 一年半ほど前に、ユーザーストーリーを台無しにする方法について書いた。 それから現在までの間に、ぞっとするようなユーザーストーリーをほかにも見てきた。 それがこの記事を書こうと思った理由だ。 以下にあげるのが、あなたがユーザーストーリーをうまく使えていない兆候のリストだ。 1. ユーザーストーリーが単なるラッパーになっているもしユーザーストーリーがたった1つのタスクから構成されていたとすると、それはユー
プロダクトオーナーの重要な役割トップ７
プロダクトオーナーはチームにビジョンを伝え、プロダクトバックログにおける作業を説明することでチームをリードする。 プロダクトオーナーは、チームと直接コミュニケーションをとって、プロダクトバックログアイテムの優先順位付けを視覚的に行うことでプロジェクトをドライブする プロダクトオーナーはビジネス価値に基づいて作業を優先順位付けする。 スクラムは開発の意思決定をエンピリカルなデータに基づいて行うという点でユニークである プロダクトオーナーはチームと作業について交渉を行う。 各スプリントの最初にチームとプロダクトオーナーはそのスプリントで何に取り組むかを決めるために会う。 しかしこの取り組む作業は、プロダクトオーナーが単に割り当てするのではなく交渉によって決められる。 そしてプロダクトオーナーはチームが出しているベロシティいついては尊重しなければならない プロダクトオーナーはチームの質問に答えた
エンジニアのキャリアパスに思うところ
このとき意識しておくべき点は以下のようなことになります。 エンジニアを貫くか管理職系にいくかは本人の志向によって決めるエンジニアから管理職になったが、やはりまたエンジニアに戻るという選択肢もあるロールチェンジするときには十分な教育が必要（これは従来型のパスだろうと同じだが）自分が管理職だった場合に、自分よりもレベルが上のエンジニアが管理対象になることがある（部下の方が給与が高いことも当然ある）要はそれぞれのロールが違って責任が違うだけなので、上司なので偉いとかそういう話ではないエンジニアは多くの場合、技術が分かっていない人から技術的な指示をされることに抵抗感を持つ。すなわち技術的な点の意思決定については現場やチーフエンジニアやプリンシパルエンジニアといった上級のエンジニアに委譲した方がよい年功序列ではなくて、各レベルで定められたJob Descriptionに合致しているかどうかが次のレベ
採用とか退職とか評価に関するよもやま話
こんにちは。@ryuzeeです。 以前に、採用プロセスを真剣に考えろという話を書きましたが、ちょっと関連する話を書こうと思います。 採用に関するメトリクスを取ろう採用プロセスに真面目に取り組んでいる会社ならやっていると思われますが、採用活動をするにあたってはメトリクスを取ることが望ましいです。特に成長中の組織でたくさんの人を採用したい場合や、ある一定規模の組織でそれは顕著です。取るべきメトリクスには以下のようなものがあるはずです。 総応募者数採用媒体別応募者数エージェント別紹介者数社員の紹介によって応募が来た数自社の採用サイトから応募が来た数各属性で書類選考を通った数各属性で一次面接を通った数各属性で二次面接を通った数 (ここは各社によって何回面接があるか違いますが…)各属性で最終面接を通った数 (同上)プロセスの途中で辞退した数オファーを出した数オファーを受けた数オファーを辞退した数各採
クラウドエンジニア採用のTIPS
人材流動性の高まりのまっただなかにいる@ryuzeeです。こんにちは。 AWSの中の人がクラウドのエンジニアを採用するにあたっての質問集や見るべきポイントを紹介していたのでご紹介します。 Hiring a Cloud Engineer? Questions to Ask and What You Should Hear これからクラウドベンダーに転職したい人や、クラウドベンダーの中で採用を担当している人はみておくと良いかもしれませんね。 以下参考までに勝手訳です。 クラウドエンジニアを雇いたい場合の質問と聞くべきポイントこのブログポストでは、あなたのスタートアップやスモールビジネスの助けになる経験豊富なクラウドエンジニアを採用する際のTIPSを紹介する。 ここでいう「クラウドエンジニア」とはポジションの説明や肩書ではなく、質や長所を表す言葉として使っている。 この手の人をCTOで雇うか一エ
採用プロセスを真剣に考えろという話
人材流動性の高まりを日々感じているみなさんこんにちは。 最近いろんな会社にお呼ばれしていて、その中でエンジニアの採用の話になることがとても多いのでちょっと整理しておきます。 ポイント▼「面白いプロダクトもないし、仕事内容は面白いとは思えないし、よい給与は払えないし、仕事環境にも自由はないけど、良い人雇いたいんだけど、どうしたらよいですか？」悪いが諦めろ。良い人は当然のことながら複数の会社が興味をもつことになるし、働く場所を自分で選択します。Pros/Consを見極めて選ぶことになるので、Prosがない場所で働く理由がありません…だとあまりに冷たいので、もしあなたが次に転職するとして、それでも今の会社に入るのであればあなたを惹きつける理由が何かあるはずで、それをアピールしよう▼「入社してから期待値にあっていないことが分かる、ってことが多いんだけどどうしたらよいですか？」期待値を明文化している
続報 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
5分で分かるデプロイ自動化への道
12月20日に第1回ワンクリックデプロイ勉強会で、デプロイの自動化について好き勝手に喋ったりデモしたりする予定なのですが、当日話す内容の概略について以下に載せておきます。 以下にあげることをやっておけばデプロイ自動化、ワンクリックデプロイはそんなに遠くないところにあると思います。 ソースコードのバージョン管理いわずもがな。全ての起点はここにあるコードの共同所有の原則への理解このソースコードは本番環境または開発環境などで同じように動作しなければならないテストを書く習慣、コミット前に他のテストも含めて通してからコミットする習慣設定ファイルのバージョン管理環境によって異なる設定値（接続先データベース情報など）が書かれた設定ファイルもバージョン管理する開発環境用、ステージング環境用、本番環境用などに分けて定義し、容易に切り替え可能にする本番環境に配置する際に、アプリケーションの各所を書き換えなけれ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
