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

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

6
SCRUMは、チームメンバーが共有されている環境をどのように管理しますか？
まあ、質問はそれ自身を言いました。私の職場ではそのようなケースが起こりますが、多くのアジャイルの本は同じ職場で働き、仕事のペースを速くするために現在のプロジェクトに集中することを促進しています。 たぶん、私はそのトピックについて知らされていないかもしれませんが、それほど厳密ではないかもしれませんが、そのような場合にアジャイルが提案することを知りたいと思ったのはそのためです。 誰か？
6
新しいオープンソースプロジェクトのために放棄されたオープンソースプロジェクトから継承する正しい/丁寧な方法は何ですか？
私のチームは、code.google.comでホストされている古いオープンソースプロジェクトのメンバーに連絡を取りました。私たちは彼らのプロジェクトに参加して、少なくともそのブランチにコミットしたいと言いましたが、誰も私たちに応答しませんでした。全員、所有者、コミッターを試しました。誰もアクティブではなく、誰も応答しませんでした。 しかし、コミットするコードがいくつかあり、そのプロジェクトの作業を続けたいと思っています。したがって、新しいプロジェクトを作成する必要があります。継承したいプロジェクトの名前に近いが重複していない名前を思いつきました。最初のコミットをどのように行う必要があり、コミットメッセージはどうあるべきですか？「このコードを継承しました。このようなライセンスの下でここに見つかりました...今、このより厳格なライセンスにアップグレードしています...」などのコメントを付けてコードをリポジトリにコピーする必要がありますか？または、コードを最初のコミットとして使用し、「継承しました...そうした変更を行いました...」などの更新を行う必要がありますか？
5
合法的にクライアントに請求する内容[終了]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 私は固定価格の仕事について話しているのではなく、かなり簡単です。しかし、私は1時間ごとの料金のプロジェクトに取り組んでいます。私の質問は具体的に何に課金するかに関するものです。 IE / CSSの問題があり、修正にCSSを精査するのに1時間かかる場合、それは有料ですか？彼らのサイトで本当にクールなjQueryアニメーションを使用することに決めたが、それを使用するのに慣れる必要がある場合、アニメーションの実験のためにそれらを請求する必要があります。 顧客が求めていること、知らないこと、したがって学習に時間を費やす必要があることに対して顧客に請求しますか？ 私が懸念している限り、それは灰色の領域であり、引用符で明確に説明されていません（おそらく、多くのクライアントがあなたのねじ込み/学習に喜んでお金を払わないからです）。 これについてのコンセンサスは何ですか？
5
すでに開発されているプロジェクトを文書化する方法は？
すでに開発されたプロジェクトを文書化するためにどのオプションが利用できるか知りたいのですが、開発者は1ページも文書を作成しませんでした。 このプロジェクトには、過去2年間にこのプロジェクトに携わった開発者によって作成および変更された機能を備えた多くのスクリプトページ以外の詳細はありません。私が持っているのは、データベーススキーマとプロジェクトファイルだけです。このプロジェクトを組織し、文書化する方法があるかどうかを知りたいので、将来このプロジェクトに取り組む開発者に役立つようにします。 このプロジェクトはPHPとMySQLで開発されました。関数のコメントが不十分であるため、doxygenで実行すると良い結果が得られません。
5
複雑な処理を伴うアプリケーションにアジャイルをどのように適用できますか？
アジャイルに関する文献のほとんどは、ユーザーが舞台裏で何が起こっているかをかなり認識しているCRUDタイプのビジネスアプリケーションに偏っているようです。（書かれているコードのほとんどはおそらくこのクラスに属しているため、それは問題ありません。） このタイプのアプリケーションでは、ユーザーストーリー（要件）と開発タスクの関係はほとんど単純です。ユーザーストーリーをいくつかのタスクに分割するだけです。 しかし、ほとんどのコードがユーザーに直接見えない複雑な処理を処理しなければならない別のタイプのアプリケーションがあります。例は次のとおりです。 コンパイラー 自動運転車の画像解析システム 流体シミュレーションシステム ここでは、タスクとユーザーストーリーを関連付けるのが非常に難しくなる可能性があります。この問題を克服するためのテクニックはありますか、それを受け入れてそれを最大限に活用しなければならないのでしょうか？
3
依存関係の重要な機能が壊れて開発が妨げられた場合はどうすればよいですか？
昨日、私はRails 5 APIプロジェクトに取り組んでいました。このプロジェクトでは、タグ付きのacts-as-taggable-onライブラリを使用して、タグを付けることができます（SEの質問など）。Rails 5は現在、アルファ版をサポートしています。現在、マスターにマージされるのを待っているバグを修正するためのPRがあります。このバグにより、機能ブランチが完了の途中で停止しました-ロードが壊れたため、ライブラリの機能を実装できませんでした。 簡単な修正として、レポジトリを複製し、PRと同じコードで問題を修正し、バグ修正が最終的にマスターにマージされるまで、Gemfile（依存バージョン管理ファイル）を自分のGithubフォークに向けました。 修正が簡単だった（そして誰かがすでにそれを行っていた）ので幸運に思ったので、問題を回避することができました。しかし、このライブラリがアプリケーションの開発にとって重要だったらどうでしょうか？私の開発を止めていたバグ修正が他の人々に広まっている問題ではなかったので、今回のようにすぐに修正が反映されなかった場合はどうでしょうか？ この機能は、他の依存機能の開発の前に完了する必要があると想像してください-その状況で何をしますか？私にとって、タグ付けが他のすべてが依存している次の開発フレーズにとって絶対に重要だった場合、どうすればタグ付けの依存関係が私の構成にバグを起こすのでしょうか？依存関係の重要な機能が機能の開発を妨げる場合、何をしますか？ そして、確かに、数時間または数日間のオフィスチェアでの剣闘は選択肢ではありません...
8
「自動化は簡単」という考え方に対処する方法は？
タイトルはそれをすべて言います。当社の一部の従業員は、自動化されたテストは「簡単」であり、COMおよびUIテストのスイートを作成するには「1日かかる」と考えています。これに対抗するために何ができますか？ 注：自動化を促進する方法については質問していません。それは問題ではありません。ここでは常に自動化されたテストとプロセスが促進され、要求されています。問題は、一部の個人は、自動化が「簡単」でも「高速」でもないことを理解していないことです。
6
システム自体の実装よりも機能テストの実装に多くの時間を費やしていますが、これは正常ですか？
基本的に、3つの主要なプロジェクトがあり、そのうちの2つはWebサービスで、もう1つはWebアプリケーションです。機能テストでWebサービスをできる限りカバーすることに満足していますが（3つのプロジェクトすべてに適切な単体テストがあります）、Webアプリケーションの機能テストの実装には多くの開発者時間がかかります。多くの場合、ユニットテストを含めてテスト対象の機能を実装するのにかかる時間は2回、場合によってはそれ以上になります。 マネージャーのポリシーは、ビジネスクリティカルではない場合（つまり、新しいCRUD）でも、追加するすべての機能をテストすることです。 すべてのWebサービス機能をテストすることに同意します。手動でテストするのは難しく、また、このテストは高速で実行され、実装するのにそれほど時間がかかりません。 それでは、システムコードの作成、単体テスト、QAチケットの修正よりも、機能テストの作成に多くの時間を費やすことの価値は何でしょうか。これは正常ですか？重要な機能についてのみ機能テストを作成し、重要な機能がない場合にQAに回帰テストを行わせてはいけませんか？ 注：医療ソフトウェアやNASAソフトウェアを開発しているわけではありません。
1
最善の方法：既存のTeam Foundation Server（TFS）ソリューションを再構築する
私の部署では、ユニファイドコミュニケーションサーバー用にいくつかの小さなアドオンを開発しています。バージョン管理と分散開発では、Team Foundation Server 2012を使用します。 ただし、すべてのアプリケーションとライブラリに対応する大規模なTFSソリューションは1つだけです。 主な解決策 用途 アプリ1 アプリ2 アプリ3 外観 図書館 Lib 1 Lib 2 道具 「アプリケーション」パスには、すべての主要なアプリケーションが含まれています。これらは互いに依存していませんが、ライブラリと外部プロジェクトに依存しています。 「外部」パスには、アプリケーションとライブラリで参照される外部DLLが含まれています。 ライブラリパスには、一般的に使用されるライブラリ（UIテンプレート、ヘルパークラスなど）が含まれています。これらは互いに依存せず、ライブラリおよびツールプロジェクトで参照されます。 ツールパスには、セットアップヘルパー、更新Webサービスなどのヘルパープログラムが含まれています。 さて、この構造を変更したい理由はいくつかあります。 サーバービルドは使用できません。 そのようなソリューション構造で、スプリント、障害などでTFSスクラム管理を管理するのは不快です。 すべての開発者は、ソリューション内のすべてのプロジェクトに常にアクセスできます。 Visual Studioで誤って[F6]を押した場合、完全なビルドが長すぎます... このソリューションで何を変更しますか？それらのプロジェクトをより小さなソリューションにどのように分割し、それらのソリューションをどのように構成すべきですか 最初のアプローチは、アプリケーション、ライブラリ、およびツールごとに1つのTFSプロジェクトを作成することです。しかし、たとえばApp 2に常に最新バージョンのLib 1が含まれていることを確認するにはどうすればよいですか？Lib 1の変更を監視し、Libが変更されたらすぐにApp 2を手動で更新する必要がありますか？または、何らかの方法でVisual Studioに常に外部プロジェクトの最新バージョンを常に使用させることができますか？ 編集： TFSには、1つのTFSチームプロジェクトを含むTFSチームプロジェクトコレクションが1つだけあります。チームプロジェクトには、1つの大きなVisual Studioソリューションが含まれています。このソリューションには、複数のVSプロジェクトを含む複数のフォルダー（上記の構造を参照）が含まれています。 私の質問は今、どのように再編成しますか： TFSチームプロジェクト VSプロジェクト
5
開発者にプロジェクト管理を行わせるソフトウェアマネージャー
私は組み込みシステム会社で働くソフトウェア開発者です。プロジェクトマネージャーがいて、プロジェクトの全体的なスケジュール（電気、品質、ソフトウェア、製造など）を担当しているため、ソフトウェアスケジュールは非常に短いです。 私の上司であるソフトウェアマネージャーもいます。彼は、ソフトウェアのスケジュール、設計文書（高レベルおよび低レベルの設計）、SRS、変更管理、検証計画とレポート、リリース管理、レビュー、そしてもちろんソフトウェアの作成と保守をさせてくれます。 ソフトウェアチーム全体（10人のメンバー）に対応するテストエンジニアは1人だけであり、常にいくつかのプロジェクトが進行中です。 私はこれらのドキュメントを作成するのに80％の時間を費やしています。私の上司はプロセスのバックグラウンドから来ており、必要なのはソフトウェアを改善するためのより良いドキュメントであると考えています。 彼はデザインが最重要であると考え、コーディングは「デザインを書き留める」だけで、それほど長くはかからず、「ハードウェアの準備ができる前にすべてのコードを書く」必要があります。 分散モデルとのコラボレーションが簡単だと彼に言った後でも、中央バージョンと分散バージョンコントロールの違いを理解していません。 コードを理解していないため、すべてのバグとその提案された解決策を理解したいと考えています。 検証は開発者が行い、検証はテスターが行うべきだと考えています。ただし、検証では実装が正しいかどうかのみをチェックし（単体テストは作成せず、スケジュールでは考慮されません）、検証はブラックボックステストであるため、単体テストはありません。 私は本当に混乱しています。 これらすべての文書を管理する責任はありますか？本質的に、ソフトウェアプロジェクト管理を行っているような気分になります。技術文書は問題ありませんが、開発者がスケジューリング/計画を立てるべきではないと考えています。 私はドキュメントの作成が本当に好きではありません。問題を解決してコードを書きたいです。私の経験では、設計ドキュメントの作成はある程度までしか役に立ちませんが、コードの改善や高速化の解決策になることはありません。 上司はより良い製品を作ることを本当に気にせず、経営者の目には良いマネージャーになることだけに関心があると思います。 私に何ができる？今年は3か月間実際のコーディングを行い、残りはドキュメントの作成とクライアントからのバグレポートの待機に費やしました。
1
小規模プロジェクトのGitワークフロー/プラクティス（pngのフローチャート）
私は個人的なワークフローを考え出そうとしています。リリースの架空の寿命のフローチャートを作成しました。ある開発者が公開githubリポジトリにプッシュし、友人が何らかの機能を手伝ってバグを修正しました。 これはバージョン管理の合理的なアプローチですか？ 主なアイデアは、パブリックリポジトリを整理することです。 新しいリリースはそれぞれ、終了時にマスターブランチで最終的にタグ付けされるまで、独自のブランチになります。 すべての作業は、異常を防ぐために、実際のリリースブランチではなく、「機能」または「ホットフィックス」ブランチで行われます。 高レベルのブランチへのマージは、常にリベースまたはスカッシュされます（混乱を避けるため）。 やり過ぎだとしても、大事なプロジェクトに必要なスキルを習得することが全体的な目的なので、気にしません。唯一の問題は、私が間違っているか不必要なことを完全にやっていることです。 編集2：元のフローチャートの悪い考えを修正し、ナビゲートしやすくしました。
7
ドキュメントの劣化-対処方法
重要：ソースコードのドキュメントに問題はありません。これは通常のコード監査に属し、最新の状態に保たれます。私たちの問題は、開発者のドキュメント（または、必要に応じて「外部」）、プログラマーからプログラマーへのブログのような小さなヒントです。 ウィキのようなシステムを使用して、プログラマーのドキュメントを作成します。プログラマーのためにプログラマーが書いた記事は、特定のコードがどのように機能するかをもう少し詳しく説明しています。これらのWikiページには通常、次のものが含まれます。 APIの各部分の設計決定の背後にある動機（たとえば、この特定のサードパーティライブラリがこの方法で何かを行うことを望んでいるため、このotherいことをしました。 特定の一般的なタスクを処理する方法の説明（たとえば、適切なアプリケーションスタイルを参照し、レジストリコンポーネントに自分自身を登録し、他のコンポーネントによって自動的に「スキャン」されるために何らかのインターフェースを実装する必要がある些細なポップアップを表示する） 良い習慣（主観的なもの、実際にこのようなものを書き留めます） 環境設定、必要なツールとそのセットアップ 一般に、主にサイズとブログ投稿/記事のような性質のために通常のコード文書に適合しないコードの記述に関連するもの。 問題 このシステムを導入することは数か月前には良い考えのように思えましたが、最近では解決するよりも多くの問題を引き起こしているように感じます。例えば： 人々は記事を書きます...しかし、コードが変更されると、Wikiの更新はめったに続きません 急いで誰かが書いたスクラッチ記事の多くは、そのように残しました 記事のリクエストは通常​​プロジェクトリーダーからのものですが、正確性や構成についてはほとんど検証されていません。 通常の劣化。コードは変更されましたが、wikiは変わりません。誰かが次に情報を探すとき、彼が通常見つけるのは、時代遅れの低品質のものの束です-そして、何が起こっているのか、彼が見つけたものが正確であるのか、（さらに悪いことに）その一部であるのか疑問に思っています。そして、助けになるはずだったものが、逆になります。 現時点では、プロジェクトリーダーを含め、人々は問題を認識しているようですが、明らかにそれで何かをすることに煩わされる人はいないようです（または、もっと面白いことがあります）。 私の最初の考えは、それをすべて忘却の中に投げ込むことでした（時代遅れの「ヒント」に何回か噛まれた後）。しかし、それは極端すぎるかもしれません。いくつかの情報は注意する価値があり、時々読むことをお勧めしますが、問題は依然として同じです。「最新」にどのように対処しますか？ソースコードに何らかの形でリンクされていますか（したがって、ファイルの更新バージョンがチェックインされると、記事の作成者はコード/記事を修正する必要があるかもしれないと通知されます）？指定された人は、毎日の基本でそれを「見守っていますか」？定期的なクリーンアップを行いますか？
2
ベクトル量としての知能
私はPeter Seibelの"Coders at Work：Reflections of Programming of Programming ''と呼ばれるこの素晴らしい本を読んでおり、Joshua Blochとの会話の一部であり、プログラマーにとって重要なこの答えを見つけました。段落は、このようなものになります。 この問題があります。つまり、プログラミングは非常に知的実力主義であり、多くの場合、これらの人々は組織内で最も賢い人々です。したがって、彼らはすべての決定を下せるようにすべきだと考えています。しかし、単に彼らが組織内で最も賢い人であるという事実は、彼らがすべての決定を下すべきであることを意味しません。それはベクトル量です。 ここで最後の文で、私は彼が共有しようとしている洞察を得ることはできません。誰かがそれをベクトル量によって意味するものとしてもう少し詳しく説明できますか？おそらく同じ洞察を提示しようとしています。 さらに下に、私は彼が電子メールを書くのにより多くの時間を費やすことができる何らかの理由で技術者でない人（時々無知）が技術者のマネージャーになることができる組織を持つことについて取っていないという点を得る上記の段落に続く文はそうでした。 また、共感や感情的な知性が欠けている場合は、APIやGUI、言語を設計するべきではありません。 ソフトウェアエンジニアリングでは、プログラマーはユーザーが自分の製品やデザインをどのように見るかを知る必要があると彼が言っていることを理解しています。 上記の段落は非常に興味深いと感じました。
8
上司が常に要件と全体的な設計に関する重要な決定を延期する場合はどうすればよいですか？
新しいプロジェクトを開始するとき、上司は常に決まった決定を下すことを避けています。彼は通常次のように言っています：わかりました、何かを書き始めて、できるだけ一般的になりなさい。終了したら、私たちがどのように続けるかを見ていきます。彼の議論は基本的に、あなたが決して知らない「アジャイル開発」だということです。 質問をできるだけ一般的にするために、上司が意思決定をしたくない場合はどうしますか？ それに固執して、数週間後に重いリファクタリングと部分的な書き換えを受ける可能性のあるコードを書くだけですか？または、ボスが少なくともいくつかの決定をするまで議論を続けますか？これは多かれ少なかれ私の現在の戦略です。それは物理学の法則に似ているため、ある時点で何かを提供する必要があります。上司のボスが結果を見たいか、何かがばかげているからです。 また、上司がほぼすべてを批判していることも観察しています。彼自身に基づいた提案でさえ...
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.