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

私は大学で（唯一の）Webアプリケーション開発者として新しい仕事に就きました。 大学には多くの異種のシステムがありますが、どれもかなりひどくコーディングされたレガシーシステムです。ほとんどがPHPで構築されており、出席、試験結果、採点などを処理します。 私の最初の仕事は、このデータを大量に組み込むシステムを構築することです。現在、さまざまなデータベースに格納されており、それを引き出すためのフレンドリーなAPIはありません（既存のシステムは、データとビューを分離せずにPHPでコーディングされています）学生に関する牧歌的な情報を記録し、教師や上級スタッフに有用な方法で提示するための新しいプラットフォームを使用して、学生に関する問題に迅速に対応できるようにします。 最初の会議では18人が参加しました！多数派を代表する明確なリーダーや声はありませんでした。識別可能なクライアントはありません。会議は、学部長からのマイナーな機能に関する詳細な実装のアイデアから、Excelスプレッドシートをデータ入力に使用すべきかどうかについての議論へと変わりました。 想像できるように、私の頭は最後に回転していました。私は実際にはたくさんの良いアイデアを持っていましたが、それらを聞くことはできませんでした。マーケティング代理店の開発チームの一員になる前、これは私にとって非常に新しい役割です。プロジェクトマネージャー、クライアント、デザイナー、開発者という非常に明確な役割がありました。 経験豊富な開発者やマネージャーが、プロジェクトチームに似たものに同僚を誘い込む方法についての指針を教えてくれるかどうかを知りたいです。アジャイルは進むべき道ですか？すべての異なる声を処理する方法はありますか？いくつかのプロセスを非常に迅速に導入する必要があることは明らかですが、それが何であるかはわかりません。

15 web-development  project-management  agile  development-process  management 

私は現在プロジェクトに取り組んでおり、Githubのプライベートリポジトリにソースコードがあり、私たちはそれぞれ共同作業者です。 不明な点は、各作業を分離する方法です。 私たちがする必要があると思うことは： リポジトリをフォークする必要があります コードをプッシュする準備ができたら、プルリクエストをプロジェクトリーダーのレポジトリに送信します。レポジトリは、これを同時にコードレビューを行う機会として使用できます プライベートリポジトリに関しては、これはフォークを使用することになっているのでしょうか、それとも状況を複雑にしすぎていますか？

14 project-management  git  workflows  forking 

アジャイルプロセスには2週間のスプリントがあります。タスクは毎日配信され（毎日ビルド）、テストチームは翌日または同じ日にテストを完了します。 Devコードレビューもありますが、これには時間がかかります（1〜2時間）ため、週3回、月曜日から水曜日にスケジュールされます。開発者が集まり、コードを改善/リファクタリングする方法を提案します。 問題は、コードレビュー後にアクションアイテムが登場するまでに、ほとんどのタスクが既にテストされていることです。テスターは、既にテストに合格したものを再テストしたくない。内部の開発者の変更を気にしません。 アジャイルプロセスを誤解していますか？コードレビューは毎日のリリース/テストサイクルと互換性がありませんか？毎日コードレビューを行うことはできません。すべての人の時間がかかるからです。

14 project-management  agile  teamwork  code-reviews  sdlc 

私が現在働いている会社では、スクラムプロジェクトを始めました。管理者に滝からスクラムに移行するよう説得することはそれほど難しくありませんでした。プラットフォームをゼロから再構築するプロジェクトを行っています。（ほとんどの）機能は既知であり、ほとんどの改善はかなり技術的です。 これでは、ユーザーストーリーではなく技術的なタスクを持つことを正当化できます。バックログには、次のようなあらゆる種類の技術的なタスクがあります。 MySQLからPostgreSQLにDBクラスを書き換えます。 システムロギングを実装します。 オブジェクトキャッシュを書き換えます。 スタンドアップ中に出てくるものには、長い「研究タスク」が必要であるが、決して実行されないことが含まれます。また、チームメンバーは、スプリントの途中で、計画外のタスクを追加する必要があると主張します。 スクラムマスターはこれにどのように対処する必要がありますか？この種のプロジェクトにとって、スクラムは進むべき道ではないのでしょうか？

14 project-management  scrum  user-story  product-backlog 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 何年も変更されておらず、最終的に製品とチームの障害につながる現在のソフトウェア開発プロセスに対処する方法を知りたいと思っています。はい、おそらくこれを解決するより簡単な方法は仕事を変えることですが、この経済では言うよりも簡単です。ただし、特定の例があり、同じ状況で複数回見たり、経験したことがあり、これらの問題に対処する最善の解決策が会社を辞めることだと思う場合は、回答をサポートしてください。重要なのは、特にこの問題に関する複数の専門家が最終的なルートがルートAであることを示す場合、この質問には本当に答えがあるということです。 私は、多くの開発者が同じような状況にあったことを知っています。これは、企業が市場で第1位から最後に、あるいは市場から外れてしまう主な理由の1つです。この投稿の回答が、同様の障害に直面している他の開発者の助けになることを願っています。小規模または大規模な開発チームでは、通常これが発生します。 一部の開発者は気にせず、フローを採​​用することを決め、多くのコードをそのまま残し、開発プロセスをそのままにすることを好むようです。 他の人は変化に飽きて辞任し、別の会社に移動します。 他の人は話をすることを恐れて静かに過ごすことを好むようです。 時には非常に少数の開発者またはたった1人の開発者が製品の改善について意見を表明し、クライアント、ユーザー、およびチームのコーディングのベストプラクティスとその利点に従うことの重要性をチームに伝えます。これらのタイプの開発者は通常、会社が提供するメリットが非常に少ないソフトウェア会社や製品に多くの可能性があるなどの理由により、チームに留まることを決定します。 私たちのチームの製品は、製品の傘を持っているため、会社が収益を得る場所のほんの一部です（この会社はソフトウェア/ハードウェア会社ではないため、少なくとも今のところ、雇用を創出する継続的な特許訴訟はありません）不安定）。ここ数年、他の開発者の経験からこれまでに学んだことと、私の経験では、開発チームを本当に知るには、数日でも数週間ではなく、数か月かかるということです。チームがあなたを雇いたい、またはあなたを必要とする場合、面接プロセス中。彼らはすべてを素晴らしい音にし、あなたが聞きたいことをあなたに伝えるかもしれません。ただし、そのチームで作業を開始し、コードの内部を掘り始めて、完全なSDLCプロセスに移行するときの現実は異なります。これは、開発者として、あなたが仕事に就いたことの現実を見始めたときです。この現実により、ある会社から別の会社に移動したいと思うのは難しくなります。なぜなら、あなたが移動する会社が良いか悪いかを知るのは難しいからです。はい、Glassdoorのレビューなどを読むことができますが、HRからではなく、実際のオンラインレビューの数はどれくらいですか？ マネージャーは最初から常に変化に抵抗しており、以前の開発者は何年も同じことをしてきたことを考慮して、以下に概説する問題に取り組む最良の方法は何でしょうか？ 長年にわたる製品革新の欠如：製品には多くの可能性があり、会社に良い収益をもたらしますが、製品は20年前に作られたように見えます。一部のユーザーは、製品が使いやすくも直感的でもないと不満を述べ、他の人は、Gmailのようなアプリに使用され、同様の機能がないために製品を使用するときにイライラすることを述べています。ここでの主な問題は、開発者として製品に変更を加えて、製品の主要な要素を数ピクセル離れたところに移動しようとすると（ユーザーフレンドリまたは直感的に）、マネージャーがパニックして、元の場所に戻します。ユーザーの生産性を向上させる機能を追加しようとすると、「ユーザーはプロセスを行うのに慣れているなどの理由で」削除するように求められます。あなたは、変化、改善、革新に対する抵抗のポイントを得たと思います（開発者としてあなたが利益の強い議論を提供したとしても、マネージャーは変化に対して開かれていません）。同社はこの分野でいくつかの競合他社を抱えていますが（そのうちのいくつかの製品ははるかに競争力があります）、何とかして現在の顧客を何年も維持しています。 プロジェクト管理の調整の欠如：この結果、一部のプロジェクトがバグで遅れて配信され、一部のクライアントから苦情が寄せられたり（クライアントからもバグが報告されたり）、プロジェクトの配信前に予算が早すぎたりするなど。いくつかのプロジェクト調整のヒントとアイデアが、プロジェクトと実行するタスクの進捗を追跡するために定期的に使用されています。 悪いソフトウェア開発プラクティス：コードの臭いは、すべてではないにしてもほとんどのファイルに見られ、ドキュメント、コードの冗長性、フロントエンド層とバックエンドが同じファイルに混在している、古い開発ツール、実際のテスト環境もテストツールもありません（コピーアンドペーストのみ）開発環境から本番環境へのファイルを作成してから、手動でテストして問題が発生していないことを確認してリリースします）。チームがコード開発とソース管理に2つのIDEのみを使用しているため、チームが知らないところで開発とテストに使用する開発ツールのほとんどは、開発環境でのみ使用できます。他の開発者は最新のフレームワークを使用して現在の問題を改善しようとしましたが、マネージャーは「あなたが去ったら、そのコードを維持するのは誰ですか？、そのままにしておきましょう」という理由でそれを好まない去り、別の会社に移った。 要約すると、他の会社の多くの開発者にも同様の状況が起こると確信していますが、状況が異なるため、開発者は（仕事の都合、仕事の柔軟性、会社の利益、またはより良い機会が届いていないという理由だけで）。私が知っている完璧な会社はありませんが、開発者としてあなたがどのように行動し、物事をポジティブに保ち、最終的に製品の改善とソフトウェア開発プロセスの改善のための変更を促進するためにこれらの問題に対処しますか？長年の開発経験またはほんの数年）？これは投稿が長いことは知っていますが、より有用なフィードバックを得る可能性を高めるために、詳細を追加することを好みました。 フィードバックと時間をありがとうございました

14 project-management  programming-practices  team  project  legacy-code 

ですから、私が取り組んでいるプロジェクトは今、無期限に凍結されます。プロジェクトが再びフリーズ解除された場合、そのプロジェクトが私または現在のチームのメンバーに割り当てられない可能性があります。実際、以前に凍結した後、プロジェクトを継承しましたが、プロジェクトの基本的なニーズを理解するのに役立つ前のチームには何も残っていなかったため、プロジェクトをよく知るために多くの時間を無駄にしました。私の質問は、私たちの後の人々がプロジェクトのニーズ、私たちがやったこと、なぜやったのかなどを最もよく理解するのを助けるために何をすべきだと思いますか。このプロジェクトで動作する他のトラックへのいくつかのトラック。 すでに行ったいくつかの手順： 技術文書（完全ではありませんが、少なくともいくつかあります）。 ソース管理システムの履歴。 プロジェクトのどの部分を改善する必要があるのか​​、そしてなぜそうするのかについての見積もり。 ユニットテストの束。 私たちがやったすべてのチケットで問題トラッカー（EDIT） 私たちがすでに準備していること、他に何ができるかについてどう思いますか？

14 project-management  software  knowledge-transfer 

特定のアクションの最大実行時間を指定する非機能要件があるプロジェクトでは、QAは、要件で指定されているハードウェアと負荷の両方の正確な負荷の下で、正確なハードウェアを使用して専用マシンでこのアクションのパフォーマンスを確認する必要があります。 一方、ソースコードに誤った変更を加えると、パフォーマンスに深刻な影響を与える可能性があります。早くこのマイナスの影響に着目、前のソースコードは、ソースコントロールに到達し、QA部門によって検証され、問題の報告QA部門によって失われた時間の点で有益であり、開発者が後でそれをいくつかのコミットを固定できます。 これを行うには、良いアイデアですか？ ユニットテストを使用して、同じアクション²をn回実行するのにかかった時間を把握するには、 C＃の属性を介してテストごとのタイムアウトを使用するには[TestMethod, Timeout(200)]？ このアプローチにはいくつかの問題が予想されます。 概念的には、ユニットテストは実際にはそのためのものではありません。コードのごく一部をテストするだけであり、機能要件のチェック、統合テスト、パフォーマンステストのいずれでもありません。 Visual Studioの単体テストタイムアウトは、初期化とクリーンアップがこれらのテストに存在しないか、結果に影響を与えるには短すぎることを考慮して、実際に測定されると予想されるものを測定しますか？ この方法でパフォーマンスを測定するのはいです。ハードウェア、負荷などに関係なく、任意のマシン¹でベンチマークを実行することは、あるデータベース製品が別のデータベース製品よりも常に高速であることを示すベンチマークを実行するようなものです。一方で、これらの単体テストが決定的な結果になることや、QA部門で使用されるものになることは期待していません。これらの単体テストは、期待されるパフォーマンスについての一般的なアイデアを提供するためだけに使用され、基本的に、開発者に最後の変更が何かを壊し、パフォーマンスに重大な影響を与えることを開発者に警告します テスト駆動開発（TDD）は、これらのテストでは不可能です。コードの実装を開始する前に、そもそもどのように失敗しますか？ パフォーマンステストが多すぎると、テストの実行に必要な時間に影響するため、このアプローチは短いアクションのみに制限されます。 これらの問題を考慮すると、QA部門による実際のパフォーマンスメトリックと組み合わせた場合、このような単体テストを使用することは依然として興味深いと思います。 私が間違っている？これに単体テストを使用することを完全に受け入れられないようにする他の問題はありますか？ 私が間違っている場合、ソースコードがソース管理に到達してQA部門によって検証される前に、ソースコードの変更がパフォーマンスに深刻な影響を与えたことを開発者に警告する正しい方法は何ですか？ ¹実際、ユニットテストは、同等のハードウェアパフォーマンスを備えた開発者のPCでのみ実行されることが期待されています。 ²アクションとは、実行に数ミリ秒かかるかなり短いコードのことです。

14 project-management  unit-testing  performance  requirements 

議論の中で、私の同僚の一人は、バグを解決しようとしている間、彼の現在のプロジェクトにいくつかの困難があると言いました。「1つのバグを解決すると、他の何かが他の場所で機能しなくなります」と彼は言いました。 私はこれがどのように起こるのか考え始めましたが、それを理解することはできません。 疲れていたり眠すぎたりして、正しく作業できず、作業中のコードの一部を全体的に見ることができない場合、同様の問題が発生することがあります。ここで、問題は数日または数週間にあるようで、私の同僚の焦点とは関係ありません。 また、この問題は、非常に管理の行き届いていない非常に大きなプロジェクトで発生することも想像できます。チームメイトは、誰が何を行い、他の作業にどのような影響を与えるかがわからないのです。これもここでは当てはまりません。開発者が1人だけのかなり小さなプロジェクトです。 また、古い、メンテナンスが不十分で、ドキュメント化されていないコードベースの問題になる可能性があります。変更の結果を本当に想像できる唯一の開発者は、数年前に会社を去りました。ここでは、プロジェクトが始まったばかりで、開発者は誰のコードベースも使用していません。 それで、彼の仕事に集中し続ける一人の開発者によって書かれた新鮮な小さなコードベースで、そのような問題の原因は何でしょうか？ 何が役立ちますか？ 単体テスト（なし） 適切なアーキテクチャー（コードベースにはアーキテクチャーがまったくなく、予備的な考えなしに作成されたと確信しています）、リファクタリング全体が必要ですか？ ペアプログラミング？ 他に何か？

14 project-management  refactoring 

現在、私は有料のインターンシップに参加しており、過去5年間にわたって（異なる時期に）複数の開発者によって開発された古いシステムを維持する任務を負っています。経営陣は「システムは生命維持中」に同意しており、現在システムを使用しているエンドユーザーからかなり定期的にバグ報告を受け取っています。 現在、経営陣はプロジェクトをさらに1年間延長したいと考えており、その過程でユーザーベースのほぼ3倍になります。 インターン（または任意のエントリーレベルのポジション）として、「プッシュバック」する方法を教えてください。オープンエンドの文書ではありますが、私は懸念を述べた報告書をすでに書いています。変更を提案するためのプロトコルまたはドキュメントタイプはありますか？私は提案をする立場にありますか、それとも単に古いシステムをサポートし続けるべきですか？ 明確にするために、ソフトウェア開発は私の会社の主要なビジネスではありません。そのため、内部プロトコルは存在しません。さらに、プロジェクトには正式な文書もまったくなく、要件文書もありません。開発は非常にアドホックです。

14 project-management  internship  legacy 

4人の開発者のチームでアジャイル/スクラムの使用を開始しました。ストーリーの見積もりを行い、ストーリーを注文しました。製品バックログのプライミングストーリー。 まず、通常の1,2,3,5,8,13 ....の代わりに、1から5までの複雑さのポイントベースの推定から始めました。 いくつかのストーリーに取り組んだ後、4ポイントと推定されたストーリーの一部は2のみである必要があると感じましたが、2と推定されたストーリーはもっと複雑で、5と推定されるべきでした。知っている： 繰り返しの途中でストーリーの見積もりを変更しても大丈夫ですか？ 通常の1,2,3,5,8,13 ....の代わりに1から5までの現在の推定ポイントを使用することは問題ありませんか？ 私は個人的には両方のケースでノーであるべきだと感じていますが、自分の理解があまり明確ではないので自分をバックアップする必要があります（良い参考資料は良いでしょう！）

14 project-management  agile  estimation 

あなたが取り組んでいるプロジェクトが明らかに不十分に構築されており、将来失敗し、維持するのが悪夢である状況にあった場合、あなたはどうしますか...しかし、それはクライアントによって幸せです？ 私は気にしないでください？クライアントは、これよりも優れたアプリケーションを使用できることに気づいてさえいませんか？ どの時点でそれを正しく構築することを気にするのを止めて、ただ流れに行くのですか？

14 project-management  client-relations 

私が直面している問題： 私のチームメンバーは、機能/技術文書を準備せずにプロジェクトの作業を開始します-たとえ当社のプロセスが開始前にこれらが存在する必要がある場合でも。 私のチームメンバーは、安価で非構造化されたソリューションを受け入れ、プロジェクト管理者が「時間に限りがある」と気付いたときに、考え直すことなく、本当に悪いハックをソフトウェアに実装します。 私のチームメンバーは、テストされていない未完成の別のチームの未完成のプロジェクトと連携するプロジェクトに取り組み始めます。（多くの余分な作業を引き起こします）。 ソフトウェアの改善とフェーズ全体が適切に計画されておらず、多くの場合、バックエンド開発者が作業を開始しなければならないときにフロントエンド/設計が終了しないという結果になります。 私がここで働き始めて以来、これらの問題は何度も何度も議論されてきました。誰もが同意し、最終的には、プロセスを実施する必要があるということでした。つまり、バックエンドの開発者は、すべてが処理されるまで起動しません。 これらの問題は起こり続けています-そして、私は仕事自体と同僚の何人かに本当にイライラしているところまで、本当にやる気を失っています。 私のチームのメンバーは多くの不満を言います-しかし、お互いにだけ。They keep on going - whatever the situation is。結果？ 私は不安になります、おそらく私ですか？ これは物事がどのように進むべきなのか？ 私の質問？How can I say no against work ignoring the process if everyone else seems to mindlessly accept?。 それは、常に何かを悩ませるようなものを探している迷惑な開発者のようには見えません。

14 project-management  teamwork 

私は自分の部署にMercurialを紹介しました。私はそれが大好きですが、それは私の最初のバージョン管理の経験です。Web開発用にNetBeans PHPで使用しています。 社内のアプリケーションで作業する別の開発者は、Visual Source Safeの使用を好み、切り替えたくないと考えています。彼はVisual Studio環境で働いています。 他のすべての開発者は、これを除いてMercurialに買収しました。しかし、ほとんどの場合、私たちは皆独立して仕事をしています。 私はこの部門を正しい方向に動かそうとしています。Kilnのアカウントで全員を設定しました。Fogbugzを使用しているすべての人にも道を譲りたいと思っていました（現在、バグデータベースが維持されていないため） VSSを使用したことはありませんが、非常に悪いことを聞いています。 それが彼が好むものであるなら、彼にVSSの使用を続けることを許可するほうが良いでしょうか、それともMercurialで彼を乗せるのが最善の利益でしょうか？

14 project-management  version-control  team  visual-studio  mercurial 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新することがありますので、上のトピックソフトウェア工学スタックExchange用。 5年前に閉鎖されました。 以下のようハスケルウィキ自身が述べています： Haskellには多くのGUIライブラリがあります。残念ながら、標準的なものはなく、すべてが多かれ少なかれ不完全です。一般に、低レベルのベニヤは順調ですが、低レベルです。高レベルの抽象化は非常に実験的です。サポートされている中レベルのGUIライブラリが必要です。 私の大学の教授は、私と他の3つのコンピューターサイエンス専攻にHaskellのGUIライブラリを検討するように依頼しました。このプロジェクトに対する彼の最初のアイデアは、Smalltalkにあるモーフィックライブラリを模倣したOpenGLの上にレイヤーを書くことでした。ただし、これは単なる提案であり、他のシステムは間違いなく検討する価値があります。 これは、実際の複数の部分からなる質問につながります。 ライブラリはどのレベルの抽象化のために努力すべきですか？Haskell Wikiは、中レベルのGUIライブラリが推奨されることを強く示しているようです。ただし、高レベルのライブラリは引き続き歓迎されます。 ライブラリを何に構築する必要がありますか？（例：OpenGL） 私たちのライブラリーを模倣したい既存のGUIライブラリー（もしあれば）とその理由は何ですか？（例：PyGame、Morphic、Swingなど） ライブラリの実装または回避を希望する機能は何ですか？たとえば、Gnomeの良き人々は、最小化ボタンは不要だと主張するかもしれません。 一般的な提案はありますか？ この架空の図書館にどんな名前を付けますか？（例：HOT-Haskell Opengl Toolkit; HAWT-Haskell Advanced Windowing Toolkit）

14 project-management  gui  haskell  project-structure  opengl 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 私たちのチームは「Project In A Week」（ブートキャンプ）を行うことを考えていますが、他の誰かがこれを行った経験があるか、何かアドバイスがあるかどうか知りたいですか？ その背景にあるアイデアは、短期間で革新的で収益性の高い製品を考案するために、オフィスの気晴らしから逃れ、お互いに動機付け、チーム内で絆を築くことです。 計画では、開発チーム全体（約5人の開発者）、デザイナー、プロジェクトマネージャー、1週間のカンファレンスセンター/ホテルに1週間滞在するセールスおよびマーケティングのカップルを獲得します。1つのWebアプリ（事前に計画済み）を構築し、それを1週間以内にライブで市場に投入することに完全に集中します。私たちはかなり長い日働きますが、夕方にはチームとして一緒に楽しい時間を過ごします。日々のクライアントサポートに気を取られないように、チームのメンバーがオフィスに数人残っています。同様の「没入型」アプローチは、Firebrandなどのトレーニング会社で使用されています。 良いアイデア？ひどい考えですか？チームにインセンティブを与えるにはどうすればよいですか？ どんな考え/経験/アドバイスも大歓迎です。 乾杯

14 project-management  project  motivation  teamwork  team-building