私のプロジェクト（アジャイル）の進捗を雇用者（プログラマーではない）に報告する方法は？

雇用主に進捗を報告するのに問題があります。私はパートタイムプログラマで、学校の（非技術）部門のソフトウェアプロジェクトを担当しています。

担当者：
1.実際にソフトウェアを使用し、機能要求を提起するスタッフ
。2.私の上司（プログラマーではない）。彼女はソフトウェアのユーザーではありません。

プロジェクトの性質：
サードパーティから購入した既製のソフトウェアです。部門のニーズに応えるために、このソフトウェアの機能を変更または追加する必要があります。これは学期を通して使用する必要があるソフトウェアです。すべての機能を最初に使用する必要があるわけではありません。

そのため、アジャイルモデルを使用しています。スタッフが特定の機能を必要とするとき、リクエストを出し、変更を加えます。学期の終わりまでに、必要なすべての機能が引き上げられ、実装されると思います。

問題：
上司が進捗状況を尋ねるたびに、答える方法がわからないので、答えられません。すべての必要な機能の完全なリストがありません。先週提起された機能を完了しましたが、上司に「完了」したことを伝えることはできません。新しい機能も追加されており、その程度はわかりません。「％の完了率があります」や「xxxで完了します」とは言えません。3つのリクエストのうち、2を完了することができたので、上司に「2を完了しましたが、まだ完了していない機能が1つあります」と伝えます。長い時間を経て、「長い間、いつも終わらない何かがあります」と聞こえます。

進捗状況を報告できないことは、私にとって本当に悪いように見えます。それは私がどれだけやったかではなく、人々に知らせる方法です。私がマネージャーであり、私のスタッフが何ヶ月も進捗を報告し続けない場合、この男も能力がないと感じます。

「ソフトウェア変更のステータス/進捗状況」と同じくらい簡単に報告する方法、または質問に答える方法がありますか？

更新 私の上司は開発タスクに直接関与していないため、私が何をしているか、またはプログラムがどのように機能するかについて、手がかりがありません。彼女は忙しいので、定期的に会うことはありません。彼女はメインユーザーではなく、プログラムの詳細を知らないので時間の無駄になると思います。

私はソフトウェアを使用し、ソフトウェアについてよりよく知っているスタッフと定期的に会います。

上司に進捗を説明するのは難しいと感じています。

これは、あなたが独立して働くプログラマであり、技術的ではない誰かに報告する場合によくある問題です。

そのようなボスは、主にいくつかのことを理解できるようにしたいと考えています。

• ユーザーはどのくらい幸せですか？
• ユーザーがやりたいことはありますか？
• あなたが払っているお金に見合うだけのことをしていますか？

あなたが言ったように、あなたのボスは本当に忙しいので、彼らはそれについて学ぶ時間がなく、おそらくとにかくそれに興味がないでしょう。

もし私があなただったら、週に一度レポートをメールで送ります：

• 最初の「エグゼクティブサマリー」：「今週3つの機能を完了し、2つの新しい機能要求を受け取りました。今週の初めに、未完了の機能要求が11あり、最後に10がありました。」
• 3つのグループに分かれた、それぞれ短い文を含む機能ステータスリスト：
  1. 今週の間に行った機能
  2. 今週中に届いた機能リクエスト
  3. 「バックログ」の他の機能
• 複雑または異常なもの、好ましくは非技術的な言語を使用したものについての簡単な議論。

私があなたの上司であり、レポートを受け取っていなかった場合、毎週それを入手できてとてもうれしいです。そして、もし私が何か違うものが欲しいなら、私はあなたにそれを尋ねるでしょう。

完了したかどうか、または完了までの距離を知る方法がないように思えます。それは大丈夫です。

要求されている機能、実行されている機能、進行中の機能、開始されていない機能のリストを保持します。これらを各カテゴリの合計の週ごとのチャートとして追跡します。これにより、終了日まで推定できるポイントのセットが提供されます。それは（「完成した」機能カウントのみを見る）

• 週1-2完了
• 2週目-5週目完了（1週目から2週目、3週目から3週目）
• 週3-8
• 週4-12

16週間の場合、約48個の機能を完了することができます（一部の機能が他の機能よりも大きい/小さいことを心配する必要はありません。4〜5週間後には通常平均になります）。その後、X個の機能しか処理できないことを全員に報告できます。プロジェクトの最後で、最も重要なことは、必要な機能を提供し、過去2週間で自分自身を殺していないことです。この方法で報告することにより、できるだけ早く主要な要件を引き出すことができます。

報告するもう1つのことは、どのくらいのキャパシティがあるかです。「機能のリクエストは2つしかありませんでしたが、3つを処理できたはずです。もっと早く機能を上げるようスタッフに依頼できますか？」

私があなたの質問に完全に答えたのかどうかわからないので、フォローアップの質問をしてください。

3つの言葉...チャートを焼き尽くします。

あなたの雇用主は、彼らがアジャイル中毒者であろうと、開発者の責任者であろうと、燃え尽きるチャートに感謝します。

誰もがプロジェクトがいつ完了するかを理解するのが大好きで、昨日の天気を活用することで、プロジェクトの完了を予測する最も正確で最も現実的な方法が提供されます。

私はあなたが少なくとも週に1回1対1でやり、その時点であなたのマネージャーとあなたの優先事項について話し合うことができると仮定しています-彼/彼女の観点から重要なこと他の人など）-したがって、あなたのマネージャーが見栄えの良いものをどれだけ実行したか、あなたが持っているものの合計量を報告することができます。

あなたのマネージャーはおそらく分ごとの内訳を探していないでしょう。仕事が終わったかどうか、重要なことにもっと注意が向けられているかどうか、そしてあなたが先に進むのが妨げられているので、あなたが負荷にさらされたり、アイドル状態になったりしていないかどうかを確認しようとしているだけです。

真のアジャイルプロセスでは、常に何かが入ってくることに注意してください。しかし、あなたとマネージャーは、最も重要/最も必要なものと、それがどれだけ現在の作業期間に収まるか（1週間か、 2週間、1か月...）、必要に応じてジョブを小さなピースに分割し、ピースが期間に収まるようにします。

数週間かかる大規模なデータベースのオーバーホールは、バックアップの確立、バックアップの確認、新しいデータベースレイアウトの設計、変換ソフトウェアの作成とテスト、ロールバックの設定とテスト、変換の試行など、次のように分類できます。ステージングマシン、同じ場所でロールバックを試行し、最終的に変換を行います。それらのそれぞれは、おそらく1週間（またはそれ以下）のチャンクに分割できます。いくつかの手順に2週間または3週間かかる場合は、次の会議の進行状況を報告します（2週間で50％、3週間で33％など）。

理想的には、実行する必要があるものとこれから実行するものがあるチャートを用意し、進行中に「今すぐ実行」項目をチェックオフします。これにより、マネージャーはただ歩き回って、マークされているものとリストにあるものの数を確認できます。

毎週1回（例のために、アジャイルプロセスの反復/スプリントの長さは1週間であると想定しています）、次のようにします。

• スタッフに新しい作業をデモし、リクエストが完了したことを確認します
• その週に完了したリクエストの数を上司に報告し、それらのリクエストを特定/説明してください。短い要約を作成する
• 週にバックログ/キューに追加された新しいリクエストの数とリクエストの総数をボスに報告する
• 上司に、あなたが来週何をする予定か（どのリクエストをするか）を伝えます。言い換えれば、現在の優先順位。彼女がそれらを確認または変更する機会であり、あなた2人がそれについて明確にする機会です
• その後の1〜2週間の計画を上司に伝えます。

あなたの上司はベロシティ、プロダクトオーナー、バーンダウンチャートのようなアジャイル用語を気にしたり理解するのに十分な技術的ではないと感じます。上記のテンプレートはそのような専門用語を避け、一般的な意味で「バックログ」や「キュー」などの単純な単語を使用しているため、上司とのコミュニケーションが容易になります。

私は彼/彼女への主要な統計として速度を使用します。これは、特定の週（または他の期間）に話をするために「同意した」タスク/機能の数と、完了した数を示します。これから、実装するより重要な機能のいくつかと、これが過去の反復から変更された理由に言及します。また、遭遇してそれを超えた障害、および速度にどのように影響したかについて言及することもできます。

上司が知りたいその他の統計情報には、発生した新しいバグレポートの数、クローズされたバグレポート、送信された新しい機能リクエストが含まれます。直接尋ねるか、最善の判断を下して、どれが最も重要かを判断する必要があります。最後に、進歩の基本的な概要を説明し、彼または彼女が知りたいことは他にあるかどうかを尋ねます。上司が知りたいのは、あなたが進歩を遂げているということ、そしてあなたが最善を尽くすために必要なことは何でもあるということです。

週次レポートのコミットを提案する：要求された機能を一覧表示します。変更された機能を記録します。行ったことを報告します。

私は、マネージャーが理解できる方法で最終結果を出そうとします。

Total Recieved Feature Requests:
Requests Completed:
Requests since last Update:
Estimated Time to required to complete remaining Requests:

あなたのマネージャーがプログラマーではないからといって、それは彼らがあなたに正確な完了日を知ることを期待していることを意味するとは思わない。持っている番号を提示してください。マネージャが受信および完了したリクエストの数を確認した後、マネージャは進行状況を確認します。あなたのリクエスト数が手に負えなくなった場合、マネージャーは、あなたが過負荷になる前に優先順位をつけることで介入し、あなたを助けることができます。そして、あなたが仕事を尽くしている場合、彼らはあなたにいくつかの小さなサイドプロジェクトを見つけることができるかもしれません。結局のところ、終わりが見えないようで、仕事の日が早く過ぎて、忙しいときはもっとやりがいがあるように見えるとき、プロジェクトで少し休憩を取るのは常に素晴らしいことです。