nDiki : 見積もり

見積もり (見積り) - estimation

2013年1月10日 (木)

毎日の仕事の計画を夜にするようにしたら捗っている

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

年末からポモドーロテクニックをやってみているのだけれど、それにあわせて毎日の仕事の計画を夜にするようにしてみたところ捗ってる。

その日の最後の2ポモドーロ(25分 x 2)で、その日にやるべき残っているアクションをやっちゃったり、メールチケットの処理したり、GTD のデイリーレビューしたりして、その流れで翌日のポモドーロ数の見積もりと、ポモドーロでやるアクティビティだったりその他アクションだったりをチョイス。でその日のふりかえりをして、翌朝の朝会で話せるように書き出してる。

今までは朝に上のようなことをしていたんだけれど、そうするとあっという間にお昼になっちゃったりしてスタートダッシュしにくかった。でも前日の夜に済ませておくと朝はさらっと再確認したら本腰入れられて生産性がアップ。 「前日に計画しても、朝になったらまたメールが入ってたりスケジュールが追加されてたりで、それなりにチェックが必要」なのかなと思っていたんだけれど、実際やってみると前日の夜と次の日の朝の差分はほとんどなく問題なかった。

あとは夜にやれるかという点。例えば開発その他をガァーっとやってると「あらもうこんな時間」となってしまって続きは明日ということになり、2ポモドーロも確保できるのかなとちょっと思ってた。だけどポモドーロテクニックで回していると時間時間で区切るので、わりにスパッと切り替えられるので OK だった。これは面白い。

いや実は昨日はどうしてもその日にやっておきたい仕事があって、このパターンにしてから初めてふりかえりやら翌日のプランニングをしないで帰ったんだけれど、もはや気持ち悪いし今日の流れも若干いまいちだった。嫌。やっぱり夜やっとく方がいいや。

そんなこんなで自分、翌日の仕事の計画を夜にやっておくの意外にあっているかも。

スポンサード リンク
[ 1月10日全て ]

2013年3月18日 (月)

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

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

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

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

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

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

[ 3月18日全て ]

2013年11月29日 (金)

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

2013年11月29日

[ 11月29日全て ]

2014年4月1日 (火)

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

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年にも引用しているのだけれど、何も決まっていないのに工数を聞かれると今でもこれを思い出してしまう。

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

[ 4月1日全て ]

2016年4月17日 (日)

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

image:https://www.naney.org/nDiki/2016/04/17/Toggl-Web.png

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

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

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

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

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

Toggl

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

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

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

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

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

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

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

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

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

[ 4月17日全て ]

2016年12月6日 (火)

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

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

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

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

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

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

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

ストーリーポイント

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

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

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

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

ベロシティ

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

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

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

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

[ 12月6日全て ]

2016年12月7日 (水)

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

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

[ 12月7日全て ]

2017年1月17日 (火)

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

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

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

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

開発チームのスキル

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

このために

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

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

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

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

開発チームの構成

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

としています。一方

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

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

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

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

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

掛け持ち

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

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

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

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

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

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

チームの寿命

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

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

[ 1月17日全て ]

2017年2月14日 (火)

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

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

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

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

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

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

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

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

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

[ 2月14日全て ]

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日全て ]

About Me

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

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

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

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