nDiki : プロダクトバックログ

2012年8月6日 (月)

今日のさえずり: タイキン工業

2012年08月06日

  • 08:00 広島平和記念式典開始。
  • 09:33 「人間とは何か」読了。ハッピーエンド。
  • 09:52 蒸す。 (@ 株式会社ミクシィ (mixi, Inc.) w/ 2 others) http://t.co/Wl8MbevS
  • 12:04 backlog に入る前のところは icebox って呼べばいいのかな?
  • 12:09 RT @kdmsnr: @Naney それはPivotalTracker用語なので、ぜんぶバックログでいいと思います。
  • 12:09 @kdmsnr 「バックログ」って「優先順位がついている」っていう解説が多いようですが、まだ優先順位がついていないものも含めても扱い的には問題ないのでしょうか?
  • 12:15 RT @kdmsnr: @Naney ぜんぶプロダクトバックログに入れるのでいいと思います。
  • 12:16 @kdmsnr ありがとうございます。参考になりました!
  • 12:31 @kdmsnr なるほど。ちょっと意識してみます。
  • 22:08 タイキン工業。
  • 22:33 スクラムやってる人が渋谷駅にいたので、いろいろ教わった。
[ 8月6日全て ]

2016年11月1日 (火)

第2回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会2回目。今日は第2章 スクラムフレームワーク。発表当番でした。

プロダクトバックログをまとめるというアクティビティ」に「グルーミング」という名前がついていて「へぇー」となりました。ここらへんはプロダクトオーナー頑張れの世界であまり扱われないのかなと思っていたので。名前がついているとタスク管理ツールに入れておきやすくて助かります。

[ 11月1日全て ]

2016年11月29日 (火)

第6回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会6回目。今日は第6章 プロダクトバックログ

プロダクトバックログは、優先順位の高いものほど詳細度を上げて分割していく一方で優先度の低いものはざっくりとで良いというのがポイント。現実的で良いなと思います。2回から3回分程度のストーリーを準備完了状態で抱えておくのが経験的に良いとのことでした。

一方プロダクトバックログはリストなのでこの分解ツリーが見える化されていません。このあたりがちょっと扱いにくいなと感じることはあります。アウトライナーのような形でツリーで整理しつつ、その中でプロダクトバックログアイテムとなるところのみビューとして抽出して順序付けるものがあるといいのになと思うことはあります。

グルーミング(プロダクトバックログリファインメント)については

プロダクトバックログのグルーミングは、プロダクトオーナー主導で行う共同作業だ。

と書かれていてこれは「おっと」と感じたました。関係者でのグルーミングはおざなりにしていたなと。ここは PO の責任範囲だとあらためて把握。なおグルーミングはいつ行ってもいいとありました。

開発チームは、各スプリントの作業時間の最大1割程度までをグルーミング用に確保すべきだ。

とあり結構たっぷりだよなと思うわけですが、考えてみるといわゆるウォーターフォール開発でも初期の工程に時間をかけているわけですし、特別多い割合でも無いのかなと。

複数チームでプロダクトバックログをどうするかについては、1つのプロダクトバックログからビューでチーム別のプロダクトバックログを用意するのが良いとありました。理想的には確かにそうだと思いますが、そこまでやるとすると結構ヘビー級のツールが必要になって気がしてそちらの学習・運用コストが馬鹿にならないのではという印象を受けました。

何事もできるだけシンプルにしていきたいですね。

[ 11月29日全て ]

2016年12月6日 (火)

第7回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会7回目。今日は第7章 見積もりとベロシティ。

プロダクトバックログ見積もり

プロダクトバックログアイテム(PBI)の見積もりプロダクトバックログリファインメント(グルーミング)で行うアクティビティです。この時プロダクトオーナーやスクラムマスターは「実際に見積もる作業」には関わらないのがポイント。

見積もりの最大の目的は、話し合う過程でいろいろな気づきが得られるということだ。

でなるほどと思いました。見積もられたサイズよりも、見積もるという過程を重視しているんですね。

ストーリーポイント

PBI の見積もり単位としてストーリーポイントと理想日を紹介しています。ストリーポイントはあくまで相対値なのでそのチーム内でしか使えない値です。プランニングポーカーのところで

多くのチームでは、1回のスプリントでこなせる最大のサイズを13で表している。

としているので、これが一つの目安でしょうか。それからストーリーポイントはベロシティと対にならないとあまり意味をなさないですね。

理想日の方はいわゆる人日。

ベロシティ

ベロシティで計測するのはあくまでも生産量であり(デリバリーしたもののサイズ)であり、成果(デリバリーしたももの価値)ではない。

ここは当たり前な感じではありますが誤解してはいけないところ。

計測で出てくるベロシティは見積もりの(精度ではなく)正確性によってかなり揺らぎがあると思うのですが、このあたりはチームが学んでいくことで安定していくものなのでしょうか。ベロシティに幅を持たせて表すと良いとありますが、どれぐらいの幅に収まっていくのか興味があります。

それからベロシティが上がるかという話がありました。ストーリーポイントとしては相対値なので上がらないはずですよね。アウトプットの絶対量は増えていくと思いますけれど。

[ 12月6日全て ]

2016年12月7日 (水)

プランニングポーカーでプロダクトバックログアイテムの見積もり

プランニングポーカーを使ってプロダクトバックログアイテムの見積もりを初めてしてみました(私はプロダクトオーナーなので見積もる作業には関わらない立場)。「見積もりの最大の目的は、話し合う過程でいろいろな気づきが得られるということだ。」というの、なるほど納得しました。

[ 12月7日全て ]

2016年12月13日 (火)

第8回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会8回目。今日は第8章 技術的負債。

スクラムのコアコンセプトの部でわざわざ技術的負債について1章割くというのがふーんという印象でした。ベロシティに大きな影響を与えるので避けて通れないというところでしょうか。あるいはウォーターフォールと違って返済していくチャンスがあるからでしょうか。

技術的負債

技術的負債。当初は

意図的に手抜きをしてすばやく仕上げるという意味

技術的負債を抱えるということは、今後の作業のための時間を担保にした融資を受けるということだ。

からきていて、後々返済する必要が出てくる代わりに先に経済的効果を得ているものを指しています。単純にまずい設計や実装のことまで技術的負債と世間で呼ばれていることがありますが、個人的には違和感を感じています。本書ではナイーブな技術的負債と呼んでいますね。

技術的負債ですが

大切なのは、どんなプロダクトであっても技術的負債からは逃れられないということだ。私はここで、技術的負債をなくすよう努力しましょうなどと言うつもりはない。仮にそんなことができたとしても、負債をゼロにするためには大変なコストがかかるだろう。

ということで必ずしも罪悪感を感じる必要のあるものではないことがわかります。きちんと把握してコントロールしていくことが重要です。

ただ

技術的負債の経済的意味についての適切な認識

については、正直なところなかなか正確に見積もれることがない気がします。技術的負債を生むという選択をした時にそこまで見積もる余裕がない、あるいはあっても先のことなので詳細化しきれない、そういうケースが多いのではないかと。

技術者レベルでの技術的負債の可視化

  • 方法1: 障害管理システムに記録する
  • 方法2: 技術的負債を表すプロダクトバックログアイテムを作る
  • 方法3: 技術的負債バックログを作る

サイズが大きいものは方法2の方が時間をとって返済しやすく、サイズが小さいものは方法3の方が「フィーチャーよりも優先度が低くていつまでも返済されないということがない」ので返済しやすいようです。

技術的負債の返済

  • 作業中に偶発的な技術的負債が見つかれば対応できるところまで対応する。
  • スプリントごとに既知の技術的負債のいくつかを返済対象として対応する。価値をもたらすフィーチャーの開発と関連するものを一緒に進めることで金利の高いものから勧められる。

あたりがポイント。

「技術的負債返済スプリント」だとか「リファクタリングプリント」などといった言葉がチーム内で出てきたら、危険信号だ。

ということで、技術的返済のみに注力するのは価値を提供し続けるというのに反するで望ましくないとありました。

また実際のところ利息がほとんど発生しない技術的負債もあるので、きちんと見極める必要がありますね。

[ 12月13日全て ]

2016年12月14日 (水)

今日のさえずり: Qiita:Team にプロダクトバックログを書いておくの、限界がきた

2016年12月14日

  • 08:12 昨晩 Solid Explorer から Macファイル共有にアクセスしようとしたけれど駄目だった。現状 SMB だと駄目っぽい。
  • 14:48 YWTM はフォーマット的にやっていないことを書きにくい。
  • 20:45 Qiita:Team にプロダクトバックログを書いておくの、限界がきた。
[ 12月14日全て ]

2017年1月24日 (火)

今日のさえずり: まさか不思議惑星キン・ザ・ザがブルーレイディスクで出るとは

2017年01月24日

[ 1月24日全て ]

2017年1月25日 (水)

プロダクトバックログを分割詳細化した時にエピックを「残り」で残す

スクラムプロダクトバックログリファインメントの時に、上位のプロダクトバックログスプリントで完成させられるように分割詳細化していきます。

 |-- P1 (分割詳細化済み)
 |   |-- P1-1
 |   |-- P1-2
 |   `-- P1-3
 |-- P2 (一部分割詳細化済み)
 |   |-- P2-1
 |   |-- P2-2
 |   ...
 `-- P3 (未分割詳細化)

ツリーになるのだけれどどうするのが良いかなあという話になりました。大きな視点だと分割元もわかるようにしておきたいし、途中までしか分割されていないものはまだ残りがあることを忘れないようにしたい。

分割し残りがあるものは「残り」としてフラットにしてしまえばいいんじゃないということになりました。「残りプロダクトバックログアイテム」を作ればフラットなリストにしても漏れないよねと。

 |-- P1-1
 |-- P1-2
 |-- P1-3
 |-- P2-1
 |-- P2-2
 |-- P2-残り
 `-- P3
[ 1月25日全て ]

2017年2月6日 (月)

今日のさえずり: プロダクトバックログを1本にまとめるの、ガッツがいる

2017年02月06日

  • 11:44 Remember The Milk Pro 本日更新した。
  • 17:36 プロダクトバックログを1本にまとめるの、ガッツがいる。
  • 21:06 3本のプロダクトバックログを1本にまとめることで、同時に進める開発の数を減らすべきというところに辿り着きそう。
  • 24:25 RT @kmnk: 年始にツイッターのタイムラインで見かけた日記の魔力を読んで、騙されたと思って日記という名の自分用ライフログを書き始めたのだけれど、意外にまだ続いている。何か良かったことがあるのかと言われると、少なくとも間違いなく寝つきが良くなっているので、他にも何か改善され…
[ 2月6日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・PO をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

follow us in feedly

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.103258s / load averages: 0.39, 0.50, 0.49
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker