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

スクラムプロダクトバックログ (Product Backlog)

フィーチャー・不具合・技術的な作業など、プロダクトに必要でプロダクトオーナーから見て価値のあるものが優先順位付けされて並べられたリスト。

2017年3月8日 (水)

複数スクラムチームでのプロダクトバックログ振り分け

今まで3つのスクラムチームで別々のプロダクトバックログをもっていたのですが、より大きい視点で優先度を考えつつ優先度の高いフィーチャーから集中的に取り組めるようにしたいと考えるようになりました。

このためしばらく前にいったんプロダクトバックログを1つにまとめました。

人数が多くてプロダクトバックログリファインメントがうまくいかず

プロダクトバックログを1本化してから3回ほど合同でプロダクトバックログリファインメントをしてみたのですが、これはあまりうまくいきませんでした。やはり人数が多いと議論が進まなかったり、人によっては自分ごとに考えにくくなったりしたようです。

プロダクトバックログアイテムの振り分け方法が決まっていない

またどのチームがどのプロダクトバックログアイテムを担当するかも決めていなかったので、先にスプリントプランニングに入ったチームからやれるものを順番に取っていくかたちになっているという課題もありました。

今回合同プロダクトバックログリファインメントと振り分けはうまくいきませんでしたが、これもまた一つの良い学習だったと思っています。

チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。 -- アジャイル宣言の背後にある原則

LeSS

やはり複数スクラムチームで仕事を進める場合は代表者を立てる進め方が良いのでしょうか。LeSS (Large-Scale Scrum) のやり方をまず部分的に取り入れてみることにしました。

各チームの代表者が集まって Overall Product Backlog Refinement と Sprint Planning One にあたるアクティビティでスクラムチーム別に振り分けを行い、その後各チーム別にプロダクトバックログリファインメントやスプリントプランニングを実施するようにしてみたいなと。

取り急ぎ今日からのスプリントに入れるように急遽集まって振り分けを行いました。スプリントレビューやふりかえりについてはまた別途考えていきたいなと思ってます。

スポンサード リンク
[ 3月8日全て ]

2017年3月14日 (火)

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

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の19回目。今日は第19章 スプリントプランニング。ここから「第IV部 スプリント」。スクラムチームにとって馴染みがあるパートです。

スプリントを回すにあたり第19章はすでに何度か先読みしているところですが、あらためて書籍にあたり気付きを得て実践していきたいところです。

タイミングと時間と参加者

スプリントプランニングはスプリントを開始するときに行います。2週間から1カ月のスプリントで4〜8時間ということなので、単純に計算すると1週間スプリントでは2時間程度でしょうか。

今は1週間/2週間スプリントのチームで賞味30分から45分ぐらいしかやっていません。実際時間不足を感じています。

  • チームメンバが2時間のプランニングミーティングに耐えられない。きちんとスプリントプランニングするメリットを感じられていない。
  • 3チームのプロダクトオーナー(自分)が時間を確保できない。

もちろん長ければ良いというものでもありませんが、もし不足だとしたらこのあたりが適切な時間をかけられていない障壁かなと。前者はチームが成長することで解消される気がします。後者は LeSS (Large-Scale Scrum) の2段階のスプリントプランニングにしてチーム別のにはプロダクトオーナーは出ないという形式にするという解決案も思い浮かぶのですが、参加しないデメリットを考えると躊躇してしまいます。

プロダクトバックログアイテムにかけるキャパシティ

完成させる自信のある計画を行うにはキャパシティの把握が不可欠になります。

 スプリントのキャパシティ
   = PBI にかけるキャパシティ + スプリントバッファ + それ以外

予定している休暇があるのにスプリントプランニングの際に宣言しないのは不誠実だということになるでしょう(休んではいけないということではなく、わかっているのに共有しないということが問題。体調不良等による突発的な休みももちろん別の話)。

今のところ自分たちのチームではベロシティ(ストーリーポイント)でなんとなくキャパシティがこれぐらいかなといった感じでしか考えられていませんが、次のスプリント期間をまず見通すことも必要だなと感じました。

作業時間を使ったキャパシティも紹介されていますが、実際ここまで精緻に管理したいと思うことはあまりないんじゃないかなという印象です。

プロダクトバックログアイテムの選択

基本優先順位順ですがスプリントゴールを示している場合はその限りではなく、またスキルの問題などでコミットできないプロダクトバックログアイテムはスキップするという選択も考える必要があります。

完成できそうにないプロダクトバックログアイテムを選択してはならない。プロダクトバックログアイテムが大きすぎて完成できそうにない場合は、顧客にとって価値のあるアイテムに分割するか、完成できそうな別のアイテムに着手する。(中略)未完成のアイテムを次のスプリントに繰り越していくと、スプリントの終了時に出荷判断可能なプロダクトインクリメントを手に入れるという目標がいつまで経っても達成できない。

ここがいつもスプリントプランニングでぶちあたるところです。プロダクトバックログリファインメントがしっかりできていないんですね。プロダクトバックログリファインメントは最重要レベルのアクティビティなんだなと。

タスク分解と作業時間見積もり

自信の獲得のためにタスク分解と作業時間の見積もりをまずしましょうとあるのですが、タスク分解と見積もりの方法については触れられていません。ここは自分たちで考えて頑張れという感じなんですかね。一般論にはできない部分だとは思いますが、ここは大ハマリするところなので参考になる話があると嬉しいなと思ってます。

スプリントプランニングでタスクを個人に割り当てるのは有害だというバッドプラクティスが挙げられていますが、ここは次の「スプリントの実施」で語られるところのようです。

[ 3月14日全て ]

2017年3月28日 (火)

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

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の21回目。第21章 スプリントレビュー。スプリントの中でいちばんうまく出来ていないスプリントレビューの話です。

スプリントレビュー

スプリントレビューは作業結果(出荷判断可能なプロダクトインクリメント)の検査と適応をするアクティビティです。

不都合な真実も含めて、現在のプロダクトの状況を透明に見せてくれる。

という、ちょっと最初は勇気が必要なアクティビティです。

この章によるとスプリントレビューはスクラムチームがスクラムチーム外の人に説明しフィードバックを得るための機会なのです。しかしながらついチーム内の確認の場になりがちで、チーム外の人からきちんとフィードバックを得られていないと反省しています。

スケジュールの調整

スクラムチーム外の参加者が最も多く、スクラムのアクティビティの中では最もスケジュールの調整が難しいと述べられています。たしかに。ステークホルダーのスケジュールに合わせてスプリントレビューのスケジュールを決め、それに合わせて他のアクティビティを合わせるのが現実的とのことでした。

スプリントレビューに参加してくれないようなら、それは開発する価値のないプロダクトということである。したがって、プロダクト開発を注視すべきだろう。

きちんと参加者が集まらない場合は同時並行の作業が多すぎないかも見直すべきなのかもしれません。

スプリントレビューのアウトプット

リファインメント(グルーミング)したプロダクトバックログと更新したリリースプランがスプリントレビューのアウトプットだと書かれています。

ほとんどのチームはスプリントレビューでグルーミングをしている。関係者全員が開発の現状と今後を理解して、新しいPBIを作成したり、既存のPBIの優先順位を変えたり、不要なものを削除したりする。

これも全然意識できていないところ。今はコメントをもらって終わりになっています。きちんと対話をしプロダクトの適応をするところまで実現できていないなと。

デモ

デモが難しいからといって、それはデモをしない理由にはならない。

プロダクトオーナー側でも「まぁいいか」と思ってしまうの良くないですね。反省。

スプリントレビューはスクラムマスターと協力してきちんと設営していく必要があるなと感じました。

[ 3月28日全て ]

2017年4月14日 (金)

第23回 エッセンシャル スクラムを読む会 (最終回)

rimage:/nDiki/2017/04/14/2017-04-14-092915-nDiki-800x1200.jpg

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の23回目。第23章 未来へ。ついに最後の章です。

スクラムは継続的な改善の一形態なのだからこれが最終形態というものは無いし、どのチームをとっても同じというものは無い。プラクティスはあってもベストプラクティスはチームによって違う。準備ができていないからスクラムを始められないというのはそもそも原則に反するので、まずやって学ぼう。現状を変えるよりもスクラムを無視したりスクラムを変更したりすることの方が簡単だけれど、組織を変するために協力しあいながら確固たる信念をもって立ち向かおう。

そんなメッセージを本章から受け取りました。

第1章の「スクラムは役に立つか?」で出た通り全ての領域でスクラムが適しているわけではないので、盲目的に導入すれば良いというものではなく、領域が変わった場合はスクラムを続けるか続けないかの判断が必要になるのでしょう。もし取り組む領域が「複雑な領域」であるならばスクラムフレームワークはとても強力だということは間違いありません。

「エッセンシャル スクラム」と「エッセンシャル スクラムを読む会」そしてなによりこの半年のスクラム開発経験でスクラムについて多くを学ぶことができました。「エッセンシャル スクラム」は「スクラムガイド」を読んだだけでは得られない広範囲な知識やノウハウが詰まった良い一冊でした。

エッセンシャル スクラムを読む会ふりかえり

エッセンシャル スクラムを読む会を終えたあとは、オフィスのコラボスペースでビールを飲みながらお疲れさま会。参加の皆さんお疲れさまでした。この回を始めてくれたはらかち氏に感謝。休まず毎回参加してディスカッションしたことでいろいろな学びを得ることができました。嬉しい限りなので珍しく私もビールで乾杯しました。いっしょに全回参加した2人のうちの1人である RabbitFake 氏も特にお疲れさまでした。

ふりかえって出てきた話題としては

  • 取り組む領域がクネビンフレームワーク(第1章)のどの領域なのかを見てスクラムを採用するかどうか考えたい。
  • チームメンバでエッセンシャル スクラムを読むことで「PBI」などの同じ理解で使える言葉が増えた。チームの共通言語作りに貢献できた。
  • 原則大事(第3章・第14章など)。
  • WIP を下げる重要性をあらためて学んだ。
  • 準備完了の定義・受け入れ条件が重要。

などが上がりました。

また実際に読む会と並行してスクラムを行ってきた中で

などの話が出ました。

スクラム実践についての「検査と適応」をタイムリーに勉強会をしながら進められて学びの多い半年間でした。

全23回

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

[ 4月14日全て ]

2017年8月1日 (火)

メンテナンスフェーズに入ってきたプロダクトの保守とスクラム

メンテナンスフェーズに入ってきたプロダクトを保守しているスクラムチームのプロダクトバックログが枯渇してきました。無理に新しいことを絞り出して手を入れ続けるのが得策ではない感じに。

もはやスクラム開発には適さない領域に入ってきたのかもしれません。一段上のレベルに戻ってプランニングするのが良さそう。

[ 8月1日全て ]

2017年8月2日 (水)

何もコミットしないスプリントで各自好きなことをする

インクリメントの完成に高いコミット意識をもって毎スプリント取り組んできている CS 開発チームがいくつか大きなリリースを終えたので、スクラムマスターと相談して今日からの1週間スプリントは「プロダクトバックログアイテムについては何もコミットしない」で各自好きなことをして良いことにしました。

リファクタリング・技術的負債の返済・開発環境の整備や、調査・学習・ドキュメントの整理など、いつものスプリント中にはなかなかできないことを各自でしてよい1週間です。

普段から持続可能なペースを意識してスプリントプランニングしていますが、それでも頑張り続ければストレスも溜まってくるでしょう。適切なタイミングでブレイクを挟むことで、バーンアウトを防ぎ長期的にデリバリーし続けられるチームでいられればと思っています。

ちなみにこの取り組みは去年別のチームが unwinding period と呼んでやっていたのを真似てみたものです。

今回スプリントがどういう感じだったのかは、いつも通りスプリントレトロスペクティブでふりかえってみます。


[ スクラム ]

[ 8月2日全て ]

2017年8月6日 (日)

仕事に追われない仕事術 マニャーナの法則 完全版

仕事に追われない仕事術 マニャーナの法則 完全版

タスク管理の記事を読んでいると「マニャーナの法則」というキーワードがよく出てきます。今までスルーしていたのですがここ最近クローズリストの考え方を取り入れてみているので、その辺りの話が書かれている「仕事に追われない仕事術 マニャーナの法則 完全版 (Do It Tomorrow and Other Secrets of Time Management)」を読んでみました。

マニャーナの法則

まずマニャーナの法則ですが

  • 原則1 新しい仕事は「明日やる」を基本にする
  • 原則2 クローズリストを使う

という2つの原則のこととあります。日本語ではマニャーナの法則と訳されていますが the mañana principle なので「(行動)原則」の方が適切に感じました。

すぐやる」ことの弊害

すぐやると「忙しいだけの仕事」ばかりが進み「本当の仕事」が進まないと指摘しています。新しくきた仕事にすぐとりかかってしまうのではなく、既存の仕事より価値があるかをまず考える必要があると説いています。

すぐやる」は自分の行動原則の一つなのでショッキングな指摘です。言われてみれば主体的な仕事よりも反応的な仕事に時間を使いがちです。

ただ「すぐやる」については

  • 「後回しにしてチャンスを逃す」ことのないようにする。
  • 先送りすることで増大するコストを最小化する。

というメリットがあるのも事実。このあたりは本書で言うところの「緊急レベルの判断」とバランスを取っていく感じなのでしょう。

全員がマニャーナの法則をやるとどうなるか?

個人個人がマニャーナの法則に従ってバッファリングすると組織全体のリードタイムが伸びるのではという懸念を持ちました。個人の稼働が最適化されるかわりに、作業の手待ち(idle work)が多く発生することになるからです。

このあたり要注意に思われます。

緊急レベルを判断する

入ってきた仕事はまず緊急レベルを判断するというのが本書の考え方です。

  • 緊急レベル1「今すぐ」
  • 緊急レベル2「今日中に」
  • 緊急レベル3「明日やる」(ベスト)

本書では「明日やる」がベスト。

これはすでに2週間前からRemember The Milk の優先度設定に取り入れてみています。

WILL DO リスト

その日にやるとコミットしたタスクを入れておくクローズリスト。自分は Remember The Milk でタスクの優先度を1にすることでリスト化しています。

処理する順番はファースト・タスクが最初で「明日のリスト作成」が最後です。それ以外はまったく自由。

1日の最後に何をおいても明日の WILL DO リストは作成することが必須とあります。仕事については実践していますが、プライベートでは翌日の WILL DO リストを夜に作るのがまだ習慣にしきれていません。

ちなみに本書ではタスクにかかる時間の見積もりについてはほとんど触れられていません。翌日時間が足りず WILL DO リストを完了できそうもない場合もいつもどおりリストを作成し翌日は「できるとこまでやる」「完了できない日が続くなら対策をとる」という感じになっています。

やり残しをどうするか?

WILL DO リストで完了できなかったものは、「やり残し」フォルダに放り込み、ファースト・タスクで処理しましょうとあります。

これは今週から Remember The Milk で backlog タグを付けるようにして実践中です。

ファースト・タスク

ファースト・タスクは「毎日の最初に行い、そこから1日をスタートさせるのが望ましい仕事」とのこと。毎朝最初にできる仕事は1つしかないので、常に1つ。

  • 原則1 とにかく、する (Do)
  • 原則2 一番始めに、する (First)
  • 原則3 毎日、する (Every day)

ファースト・タスクに向いている仕事は

  • 「やり残し」を片付ける
  • 仕事のシステムを修正する
  • プロジェクトを進める

です。今は「やり残し」を片付けるのに使っています。先送りし続けることが減りました。

実際のところ実際に一番最初にはやれてなくてまず「セットアップタスク」なるものをやってたりします。これらを前日に済ませるようにできれば本当のファースト・タスクにできるのかも。

ダッシュ法

ダッシュ法はポモドーロテクニックにつながるところを感じました。ちょっとマニアックでテクニカルなやり方だというのと、マルチタスク型な印象なのとで今回はスルー。

二分等法 すべての仕事を半分にする

プロジェクトをタスクに分解する方法。 GTD でプロジェクトに対して具体的な行動を設定するのと同様、本書でも具体的な行動に落とし込むよう指導しています。

その具体的なやり方として二等分法というのが紹介されていました。プロジェクトを二等分し、先にやる方をまた二等分にするというのを繰り返して「抵抗感が問題にならない状態」になるまで分割を続けるという方法です。

全てをブレークダウンすることはせず直近取り組む部分だけ具体的にするというやり方がスクラムにおけるプロダクトバックログリファインメントの考え方に似ていて気に入りました。

行動の合間に考える習慣をつける

最後の方の「考える」ということについての話で「行動の合間に考える習慣をつける」エクササイズが紹介されていました。

  • 「毎日15分」など時間を決め確保する。
  • 邪魔が入らない場所でノートと筆記用具を用意し、浮かんできたアイデアや考え方をノートに書き留める。
  • 時間の終わりに近づいたら書いたものについて考える。良いアイデアや行動が必要なことに下線を引く。

というものです。時間(期限)を決めその時間の最後まで考え抜くというのがポイントだそう。ぜひ取り組んでみたいなと思います。

冒頭にキーワードが説明されているのが良かった

最後に本書の構成について。

本書では冒頭で「本書に登場する18のキーワード」として

  • 「クローズ・リスト」「オープン・リスト」「チェック・リスト」
  • コミットメント」「本当の仕事」「忙しいだけの仕事」
  • 「バッファー・ゾーン」「マニャーナの法則
  • 「タスク」「プロジェクト」
  • 「タスク・ダイアリー」
  • 「デイリー・タスク」「ファースト・タスク」
  • 「TODOリスト」「WILL DOリスト」
  • 「ダッシュ法」「期限の効果」
  • 「ラベリング」

が列挙されてそれぞれに簡単な説明がついています。簡潔でわかりやすく、本を読み進める助けになります。

本では「はじめに」で第1章では◯◯、第2章では△△とずらずらと書かれていたりしますが、前提知識が無いとわかりにくい書き方のものが多いです。それに対して、本書ではキーワードという見出しでサマリと流れをうまく説明していて素晴らしいなと感じました(ちなみに本書も「はじめに」では構成が手短に説明されています)。


[ 読書ノート ] [ お薦めの本 ]

[ 8月6日全て ]

2017年8月9日 (水)

何もコミットしないスプリントで各自好きなことをして得られたもの

「プロダクトバックログアイテムについては何もコミットしない」で各自好きなことをして良い1週間スプリントが終わったのでチームでふりかえりました。

何をやらなかったか?

何をやったか?

このチームが自主的に決めたワーキングアグリーメント(記事)に

スプリントゴールが全て達成された場合は、優先する割り込みタスクがあれば対応し、そうでなければ準備完了になっていないプロダクトバックログアイテム(PBI)に関する情報収集・まとめを優先度の高いものからしよう。」

というのがあり、この活動をしていたメンバが多かったです。「スプリントバックログが空 = ただちにスプリントゴールが達成されたので PBI の準備に取り組んだ」わけですね。

環境整備にあてたりとかはあまり多くなかったようです。シェルの設定見直しをしたエンジニアは「失敗したら1日潰れてしまいそうで普段やれなかったことをできた」とやって良かったと言っておりました。

どう感じたか?

開発メンバからは以下のような意見が出ました。

得られた気付きは?

  • タイムボックスの良さにあらためて気付いた(期日から逆算していつまでに何をやるということを考えやすい)。
  • 複数人で作業を見積もることで自信が得られることに気が付いた。

自由になったことで、普段やっているアクティビティの良さを再認識できたようです。チームが取り組んでいるプロダクトの状況から考えるとスクラムではなくカンバンの方が進めやすいのかもしれないのではと私は考えていたのですが、今回の取り組みで開発メンバは「スクラムで続けたい」と改めて思ったとのことです。

スクラムの基本からは外れる取り組みではありましたが、基本通りにやっていたのでは感じ考えることのことができないことを得られたという意味では非常に有意義な1週間でした。

[ 8月9日全て ]

2017年8月15日 (火)

今日のさえずり: アイデンティティを作り上げている大好きなものを再認識できる偏愛マップ作り

2017年08月15日

[ 8月15日全て ]

2017年9月20日 (水)

早すぎるプロダクトバックログリファインメント

今日はスクラム開発している CS 開発チームのスプリントプランニングだったのですが、プロダクトバックログアイテムの中に見積もりした時のことをあまり覚えてないという事案が発生しました。多分1カ月ぐらい前にプロダクトバックログリファインメント済みのもの。

プロダクトバックログリファインメントであまり先まで検討しても、状況が変わって無断になる場合があるよというのは言われているのですが、それ以外にも単純に忘却してしまうというデメリットがありますね。

[ 9月20日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・プロダクトオーナーをしています。

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

follow us in feedly

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

月別インデックス
Process Time: 0.101386s / load averages: 0.66, 0.54, 0.59
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker