ソフトウェアの開発にかかる時間では計測できない。実績は計測できると思われがちだが、妄想である。ClassAを作ってClassBを作る時間とClassBを作ってClassAを作る時間と違うからである。 ましてや、ClassAとClassBを作る時間などまったく概算である。ClassA…

以前、コメントで書いたように、生産性は打率のようなもので波がある。そこで、各個人の生産性の和をチームの生産性とすれば、平準化されるのではないかと考えてみた。1.2倍の人たちが集まったチームは誰かがやっているよみたいな感じ慢心していてチームとし…

システムの複雑さは、 「ユーザの求めているサービスの複雑さ」×「実装環境の複雑さ」 となり、 「実装環境の複雑さ」を簡単にしょうというのがシーサーで 「ユーザの求めているサービスの複雑さ」をとくほぐそうというのがクースです。

メトリックス(Metrics)を定義しないと進められない。数値化された情報と目標値のセットと定義しておく。数値化された情報だけをメトリックスと呼んでいる場合があるが、これはメジャメント（Measurement:測定したもの）である。 ところで、あいかわらず、サ…

生産性の基礎データは難しい。LOCなんてね・・・。なのに見積もり手法があるからまか不思議。このツールを使うと生産性が何倍になりますってよく見かけるけどベースが明確でないのに何倍といわれても困る。学術的には部品化を行うと1.2倍になるというオムロ…

固定したメンバで開発している場合は、予測可能だし、「あいつ最近変な店にはまっているからちょっと駄目だろうなぁみたいに」顔色みて判断できるので問題ない。逆にはじめての協力会社はまったく予測できないから怖い。

企業のメトリックス正確にはインデックスがあるわけだから、チームのメトリックスも機能して良い気がしてきたので再考する。

個人の生産性の和がチームの生産性にならず、相性係数を導入しなければならない。やはりメトリックスはつまらない。

メトリックスには興味がないですが生産性を測る必要性は理解しています。野球の打率と同じで、去年三割打ったからといって今年も三割打てるとは限らないじゃないですか。いろいろな状況で変動してしまう不確定なものですね。で、私は見積力も含めて開発能力…

id:takadesignさんのコメントを読んで考えたのですが、成長（減退）係数も必要。