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

私はモバイルアプリケーションのAPIを公開するバックエンドを開発しています。ユーザーは登録、製品の追加、製品のリンクを電子メール/ SMS /どこでも共有でき、他の人はそれをクリックして製品を購入できます。これは、モバイルアプリケーションの単純なワークフローです。アプリは、画像のアップロードと取得がサードパーティのクラウドサービスによって行われる、画像集約型のアプリです。SO画像部分は私のバックエンドで処理されません。 現在、私は開発チームの出身で、ハードウェアサーバー側の経験はほとんどありません。インフラストラクチャの要件を説明したところ、次の質問がありました。 アプリケーション/ストレージスループット アプリケーションのスループット（3か月、6か月、1年の同時接続数） ストレージスループット（3か月、6か月、1年でのデータの増加） HA要件 DR要件 上記の3点をどのように予測すればよいかわかりません。スループットはどのように計算されますか？最初の1か月でアプリケーションに10000人のユーザーが登録すると推定されます。そのうち5000人がアクティブユーザーになります。アプリケーションへの平均ログインでは、ユーザーあたり10 APIヒットがあり、これは5000 * 10 = 50,000ヒット/月になります。これは、1分あたり1 APIヒット、つまり最初の月に最大2つの同時接続になります。 計算はこのようになりますか？データの増加をどのように計算しますか？それは、ユーザーが製品を登録、作成し、そのために消費されたデータベースサイズを合計すると、データの増加と呼ばれることになるということですか。 この質問は悲惨に思えるかもしれませんが、サーバーの要件に対してスループットがどのように計算されるかを理解するには、本当に助けが必要です。

9 web-development  programming-languages  programming-practices  project-management  web-applications 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、討論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 いくつかのオープンソースプロジェクトがあり、いくつかの重要な使用法があり、メンテナンスとサポートのリクエストに関してボトルネックにならないように、またプロジェクトがどのように進化するかについて他の見方を得るために、共同メンテナを見つけたいと思っています。 共同メンテナはどこに探すべきですか、共同メンテナは何を探す必要がありますか？コードとメンテナの責任をスピードアップするにはどうすればよいですか？

9 project-management  open-source  collaboration 

ほとんどのプログラマーは、それが実行不可能な場合でも、プロジェクトで一人で作業することを好むと思います。プログラミングプロジェクト以外でも、私は一人で作業することを好みます。他の開発者と作業するとき、私は通常それを見つけます 書式や規則（変数名やメソッド名など）が気に入らない 彼らが書いたコードがどのように機能するかについて私はよく理解していません。 彼らが書いたものを実装するためのより良いまたはより効率的な方法があると思います 4〜5人のプログラマーがいるプロジェクトで、これらの問題や他の同様のチームの問題を克服するための最良の方法は何ですか？

9 project-management  team 

すぐに小さなサイドプロジェクトを開始しますが、今回はプログラミングの前によく行う小さなUMLドメインモデルとケース図だけではなく、完全な機能仕様を作成することを考えました。私がそれに追加する必要があるものを私に勧めることができる機能仕様を書いた経験がある人はいますか？どのように準備を始めるのが最善でしょうか？ここで、より関連性があると思うトピックを書き留めます。 目的 機能の概要 コンテキスト図 重要なプロジェクト成功要因 スコープ（イン＆アウト） 仮定 アクター（データソース、システムアクター） ユースケース図 プロセスフロー図 アクティビティ図 セキュリティ要件 性能要件 特別な要件 ビジネスルール ドメインモデル（データモデル） フローシナリオ（成功、代替…） タイムスケジュール（タスク管理） ゴール システム要求 予想経費 それらのトピックについてどう思いますか？他に何か追加しましょうか？または何かを削除しますか？ ひとつひとつの回答に乗りましたが、有益な情報をありがとうございます。 私はこのサイドプロジェクトを会社のために行っています。彼らは私から一定のコミュニケーションの流れを見ており、私が彼らに提供するリソースを管理する必要があるので、私がすべてのことを行う理由を説明する必要があります。これは私の最初の機能仕様になります。私が言ったように、私はそれが大きくて役に立たないだけでなく、役に立つことを望んでいます。これはやらなければならないことだと思いますが、私や私のチームにとってもっと役立つ方法でやりたいです。マネージャーがいないのは悪いことなので、管理タスクにも注意が必要です... アジャイルプログラミングに関しては、これはアジャイルアプローチと100％互換性があると思います。私は自分自身をアジャイルプログラマです。正直に言って、誰かがすでに私のために考えているときは、自信がつきました。私はまだジュニアですが、以前は他のプロジェクトでタペストリーのWeb開発者として働いていました。 私は滝のアプローチをしていることに同意しません。開発が始まるときにプロジェクトをより簡単にするいくつかの境界を定義しようとしているだけだと思います。

9 java  project-management  specifications  projects-and-solutions 

私は最近、会社でアジャイル手法を使い始めました。私はアジャイルにかなり慣れていないので、アジャイルの基本原則に従って、実装方法が正しいかどうか疑問に思います。 以前は、ビジネスアナリスト、QAテスター、ソフトウェア開発者などの役割がありました。しかし現在、経営陣はこれらの役割を削除する必要があると決定し、誰もがソフトウェア開発者として働くことになります。 実際には、これは、1人のソフトウェア開発者が以前に3つの別々の役割（つまり、1人のビジネスアナリスト、1人のQAテスター、および1人のソフトウェア開発者）と同じ責任を持つことを意味します。 彼らはこれがアジャイルであるという事実で変更を正当化します。これは他の企業もアジャイルを実装する方法ですか？

8 agile  project-management  team  systems-analysis  testers 

たまにはこういうコメントをします # We only need to use the following for V4 of the computation. # See APIPROJ-14 for details. または # We only need to use the following for V4 of the computation. # See https://theboringcompany.atlassian.net/browse/DIGIT-827 for details. そうすることに関する私の主な懸念は、JIRAへの依存度が高まることです。そのため、別のプロジェクト管理システムに移行する場合、これらのコメントはまったく意味がありません。近い将来に発生することは予測できませんが、組織コンポーネント（この場合は、コード、コードリポジトリ、プロジェクト管理システム）の結合の増加に引き続き注意します。 ただし、コードベース全体で、文書化された設計の決定と機能のインスピレーションへの参照があることの利点はわかります。私の知る限り、メリットは 設計の決定への明確な道筋。これは、見慣れないコードの特定のセグメントのデバッグと強化に役立ちます。 複数行のコメントが少ないため、コードがよりクリーンになり、新しい貢献者を脅かすことが少なくなります。 （潜在的に）現在の技術的および非技術的利害関係者への明確な道筋 前述の理由により、「なぜここにあるのか」という質問の数は減少しています。

8 project-management  coding-style  communication  comments  jira 

私の会社では最近、締め切りが非常に厳しいプロジェクトがあり、極端な個人的な問題のために私が不在になるまで、すべてが計画どおりに進んでいました。 結局、4〜5日で締め切りに間に合いませんでした。 これらの状態の通常の回復計画は何ですか？私の会社は私の仕事を完了するために開発者を外部委託しようとする必要がありますか？それを見つけるのに数日かかるかも？

8 project-management  software  deadlines 

私はソフトウェア開発者で、小さなWeb開発会社で働いています。なかなか時間がかかるとミドルマネージャーから聞かれるのはよくあるテーマのようで、見積もりを出すと高すぎると思います。それがより技術的なマネージャーまたは別の開発者である場合、彼らは通常、自分自身の見積も​​りをすでに心に留めており、より速く実行できると考えているため、独自の方法でそれを実装しようとします。 ただし、他の開発者が見積りよりも大幅に多くの時間を費やしてしまう傾向があります。彼らは予算の半分を経て、実装計画では適切に対応できないビジネス上のニーズがあることを認識します。たいていの場合、私の計画はこの必要性に対処するはずでしたが、「あなたはそれを必要としない」機能として肩をすくめられました。 さらに悪いことに、彼らがこの壁にぶつかったとき、彼らは通常、彼らが自分たちが描いたコーナーから抜け出すのを手伝うために私のところに来ますが、私の一日にはほんの数時間しかありません。 最良の場合：これらの中断は、自分の開発作業に割り当てた時間に割り込んだため、他のプロジェクトが遅れたり、「Xを実行できる唯一の人」であるため、残業しなければなりません。 最悪の場合：私は自分でタスク/プロジェクトを引き継ぐ必要があり、その時点では予算に「私の」やり方でそれを行う時間は残っていません。彼らが始めた方法で彼らが始めたものを終わらせなければならないので、「会社はこれ以上お金を失うことはありません」。「私の」ハッキーコードになるので、これはいつも私に噛み付きます。それが壊れると、なぜそれがそのように作成されたのか、人々は私に尋ねます（結局のところ、誰が実際にそれを作成したのかわかりません）。 ですから私の質問は次のとおりです。物事が想像しているほど単純ではなく、クライアントのニーズに対する理解を再評価する必要があるときに、これらの同僚がどのように理解できるようにすることができますか？ [既存の]技術的負債に対処するための経営陣の説得に関するこの同様の質問とは異なり、私の質問は、それが最初から起こらないようにするために、チームが技術的負債を負おうとする前に[積極的に]実現するのを助けるための戦略を求めています。これら2つは密接に関係していますが、私の考えでは明らかに異なります。他の質問の答えは、将来の機能の見積もりにリファクタリング時間を追加することを提案しています。他の開発者（したがってマネージャー）が、将来の機能は実際よりも時間がかからないといつも考えている場合、これは決して機能しません。また、私の見積もりがより現実的であると彼らに納得させることができません。

8 project-management  teamwork  estimation  technical-debt 

私たちはウェブアプリに取り組んでいる低予算のチームです。いくつかの複雑さのため、1月以降はリモートで作業する必要があります。いくつかのコンサルティングとグーグルの後、いくつかの小さなリポジトリがより安価なオプションであると結論付けました。私たちは考えています： バックエンドとサービス ミドルウェア フロントエンド このようにして、関連するチームに分離し、それぞれがリポジトリでリモートで作業できます。私たちのアプリをいくつかの小さなプライベートリポジトリに置くことは、どの程度実行可能ですか？ さらに、この方法で作業する場合、どのような考慮事項を考慮する必要がありますか？ 注：複数の小さなリポジトリに分割された単一の大きなプロジェクトについて質問しています。これは、1つまたは複数のリポジトリで複数のプロジェクトを要求しているため、このサイトで尋ねられた関連質問とは異なります。さらに、私たちはプロジェクトを分割することを選択しました。これは主に、私たちがそれに固執しない限り、単一の大きなプライベートリポジトリに投資するつもりがないためです。

8 project-management  team  repository 

私のプロジェクトIntentExamplesには、サービスに対応するこのフィルターがあります。 <intent-filter> <action android:name="biz.rpcodes.apps.intentexamples.START_SERVICE" /> </intent-filter> 別のプロジェクトUseExampleServiceには、次のようなものがあります。 Intent i = new Intent("biz.rpcodes.apps.intentexamples.START_SERVICE"); startService(i); ...この答えによって導かれる：https : //stackoverflow.com/a/16439551/5181778 私の質問は、複数のプロジェクトにわたってこれらのインテントフィルター文字列をどのように管理すればよいですか？私が今持っている最善の解決策は、Serviceプロジェクトから他のプロジェクトにコピーアンドペーストするクラスを作成することです。 class ExampleServiceIntents { public static final String ExampleServiceIntents.START_SERVICE = "biz.rpcodes.apps.intentexamples.START_SERVICE"; ... Serviceクラス自体をインポートすることもできますが、 new Intent(this, ExampleService.class)Serviceクラスを独自のプロジェクトに保持したいと考えています。

8 java  project-management  android 

私は通常、次の方法でアプリケーションを設計していることに気づきました。 必要なサブシステムのインターフェースを含む1つのDLL。たとえば、Company.Framework.Persistence.dll。 上記のサブシステムの各戦略（または実装）ごとに1つの新しいDLL 。例えば： Company.Framework.Persistence.MSSQL.dll Company.Framework.Persistence.MySQL.dll Company.Framework.Persistence.FileSystem.dll これにより、多くのプロジェクトで非常に大きなソリューションが得られますが、一方で、消費者は自分のニーズに適したDLLを選択する機会が与えられます。 と呼ばれる単一のDLLがある場合Company.Framework.Persistence.dll、消費者は彼が決して使用しない可能性がある多くの戦略をロードする必要があります。DLLをモジュール化すると、この問題を解決できます。 これは良い習慣ですか？この設計には欠点がありますか？

8 design  design-patterns  .net  project-management  anti-patterns 

新しいソフトウェア製品の研究開発をしています。 経営陣は当然のことながら、明らかに顧客に利点をもたらす主要機能に焦点を当てています。しかし、同様に重要と見なすことができる多くの要件があります（例：パフォーマンス、将来の拡張性、データのトレーサビリティ、セキュリティ、スムーズなUI）。これらの暗黙の要件は、おそらくすべての製品の数が多く、満たされていない場合、顧客を不幸にする可能性があります。 どういうわけか、開発中にこれらのものが自動的に実装されるようになることが予想されます。私にとっては、すべてがそれ自体の注意と開発努力を必要とする原子的な側面です。 経営が忙しくて、そういうところに目が行き過ぎているのではないかと感じています。開発者の誇り、品質管理、および費やした労力を説明できるようにするために、暗黙の要件をいつどのように文書化して伝達する必要がありますか？ （つまり、製品に存在するが、顧客または管理者のいずれとも明示的に話し合われていない機能） 明確化 質問に関心をお寄せいただきありがとうございます。これまでの回答の主な要点は次のようです。 「暗黙の要件を明示的にする必要があります。」 ネズミ...それは私には起こりませんでした。 私が意味する要件には、次のタイプがあります。 お客様がこれらの要件について聞くことはできません。私は、製品がどのように満足するかについて話すのではなく、製品が失敗する可能性がある方法の長いリストを提示するからです。 忙しい経営者は、「明白な」機能について話すとき、私は彼らの時間を浪費していると感じています。 実装中は、これらの要件の一部のみを説明できます。計画中、特定の問題は開発中に集中的な努力を必要とするかもしれないと直感するだけかもしれません。 会社のトーテムポールで必要な高さではなく、自分の労働条件を決定している。 本格的な要件よりも労力をかけずに、[暗黙の]要件をセミフォーマル化する方法のガイドラインを求めていますが、判断の準備をしているので、手ぶらで捕まることがありません。

8 project-management  requirements-management 

私は約3人の他の人（開発者以外）と一緒にまともな小規模プロジェクトに取り組んでいるソロ開発者です。これらの他の人々は開発以外の方法でプロジェクトに関与しており、1人は私のマネージャーでもあります。誰もがその場限りの議論にもかなりオープンです。 私のマネージャーはちょうど夢のように見えるものを私に与えてくれました-私はどの会議構造がプロジェクトに最適かを決定することを任されました。これは、会議の過負荷や無意味な会議に対処するための素晴らしい方法のようです。 今のように、大きな力には大きな責任が伴います。もし私が最終的に多くの無駄な時間をもたらす何かを提案した場合、それは私のせいです。 会議をどのように構成するかを考えるのにこれほど白紙の状態はありませんでした。私の考えは： 毎日の目標を伝え、前日の内容を確認するために、15分以下（スタンドアップミーティングと同様）の毎日の「タッチベース/ステータス更新」ミーティング。または、ホワイトボードを手に取り、自分の机に置いてこの情報を伝えることもできたようです。 特定の決定を下すため、またはチームのいずれかが持っている質問に対処するために必要に応じて会議 ...毎週の「ステータス」プロジェクト会議の必要性はないと思います。また、2番目の箇条書きで正式にスケジュールされた多くの会議が必要になるかどうかもわかりません。 私の懸念は、これらの「開発者に焦点を当てた」（つまり私）が他の人との疎外を引き起こしたり、この構造がほとんどのプロジェクトが実行されるものとはかなり異なるため、プロジェクトに対するコントロールの喪失を感じたりする可能性があることです。 1人の開発者が選択する必要のあるプロジェクト会議の構造は何ですか？ コメントへの対応： 他に貢献している人は何ですか？彼らはこのプロジェクトの対象ユーザーですか？開発の非側面（ウェブサイトのテーマと画像、DBA、QAテストなど）に取り組んでいますか？他のレベルの管理/管理？ 彼らは最終的なユーザーの一部であり、全体的なワークフローに関心があります。また、フォーム/ドキュメントのいくつかの領域にも貢献しています（その形式は開発作業に影響しません）。 他の2人のメンバーからフィードバックを得ることができますか？一部のマネージャーは、定期的に会議をスケジュールする必要があります。そうしないと、会議をスケジュールに合わせることができません。 時間を稼ぐことは今後の問題ではないようです。

8 project-management  communication  solo-development  meetings 

私は最初の契約（上陸、自営業！）を上陸させ、会社は時間の見積もりを求めています。 プログラマーは時間の見積もりが悪かったことで悪名高く、私は以前、笑えるほど間違っていたことを知っています。固定入札なので、課金は気にしません。期待管理についてだけ心配です。 これまでのところ、実行する必要のある作業を項目別に示し、所要時間を見積もり、その時間を大幅に埋めていました。でも、まだ緊張しています。「予期せぬ遅延」に間に合うように書くことは受け入れられますか？見積もりは4週間ですが、考えていなかった問題については5週目を追加したいと思います。それは人々がすることですか？誰かがその中でそれを使って見積もりをくれたら、あなたは気を悪くしますか？

8 project-management  freelancing  estimation 

私の会社の一部の開発チームはアジャイル開発手法に切り替えており、開発者の作業は、2週間の反復サイクルのため、些細なソフトウェア機能について細かい点について話し合い、プログラムするために減少しているようです。また、「開発者なら誰でもバグを修正できる」という考え方もある。私は最近、それらのチームの1つに参加し、同じ会社の別のチームから転勤しました... 開発者はソフトウェアの機能を最初（設計）から最後（実装および単体テスト）まで所有する必要があると強く感じます。アジャイルはこの考えに反しているようです。私の認識に真実はありますか、それともアジャイルの悪い実装を生きているだけですか？ 2週間の反復の間、人々は、そのサイクル中のワークロードに応じて、新しい小さな機能とバグ修正をいくらか恣意的に割り当てられます。ソフトウェアの主要な機能の責任を誰も所有していないようです。我々は追加のような、些細なものに倍の愚かな金額を費やす単一などの話、毎日スクラム、コードレビュー、で、2週間の反復中にダイアログに完了ボタンを では、アジャイルプロジェクトでは、より大きな機能をどのように管理するのでしょうか。責任は誰にありますか：個々の開発者またはチーム全体？どのようにしてマニューシャから自分自身を抽出し、より長期的な目標に焦点を当てますか？どんなフィードバックも価値があります。

8 project-management  agile  product-features  code-ownership