Tomy

A software engineer at Relic Inc. and RUFU Inc.

Tomy

A software engineer at Relic Inc. and RUFU Inc.

長すぎるプロダクトバックログをなんとかするTips

プロダクトバックログをMustとBetterで分けるいくつかの対策をやったが、これが一番効果的だった。MustなプロダクトバックログとBetterなプロダクトバックログに分けてしまう。Mustに入れるものは本当に絞って、それ以外はBetterに入れる。自分の場合はなぜか100近いプロダクトバックログアイテム(PBI)があったが🤔、Mustが10~20くらいになればいいし、 20ちょいでもなんとか希望が持てた。 Mustの定義としては、社外のステークホルダーとはっきり約束した

Tomy

    • エンジニアリングマネージャーを自称してからやったこと

      これはなにここまで自分がやってきていることの振り返りのためのメモ。 ちなみにタイトルにエンジニアリングマネージャーと入れたが、チーム内での自称であって会社の公式な役職ではない。マネージャーなる人物が上司として居て、人事評価はマネージャーにやってもらっている。EM自称おじさん エンジニアリングマネージャーについてエンジニアリングマネージャーの定義は大体こちらを参照。 ピープル、テクノロジー、プロジェクト、プロダクトの４領域にまたがるマネジメント。特にピープルマネジメントを軸

      Tomy

      • ストーリーポイントを導入してみたらプロダクトバックログが健全になった

        最近になってスプリントプランニングにおいてストーリーポイントを利用し始めました。 これが案外良かったのでここにまとめておこうと思います。 スクラム開発をなんとなくやっているがうまくいかない系の方のお役に立てば幸いです。 ストーリーポイントとはという話はここでは省略します。 なぜ導入したか私のいる開発チームでは元々スクラムの開発プロセスを採用していましたが、以下のような課題が挙がっていました。 プロダクトバックログの順番通りに開発を進められていない (スキルやスプリント内

        Tomy

        • アジャイルになるために：アジャイルをウォーターフォールと対比するのはやめようという話

          ソフトウェア開発会社で働いているとアジャイル or ウォーターフォールという開発スタイルの話がよく挙がりますよね。アジャイルに関する知識や事例がかなり広まってきていると感じる一方で、明らかに間違った意味でアジャイルなりウォーターフォールという表現が使われてるなと思っていて、今回は自分の考えをまとめるためにアジャイルとウォーターフォールを対比するのはやめようという話をしようと思います。 筆者の前提知識私の考えはほぼこちらの記事に依拠しています。アジャイル宣言のメンバーの一人で

          Tomy

        • 長すぎるプロダクトバックログをなんとかするTips

          Tomy

        • エンジニアリングマネージャーを自称してからやったこと

          Tomy

        • ストーリーポイントを導入してみたらプロダクトバックログが健全になった

          Tomy

        • アジャイルになるために：アジャイルをウォーターフォールと対比するのはやめようという話

          Tomy