ソフトウェアエンジニアに時間の追跡を促す
同僚に問題の解決と機能の実装に費やす時間を追跡するように促すにはどうすればよいですか？これを行うソフトウェアはありますが、数字を入力しないだけです。
過去の見積もりと実際に費やした時間を比較することで、チームにプロジェクトの見積もりを提供してもらいたいです。私の同僚は、プロジェクトのスケジュール設定に頻繁に関与していないため、個人的なメリットを認識していないと思います。
私の同僚は、プロジェクトのスケジュール設定にはあまり関わっていないため、個人的なメリットを認識していないと思います。
それは修正可能です。
それらをスケジューリングに関与させます。
Joel Spolskyが Evidence Based Scheduling についての記事を書きました。これは、いくつかの議論を見つけるのに役立ちます。
より良い見積もりスキルが彼らがより良いソフトウェアを生み出すのを助けることができることをあなたの同僚に納得させなければなりません。タスク時間の追跡に有利ないくつかのポイントを次に示します。
- 任意の管理設定期限がある場合、適切な見積もりは、その時間に実際に何を達成できるかを示します。おまけとして、何を話しているのかわかっていることをマネージャーに納得させる素敵なグラフがいくつかあります。
- プロジェクト全体をより慎重に検討する必要があります。私がリンクした記事は、「時間で測定できる非常に小さなタスクにスケジュールを分割する必要がある」と述べています。プロジェクトのほとんどすべての側面について考えたので（うまくいけば spec ！と書く）、思いもしなかったことに驚くことはほとんどありません。
- それはあなたをより良い開発者にします。時間の経過とともに過小評価する傾向のあるタスクの種類がわかるので、盲目的に最適化するのではなく、これらの特定のタスクを改善することに少し時間を費やすことができます。
ニンジンとスティック-標準的な方法でこれを達成できます。
この場合のニンジンは、「現在の速度を理解することによって改善された将来の推定」である可能性があります-しかし、あなたはフォロースルーする必要があります。
彼らがプロジェクトのスケジューリングに頻繁に関与していないというあなたのコメントは、これを売り難くするかもしれません。
特に [〜＃〜] psp [〜＃〜] のフォロワーがいる場合、それらの中で最も高機能なのは、彼らがより良くなるのを助けることです。
最も一般的なスティック（ニンジンを前で押さないで叩く）は「必須です、それを行う」です。やる気はそれほどありませんが、少なくとも位置は明確です。
最後に、あなたが使用しているソフトウェアは彼らの無口に貢献していますか？不格好ですか？システムAでタイムコードを調べてから、システムBで時間を調べる必要がありますか？それは細かすぎますか、それは「オフ」時間を考慮せず、1日あたり8時間の計算を要求しますか。採用を助けるために、できるだけ摩擦のない状態にします。
幸運を
私の経験では、ほとんどの時間追跡ソフトウェアの問題は次のとおりです。
- 開発者には、タスクをその場でより簡単に推定できるサブタスクに分解する能力や権限がありません。
- 何かに取り掛かるまで知らなかったサブタスクを説明する良い方法はありません。ソフトウェア開発とデバッグでは、常に状況が発生します。
- 費やされた時間は、実際にどれだけ集中して作業に費やされたか、会議、同僚の質問、ピアレビュー、その他のオーバーヘッドにどれだけ費やされたかを正確に思い出すことが困難な場合に入力されます。
- 追跡されていないタスクを説明する良い方法はありません。 1日の終わりに、そのうちの6人が会議などの処理に費やしていたとしても、8時間は休むでしょうか。
- 見積もりの不確実性を説明し、伝えるための良い方法はありません。
私は自分のためにポモドーロ技法を使い始めることによって、これらの問題の多くに対処しました。タスクを25分間中断せずに行うと、その時点で記録され、私の中断は中断されていない間隔で計算されます。エビデンスベースのスケジューリングを組み込んで不確実性を伝え、自分の細かい追跡をPMが好む粗いスケジュールの見積もりに変換する作業を続けていますが、これまでのところ確実に改善されています。
良い方法
たとえばMylynなどのソフトウェアを使用すると、実際にそれが簡単かつほぼ透過的になります。たとえば、1時間のバーンダウンチャートなどのツールと組み合わせます。
悪い方法
プロジェクト、タスク、正確な日付と時刻などを手動で指定する必要がある退屈なタイムシートを入力するように強制します。
あなたがチームリード/ PMでない場合は、これに苦労することになります。どうしても必要な場合よりも多くの仕事をする必要がある場合、人々は同僚の話を聞くのを嫌います（とにかく私の経験では）。チームリーダーまたはPMと一緒にそれを取り上げてみてください。彼らがあなたのケースに同意する場合、おそらく時間のロギングを必須にすることができます（これが私が現在働いているところです）。
チームリーダーまたはPMの場合は、より強力に自分の役割を演じる必要があります。これらの人々は、あなたが彼らに伝えることを（効果的に）行うためにそこにいます、そしてあなたの仕事をするためにより多くの情報が必要な場合は、彼らにそれを提供させる必要があります。情報。彼らがあなたが情報を得るのを手伝う気がない場合、それはおそらく彼らがなぜそれが有用であるかを理解していないためです、あなたのプロジェクトがどのようにしばしば予定外になったか、過大評価されたか、何が、なぜそれが引き起こしているのか説明するために彼らと話してみてくださいあなたの問題、あなたがそれらを好転させることができるかどうか見てください！
あなたの時間を追跡するか、支払いを受けないでください。何百万もの人々がそれをします（コンサルタント、弁護士など）、なぜ彼らはできないのですか？
これはかなり厳しいと思うかもしれませんが、そうではありません。あなたがスターバックスで働いているなら、あなたはバスルームを掃除する必要があります。銀行で働いている場合、スーツを着て仕事に結びつきます毎日、そしてあなたが時間を追跡する必要があるチームのソフトウェアエンジニアである場合あなたやる！
時々、嫌いな仕事をしなければならないことがあります。私たちは皆、大きな男の子と女の子です。私たちはそれを処理できるはずです。
明らかに、最良の答えは、チームの心理的なブレンドに完全に依存します。彼らは競争力がありますか？システムに時間を入力したことで受賞者に報酬を与える定期的なコンテストを設計します。コンテストを調整して調整し、プレーヤーが公正で楽しいと思うようにします。ゲームにしましょう。
おそらく彼らは、彼らが実際にタスクの実行に費やした時間に透明性があった場合、マイナスの結果が生じることを懸念しています。匿名で、バケットのレベルが十分に高く、複数の個人が各バケットに費やした労力を注いで、個々の貢献者を特定できないような「努力追跡ツール」を設計することについて、私はいつも疑問に思っていました。高レベルのプロジェクトバケットのより正確な労力コストを取得するだけでも、プロジェクト計画とチーム全体の速度にとって有用なデータになる可能性がありますが、これは「OMG、ジョーが3倍の見積もりをして非常に単純なことをしたとは信じられません。 」とか、人々が伝統的な時間追跡システムで報告することを恐れているということではありません。
これらは2つの例にすぎないと思いますが、実際には、チームの心理的な構成をよく理解することで、インセンティブを与える方法や、努力コスト情報への貢献を奨励する方法について正しい答えが得られます。
理由について考えてみてください。彼らがこのリクエストにうまく応答しない可能性があります。彼らが怠惰だとか、努力を回避していると思い込まないでください。
証拠の作成を回避する開発者は通常、
- それがどのように使用されるのか、および/または心配
- データの有効性が心配
これが ポイントベースの推定とシャツのサイズ が近年始まった理由です。これは、推定プロセスの非常に不確実な性質を考慮に入れ、「マジック」（別名、不確実性からの平均化）がスケジューリングを制御できるようにします。
そして、それは論理的に見えないかもしれませんが、それはほとんど機能します-少なくとも時間ベースまたは日ベースのシステムと同様に。また、任意の方法で行われた場合、チームまたは個人が1か月で達成したことを頭の周りに当てることは非常に困難です。
スクラムを使用すると、開発者は速度を制御することもできます。つまり、A、B、C、またはA、Y、Zから選択したものは何でも達成することを約束します。その約束をした後、開発者は失敗したくありません。しかし、あなたが彼らのためにその約束をするなら、彼らは気にしないでしょう。それが間違っているならそれはあなたのせいです。
そのように再推定を使用しないとおっしゃっていたとのことですが、チームの個人はどの程度確信していますか？
プログラマーがプログラミングからさらに多くの時間を費やす必要があるツールは、必ずしも素晴らしいものではありません。プログラマーはすでに多くのオーバーヘッドを抱えており、5分間のミーティングを行ってから、嵐をコーディングすることはありません。
あなたが力を持っているなら、あなたは彼らにそれを強制することができます。しかし、断然最良のソリューションは、シームレスなツールを構築して痛みをなくすことです。設計のためにそれを行う方法を説明することはできませんが、コーディングのために、開発環境で行われた変更をログに記録する必要があります。これは非常に高いバーでしたが、Eclipseのようなものを使用している場合、それほど悪くはありません。おそらくすでに存在しています。このようにして、各ファイル、および場合によってはJavaで各メソッドに費やされている時間を測定できます。これは、請求を依頼するよりもはるかに詳細な情報であり、かなり正確な場合があります。
同様に、デザインを入力するためのツールがあれば、そこで傍受することができます。
数字を入力するように説得する代わりに、簡単に機能するソフトウェアを使用します。 ScreenAwareを使用しています： https://www.screenaware.com/en/ 時間を自動的に追跡し、それぞれのプロジェクトに割り当てます。だからそれは常に正確で、誰ももう推測する必要はありません
どのようにそしてなぜあなたが彼らに時間を追跡させて欲しいかに依存します、また私達は単にオフィスでの時間を数えているのですか、それとも問題について考えて通勤するのに費やされた時間も数えているのですか？
プロジェクトのスケジューリングは困難であり、得られるメトリックは、思ったほど有用ではない可能性があります。 2つの問題が同じではないため、1つのタスクが8時間かかり、別のタスクが完了するまで32時間かかる場合があります。
開発者がタスクにかかる時間を推定し、その推定がどれだけ優れているかに基づいて時間とともに調整するため、証拠に基づいたスケジューリングを検討することをお勧めします。ただし、すべてのタスクを事前に把握していない可能性があるため、大規模なプロジェクトには適していません。大規模なプロジェクトの場合は、個々の見積もりを集計するのではなく、同様の範囲の過去のプロジェクトを見て、それらを尺度として使用した方がよい場合があります。
ポモドーロテクニック のような個人の組織システムにそれらを導入してみてください（他にもたくさんありますが、それは私が今試みているものです）
この手法では、タイマーを使用して、作業時間を「ポモドリ」と呼ばれる25分間隔（イタリア語の「トマト」から）で区切り、短い休憩で区切ります。この手法は、ソフトウェア設計で使用されるタイムボックス化や反復的および段階的開発などの概念に密接に関連しており、ペアプログラミングのコンテキストで採用されています。この方法は、頻繁に休憩することで精神的な敏捷性が向上するという考えに基づいています。