ブックマーク / www.ryuzee.com (6)

  • 【資料公開】プロダクトマネージャーのしごと

    みなさんこんにちは。@ryuzeeです。 2023年10月17日に行われたオンラインイベント「プロダクトマネージャーのしごと - Forkwell Library #33」の登壇資料を公開します。 内容は、新刊書籍『プロダクトマネージャーのしごと』に関するものなのですが、30分という時間で全部を網羅的に紹介するのは無理ですし、ぜひ書を読んでいただきたいので、僕が気に入っているところと、書全体を通して中心にある考え方を紹介しました。 ちなみに書籍は16章から構成されていて、そのなかで特に自分が好きなのは「7章 「ベストプラクティス」のワーストなところ」です。 職業柄、日頃から「プロダクトマネジメントではどんなフレームワークを使うといいですか?」「プロダクトマネジメントの日での成功事例を教えてください」「プロダクトマネジメントのベストプラクティスを教えてください」のような質問をたびたびい

    【資料公開】プロダクトマネージャーのしごと
    hkmn
    hkmn 2023/10/19
  • 【資料公開】エンジニアリングマネージャーのしごと

    みなさんこんにちは。@ryuzeeです。 2022年9月6日に行われたオンラインイベント「エンジニアリングマネージャーのしごと - Forkwell Library #5」の登壇資料を公開します。 内容は、新刊書籍『エンジニアリングマネージャーのしごと』に関するものなのですが、書は18章、350ページからなるであり全部を網羅的に紹介するのは無理筋なので、今回は根底にある考え方にフォーカスを当てています。この発表のあとにQ&Aコーナーがあったのですが、その内容については、aki.mさんのブログ記事にまとまっていますので参考にしてください。 内容に関するご意見やフィードバックは、Twitter: @ryuzee までお知らせください。 スライドを見て興味を持たれた方は、ぜひ書籍『エンジニアリングマネージャーのしごと』を読んでいただければと思います。 それでは。 エンジニアリングマネージャー

    【資料公開】エンジニアリングマネージャーのしごと
    hkmn
    hkmn 2022/09/08
  • なぜスクラムチームの開発者が複数チームを兼任しないほうがよいのか

    みなさんこんにちは。@ryuzeeです。 よく受ける相談の1つに、「スクラムチームの開発者は複数のチームやプロダクト、プロジェクトを兼任してもよいのか」というのがあります。コーチ業をしている人ならみんな受けたことがあるものだと思いますが、詳しく見ていきます。 まず最初に結論ですが、タイトルにもあるとおり、「スクラムチームの開発者は複数チームを兼任しないほうがよい」です(スクラムガイドには書いていないですが、スクラムガイドは全てを詳細に記したハウツーではありません。あくまでゲームのルールです)。 理由を順番に見ていきましょう。 1. 開発に使える時間がかなり少ないスクラムチームの開発者はスプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブといったイベントと、プロダクトバックログリファインメントのような活動に一定の時間を使います。 チームによって時間は変わ

    なぜスクラムチームの開発者が複数チームを兼任しないほうがよいのか
    hkmn
    hkmn 2021/06/14
  • 【翻訳】あなたのスクラムチームの成熟度は?

    みなさんこんにちは。@ryuzeeです。 3月23日に『スクラム実践者が知るべき97のこと』が発売になりますのでよろしくお願いします。 さて、スクラムチームがどれくらいの成熟しているかは、とくにスクラムを始めてまだ長時間たっていない場合には気になるところだと思います。 そこで今回はスクラムチームの成熟度を自己評価して、改善に結びつけるための資料を共有します。 この資料はScrum.orgのトレーナーであるRon Eringa氏がブログで公開しているものです。 このモデルでは、スクラムマスター、プロダクトオーナー、開発チーム(スクラムガイド2020で開発者に改められています)のそれぞれで成熟度を明らかにします。 そして、全体でいちばん低い数字がスクラムチームとしての成熟度になるとされています。 使い方ですが、人事評価や他チームとの比較に使うのではなく、チームとしてどう成長していくべきか、どこ

    【翻訳】あなたのスクラムチームの成熟度は?
    hkmn
    hkmn 2021/03/01
  • こんなスクラムには気をつけろ!?

    こんにちは。@ryuzeeです。 支援をしている際に、こういう兆候があったら注意して見る、というポイントがいくつかあるので共有します。 あくまで課題発見用のツールなので、マルバツ表を作ってどうこうする、という類のものでもないですし、そうすべきでもありません。 スクラムマスターの人、外部から支援する人は、自分用の確認ポイントを整理しておくと良いと思います。 なお、スクラムを実践すること自体は目的足り得ないので改めて言っておきます。 全体なんでもアジャイルでやろうとするそもそもアジャイルを採用することが目的化しているプロジェクト初期にマイルストーンやスケジュールを決めていない十分にトレーニングを受けていない認定資格をとればそれで十分だと思っている全体の要件やアーキテクチャを考えずいきなりコードを書く予定できることなのに、「アジャイルだから」と予定しないドキュメントを書かない文化や考え方を変える

    こんなスクラムには気をつけろ!?
    hkmn
    hkmn 2018/09/04
  • スクラムで削除された5つのトピック

    みなさんこんにちは。@ryuzeeです。 スクラムのフレームワークの中身はスクラムガイドで定義されていますが、登場以来ずっと同じ内容なわけではなく、何度か改定が行われています(2010年版、2011年版、2013年版、2016年版、2017年版)。過去の改定内容はこちらに記載されています。 過去の変遷においてよく議論になる5つの項目についてWillem-Jan Ageling氏が5 controversial topics that were removed from Scrumという記事にまとめています。 御人から快諾いただきましたので和訳にて紹介します。 スクラム再発見の時間です。 5年かそれ以上前にスクラムを適用した場合、現在のものとは異なる情報源を元にしていたはずです。 しかし、スクラムとして定義されてスクラムガイドで言及されたものの、ある時点で削除されたものが多数あります。 ま

    スクラムで削除された5つのトピック
    hkmn
    hkmn 2018/08/04
  • 1