nDiki : 見積もり

ポモドーロテクニック終わり

去年末から仕事でポモドーロテクニックを取り入れてみていたんだけれど、どうも今の自分には合わないのでやめることにした。今まで通りストレートに GTD の次の行動リストベース1本にする。

1日に何回かミーティングがあって、例えば 14:00-15:00 と 16:00-17:00 の予定になっていたりすると 15:00 から 16:00 の1時間が微妙なんだよね。2ポモドーロ入るわけだけれども、準備やら移動やらを考えると実際には2ポモドーロはできない。では1ポモドーロだけやって、あとは25分以下のアクティビティをやるかということになるのだけれども、やはり中途半端なんだよね。25分/5分 のリズムにのれる場合は有効なんだけどね。

ポモドーロテクニックをやって良いなと思ったのは見積もりの精度。タスクにかかる時間を過小評価しすぎるといのがよくわかった。あと25分毎に5分休むというのもメリハリがあって良い。なので一度は取り組んでみる価値があるよ。

ポモドーロテクニック原理主義からは離れるけれども、集中したい時にはポモドーロタイマーは活用していくつもり。

• アジャイルな時間管理術 ポモドーロテクニック入門

今日のさえずり: 「ガッツフィーリング」ってガッツ100%出し切った時の見積もりだと最初思ってた

2013年11月29日

• 09:51 まずは Windows Update。
• 10:05 昨日、20:30 には寝てしまったのでスッキリしている。
• 10:11 昨日休んだのでミーティング7本ノック。 (@ 株式会社ミクシィ (mixi, Inc.) w/ @sseze) http://4sq.com/1gn8gkK
• 11:49 ガッツフィーリングでお願いします。
• 11:51 昔よく「ガッツフィーリングで」って言われた。ガッツ100%出し切った時の見積もりだと最初思ってた。
• 14:27 今月も買ってしまった。 (@ バンナイズ 渋谷店 w/ 4 others) http://4sq.com/1evLm9M
• 22:10 ユニクロのチラシに「ワイヤレスブラ」というのが載ってた。無線なのか。
• 23:19 ぬめ革ベルト用いい感じのスイングアタッチメント。 http://flic.kr/p/hWnopu
• 23:21 TOC EXPRESS は土曜日運休とな。
• 24:18 今年見に行きたい。 / “目黒川で「冬の桜」イルミネーション「満開」－地域ボランティアも協力 - 品川経済新聞” http://bit.ly/1b3MnoP

プロジェクト開始時の開発見積もりは意味がない

140文字程度のなんとなくやりたいことで、すぐに工数見積もりが欲しいと言われたりするので「ソフトウエア開発55の真実と10のウソ」真実 9. を言及できるよう引用。

真実 9. ソフトウエア開発の見積もりは、プロジェクトの開始時に実施する場合が非常に多い。これだと、要求定義が固まる前に見積もることになり、どんな問題がどこにあるかを理解する以前に予測するので、意味がない。従って、見積もり時期として適切ではない。-- ソフトウエア開発55の真実と10のウソ p.48

(日本語訳では「開発時」となっているけれども原文からすると「開始時」なので上記では修正)

Most software estimates are performed at the beginning of the life cycle. This makes sense until we realize that estimates are obtained before the requirements are defined and thus before the problem is understood. Estimation, therefore, usually occurs at the wrong time. -- Facts and Fallacies of Software Engineering Rovert L. Glass

既に2005年にも引用しているのだけれど、何も決まっていないのに工数を聞かれると今でもこれを思い出してしまう。

せめてユーザーストーリーぐらいまではまず書こう。

Toggl でタイムトラッキングするだけで時間の使い方が良くなる

GTD では使える時間を基準に行動を選ぶ

GTD では次の行動を「状況」「時間」「エネルギー」「優先度」の順の基準で選びます。

今使っているタスク管理ツール Remember The Milk はタスクに予測時間を設定しておくことができます。そして検索やスマートリストで使える時間に応じたタスクをリストアップすることができます。

タイムトラッキングしてタスクの時間見積もり精度を上げる

ただこの予測時間の見積もりはだいたいこれぐらいかなと思って入力することがほとんどだったりします。もう少しきちんと入力できるようにタイムトラッキングしてどれぐらい時間がかかっているか実測してみることにしました。Remember The Milk にはタイムトラッキング機能が無いので、今回はタイムトラッキングサービスでは有名な Toggl 試してみます。

• https://toggl.com/

Toggl

サインアップすると Toggl サイト上でタイムトラッキングできます。Google Chrome 拡張を入れると Remember The Milk のタスクの横にも Toggl のボタンがついて1クリックでトラッキングの開始・終了ができるようになります。Remember The Milk のタスク名がきちんと Toggl のエントリの description に設定されるなど良くできています。これは便利。

スマートフォン向けアプリもあってそちらでもトラッキングの開始・終了ができます。以前ちょっとタイムトラッキングをしてみていた時(2007年前後)は Task Coach を使っていましたが、この頃は特定の PC でしかトラッキングできませんでした。スマートフォンの登場でかなり便利になりましたね。

タイムトラッキングすると時間の使い方が上手になる?

費やした時間を記録してあとで精査することで所要時間の見積もり精度を上げたり無駄な時間を見つけたりすることがタイムトラッキングの大きな目的だと思っていました。

しかし実際にやってみると

• 「トラッキング中はネットサーフィンなどのような計測している実際のタスクとは違うことはしたくない」という気持ちになって集中してやるようになる。マルチタスキングもしなくなるのでコンテキストスイッチのコストが無くなる。
• タイマーを設定することをイメージして「そもそもこんなことに時間を使わない方がいいな」と考えるようになり、無駄に思われる行動をやめるようになる。

など、ふりかえりをせずとも即行動に影響が現れたので驚きでした。家計簿をつけたり食べた物を書き留めるのと同じで、無駄に対する意識が高まるようです。

これは楽しいですね。しばらく続けてみることにします。

(画像は https://blog.toggl.com/media-kit/ より)

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

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

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

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

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

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

ストーリーポイント

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

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

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

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

ベロシティ

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

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

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

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

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

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

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

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会11回目。今日は第11章 開発チーム。

ここまでの章で様々な視点でスクラムの説明がされてきたので、開発チームの章は比較的おさらないな感じで読めました。

開発チームのスキル

開発チームは設計・開発・統合・テストなど必要な作業を全て行うので、必要なスキルをチームは全て備えている必要があります。

このために

マネージャーは、今いる人たちでT型スキルのチームを作るべきである。

マネージャーは、学習や実験の時間がうまく作れるように、チームメンバーを支援する必要がある。

と書かれています。他のメンバと互いに専門分野を教え合いながらできる仕事を増やしていくのがまずは近道でしょうか。ただこの方法だと浅く広く学習は進むと思うのですが、 T 型の縦の部分、専門分野の部分を深めていくのは(機能別のチームで学び合うのに比べて)難しくなるのではと感じました。

「専門分野については個人で学ぶ方法を獲得していて自力で学べるのでは」という意見が勉強会では出ました。

開発チームの構成

チーム構成の話では小さいチームの方が

• コミュニケーションでの帯域が向上する
• 誰かがやってくれるという意識が減る

としています。一方

• チームのもつスキル
• 議論の多様性
• 学習

などを考えるとある程度の人数も必要でこのあたりのバランスが重要そうです。本章では

一般的には5〜9人のチームが最適とされている。

ビジネス価値を迅速に届けるスイートスポットは5〜7人のチームである。

と述べられていました。そういう意味では今の私のいるところのスクラムチームは人数がちょっと少なすぎるかなと感じました。

掛け持ち

掛け持ちに対する問題は承知しているものの、現実的にせざるを得ない場合が発生します。

複数のプロダクト(またはプロジェクト)や複数のチームに関わると生産性が低下する

3つ以上のプロジェクトの仕事を同時に行うのは経済的ではない

とありこれに従うとすると仕方なく兼務にするにしても2つまでにすべきということですね。そういった状況が発生するのは

多くの組織では、同時に開始するプロジェクトが多すぎる

ということで組織体制の工夫以前にプロジェクトの見直しをすべきなのでしょう。

チームの寿命

長寿のチームはできたてのグループよりも生産性が高い

については完全同意。今までもチーム殺しをしないように意識はしてきました。特にスクラムではチームとして見積もりやベロシティの履歴が蓄積されることで正確性が向上していくところがあるので、チームを維持していくことがより大切に感じられます。

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

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の15回目。今日は第15章 さまざまなプランニング。昨年12月のプロダクトオーナーの章ぶりの発表当番です。

この章ではスクラムを使ったプロダクト開発に関係する以下のプランニングを紹介しています。

• ストラテジープランニング
• ポートフォリオプランニング
• プロダクトプランニング(エンビジョニング)
• リリースプランニング
• スプリントプランニング
• デイリープランニング

勉強会では自分たちの事業でのプロダクトは何か(例えば mixi は1つのプロダクト)を確認し、実際やっていることのどれが各プランニングにあたるのかを確認。スクラムチームメンバから直接体感できるのはプロダクトプランニングまでで、ポートフォリオプランニングはうかがい知れないことが多そうという話になりました。

それから(旧来からの)受託開発の場合は、リリースが固定スコープ・固定日だよねなんて話も。

スクラム開発チームメンバからは「トップダウン型のプランニングの流れの印象だが、スクラムチームの見積もりでわかった計画との差異はどのように上位の計画に反映していくのか?」という疑問もあがりました。

このあたりは続く章で説明があるのかもしれません。

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

今日のさえずり: ワイルドブルー ヨコハマいいですよね(1度しか行けなかったけど)

2017年02月21日

• 13:48 「これまで2年に渡って運営、キュレーションしてきた各公式パブリケーションや公式 Twitter、公式 Facebook を本日を持って止めることを決定しました。」 / “Medium Japan より大切なお知らせ – Me...” http://bit.ly/2lFSai4
• 17:35 見積もり済み PBI 枯渇の危機。
• 20:16 ワイルドブルー ヨコハマいいですよね(1度しか行けなかったけど)。
• 23:05 ガイオンフェスティバル (Gion Festival)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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