『アジャイルサムライ』読書記録 - 7章 - 見積もり：当てずっぽうの奥義

単なる読書メモなので、あまり読んでもおもろくないと思う。

プロジェクトで最初に出す初期見積もりは実に--そう、実にひどい当てずっぽうに過ぎないってことなんだ。

まあ、SIerはそれをずっと維持し続けようとするから、あとで火を噴く訳だな。
開発なんてやってみなければどれくらいのスピードでできるかわからない。

前もって正確に見積もるなんて無理。…前もって見積もるときに、私たちが欲しい答えはただひとつだ。つまり、

このプロジェクトをやり遂げられそうなのか？！

だから私たちには、次の３つの条件をみたすような見積もり手法が必要だ。

• 今後の計画をたてられる
• 見積もりは当てずっぽうだという前提を踏まえている
• ソフトウェア開発の複雑さを認めている

このプロジェクトをやり遂げられそうなのか？！は非常に重要なところだと思う。

できないものをできるとかいうと後々痛い目を見そうだし。

7.2 ピンチをチャンスに

見積もりを信用できるものにしようと思ったら誰でもやっていることをやるだけの話だ。…

• ストーリーそれぞれを互いに相対的なサイズで見積もる
• ポイントをもとにして進捗を追跡する

相対的な見積もりについて

ストーリーをそれぞれ、お互いたお互いに対してどれくらいの大きさなのかを相対的に見積もる。それから、自分たち開発チームがどれくらいの速度で仕事を進められるか(ベロシティ)を計測する。アジャイルな計画づくりにはこの２つがあれば十分だ。

ポイントについて

相対サイズ見積りでの１日は、実際のカレンダー上の１営業日とは必ずしも同じじゃないってことだ。

…

たとえば、あるストーリーで、最初の見積りが３日だったのに、実際には４日近くかかったとしよう。
このとき、他のストーリーの見積もりをすべて33%増やすこともできなくはない。
だが、そうできるからといって、誰がこんな単位で仕事をしたいだろうか。1.33日とか1.66日とか……。…もしも、1.33日と見積もったストーリーが、実際には1.66日近くかかってしまったらどうする？また再見積りするの？

アジャイルしゅほうではこうした状況、すなわち見積もりの数値を再調整する作業がいつまでも終わらなくなる状況に陥るのを避けるために、見積り結果の数値の単位には意味を持たせず、ただポイントとして表現することを推奨している。その狙いは、見積の数値と営業日の日数とを対応させないようにすることだ。

見積もりは確実なものでないとわかっているので、日数でなく、これくらいみたいな感じで見積もっておいたほうがよいってことかな。

SIer「このプログラム何日かかる？」
プログラマー「わかりませんが、この前の仕事の5割増ですね。」
SIer「つまり3日だね？」
プログラマー「どうですかね？この前の仕事は確かに2営業日でできていますけどね。まあ、たぶんこの前の仕事より5割増くらいだということですね。」
SIer「つまり３日だね？」
プログラマー「いや、分かりません。」
SIer「この前のは２日でできたのだから、それの５割増だから、３日だろう。」
プログラマー「どうですかね？この前の仕事は確かに2営業日でできていますけどね。まあ、たぶんこの前の仕事より5割増くらいだということですね。」
SIer「つまり３日だね？」
…以下続く

見積り技法

三角測量

ストーリーの一覧から１回のイテレーションの期間に収まりそうなサイズのストーリーを大中小選び出す。
選び出す際の視点。

• 論理的なグループ分けができる
• エンド・トゥ・エンドになっている
• プロジェクトを象徴するストーリー

スパイク

今まで経験したことのないようなストーリーに対する見積もり方法。
タイムボックス化して数日以内でストーリーを見積もれる程度に様々な調査を行う。

プランニングポーカー

開発メンバーが一つ一つのストーリーを自分自身で見積もる。
その結果をメンバー同士で共有する。
一致していたら、その見積もりにする。
異なっていたら相違について話し合って見積りを出す。

重要なポイントは話し合いがあること。
プランニングポーカーは投票システムではないこと。
ストーリーのサイズは小さくする。(1、3、エピックを表すのに5を使う。)

現場で使えるJavaライブラリーのサンプルを丸写ししてみた。

最近次のような本が発売されました。

現場で使えるJavaライブラリ
竹添 直樹 (著), 島本 多可子 (著), 小津 美夕紀 (著), 亀井 隆司 (著)
翔泳社 (2011/7/16)

で、早速そこに載っているライブラリーを試してみました。

charts4j

各種のチャートをWeb上で処理してくれるライブラリーです。

@Grab(group='com.googlecode.charts4j', module='charts4j', version='1.3')
import com.googlecode.charts4j.*;

def plot1 = Plots.newBarChartPlot(Data.newData(20, 100, 10, 30), Color.BLUE)
def plot2 = Plots.newBarChartPlot(Data.newData(50,  80, 30, 70), Color.RED)

def chart = GCharts.newBarChart(plot1, plot2)

chart.setTitle('Sample')
chart.setSize(400, 300)
chart.setBarWidth(40)
chart.setGrid(10, 10, 2, 2)
chart.addXAxisLabels(AxisLabelsFactory.newAxisLabels('A', 'B', 'C', 'D'))
chart.addYAxisLabels(AxisLabelsFactory.newAxisLabels('0', '50', '100'))

def url = chart.toURLString()

実行した結果のURL

http://chart.apis.google.com/chart?cht=bvg&chxt=y,x&chs=400x300&chtt=Sample&chbh=40,4,8&chg=10.0,10.0,2,2&chco=0000FF,FF0000&chd=e:Mz..GaTN,gAzMTNsz&chxl=0:|0|50|100|1:|A|B|C|D

実行結果の画像

なかなかやりおる。
コードがGroovyっぽくないので、すこしリファクタリングしないとダメですね。

97 things Every Project Manager Should Know を読んでみた(3)

A Word Can Make You Miss Your Deadline

たかが言葉、されど言葉

第三回目です。
いつもどおり、ゆる～く翻訳、意訳します。逐語訳ではないです。

プロジェクトのマネージメントについて。
これを読むと日本のプロジェクトマネージメントと
考え方が若干違うなと思いました。

だからアメリカ発祥のPMPだやらの考えを
日本に適用しても無理だと思う気がしました。

では、以下本文

WHICH WORD CAN MAKE YOU MISS YOUR DEADLINE? The answer is "any word." When you are developing a product that will be released in languages other than English, you are adding numerous new risks and constraints to your project.

どの言葉が締切りを破らせてしまうのか？答えは、「どの言葉で」もそうなる。英語以外の言葉でもリリースされる予定のあるプロダクトを開発している場合、そのプロジェクトには多くの未知のリスクや制約がかかっている。

Some are technical and obvious. For example, if your product will be released in Japanese, it has to support the appropriate fonts. If it doesn't, the Japanese version won't work, even if the English one works perfectly. But font compatibility is not under your control. You and your team need to be aware of translation quirks and consider them before coding. Make sure that the development practices follow international standards that will eliminate such issues.

いくつかの問題は技術的なものだし、明らかなものであったりする。たとえば、今制作しているソフトウェアが日本でも発売されることとしよう。その場合、ソフトウェアは適切なフォントを扱えなければならない。もしそれができなければ、日本版は動くことはないでしょう。たとえ、英語版がどんなにすばらしくても。しかしフォントの互換性はコントロール可能な課題ではない。このような翻訳にまつわる問題は事前に考慮して開発する必要がある。つまり、国際的な標準に則ることがこのような問題を解決するのである。

However, the mere need for alternate language versions also constrains what decisions you can make and when. Typically, localization (Japanese, Swedish, German, etc.) happens in parallel with English development, with a certain lag. It can be a few days, weeks, or even months. However, at some point the translation of the foreign version has to "catch up" with the English version.

しかし、他の言語版を作成するという単純な要求がいつ何を決定するのかという問題に制約を課しているものなのである。よくあることだが、国際化(日本語化、スウェーデン語化、ドイツ語化など)は英語版の開発とほぼ同時に、いくらかの時間差の後に発生しているものなのである。その時間差は数日、数週間、ひと月などになるかもしれない。しかし、あるタイミングで他言語版は英語版と同等になるときが来るのである。

You need to make sure during testing and reviews that:
- What is in the English version can be properly translated
- What is translated truly corresponds to the English version
- The translated product works flawlessly
Here's the catch. These three things may be tested after the English version is finished and signed off on. During the testing and reviewing of a localized version, you will always find at least one challenging issue that can't be solved except through a change to the English product.

以下に示すことだけははっきり確認しておいて欲しい。テスト中や、レビュー中のうちに。
- 英語版のうち何が正しく翻訳されうるのか
- 翻訳されたものは英語版と同じ意味をもっているか
- 翻訳された製品は確実に動作するか
どうだろう。ここに挙げられた事柄は英語版が完成して出荷された後にもテストをしなければならない。各言語版対応へのテストおよびレビューの最中に、たいてい英語版にも改修が必要になるような問題を発見してしまうものなのだ。

97 things Every Project Manager Should Know を読んでみた(2)

Avoid Whack-a-Mole Development

モグラたたき開発から逃げろ

開発する早さの評価に関するエッセイ。
日本のSIerではバーニーさんの方が評価される傾向にありますね。
ものづくり日本という標語が盛んに叫ばれたりしています。
でも、なんか年末になるといらない工事とかがあったりして、
作りっぱなし日本という標語が適切な気がしなくもないです。
だからこそ、読んでほしい一節です。

ちなみに、前回と同じく、翻訳の詳しいところはいい加減です。
翻訳はノリが大事です。
多分怪しいところは満載なので、ツッコミ歓迎です。
それと、オレには突っ込まないけど、オレだけ知ってウッシッシな人はGoogle 翻訳にでもかけてください。

SOFTWARE PROJECT MANAGERS faces a lot of pressure to deliver fast. Time is of the essence. How can you get things done fast?

ソフトウェア開発プロジェクトマネージャーは早く提供するというプレッシャーに晒されるものである。時間が重要なのである。どうやれば早くできるのか？

Imagine you have two programmers on your team, Bernie and Rob. Both are capable, have the same amount of domain knowledge, and have equal language skills. During development, you find that Bernie finishes his feature implementations much faster than Rob.

プロジェクトに二人のプログラマーがいるとしよう。バーニーとロブだ。ふたりとも才能があり、業務知識も同等であり、開発言語のスキルも同等であるとしよう。開発の途上、機能の実装がバーニーのほうがロブよりも早いことがわかってきた。

While Bernie focuses on getting the code completed quickly, Rob spends time writing code and then refactoring it. He names the variables and methods better. Once he gets things working, he breaks the code into smaller pieces. Now he writes tests to make sure each piece of his code does what he meant it to do. When he's reasonably satisfied, he declares the coding of that functionality done.

バーニーがコードを早く完成させるのに集中しているのに対して、ロブは彼の時間の多くをコードを書いてすぐリファクタリングすることに当てている。彼ロブは変数やメソッドがより妥当なものがないか探る。彼はプログラムが動くようになったら、すぐにそのコードを小さな単位に分解する。次にはテストコードを書いて、コードが彼が想定していたとおりに動いているかどうかを確認する。彼はそれで納得した時点でやっと、機能の実装がなされたと報告するのである。

But assume you don't know these details. If you only look at the speed with which the functionalities are declared done, clearly Bernie is the better man, right?

さて、詳細を知らないプロジェクトマネージャーである君が、機能が実現されたという報告だけをもとにしたら、バーニーのほうが優れていると考えるのではないかな？

A few weeks go by, and you demonstrate the features to your customer. As usual, the customer loves your completed features, but now wants you to change and improve them. You ask your developers to make those code alterations. When you take the new and improved functionality back to your customer, they try out the features that Rob implemented and are pleased with the changes.

何週間後、とうとうお客さんにお披露目するときがやってきた。たいてい、お客さんは完成された機能に満足するんだけど、あれあれ、今回はそうでもないみたいです。ここ変えてとか、いい感じにしてって要望を出しているようです。仕方ない、君はプログラマーさんに修正をお願いすることにします。機能を改修した後にお客さんのところに持って行きました。お客さんはロブが実装した方の機能を試してみています。非常に満足しているようです。

Unfortunately, they discover something odd with the features that Bernie implemented. While Bernie has programmed in the new functions fine, now a few things that worked before don't work anymore. The customer marks these as defects, and you ask Bernie to fix them. The customer tests the features again. Now even newer, stranger things seem to be broken. What's going on here?

ただ、残念なことに、お客さんはバーニーが開発した機能におかしなところがあるのを見つけたようです。バーニーは新しい機能をいい感じにプログラムしたのですが、いくつかの機能が前と同じように動かなくなったのです。お客さんはこれを欠陥と考えたので、君はバーニーに治すようにお願いします。お客さんは機能を再びテストする。おや、なんだかあたらしい不具合が出てきたようだ。何が起こっているんだ？

If you have a child, you know what is happening. Bernie has created a Whack-A-Mole application. Whack-A-Mole is a toy. Kids are given a wooden hammer to strike moles that pop up at random. It's fun for them to be surprised by which mole pops up next. However, fixing applications with broken code popping up at random places is not fun. It is frustrating, unpredictable, and it slows your product development. Bernie was sprinting initially, but he was running in the wrong direction.

お子様をお持ちの方なら何が起こっているかわかるだろう。バーニーはモグラたたきを自分で作って、遊んでいるのだ。面白いだろう、モグラがどこから出てくるのかわからないんだから。でも、アプリケーションの修正でモグラが出てくるのは面白いことではないね。ムカつくし、迷うし、そんでもって開発のスピードを遅くしちまう。バーニーは滑り出しはうまく行ったが、とんでもねぇ方向に走ってたんだ。

While Rob appeared slower at the outset, he was actually creating superior code. His pace proved sustainable. The better quality of his initial code helped him make workable changes quickly. Plus, the test he wrote in the beginning gave him instant feedback regarding whether or not his new code was compatible with other parts of the application where the code was used.

一方、ロブの方は見かけは遅いんだけど、優れたコードを実際につくっていたのだ。彼のペースは一定であった。最初からよりよい品質のコードを記述していたので、変更にも柔軟に対応できた。それどころか、彼が最初から書いたテストコードは、新しく追加したコードが他の部分に影響するかどうかを素早く検知してくれたのだ。

When measuring time for a feature implementation, do not consider only the time it takes to write it in the first place. Add the time it takes to enhance, fix, and improve the code. Writing good quality code and tests takes time. It appears to be a short-term loss. However, it comes with a long-term gain.

Ask yourself if you want speed, or if you want to savor sustainable progress.

実装の速度を計測するときに、機能の実現に要する時間だけを測ってはイカンのだ。変更の反映、修正、コードの改善といった時間も含めて計測するべきなのだ。よいコードを書くこととテストを書くことは時間がかかる。それは一瞬時間を無駄にしているように思われる。しかしながら、長い目で見れば時間の節約になるのだ。

一瞬のスピードが欲しいのか、持続可能な進捗が欲しいのか、どっちが欲しいのか言ってごらん

ま、このブログを読む人なんて、えらいプロジェクトマネージャーなんかいないだろうけどね。
それと、お客さんに同じ機能のテストをさせるなんて、どう考えたってムダでしかない。
ソフトウェアを作りっぱなしで、お客さんになんども同じことをさせるのはどうかと思う。

97 things Every Project Manager Should Know を読んでみた(1)

表題のとおり、読んで、勝手に訳してみた。

今回はその最初のエッセイ『Get Users Involved As Early As Possible』。

ちなみに、オレの翻訳はかなり適当感満載なので、
各自Google先生に正しい訳を求めること。

オレが提供するのは英文が醸し出している雰囲気のみ。

PAST PATTERNS OF SOFTWARE DEVELOPMENT involved getting user requirements and then going off to do the coding and testing under a veil of great secrecy. After all, the users wouldn't understand what we were doing anyway, right? At the end of the project, our magician's magic cloth was whisked away and the user was expected to "ooh" and "ahh" at the brilliance of what we had produced. However, all too frequently the reaction was, "Well, I know you went to a lot of work, but what I really wanted was...".

旧来のやりかただと、まずユーザーの要求を集めて、その後、ユーザーにお楽しみにねなんて言って、コーディングしてテストしてっていうやり方でした。そして、ユーザーは私たちが何をやっているか理解なんかしていなかったんじゃない？プロジェクトの終わりに、私たちの魔法の種明かしの時がやってきて、きっとユーザーは私たちのプロダクトを一目見た瞬間に「オオオッ」とか「うほっ！」とかって言うんだろうな～なんて期待しているんですよね。でも、たいていのリアクションが「あぁ～、なるほど、よく働いてくれたよ。でもね、我々が望むのはね、云々」

Today, the secret to project success is to involve the users almost as soon as there is anything visible to show them. How much better it is to find out that there are problems with what we are developing early on, rather than after the project is complete!

最近ではプロジェクトを成功させる秘訣というのは、ユーザーをできるだけ早めに巻き込むことなの。ユーザーさんが触れるようになったらすぐ触らせてみて。早い段階で私たちが作っているものに何か問題があることを見つけてもらえるなんて、プロジェクトが終わってから見つかるよりも全然いい。

Costs for changes become increasingly high the further along we are on the project schedule timeline. The time to recode, retest, and rework the immediate software, as well as to test integration with all the peripheral code involved, can delay the project substantially. And both time and cost baselines are jeopardized if a change is so major that it has to go through a lengthy Change Control Board process for approval.

変更にかかるコストはどんどん高くなります。プロジェクトが進行していくとね。コードを修正して、テストを再実行して、そのたもろもろの作業をさささっとおこなって、もちろんすべての関連するコードも動くことを確認して、なんてやっているとプロジェクトが知らないうちに遅れ始めます。そして、時間とコストが危険を迎えるようになります。特に変更がでかいモノで変更管理委員会から承認が必要なものだったりすると、もう最悪。

Programming decisions over very minor issues, which make perfect sense to the software developer and the project manager, may create chaos back at the workstation when the software goes into use.

ちょっとしたプログラムに関する変更、それは開発者とプロジェクトマネージャーにとって非常に重要なものなのかもしれませんが、それを使っている人にとって混沌とした状態を作り出してしまいます。特にソフトウェアが使われ始めた後などではね。

以下、2011/06/04に追記

I know of a large training company that spent $5 million redesigning its ordering software. Previously, the item numbers matched the product being ordered in a logical way. For example, 4125 might be a student manual, 4225 was the accompanying student exercise disk, 4325 could represent the instructor manual, 4425 was the course outline for marketing purposes, and so on. You could order all the items in the 4X25 series on the same screen

私の知っている大規模な研修会社で行われた500万ドルの規模になるソフトウェア改修の例を取り上げてみます。以前は商品番号はうまい具合に発注する商品と関連付けられていました。例えば、「4125」という商品番号は学生用の研修資料、「4225」は学生の自習用ディスク、「4325」は講師用のテキスト、「4425」はマーケティング用のコース概要などと関連付けられているような感じです。ユーザーは「4X25」という値を同じ画面から入力することで、すべての商品を発注することができたわけです。

Each day, administrative coordinators in 140 locations around the world ordered the same kinds of materials over and over and soon memorized the item numbers. Once you knew the number for a student manual, you could immediately key in the numbers for the other items without looking them up, and ordering went quickly.

毎営業日、世界140箇所に点在するコーディネーターの責任者は同じ資料を発注していて、すぐに商品番号を覚えてしまいました。ひとたび商品番号を覚えてしまえば、画面を探し回ることなく、一発で目的の商品番号を入力でき、発注業務は非常に素早く行えるものでした。

In the redesign, somehow the project team forgot to consider the way the ordering process was used by the real people doing it. Under the new design, there was no logical relationship between items. Item 6358 might be the same student manual that once was 4125, the accompanying student exercise disk was now 8872, and the instructor manual for the same class was 3392.

ソフトウェアの再構築に当たって、プロジェクトチームはどうやら発注業務を、実際に人がやっているやっているということを失念してしまったみたいです。新しいソフトウェアの設計では、商品番号と商品とがうまく関連づかなくなってしまったようです。新しい番号6358が前は「4125」だった学生用の研修資料に、学生の自習用ディスクは今では8872に、講師用のテキストが3392になってしまったようです。

Not only did the user have to look up each item and try to "forget" the old numbers and system, but also each type of item was now on a separate page.

Administrative coordinators were furious. Ordering slowed to a crawl. The project far exceeded its time and cost baselines.

As a project manager, you should get the users talking to the software developers early and often.

その結果は、ユーザーは個々の商品について前の知識を捨てて、画面をくまなく探さなければいけなくなっただけではありません。個々の商品が別個の画面に表示されるようになってしまったのです。

コーディネーターの責任者は非常にぷんぷくり～ん＞＜したようです。結局プロジェクトは時間とコストが、計画をオーバーしました。

プロジェクトマネージャーとしては、早い段階、かつ頻繁にユーザーと開発者とが話をできるようにするべきです。