問題タブ [project-planning]

ジェフの最近の記事は、時間管理のパレートの法則（または80/20ルール）について説明したFirst Fit Decreasingアルゴリズムの時間管理の例にリンクしています。つまり、作業の80％が20％で生成されます。私たちの時間。

今、私たちは皆、プログラマーの引用を聞いています：

コードの最初の90％は、開発時間の最初の90％を占めています。コードの残りの10％は、開発時間の残りの90％を占めています。

しかし、冗談はさておき、コードの20％がやりたいことを実行し、残りの80％が例外を処理するように見えることがよくあります...では、80/20の法則は本当に開発者に適用されますか？

なぜそれが私たちに当てはまる/当てはまらないのかという例はありますか？

ウェブベース/ブラウザベースの従業員スケジューリング ソフトウェア/ツールを知っている人はいますか?

現在、すべて Excel で実行していますが、十分にインテリジェントではありません... 製品に関する提案はありますか?

数週間から数か月にわたって複数の従業員を処理する必要がある...仕事の短期および長期のスケジュールを立てるため、考えられるリソースの問題などを確認できるようにする.

プロジェクトのみの場合は簡単な質問の答えですが、私の代理店では、プロジェクトや、いつでも入る可能性のある日常のリテイナー型の作業に取り組んでおり、通常は「すべてをドロップして今これを実行する」タイプです。 .

それが単なるプロジェクトである場合、オンラインのプロジェクト管理ツール (GoPlan、Cop​​per Project、MS Project) のいずれかで十分です (ただし、Basecamp は絶対に必要ではありません。非常に小規模なプロジェクトや小規模なチームではこれで問題ないと思いますが、それよりも規模の大きいものであれば何でもよいと思います)。 PMツールとして完全に落ちます）

私が望んでいたすべてを実行するのに近づいた唯一のことは、Workschedule - http://www.workschedule.net/でした。

ブラウザベースで低コストであり、エージェンシーのリソース レベルを計画するのに非常に役立つ多数のオプションがあります。唯一の欠点は見た目がかなり悪いことですが、すぐに克服しました。

明確化: 汎用である必要があります。つまり、1 つの業界だけではありません。

• プロジェクトの計画と、新しいプロジェクトの時間見積もりの​​作成に関して、どのような経験がありますか?

• 使用しているアプローチは何ですか? また、それがうまくいった、またはうまくいかなかった理由は何ですか?

• 考慮すべきベストプラクティスはありますか?

タイトルが示すように、私は現在 1 つのプロジェクトを開始しており、プロジェクトのインフラストラクチャ (SVN、電子メール、バグ追跡、オンライン フォーラムなど) をレイアウトしようとしています。

では、Bugzilla か Mantis か。

潜在的な従業員や雇用主にインタビューする方法についていくつかの質問を見てきましたが、これは私が過去に遭遇した非常に重要なことであり、ここにいる他の多くのユーザーも同じようになると確信しています:

小さな開発会社、コンサルタント会社、またはフリーランスで働いている場合、潜在的なクライアントにどのような警告サインを探しますか? 顧客が多くの監視を必要とし、多くの時間を要求し、それに応じて充電モデルを調整する必要があることを示す指標がいくつかあるはずです-あなたの経験では、これらは何ですか?また、それらをどのように処理しますか?

顧客が面倒すぎてまったく対応できないことを示す危険信号は何ですか? この決定のしきい値をどこに設定しますか?

ユーザー ストーリーの実装に必要な時間をどのように見積もっていますか? それがどれくらいの時間がかかるかを知る前に行ったことがある場合。しかし、それがあなたにとってまったく新しいものである場合はどうでしょうか? 「サプライズ」のためにどれくらいの時間を確保していますか?

ソフトウェア プロジェクトでどちらかを使わないといけないとしたら、どちらを選びますか? クライアントや PM が、どちらかがなくてもやり遂げられると考えていたプロジェクトがたくさんありました。私たちは常に代償を払いました。

Visual Studio のプロジェクトとソリューションで製品のコードネームを使用することに関して、慣行はありますか? 通常、製品名が選択されたら、名前空間、アセンブリ名、バイナリ出力などの名前を変更する必要があります。これに対処する方法はありますか?

コードの一部をリファクタリング/レビューする時期はいつわかりますか? さらに良いことに、いつそれを行いますか?

おそらく他の人たちと同じように、何かにリファクタリング/レビューが必要であることはわかっていましたが、締め切りと管理のためにその時間がありませんでした。また、一般的な開発プロセスにコード レビューをどのように組み込んでいるかについてもお聞きしたいと思います。

最近、私は新しい機能/コードに取り組む前にそれをやっていることに気づきました。たとえば、アプリケーションのモジュール X で何か新しいものを開発したり、何かを変更したりする必要がある場合、そのモジュールのコード レビューを行います。また、モジュールをよりよく理解するのにも役立つことがわかったので、変更をより簡単に行うことができます。

では、いつその時が来たかを知り、いつ実行しますか? そして何よりも、それをプロジェクトの計画にどのように含めますか?

機能仕様はあなたの期待を助けますか、それとも妨げますか? ウォーターフォールの方法論を実践するプログラマーは、機能仕様に対してオープンですか? 私は 5 人のプログラマーのチームで作業している Web デザイナー/開発者であり、作業を開始するときに、同じ目標に向かって取り組んでいることがわかるように、必要なものを説明する機能仕様を書きたいと考えています。