問題タブ [project-management]

.netテクノロジープロジェクト管理に参加することを考えています

私はPHPプロジェクトで多くの経験を積んでいます。既存のフレームワークとライブラリのほとんどを知っており、この知識に基づいて仕様とケーススタディを作成しました。

.netについて何を知っておくべきですか？テクノロジーをすばやく学び、後で最新の状態に保つことができるように、どのトップリソースを知っておくとよいですか？

編集（8.24.08）：これまでに得た答えは、基本的に優れたPMであることについて説明しています。ありがとう、でもこれは私が言ったことではありません。.netの必需品をいただければ幸いです。

Web アプリケーションをゼロから開発する場合、使いやすくインタラクションが豊富な製品を作成するために必要なスキルは何ですか?

• 最初に UI プロトタイプを作成しますか?
• ユーザーストーリーを使用していますか?
• 推奨または積極的に推奨するアジャイル手法またはベスト プラクティスはありますか?

要するに:要件の収集から AmazingWebApp™ への移行に必要なスキルは何ですか?

最後に：お勧めの本はありますか？

さまざまなプログラム マネージャーがさまざまな形式で仕様を記述しているのを見てきました。ほぼすべての人が、独自の仕様書の書き方を持っています。

一方では、プログラマーに与えられた冗長な文書は、プログラマーにいくつかの見落としを引き起こす可能性が高いものです。私は個人的に単語文書の仕様を恐れています...それは私の読書スタイルのせいだと思います...私はいつも物事を速読しているので、重要なポイントを見逃していると思います.

一方、クライアントの 1 人が Excel で作成した革新的な仕様書を目にしたことがあります。彼が仕様を作成するために使用した方法は、Excel でモック アプリケーションを作成し、VBA を使用してそれをモックするというものでした。彼は、ボタンをクリックしたときにフォームがどこに移動するか、またはどのアクションを実行する必要があるか（コメントで）などを行います。

データフォームでは、フォームをセルに表示し、各データ入力セルで、有効な値とは何か、どの検証を実行する必要があるかなどについてコメントします。

このテクニックを使えば、やらなければならないことを見逃す可能性が低くなったと思います。また、開発者の単体テストがはるかに簡単になりました。テスト担当者も、実際に作成する前に「実行」されたシステムをよりよく理解していました。

Visio も画面デザインを行うツールですが、VBA のサポートとその機能を考慮すると、Excel の方が優れていると思います。

これはより一般的な仕様書の書き方になるべきだと思いますか? プロジェクトマネージャー（または仕様を書いている人）の一部に少し余分な作業が必要であることは知っていますが、その見返りは大きいです...私自身、それを使用することで多くの生産性が向上することを確認できました. そして、実際にプログラマーに役立つ仕様のより良い形式があれば。

私たちは小規模 (20 名) ですが成長中のインターネット エージェンシーであり、オペレーション ディレクターを任命する時が来たと判断しました。運用上の重労働のほとんどは、Tech Director と 1 人のプロジェクト マネージャー (プロジェクト管理から製品開発に移行中) によって処理されています。

• 性格はどのタイプがいい？
• 彼らは技術的なバックグラウンドを持っている必要があります (プログラマーとして? システム管理者として?)
• 年齢は重要ですか？30歳以上の人を探すべきですか？
• 誰かが運用の神/女神であることを示す特定の種類の趣味、環境、その他の外部指標はありますか?

最近、「プロジェクトの失敗」について上司とちょっとした議論をしました。3年後、コードベースを新しいプラットフォームに移行するプロジェクト（1.5年間行っていたプロジェクトですが、チームリーダーは数か月しかいませんでした）が稼働しました。彼は、私の会社とクライアントの両方の上級管理職（私はあなたがよく耳にする神々しいコンサルタントの一人です。私の関与は「アプリケーションアウトソーシング」です）とともに、プロジェクトが成功したと宣言しました。私が見つけた古いプレゼンテーションでは、元のスケジュールと比較して、展開の遅延は数か月で測定するのが最適であり、数年で測定できる可能性があることを示していることに同意しませんでした。プロジェクトの失敗について私が知っていることと、失敗率の背後にある研究と統計について説明しました。彼は、それはすべて学界であり、彼が主導したプロジェクトは失敗しなかったと答えました。

このようなコンサルティングは他のプロジェクトとは異なるかもしれませんが、時間通り、予算内、または完全な機能で提供できなかったという汚名を避けるために、これはより美しい名前に包まれた失敗のようです。私の会社が最大の予算内でプロジェクトを完了するために無料で何時間もの仕事を与えたと彼が説明したという事実は多くを語っています。

だから私はあなたにこれを尋ねます：

• 変更管理とは何ですか？それはプロジェクトにどのように適用されますか？
• 「変更管理」はどこで終わり、「プロジェクトの失敗」はどこから始まりますか？

---

@ shog9：
特にこの場合、私はコンサルタントを代表しているので、私はコンサルタントとの非難ゲームについて質問していませんでした。必要な機能が最終的に実装されたかどうかに関係なく、プロジェクトが「失敗」したと見なされる時期についての見解を探していました。
「これは実際には私たちが思っていたよりも少し複雑で、もう1週間になるでしょう」と、「プロジェクトの失敗」との違いを探しています。ただし、失敗を定義したいと思います。違いもありますか？このマイナーレベルのスケジュールのずれは、統計的な「プロジェクトの失敗」を構成しますか？

私は現在、非常に大きなライブラリに取り組んでいます（500万行のコード、VS2005のC ++、1つのソリューション、100近くのプロジェクト）。コンパイルを配布し、増分リンクを使用しますが、ソースの小さな変更後の再コンパイルと再リンクには、数分（通常は少なくとも3分）から1時間近くかかります。

これは、コード/ビルド/デバッグの変更サイクルが非常に長くなる傾向があり（私の好みです！）、ビルド中に「フロー」を失うのは非常に簡単です。通常、有用なことを行う時間はあまりありません（おそらく少しの電子メール、そうでなければオンラインでいくつかの記事または本の数ページを読んでください）。

新しいコードを書いたり、主要なリファクタリングを行ったりするときは、一度に1つのファイルだけをコンパイルしようとします。しかし、たとえばデバッグ中は、本当に神経質になります。

どうすれば時間を最適化できるのでしょうか。私はその状況で私だけではないと思います：あなたは何をしますか/しますか？

ネットワーク上の .mpp ファイルからデータを抽出し、それをいくつかの異なるデータベースの他のデータと組み合わせる必要があります。アプリケーションは、Perl、VB6、VB.net、または C# で記述できますが、Windows ベースのサーバーから簡単にスケジュールする必要があります。

ユーザーの介入なしで MS Project データを抽出するには、何をお勧めしますか?

MS Project で使用できる ODBC ドライバーはありますか?

.mpp を開いてアクティビティ データを読み取るためのモジュール (Perl、VB、VB.net、または C# 用) はありますか?

プロジェクトマネージャーは、プロジェクトが期限に間に合うように時間を整理する必要があります。

開発にかかる時間を見積もるために使用するある種の方程式はありますか？

データベースとしましょう

time = sql storedprocedures * tables manipulated or something similar

それとも、適切な見積もりを取得するために経験を積む必要があるだけで立ち往生していますか？

スプリントのチーム ベロシティを計算するためのアドバイスが必要です。

私たちのチームは通常、約 4 人の開発者と 2 人のテスターで構成されています。スクラム マスターは、すべてのチーム メンバーがベロシティの計算に平等に貢献する必要があると主張しています。つまり、スプリントでどれだけのことができるかを計算するときに、開発者とテスターを区別してはなりません。スクラムによると正しいですが、ここに問題があります。

反対の提案にもかかわらず、テスターはテスト以外のタスクを手伝うことはなく、開発者は開発以外のタスクを手伝うことは決してありません。また、さまざまな提案にもかかわらず、テスターは通常、各スプリントの最初の数日間、何かをテストするのを待っています。

その結果、通常、スプリントで実際に処理できる能力よりもはるかに多くの開発作業を引き受けることになります。たとえば、開発者はベロシティの計算に 20 日間、テスターは 10 日間貢献する場合があります。ただし、スプリント計画の後にタスクを合計すると、開発タスクは最大 25 日、テスト タスクは最大 5 日になります。

皆さんは、このような状況にどのように対処していますか？

プロジェクトの時間を見積もる (または他の誰かの見積もりを確認する) 必要があるたびに、アルファ版と製品版のリリースの間に行われるテスト/バグ修正に時間が割り当てられます。私は、サイズが未知の一連の問題に関してこれまでのところ未来を見積もることが、成功する見積のための良いレシピではないことをよく知っています. ただし、さまざまな理由から、定義された時間数がこの作業セグメントの最初に必ず割り当てられます。そして、この最初の見積もりが実際の最終的な値から遠ざかるほど、デバッグに関与する人々は、後で見積もりを「超えた」ときに、より多くの悲しみを抱かなければならなくなります。

私の質問は次のとおりです。このような見積もりを行うことに関して、あなたが見た中で最善の戦略は何ですか? 全体的な開発見積もりの​​均一なパーセンテージ? 時間数を設定しますか (それが上がることを期待して)? 他の何か？

他に考慮すべき点: クライアントが (内部 QA ではなく) テストの責任を負い、クライアントが見つけるかどうかわからないバグに対応するための時間を割り当てる必要がある場合、これにどのように別の回答をしますか?テストではなくバグ修正にかかる時間の見積もりを把握するため)