7

私は多くのオフサイトの開発者や請負業者と仕事をしています。私は毎日彼らに、その日の仕事の状況を 5 分で簡単に送ってくれるように頼みます。クライアントに期末レポートを提出するために、個人のステータスをチームにまとめたり、1 週間のステータスをまとめたりする必要があります。

学びたい:
  • 達成された項目と、それぞれに費やされた時間
  • 発生した問題と、それぞれに費やされた時間
  • 次に取り組む項目とその見積もり(工数)と目標日
  • 仕事に関する質問
この情報を提供するフォーマットを探しています:
  • 開発者がすぐに完了するようにする (あまり考えずに 5 ~ 10 分)
  • 読みやすく、すばやく閲覧できます
  • 開発者ごとに統一

何を提案しますか?

4

5 に答える 5

4

あなたはおそらくこれを聞きたくないでしょうが、とにかくここにあります -

私はデスクの両側でこのような状況にあり、このようなロールアップされたステータス レポートは、あなたと開発者にとって完全に時間の無駄であるという結論に達しました。理由は次のとおりです。

  • 開発者は、指定された期限で機能/成果物に取り組む必要があります
  • 開発者は、問題が発生したときに質問する必要があります
  • 通信は必要に応じて双方向に流れる必要があります

これらのことが起こっていない場合、受動的な状況報告の量は、必然的に発生する問題を解決するつもりはありません.

フェンスの開発者側 - 「クイック 5 分ステータス」[私はそのフレーズが嫌いです。5 分は速くありません!] 開発者の流れを中断し、15 分 (またはそれ以上) の生産性の損失を引き起こします (joel はブログでさえこれは私が思う)。しかし、実際にはたった 5 分であっても、12 人の開発者がいる場合、管理にに 5 時間 (おそらく 20 時間)を無駄にしていることになります。

フェンスのマネージャー側では、個人のステータス レポートをプロジェクトごとにチームにまとめることなどは、非生産的な多忙な作業であり、時間も浪費します。誰もレポートを読んでいない可能性があります。

しかし、ここに本当の問題があります。この種のレポートとロールアップは、積極的な管理ではなく事後的な管理を示している可能性があります。言い換えれば、スクラム、XP、アジャイル、合理的、ウォーターフォール、自家製など、どの方法論が使用されているかは問題ではありませ。それは事前に計画されていました。そして、それがその日の朝に計画されていたのか、6 か月前に計画されていたのかは問題ではありません。

プロジェクトを管理するために日常的にこの情報が本当に必要な場合は、プロジェクトに深刻な問題が発生している可能性があります - 開発者に、次に何に取り組み、どれくらいの期間作業するかを毎日尋ねます。たとえば、実際の計画が事前に行われていないというヒントが得られます...

クライアントの要件に関しては、彼らがこの種の詳細を絶対に主張する場合 [そして、たとえば、一部の政府機関がそうしていることを私は知っています]、最良の選択肢は、Web インターフェイスまたはその他のアプリケーションを提供して、退屈な作業を自動化することです。あなたのためのロールアップ。あなたはまだ開発者の時間を無駄にしていますが、少なくともあなたの時間を無駄にすることはありません ;-)

ああ、あなたの質問に文字通り答えるために: 完璧なステータス レポートは、「プロジェクト計画の目標を達成している」と言うだけです ;-)

于 2008-10-03T02:23:45.613 に答える
2

スクラムを使用します。スプリント バックログを作成し、タスクを含むスプレッドシートと、スプリントの各日の列を用意します。毎日、各タスクにかかった時間を記入してもらいます。スプリントのバーンダウン チャートから始まる日次レポートを送信してから、メンバーごとに 2 つの 1 つのライナー (最後に作業したものと次に作業したもの) を短くします。バーンダウン チャート、各主要機能の赤/黄/緑のステータス (緑でない場合はブロックの問題とメモ)、およびスプリント バックログの残りの項目を含む週次レポートを送信します。

サンプルへのリンクはありませんが、ここにいくつかのドラフトがあります。

2008 年 10 月 2 日 - 製品 A の毎日のステータス

<バーンダウンチャート>

チームメンバーA
最後の 24: 機能 A
次の 24: 機能 A 単体テスト

チームメンバーB
ラスト 24: バグ刑務所
次の 24: 機能 B

チームメンバーC
ラスト 24: 機能 C
次の 24: 機能 C
ブロック対象: 依存関係 D - チーム D からの再配布をまだ待機中
2008 年 10 月 2 日 - 製品 A の週間ステータス

<バーンダウンチャート>

**機能 A** - 緑
[注: 赤/黄/緑はステータスを表します。より良い視覚化のために背景色も使用してください]
順調に

**機能 B** - 黄色
[注: 赤/黄/緑はステータスを表します。より良い視覚化のために背景色も使用してください]
バグ監獄のせいで 1 日ずるずる
軽減策: チーム メンバー A で単体テストの負荷を分散します

**機能 C** - 赤
[注: 赤/黄/緑はステータスを表します。より良い視覚化のために背景色も使用してください]
チーム D からの外部依存関係で機能がブロックされています。ブロック解除の ETA はありません。
軽減策: このスプリントの機能を削除することを検討してください

**マイルストーンのスケジュール:**
計画完了 - 9/15 (2 週間の計画)
コードの完成 - 10/15 (4 週間のコーディング)
RC - 10/30 (2 週間の安定化とテスト)
于 2008-10-03T00:00:54.817 に答える
0

データが返されると予想される形式でレイアウトされたテンプレートを提供するだけです.将来の仕事。誰かが 5 分で思いついた見積もりは信用できません。考えずに。

現在プロジェクト管理ソフトウェアを使用している場合、開発者が行ったことを記録して確認する (または単に覚えている) ことは簡単です。理想的には、彼らは 1 日を通して問題や質問を記録し、レポートに記入するためだけにそれらを考え出そうとするのではありません。

あなたの「学びたい」リストは、テンプレートを生成するための優れた出発点のようです。あなたにとって完璧なフォーマットが何であるかは、あなただけが知っています。

于 2008-10-02T23:59:58.127 に答える
0

エクストリーム プログラミングのスタンドアップ ミーティングをやりたいようですね。

http://www.extremeprogramming.org/rules/standupmeeting.html

スピーカー付きの電話または VOIP を使用して、オフサイトのチーム メンバーと話すことができます。

于 2008-10-03T00:03:45.577 に答える
0

一般的に、私はステータス レポートを提供する手段として電子メールに依存してきました。電子メールは単純さと完了の速さを提供しますが、何らかの統一性を強制するものではありません。

これを実現するためのオプションは多数ありますが、いずれもプロセスがより複雑になり、時間がかかるというリスクがあります。これらのいくつかは次のとおりです。

各シートのセクションを含むオンライン フォーム、または各シートがセクションである複数シートのスプレッドシート。

これらはすべて自分で作成するのに多少の努力が必要ですが、何らかの目的で統一が必要ですか? たとえば、要約レポートを自動化します。

これに代わる方法は、請負業者が作業中に記入し、いつでも報告できるプロジェクト管理ツールを使用することです。私はThoughtworks Studio Mingleをお勧めしますが、アジャイルのようなプロセスに依存しています.

于 2008-10-03T00:14:09.077 に答える