見積もりスキルを向上させるための良いチームビルディング活動は何でしょうか?[閉まっている]


9

私はチームメイトの一部(すべての開発者)に提供するプレゼンテーションをまとめています。見積もりスキルの向上に焦点を当てた短いチームビルディングアクティビティを含めたいと思います。誰かが私に提案できるチーム構築活動を知っていますか?


2
見積もりの​​改善は、短いアクティビティで実行できるものではありません。推定値と実際の時間が異なる理由を判断するために、推定値、実際の時間、およびある種の事後分析を追跡するための長期的な努力が必要です。それはまた、時間の経過とともに発達するスキルでもあります-分析を通じて間違いを推定し、そこから学ぶことでより良くなります。
Thomas Owens

なにかもんだいがありますか?あなたの見積もりはどれほど正確ですか、それらを改善するために時間をかける必要がありますか?
JeffO 2011

@トーマス・オーエンス、それは短い活動でできることではないことを知っています。優れた見積もりスキルを身に付けることの重要性に対する意識を高めようとしているだけです。私は私の質問でより具体的だったはずです。
Rob

2
@Jeff O、問題ありません-これらは新入社員であり、経験の少ない人もいます。概して見積もりに取り組む手助けをしたいと思います。
Rob

回答:


8

Joel On SoftwareのEvidence Based Schedulingを確認してください。これは、見積もりをより正確に把握するための非常に簡単な方法です。

見積り方法を学習する最良の方法は、適切な要件、実践、実践、実践を行うことです。Evidence Based Schedulingのようなことを教えると、より効果的に練習できますが、実際の練習に代わるものはありません。


私はいくつかのEBSが大好きです(私は熱心なFogBugzユーザーです)。ただし、例として使用することは考えていませんでした-良い提案です。それからインスピレーションを得ます。
Rob

6

Minecraftを使用して問題の例を示します。

お客様は、20x20ブロックの茶色の階段ピラミッドが必要です。ピラミッドには、少なくとも10ブロック幅の堀も必要です。

簡単なWBSと見積もりを作成するのに3分かかります。

2分後に、顧客が気が変わって30x30のピラミッドが必要になったと言います。残りの分で見積もりを修正するように伝えます。

時間の終わりに鉛筆を下に置くように言い、今度は開発者がプロ​​ジェクトに取り掛かったが、堀を渡る橋がなかったためにクライアントは混乱していると言います。

橋が発達するのにX時間かかり、過小評価しているすべての人に立ち上がるよう依頼することを彼らに伝えます。

これはポイントをホームにドライブします。


2
私はこれが好きですが、Minecraftに精通していない場合は、どのようにして意味のある見積もりを出すことができるかわかりません。茶色の階段ピラミッドを構築するのにかかる時間をどのように定量化しますか?
Rob

1
@Thomas Owens、maple_shaftのポイントは、これらのタイプの要件を発見することの重要性を開発者に印象づけることです。私はコンサルタントとして、ユーザーが求めるべきであるとんでもないほど明白なことの多くの例を個人的に見てきましたが、彼らがそれが必要であることを理解していなかったため、そうしませんでした。私と私の開発者はすべてコンサルタントであり、現在の状況では、優れた要件エンジニアの贅沢さはありません。そのため、私は、クライアントにこれらのタイプの発見の質問をして、見積もりを改善するように頼む手助けをしようとしています。 。
Rob

2
@ unforgiven3ただし、推定とは関係ありません。要件エンジニアリングの仕事は開発者に委ねられる可能性がありますが、推定は既知の要件に基づいてのみ行うことができます。要件を分析、検証、検証、および発見する能力の向上は、タスクの実行にかかる時間を推定する能力の向上とは無関係です。要件は変化し、したがって推定値も変化しますが、わからないことや推定してはならないことを推定することは不可能です。
Thomas Owens

1
@Thomas Owens、私はあなたが知らないものを見積もることは不可能であることに同意します-これはまさに私のポイントです-あなたは機能の要件を発見し、まともな見積もりを作成するための前提条件としてそれに関する仮定を検証する必要があります。ただし、ある程度の検討の結果、見積もり能力の向上とは無関係であることに同意します。おそらく、アクティビティを要件の発見に集中させる方が、見積もりアクティビティよりもすぐに役立つでしょう。良い点-彼らは間違いなく私が改善するために間違ったスキルに焦点を合わせていると私に考えさせています。
Rob

1
@ unforgiven3優れたエンジニアは常に両方の改善に取り組む必要があります。私は要件エンジニアリングを任されていなかった立場にありましたが、私が見たものに問題があるという仕様を手渡されました。それらを見て適切な質問をするスキルを持つことは、ソフトウェアを開発する誰にとっても不可欠であり、取り組む必要があります。ただし、見積もりを行うときは、質問がある場合でも、常に仕様に基づいて見積もりを行います。エラーのために大きなウィンドウを残すだけです(85%ではなく75%の確率を与えるか、わずかに大きなウィンドウを与える)。
Thomas Owens

1

次の点については、ラビリンスジェネレーター/ソルバーをお勧めします。

  • するのが楽しい
  • 初めてすべてのケースを考えることはできません
  • 生成と解法は非常に相補的です
  • これは、データ保存のバックエンドからデータ読み込みのフロントエンドまでをカバーします
  • 多くのポイントを人々に割り当てることができます:ファイルの仕様、表示、生成、解決、最適化、テストなど...

1

「これを書くのにどれくらいかかりますか?」ゲーム。X時間でラスベガスまで車で行く方法について自慢している人々のグループに似ています(Xの数字は通常、誰かが1時間以内にそれを行うことができると主張するまで、各自走車で減少します)。したがって、コーダーの場合:単純な目標をスローして、各個人の発言を確認し、グループによるコンセンサスや顕著な意見があるかどうかを確認します。Hello Worldを書くのにどのくらいかかりますか?「書き込み」とはどういう意味ですか、「実行」と「テスト」も意味しますか?最初にシミュレーション環境が必要ですか?どのプラットフォームとどのクロスコンパイラーにあり、ツールはすでにインストールされ、準備ができていますか?etc ..「Hello world」は、組み込みプラットフォームでの「書き込み」に4日かかる場合があります(ツールをインストールし、プラットフォームを準備します。

チームが目標にかかる時間の決定を終えたら、実際にかかる時間を測定するか(おそらく提案された目標ではなく、現実の類似した目標の場合)、非常に類似した目標を持つ以前のプロジェクトを思い出します。見積もりと実際の見積もりを比較します。見積もりと実際の誤差を大げさに誇張し、すべての結論を公開します。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.