2

私はインドに拠点を置く大規模なアウトソーシング会社で働いています。私は米国にいて、3 人の開発者のチームを持っています。私たちはスクラム プラクティスを使用しており、私たちのアプローチで大きな成功を収めています。

私の問題は、私たちの会社では、毎週の繰り返しに取り組んでいるのに対し、毎月の活動時間を見積もることを要求していることです。システムは、45 のアクティビティのリストを提供します。例として、コーディング、コーディング レビュー、コーディング リワークなどがあります。

現在、毎日、これらの活動に対して実際の時間を入力することになっています。さらに悪いことに、時間追跡システムの設計は非常に貧弱で、非常に遅いです。

経営陣がこのプロセスの背後にある理論的根拠は、将来の作業を予測するために記録されたこの時間を使用したいということです。しかし問題は、正確な時刻を確実に入力するためのプロセスが整っていないことです。そのため、任意の数字と 1 日の終わりを入力することになります。

これはチームの生産性と士気に影響を与え、目的全体を台無しにしています。

アジャイル プロジェクトでのタイム トラッキングについてどう思いますか?

4

6 に答える 6

5

アジャイル プロジェクトのタイム トラッキングについてどう思いますか?

100% 無駄: あなたにこれをするように頼むとき、あなたのマネージャーは実際にはコードに取り組むことを妨げています。したがって、これは実際には 200% の無駄に近いように見えます)。これは時代遅れのコマンド アンド コントロールのように思えます。これはスクラムマスターが障害として処理する必要があります。

于 2010-02-10T06:34:56.467 に答える
2

これをスクラムマスターに差し迫ったものとして必ず取り上げ、ふりかえりでも取り上げてください。

あなたはそれと一緒に暮らす必要があるかもしれないので、2つのアプローチを提案させてください:

  1. できるだけ正確に、一日の終わりに見積もりを出してください。
  2. 不格好なレポート システムのフロント エンドを作成します。使いやすく時間の節約になるインターフェイスを考え出し、それを記述して、不格好な古いシステムにフィードさせます。
于 2010-02-10T06:37:05.513 に答える
1

ROWEで働いていない限り、給料を払っている人がどこでお金を使ったかがわかるように、時間をどこかに記録する必要があります。これがどれほど有用で、どれだけ使用できるかは、永遠に議論される可能性があります. 証拠に基づいたスケジューリングは、あなたの経営陣が持っているアイデアかもしれません。

繰り返しと計画が一致するように、経営陣がここでいくつかの中間タイムラインに同意するかどうかを確認したくなります. 3 ～ 4 週間先の計画を立てようとする際の問題は、次の 1 ～ 2 週間で起こることが劇的に影響する可能性があることです。私の提案は、一度にほぼ半月が計画されるように、2 週間のタイムラインで合意できるかどうかを確認することです。少し妥協していますが、毎月のデータが入るシステムが隔週で何かを受け入れることを前提としています。別の方法は、毎月の反復を行うことですが、それは私が想像する大変動を引き起こす可能性があります。

時間の追跡は、信頼と誠実さがあり、ほとんどの人が情報を尊重している場合に役立ちます。多くの人がそのようなシステムによってやけどを負ったと想像するので、これは多くの質問になる可能性があります。経営陣は、時間追跡の遅さと設計の悪さを認識していますか? たとえば、常にログを記録するのに 1 日 1 時間かかっていて、その理由を説明できる場合は、より良いシステムを入手できる可能性があります。ここでの重要なポイントは、具体的に何が問題なのか、なぜ問題なのか、どのような提案ができるのかを知ることです。管理には最適ではないかもしれませんが、これの一部はトレードオフを受け入れることです.IMO.

于 2010-02-10T16:59:38.190 に答える
0

タイムトラッキングは、おそらく少し細かすぎるか、エントリが硬すぎるように聞こえます。1日の終わりに各カテゴリの時間を入力する代わりに、その日の間に現在行っていることを記入できるログを保持するように求められた場合はどうなりますか？：

8:30 am-9:45am：コーディング9:45 am-10：00am：コーディングレビュー

等。

于 2010-02-10T06:28:25.490 に答える
0

私は正式なテストクラスに参加していましたが、講師は学生の 1 人にタイムシートを使用して時間を追跡するよう説得するのに非常に苦労していました。これは、ソフトウェア エンジニアリング/プロジェクト管理の理論全体がタイムシートに基づいて線形予測を行うためです。問題は、現実が非線形であることです (プロジェクトのボラティリティのレベルによって異なります)。スクラムのようなアジャイル プロセスは、プロセスではなく人に焦点を当てていますが、人とビジネスはどうですか。追跡時間が顧客への請求に使用されていると述べたためです。時間を追跡することの問題は、人を傷つける可能性があることです。たとえば、タスクを見積もって 10 日で実行し、次に同様のタスクを実行し、10 日後に何らかの予期しない理由で実行できなくなった場合、スクラム マスターや PO でさえ、不足しているという感覚を理解して共有することができます。締め切り（完全にあなたのせいではありません）... しかし、そのレイヤーの背後にいる他の人、トップマネージャー、他のプロジェクトマネージャー、他の開発者はどうですか...彼らはあなたのパフォーマンスに問題があったと誤解するかもしれません....開発者の背後で完全に行い、そのデータを使用して根本原因を分析し、チームがそこから学ぶためのフィードバックを提供します。トリッキーな部分は、グーグルが彼らの派手なスタイルの場所であると言われている場所を除いて、これをうまく行うことができる職場をまだ見つけることができない人々に悪い印象を与えずに行うことです. したがって、開発者の背後で完全に追跡する方法があれば、時間の追跡は問題ありません。そのデータを使用して根本原因とフィードバックを分析し、チームがそこから学ぶことができます。トリッキーな部分は、グーグルが彼らの派手なスタイルの場所であると言われている場所を除いて、これをうまく行うことができる職場をまだ見つけることができない人々に悪い印象を与えずに行うことです. したがって、開発者の背後で完全に追跡する方法があれば、時間の追跡は問題ありません。そのデータを使用して根本原因とフィードバックを分析し、チームがそこから学ぶことができます。トリッキーな部分は、グーグルが彼らの派手なスタイルの場所であると言われている場所を除いて、これをうまく行うことができる職場をまだ見つけることができない人々に悪い印象を与えずに行うことです.

于 2013-06-26T16:32:45.853 に答える
0

これは大変なことです。問題は、使用された時間が将来の作業を予測しないことです。これは十分に文書化されており、多くの人が陥る危険な罠です。ベロシティは将来の作業を予測するのに役立ちますが、設計上、時間はわかりにくくなります。

このアプローチの問題点は次のとおりです。すべての時間が同じというわけではありません。時間をキャプチャすることで、作業が「理想的な」時間に変わります。将来の仕事は、その仕事をしているチームではなく (2 つとして同じチームはありません)、それらの時間を使って何らかのアルゴリズムを考え出した経営陣によって見積もられます。おなじみですか？スクラムでもアジャイルでもありません。経営陣はスクラムのプロセスを理解しておらず、それに賛成していません。

その混乱は良くありません。クライアントは、あなたが提供していないものを提供していると信じ込み、チーム メンバーは誤った思い込みで働き、経営陣はあなたが本当に必要としているサポートを提供できません。

したがって、何時間何を書き留めたかは問題ではありません...おそらく、プロセスはアジャイルではないアプローチに戻ります。これは、時間を作ってランダムに報告するのと同じくらい統計的に正確です。ばかげているように聞こえるかもしれませんが、時間を節約して、時間を稼ぐこともできます。

さて、面接にどれだけの時間を費やしたかを知るために時間を使えば、追跡システムがなくても簡単に測定できます。

時間が請求に使用される場合、それは別の話です。それはスクラム関連ではなく、ビジネス プロセスの一部です。

于 2010-10-13T04:31:19.433 に答える