私が言いたいのは、プログラミングプロジェクトの見積もりを可能な限りタスクに分割している場合、タスクを作成するのに十分な最大値があるということです。つまり、最大値が4〜6であると言えば、タスクがそれよりも長い場合は、より多くのタスクに分割する必要があります。でも、これがあまり役に立たなくなるポイントがある気がしますし、最大10〜12時間は許容できると思いますが、上司は同意しません。ここでの考え方は、タスクを完了するのにどれだけの時間が必要かをできるだけ知ることができるようにすることですが、同時に、実際にコードに飛び込むまで、あまりにも多くの内訳が無意味になるポイントがあると思います。何か考えや一般的な慣習はありますか?
4 に答える
タスクの時間内訳を自分で書いていたとき、1つのタスクの目標として最も有用な数値を約4時間で最大化することに気づきました。そして、それが本当に難しく、予想以上に時間がかかったとしても、それほどひどいことではありませんでした。
次の場合を除いて、これらのプロジェクトを実際に意味のあるものとして保持することは有用ではないと思います。1.)タスクを実行する人がプロジェクションを作成しました。2.)投影を作成する人は、作業に十分精通しています。
私の最後の仕事では、私は3か月間そこにいるまで、タスクの投影を開始しませんでした。その後、私の予測が意味を持つようになるまで、もう1、2か月かかりました。
これはとても個性的なことだと思います。非常に詳細なレベルで物事を考えることに慣れている場合は、小さなタスクをたくさん持つ方が理にかなっています。より一般的な言葉で物事を考えるのが好きなら、いくつかの大きなタスクを持つことは理にかなっています。あなたとあなたの上司がこの種の個人的な好みをタスクの予測に強制しようとすると、あなたの予測はせいぜい無意味であり、最悪の場合は敵意の創造者であることがわかるでしょう。
私の経験とその表現があなたのお役に立てば幸いです。
-ブライアンJ.スティナー-
適切な見積もりができるように内訳構造を十分に詳細にしますが、あまり詳細ではないため、後で状況が変化したとき(状況が変化した場合ではなく、状況が変化した場合)にそれを維持および追跡するのに問題が発生します。
WBSのタスクが見積もられる時間数は実際には重要ではありません。
タスクはどのように見えますか?
ドキュメントを書きますか?ドキュメントの章を書きますか?文書に文章を書きますか?
プログラムを書きますか?クラスを書きますか?メソッドを書きますか?
私は次のことが真実である必要があると思います:
1)。タスクは十分に大きいので、タスクが完了したことがわかります。単一の文またはメソッドは独立していません。通常、これほど小さなものを単独で配信することはできず、受信者はそれを「テスト」できません。
したがって、たとえば、タスクであるSCMにいくつかのコードを単体テスト、文書化、およびチェックインすることができます。
1時間未満のタスクは想像できません。通常、私にとっては半日です。
2)。タスクは十分に小さいので、推定時間内に実行できると確信できます。チャンクを理解するのに十分なほど問題を分析しました。
人は機械ではありません。
そうは言っても、私が見ているように、2つの主要な開発モードがあります。
- 発展させる
- 維持/修正
2つ目は、タスクにかかる時間の経験を積むことができます。開発者はコードを知っており、ほとんどの場合、何が間違っているのか、それを機能させるために何をすべきかを適切に予測できます(この場合は厳密な監視+開発者が適切な見積もりを得ることができない場合、良好な協力を得続けるためのバッファが必要です-これは非常に大きな問題の兆候です)
最初のものについては-それはより複雑です:
これが大変な労力の仕事である場合-頭脳を必要とせず、プログラムをポイントaからポイントbまで実行するだけで...タイトなスケジュールを定義できます。
開発者が創造性を発揮したり、優れた実装について考えたりする必要がある場合...傑作を永遠に待つことはできませんが、生き残るための考えしか持たない開発者からは多くを得ることができません:)
チームリーダーと開発者が一緒に目標を設定するアジャイルについて学びます。目標は非常に厳しいかもしれませんが、開発期間内に、マネージャーと同じくらい責任があると感じる開発者は...自分の時間を管理できます。
したがって、適切な管理システムを使用すると、タスクの長さが1週間になる場合があり、おそらくそうなるはずです。
マジックナンバーはありません。プログラミングの種類を理解し、適切な管理管理システムを見つけてください。
幸運を