複数のタスクに費やされた時間をどのように記録する必要がありますか？
証拠ベースのスケジューリングに関するJoelのブログ 彼は、最小の作業単位に基づいて見積もりを行い、余分な作業を元のタスクに記録することを提案しています。
私が今経験している問題は、オブジェクトBを作成し、上記のすべてをテストするサブタスクメソッドAを使用してオブジェクトAを作成することです。
これらのそれぞれについてタスクを作成し、見積もりは大丈夫だと思われます（練習が必要です）が、ログ作業に行くと、方法Aを微調整してバグを見つけたため、一度に4つのタスクに取り組んだことがわかりました。オブジェクトBをコーディングしながら、すべてテストしてリファクタリングします。
この作業をログに記録するにはどうすればよいですか？たとえば、1日8時間で取り組んだ4つのタスクのそれぞれに2時間を費やしたと言うべきでしょうか。
それはあなたがあなたの仕事を組織している方法のせいではないのだろうか。私が読んでいるように、あなたはコードのレベルでタスクを作成しています。つまり、クラスAのタスク、およびおそらくメソッドB、Cのサブタスクです。
より高いレベルの抽象化（つまり、ユースケース/機能的動作/ユースストーリーレベル）でタスクを設定してみてください。 1つの結果を達成するためにコードの4つの領域を変更する必要がある場合、それは1つのタスクです。また、技術的なアプローチを変更するときに、タスクを「リファクタリング」する必要がなくなります。
SDLCアプローチに応じて、これらのタスクレベルが正しくサイズ設定されていることを確認する必要があります（通常、アプローチの俊敏性が高いほど、サイズは小さくなります）。
私は証拠に基づくスケジューリングに精通していませんが、あなたのタスクは小さすぎるようです。タスクをより包括的にするように努める必要があります。 Joelの投稿の例の1つは「サブルーチンfooを書く」ですが、それは小さすぎると思います。タスクが目に見える成果物であり、サブタスクがその一部である場合、私はよりうまく機能することがわかります。例として、タスクは出力ファイルの欠陥を修正することであるかもしれません、そしてこの欠陥は欠陥追跡システムに入力されます。私のサブタスクは、コードを確認し（特に、コードに慣れていない場合）、テストケースを作成して欠陥を確認し（そして修正されたことを確認するのに役立ちます）、修正を適用し、ドキュメントを更新し、スモークテストを実行することです。変更をプッシュする前に、システムに他の欠陥がないことを確認してください。
また、一度に1つのタスクに集中することをお勧めします。他にやるべきことがある場合は、一時停止して書き留め（またはバグトラッカーに欠陥を入力するか、// TODOコメントを追加するか...）、実行していたことを再開します。現在のタスクが終了したら、新しく見つかったタスクに優先順位を付け、チームのプロセスごとに追跡されていることを確認し、その仕事を行うのに最適な人がタスクを実行していることを確認します。
この種のことを行うには、いくつかの方法があります。以前に取り組んだことで問題を見つけた場合は、次のことができます。
- 作業中のタスクの一部として問題を修正します。依存関係をリファクタリングして、現在のタスクが正常に完了するようにします。
- バグをログに記録し、問題追跡システムで修正するための見積もりを提供します。次に、タスクに優先順位を付けて、
- 最初に依存タスクを完了するか、または
- エラーを示すテストで現在のタスクを完了してから、ログに記録したバグを修正し、完了したら、両方のケースでテストに合格するのを待ってから、すべてをチェックインします。
個人的には、他の問題を修正するときにエラーを残すことには賛成しません。バグが新しく、依存関係にある場合は、作業中のタスクの一部として問題を修正するだけです。タスクが完了すると、タスクは完了します。バグがある場合は、バグがあります。テストでこの状況が回避されることを願っていますが、それでもテストに合格する場合は、前のタスクを終了して閉じ、そのままにしておく必要があります。
タスクを非常にきめ細かくした場合は、最初に依存関係アイテムを処理したことを確認する必要があります。共通の依存関係を持つ2つのタスクがある場合、次のタスクに移動するときに使用できるように、1つのタスクで依存関係を完了することができます。したがって、タスクを効果的に完了することで、2つのタスク間を行き来することを心配する必要がなくなります。これは、バグをログに記録する場合、またはその時点で作業している可能性のあるものの必要な部分としてバグを修正する場合にすぎません。
はい、これはすべてあなたの見積もりを台無しにする可能性がありますが、これが頻繁に発生するものであり、エビデンスベースのスケジューリングを使用している場合は、しばらくすると見積もりはすべて（統計的に）うまくいくので、あまり心配する必要はありませんそれについて。 :-)