ページ

2010年11月10日

コードの読まれ方がわかっても工数見積もりに寄与するのか?

「コードの読まれ方が分かった」、工数見積もり精度向上に寄与」という記事は、はっきり言っておもしろくありません。まず、コードリーディングでの結果から導き出されたことを纏めてあるのですが、導き出されたことはごく当たり前のことで、全く新鮮味がありません。新鮮味はないかもしれませんが、定量的にそれらが証明されたらしいということは評価できるとおもいます。「らしい」と言うのは、上の記事からは数字なども示されていないので、判断できなくって、書いてあることを信用するだけだからです。

全体的には悪い記事じゃないんですが、工数見積もりの精度向上とか書かれていると、タイトルとしては気持ちはわかるんですが、身構えちゃうのは心が汚れているからでしょうか? 


「追加、修正行数だけによる工数見積もりは難しい」を実証

とあるんですが、見積もりする方からすれば最初に行数はわからないなので、それをベースに見積もるようなこの表記はちょっとおかしんじゃないかな? と思ったりもします。

そんなことを言っても何も生まれないし、上の表記も完全な間違いじゃいのでアリエルではどんな風に工数見積もりしているかを書いてみます。ちなみに、新機能の追加だけです。バグ修正は調査工数が見積もれないことがあるので範囲外です。

さて、どんな風に工数見積もりしているか?それはほとんど職人の経験によって決めています。で、経験をもとに何を判断しているかと言えば、

1. 影響を受けるモジュール

すべてはAPIのように階層的な構造をもっていて、下のレイヤーは上のレイヤーの知識を知らない状態です。また、OO的に開発していて、隠蔽は進んでいます。といっても影響する範囲はそこそこでるものです。そのあたりをざっと判断します。

2. 変更するソースコードの規模の判定

影響を受けそうな範囲がわかったところで、ソースコードの規模をざっと見積もります。影響を受けるモジュールなんてのは丁寧に時間をかければ調べればわかりますが、 これは、うーん、みんなどうやっているんだろう?こっちは経験としか言いようがないと思います。

3. 単体テストの規模と結合テストの規模

修正や機能追加自体は、アリエルの人の場合はすぐです。ものにもよりますが、一週間は割と長い期間です。 でも、実装の後にテストがあります。単体テストと結合テストの規模は、上の二つを元にやった方が良さそうなことをあらいだして、どれくらいか見積もります。これは、以前のテストケースの量などをいいわけにして、やっぱり経験で決めています。

こんな感じだと思いますが、割と意識せずにやっているので、間違っているかもしれません。うーん、うーん、なんか結局、経験という名目の勘のような気がしてきました。 



0 件のコメント: