問題タブ [project-management]

他のベンダーの商用製品を使用してシステムに統合するプロジェクトがあります。問題は、特定のベンダーが非常に非協力的であり、電子メールの返信や電話の範囲まで工数を請求したいということです.

この種のベンダーにはどのように対処すればよいでしょうか。問題は、その製品をシステムに使用する必要があるため、サポートを受けなければならないことです。そうでなければ、オープン ソース製品に頼っていたでしょう。

私はHashRocketの Rescue Mission のアイデアを見たことがあります。これは、失敗した Rails 開発プロジェクト (タイムライン、予算、または他の何かが満たされないかどうか) に介入して回復するように設計されています。

他の人がこのサービスを PHP プロジェクトや Web 開発プロジェクト全般に提供しているのではないかと思っていました。

理想的には、仕様の形式化、プロジェクトを世に出すためのロードマップ、および必要に応じてコーディングに関与することです。

これらのような場所を知っている人はいますか？

開発チームが現在使用しているライフサイクルツールを置き換えることを検討しています。私が探しているツール：

• バージョン管理
• 欠陥/問題追跡
• 要件の追跡
• テストケース管理
• （潜在的に）プロジェクト管理：プロジェクトステータス、時間エントリ

すべてのツールを実行するための新しい強力なサーバー（Windows 2008 Server）があります。COTSとオープンソースのオプションを検討していますが、まだ決定していません。

その他の要因：

• 分散チーム（さまざまな物理サイト）
• 一部のWindows開発、一部のLinux開発
• ソフトウェア、ファームウェア、テクニカルライティングはそれを使用できる必要があります

一緒に機能する優れたスイートに関する推奨事項はありますか？
オープンソースの場合、Windows 2008 Serverで実行するための最良のアプローチは？

私はしばらくこの問題について考えてきましたが、安定した/エレガントなアイデアはまだ思いつきません。

MyISAM テーブルを使用すると、テーブル定義の更新時間を取得できますが、InnoDB ではそうではありません。.frm ファイルを見て、定義が変更された可能性がある時期を確認することさえ信頼できないことがわかりました.. .. データセットが変更されていても気にしないでください。

30 分ごとに mysqldump でスキーマの内容をダンプし、それを AWK スクリプトで分解し、それを最後のバージョンと比較するという考えがありましたが、それは少し過剰に思え、関連するデータセットが大きい場合は問題になる可能性があります.

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

• 達成された項目と、それぞれに費やされた時間
• 発生した問題と、それぞれに費やされた時間
• 次に取り組む項目とその見積もり（工数）と目標日
• 仕事に関する質問

• 開発者がすぐに完了するようにする (あまり考えずに 5 ～ 10 分)
• 読みやすく、すばやく閲覧できます
• 開発者ごとに統一

何を提案しますか？

ここでは私は例外かもしれませんが、3 人以上の開発者または 5 人以上のチームで働いたことはありません。それでも、なんとか仕事をやり遂げることができました（何とか）。

この「極端な」シナリオに適合するソフトウェア開発プロセスはありますか? また、スタンドアロンのプログラマーとして働いている場合、日常生活をより予測可能にし、一貫性を持たせ、文書化し、仕事を終わらせるために日常生活に適応できるものはありますか?

上層部が「ほら、やってみろ」と言う状況に何度出くわしたかわかりません。これは明らかに計画プロセスの厳格さを犠牲にしており、(おそらく) 製品の品質に影響を与えます。

今では、これについてより多くの経験を積んでおり、ここで作成するアプリケーションの品質に自信を持っています.

この問題をどのように処理しますか?

プログラマーに対して「とにかくやる」コマンドを使用したマネージャーはいますか? なんで？

多くの企業がアジャイルのように振る舞っていると聞いていますが、彼らが行っているアジャイルはスクラム プロセスだけです。これはアジャイルと見なすのに十分でしょうか? スクラムを単独で使用することは、悪いマネージャーがより頻繁に会議を行うための完璧な言い訳のように思えます。私はそのような会社にうんざりすべきですか？

Stack Overflow で、C#2.0 から C#3 に変換した人を読んだことがありますが、本当に価値があるのでしょうか?

メンテナンス段階に入る前に 75% で完了したプロジェクトがあります。C#3.0 に切り替える価値があるかどうか自問自答しています。

アップデート：

プロジェクトには Web インターフェイスが含まれるため、メンテナンス フェーズに入る前に Web パーツを開発する必要があります (すべて Windows フォームを使用して内部目的で行われました)。ほとんどの部品は再利用されます (バックエンド)。ほとんどの人は、すでに 75% だったので、それは価値がないと言いましたが、今でも価値がないと思いますか?

最終的にできたこと

最後に、Web インターフェースでプロジェクトを継続しているため、新年には 3.5 に更新します。皆様、ご意見をお寄せいただきありがとうございます。

I am about to join a new software team midway through a project. They are using ExtremePlanner to track their progress.

While they tracking tasks completed, they are not tracking how the estimated size of the project is changing over time. In the short time I have been monitoring the project this estimate has changed faster than the completion rate of the tasks. My gut feeling says that this is not just a blip but a problem that has been consistent throughout the project lifetime.

But how do I prove or disprove this?

I have not found the ExtremePlanner metrics useful for this. I have been exporting the data to MS Excel but the exported task and story info is missing important data like the creation date. Working around this is a bit of work. Is there a better way of doing this?

Alternately am I making too much of this? It has been argued by some of my prospective team mates that since no new features have been added that the scope has not changed and it is not a problem. However I argue that since new work within the features is continually being found the scope is changing and that this needs to be taken in to account when estimating the release date.