タグ付けされた質問 「project-management」

プロジェクト管理は、特定の目標を達成するためのリソースの計画、編成、確保、および管理の分野です。

4
より組織化されたプログラマになるには?[閉まっている]
ここで何が質問されているのかを理解することは困難です。この質問は、あいまいで、あいまいで、不完全で、過度に広い、または修辞的であり、現在の形では合理的に回答することができません。再開できるようにこの質問を明確にするヘルプについては、ヘルプセンターに アクセスしてください。 7年前休業。 私はコーディングできるプログラマーです。しかし、私は物事を成し遂げることができますが、物事をうまくやったり、ほとんどのオープンソースコミュニティがそうするようにしたりはしません。ええと、私はgit hubのライブラリの一部を使用しています。私はプログラムのほとんどがうまく構成されていると思います。また、私を読んでください。 私の質問は: コミュニティで一般的なファイル構造や命名規則はありますか?これは個人的な好みの問題ですか? コードを書くのではなく、より組織化されたプログラマーになる方法はうまくいきます。しかし、あなたのプロジェクトに他の人が参加しやすいようにもっと整理されていますか?

5
問題追跡システムを使用することの欠点についての調査はありますか?[閉まっている]
現在のところ、この質問はQ&A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、議論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 8年前休業。 次の理由で、問題追跡システムは好きではありません。 その中で問題を説明するには時間がかかりすぎます。これはその使用を思いとどまらせます。 バグを保管する場所を作成します。そして、彼らのための場所があれば、人々は通常、バグを修正することについてあまり気にしないので、いつか誰かがそれを修正できるようにするためにバグをそこに置くことができます。 時間が経つにつれ、バグリストは非常に長くなり、だれもそれを処理できなくなり、多くの時間を費やしています。 ホワイトボードでポストイットを使用して問題を処理したり、顔を見ながら会話したり、重要なバグが現れたらすぐに殺したりすることを好みます。オーバーヘッドに見合うだけの価値はないと思うので、バグの履歴を追跡することはあまり気にしません。 私はここに一人ですか?問題追跡システムを使用することの欠点(または大きな利点)に関する研究(本/記事/何でも)はありますか?

2
Web開発の準備とプロジェクト全体のワークフロー
私はWeb開発プロジェクト(フロントエンドとバックエンド)で一人のプログラマーとして働いています-私はいくつかのプロジェクトを完了しているので、これはかなり新しく、いくつかのアプローチを読んで試してみて、ある方法に到達しましたそれらについて。質問と私の説明はかなり長いので、しばらくお待ちください。 私が探しているものは、次のとおり です。1.何を構築する必要があるかを正確に理解した後、開発を開始する前に通常行われる準備/計画。 2.経験から、私が現在フォローしているプロセスについてのフィードバック/提案を教えてください。 私が扱うクライアントは、一般にスタートアップであり、予算が限られているため、時間単位で課金することはできません(これは、大企業が通常、クライアントに[人/時間]で開発プロジェクトに請求する方法です)。固定予算で作業します。 これが私が現在従うプロセスです 。1.プロジェクトの範囲を測定し、2、3回の会議で彼らが何を達成しようとしているのかを理解しようとします。 2.彼らがプロジェクトから何を得ることが期待できるかを一般的に説明する見積もりで大まかな球場図を与えます、私は機能について具体的にしようとしますが、私は知っているのでこれにあまり多くの時間を入れませんクライアントは単に見積もりを求めているだけで、実際には変換しません。 3.支払いと作業に関するJeff Atwoodの提案に従います。 15%の支払い-作業を開始する前の事前準備 このフェーズでは、最終的なWebサイトのHTMLモックアップが作成され、Webサイトを可能な限り詳しく説明するフローチャート(yEd付き)と、フローチャートにはない他の機能を説明するドキュメント。これは、プロジェクトのすべての詳細を調べ、適合する価格と、合意された価格で実装するにはあまりにも多くの作業が必要なものを完成させることによって行われます。詳細については前に説明していませんので、これらの一部は多かれ少なかれ実際に何が得られるかについての交渉です。これは固定予算プロジェクトであるため、固定要件が必要です。それ以外の場合、機能が追加されても価格は下がり続けます。 配色、デザインワイヤーフレーム、デザインPSDも完成します。 35%の支払い -開発 の開始プロジェクトは修正され、開発を開始します。サーバーでサイトをホストしています。クライアントはフロントエンドにアクセスできますが、コードにはアクセスできません。 30%の支払い -コードをクライアントのサーバーにシフトする/クライアントにサーバーアクセスの詳細 を与えるサイトをライブにする 20%の支払い -すべてのバグが修正された後、サイトが稼働してから数週間。 質問: 1.何を構築するのかが正確にわかったら、コーディングを開始する前にどのような計画を立てますか? 2.経験から、プロセス全体のどの部分を異なる方法で実行しますか?

3
滝に焦点を当てた人々にアジャイルプロジェクトを表す方法[終了]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 5年前休業。 私たちのチームは、私たちの開発努力をプロジェクト計画に表すよう求められました。私たちの仕事に不満を抱いたり、提供能力に疑問を投げかけたりする人はいません。プロジェクト計画のIT牛募集に参加しているだけです。問題は、私たちがアジャイルチームであり、正式なプロジェクト計画の観点から私たちの仕事について考えたことがないことです。 私たちは次に何をしているのかについての一般的な考えを持っていますが、反復を計画するまで100%確信が持てません。これまでのところ、私たちのチームは大部分が孤立していて、私たちの方法論や測定基準を外部の関係者に提示する必要はありませんでした。私たちは、エクストリームプログラミングで採用されているほとんどのプラクティスに従います。 四半期ごとに計画する会議を開催して、四半期に向けて取り組むストーリーの概要を把握します。とは言っても、私たちのストーリーは3x5カードで文書化されており、それらが機能するイテレーションの開始時にのみ推定されます。見積もりの​​後、そのストーリーをTeam Foundation Severに文書化します。イテレーション中、ストーリーにコードを添付し、ストーリーが完了したらストーリーに完了のマークを付けます。このデータから、バーンダウンチャートと速度チャートを生成できます。最も重要なのは、反復の平均速度がわかっているため、噛む以上に噛み付かないようにすることです。 私は開発方法を変更するつもりはありませんが、ウォーターフォールに精通している人だけが理解できるレポートで開発活動を紹介したいと思います。ではアジャイルプロジェクト計画のように見えるが何をするか、ケントマクドナルドはアジャイルとウォーターフォールプロジェクト計画との違いをレイアウトする良い仕事をしていません。彼は消耗品の弾丸の違いを明記しています: アジャイルプロジェクト計画は機能ベースです アジャイルプロジェクト計画は反復に編成されます アジャイルプロジェクト計画には、時間枠に応じて詳細レベルが異なります アジャイルプロジェクト計画はチームが所有しています 違いを説明できるのは素晴らしいことですが、データを提示するにはどうすればよいでしょうか。

4
影響分析文書に何を入れましたか?
したがって、バグを修正しているときに、ソフトウェア製品の他のモジュールに影響を与える可能性のあるバグに遭遇しました。あなたのデータは、修正の影響についてのあなたの主張をサポートするのに十分ではなく、影響分析文書を作成するように求められました。 これを行う方法について定義されたプロセスはありますか? 必要な重要な情報は何ですか? このドキュメントの既知のフォーマット/テンプレートはありますか?

3
ソフトウェア開発の進捗状況を関係者にどのように提示しますか?
バグと機能のリクエストを追跡するためにBugzillaを使用し、開発者が機能のコーディングを完了した場合は、別のリリースノートに書き込むことも必要です。昔のファッションだと思います。 上記の配置で私たちが抱えている問題の1つは、すでに販売しているソフトウェアには問題なく機能しますが、新しいソフトウェア開発プロジェクトの進捗状況を追跡する場合にはまったく役に立ちません。その理由は、新しいソフトウェアを開発する時点では、バグジラを使用して機能を追跡することはできず、むしろできません。なぜなら、バグジラは、複雑な機能の依存関係を表すのに適していないからです(新しいソフトウェアアプリケーションでは、コード化する機能が多すぎて、Bugzillaに配置する気がありません。そうしたとしても、どの機能がどの機能に依存しているかを知る方法がなかったため、できませんでした。とにかく、出荷日を正確に予測します)。 次に、関係者は開発の進捗状況(または不足)に懸念を抱き、チームリーダー(本当にあなたの)の見積もりにたどり着きます。悲劇的にも、正直なところ、新しいアプリケーションが完成するまでの距離を知っている。 ソフトウェア開発の進捗状況を関係者にどのように提示しますか?

2
ソフトウェアプロジェクトの測定基準は、今日の業界で人気がありますか?
チームプロジェクトについて外部のアドバイスを求めている開発者に出会いました。企業の幹部、プロジェクトマネージャー、開発者向けに、メトリックを自動的に計算し、反復ごとにグラフ化できる巨大なソフトウェアスイートを開発していることがわかりました。 コンピューターサイエンスのバックグラウンドを持つ学生として、メトリックスとその重要性についてほとんど知りませんが、私の質問は次のとおりです。 ほとんどの企業には何らかの方法がありますか、意味のあるメトリックを測定するために、エレガントなプログラムである必要はありませんか? プロジェクトの範囲と見積もりを絞り込むのに役立つ単一または組み合わせのメトリックはどれですか? 指標を分析する人として、どのくらいの頻度で指標に基づいて決定を下しますか?IE。毎週失敗したテストは劇的に増加していますか? 調査指標の導入により、プロジェクトの理解が深まったと思いますか? なぜだかわかりませんが、開発者プロジェクトに興味をそそられました。yの場合

3
要件にWikiを使用する
要件管理を改善する方法を検討しています。現在、Word文書をWebサイトで公開しています。残念ながら、(私の知る限り)あるリビジョンから次のリビジョンへの変更を確認することはできません。私は、wikiやVCSのように(または両方がbitbucket上のwikiのように!)できるようにしたいのですが。 また、各ドキュメントは、開発者が所定の期限までに満たすことが期待される変更について説明しています。蓄積されたアプリ機能のコレクションはどこにも文書化されていないため、レガシーアプリをすばやく修正しようとすると、バグと(設計が不十分な)機能を区別するのが難しい場合があります。 だから私はフィードバックを得たいと思っていました。何について: 誰がいつ何を変更したかを追跡できるようにwikiを使用します(ほとんどの場合、前回の表示以降に編集が行われたかどうかを確認するためにも)。 たとえば、期限ごとではなく製品ごとに1つのwikiページを用意し、実装すべき変更ではなく製品のすべての機能に対応します。このようにして、ページの特定のリビジョンを確認して、特定の時点でアプリが何をすべきかを確認できます。また、次の期限までに要件を実装するための最後のリリース以降のページの変更を確認できます 。 ワダヤシンク?

14
プロジェクトのコードベースに深刻な作業が必要であることをプロジェクトマネージャーまたはリードデベロッパーに(巧みに)伝えるにはどうすればよいですか?
私は(比較的)小さな開発チームに参加しました。1年ではないにしても、数か月間プロジェクトに取り組んでいます。ほとんどの開発者がプロ​​ジェクトに参加するのと同じように、最初の数日間はプロジェクトのコードベースを確認しました。 このプロジェクト(中規模から大規模のASP.NET WebForms内部基幹業務アプリケーション)は、より具体的な用語がないため、災害です。コーディング標準には、すぐに気付く3つの問題があります。 標準は非常に緩いです。すべきことよりも、すべきでないこと(ハンガリー語の表記法を使用しないなど)の詳細を説明します。 標準は常に守られているわけではありません。どこでもコードのフォーマットに不整合があります。 この標準は、Microsoftのスタイルガイドラインに準拠していません。私の意見では、フレームワークの開発者と言語仕様への最大の貢献者によって示されたガイドラインから逸脱することには価値がありません。 ポイント3については、MCPDをWebアプリケーション(具体的にはASP.NET)に集中させるために時間をかけたため、おそらくもっと面倒です。また、私はチームで唯一のマイクロソフト認定プロフェッショナルです。私はすべての教育、自習、および実地学習(認定試験の準備を含む)で学んだことにより、プロジェクトのコードでいくつかのインスタンスを見つけました。最良の方法。 私はこのチームに1週間しかいませんが、コードベースには多くの問題があり、「自分の方法」で物事を行うためにすでに記述されているものとの戦いに費やす時間が増えると思います。たとえば、より広く受け入れられているコーディング標準、アーキテクチャパターン、ベストプラクティスに準拠したプロジェクトに取り組んでいます。これは私に私の質問をもたらします: プロジェクトを大幅に刷新する必要があることを、プロジェクトマネージャーとチームリーダーに提案する必要がありますか(その場合はどうすればよいですか)? 彼らのオフィスに足を踏み入れたくないので、私のMCTS証明書とMCPD証明書を振って、彼らのプロジェクトのコードベースはくだらないと言っています。しかし、私は実際に高品質のソフトウェアを書きたいと思っており、最終製品を安定させて簡単に保守できるようにしたいので、私はまた、黙っていたくないし、彼らの厄介なコードの上に厄介なコードを書かなければなりません。

4
プログラミング料金を他のソフトウェア開発者と共有する
私の質問は、クライアントから私や他のプログラマー(どちらもフリーランサー)に支払われた料金をどのように共有すべきかに関するものです。 私はいくつかのオプションを考えましたが、どちらが私たちの両方にとって最も動機付けになるかについてジレンマに陥っています。 1)私が考えた最初のオプションは50から50のシェアです。ただし、同僚の方でもっと多くの頭脳作業を行う予定ですが、少なくとも最初はお客様とのコミュニケーションを担当します。 2)2番目のオプションは60〜40のシェアで、より多くの努力をしている同僚がより大きなシェアを獲得します。これは私が採用する傾向があると思うオプションですが、長期的にどのように感じるかはわかりません。 3)3番目のオプションは、費やされた時間数に関して各自の貢献を計算し、それに応じて収入を分配することです。 これについて皆さんの考えを聞くのは素晴らしいことです!


5
プログラムマネージャーとプロジェクトマネージャーの違いは何ですか?
プログラムマネージャーは、プロジェクトマネージャーによって順番に管理される複数のプロジェクト(単一のプログラムの下)を管理する人ですか? または、ここで Joel Spolskyが定義したプログラムマネージャーの人です。 注:私はこれについて言及していません。

3
一貫した変化を考えると、計画期間の短さは短すぎますか?
変更は珍しくなく、要件の変更、仕様の変更、ワークフローの変更です。変化があることを受け入れましたが、私は疑問に思います。変化が起こることを知っていると、計画期間の短さが短すぎますか?(正当化が奨励されます) 繰り返し(2〜4週間)? 一週間? 2〜3日ですか? 一日? 1日1/2? 会社が現在から1 [時間間隔(上から)]を「計画」し、計画が次のように聞こえると仮定します。 「[今朝/今日/今週の/ etc。]あなたは上で動作するでしょう。このと[今日の午後/明日/来週の/ etc。]あなたは上の作業になりますもの。 また、フォーカス/方向の変更が毎秒から3番目の時間間隔で一貫して発生するとします。

9
プログラマはビジネス/管理について何を知っている必要がありますか?[閉まっている]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 私が他の投稿で示唆したように、私はまだ労働力にかなり新しいです。チームミーティング中は、技術的な議論についていくことができる傾向がありますが、プロジェクトマネージャーが新しい契約を獲得した方法や、新しい提案の入札に関与している方法などについて話し始めたときは、技術ではなくビジネス、本当に...すぐに迷子になるかもしれません。 すべての開発者が機能するためにプロジェクト管理/ビジネスについて知っておく必要がある最低限何ですか?


弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.