タグ付けされた質問 「development-process」

私は最近、いくつかのサードパーティ製の「エンタープライズ」システムとその周辺での作業を伴うプロジェクトに雇われました。私が想像するのは、実稼働環境の十分に忠実なレプリカを構築するために必要な天文学的なコストと労力であるため、実際の開発環境を持つ見込みは、ごくわずかにしか見えません。 これはもちろん理想的ではありません。明るい面では、このような複製不可能な環境にソフトウェアを安全にテストおよび展開している人々がいるはずであり、おそらく彼らの足跡をたどることができるでしょう。 このような状況に効果的に対処する人はどのようにそれを行うのでしょうか？

12 testing  development-process 

私は組み込みシステム会社で働くソフトウェア開発者です。プロジェクトマネージャーがいて、プロジェクトの全体的なスケジュール（電気、品質、ソフトウェア、製造など）を担当しているため、ソフトウェアスケジュールは非常に短いです。 私の上司であるソフトウェアマネージャーもいます。彼は、ソフトウェアのスケジュール、設計文書（高レベルおよび低レベルの設計）、SRS、変更管理、検証計画とレポート、リリース管理、レビュー、そしてもちろんソフトウェアの作成と保守をさせてくれます。 ソフトウェアチーム全体（10人のメンバー）に対応するテストエンジニアは1人だけであり、常にいくつかのプロジェクトが進行中です。 私はこれらのドキュメントを作成するのに80％の時間を費やしています。私の上司はプロセスのバックグラウンドから来ており、必要なのはソフトウェアを改善するためのより良いドキュメントであると考えています。 彼はデザインが最重要であると考え、コーディングは「デザインを書き留める」だけで、それほど長くはかからず、「ハードウェアの準備ができる前にすべてのコードを書く」必要があります。 分散モデルとのコラボレーションが簡単だと彼に言った後でも、中央バージョンと分散バージョンコントロールの違いを理解していません。 コードを理解していないため、すべてのバグとその提案された解決策を理解したいと考えています。 検証は開発者が行い、検証はテスターが行うべきだと考えています。ただし、検証では実装が正しいかどうかのみをチェックし（単体テストは作成せず、スケジュールでは考慮されません）、検証はブラックボックステストであるため、単体テストはありません。 私は本当に混乱しています。 これらすべての文書を管理する責任はありますか？本質的に、ソフトウェアプロジェクト管理を行っているような気分になります。技術文書は問題ありませんが、開発者がスケジューリング/計画を立てるべきではないと考えています。 私はドキュメントの作成が本当に好きではありません。問題を解決してコードを書きたいです。私の経験では、設計ドキュメントの作成はある程度までしか役に立ちませんが、コードの改善や高速化の解決策になることはありません。 上司はより良い製品を作ることを本当に気にせず、経営者の目には良いマネージャーになることだけに関心があると思います。 私に何ができる？今年は3か月間実際のコーディングを行い、残りはドキュメントの作成とクライアントからのバグレポートの待機に費やしました。

12 design  project-management  development-process  documentation 

昨日、ウォータークーラーで耳にした：「スクラムには防衛契約の場がありません。」 私はスクラムが多くのシナリオで機能するように調整できると信じているという意味で意見が合わない傾向があり、防衛がそれらの1つであることがわかります。これは私の同僚の間でかなりの議論を巻き起こしました（私たちの多くは防衛契約で働いています）。 これを適切な質問にするには：防衛契約の状況でスクラムを使用した人（または使用経験がある人）はいますか？何がうまくいったのか、何がうまくいかなかったのか、バニラスクラムの変更（もしあれば）をしましたか？

12 development-process  scrum  development-methodologies 

コード生成を主張して、コード品質を向上させる方法の例を探しています。コード生成の意味を明確にするために、私のプロジェクトについてのみ説明します。 XMLファイルを使用してデータベーススキーマ内のエンティティの関係を記述するため、エンティティの追加、削除、変更に使用できるORMフレームワークとHTMLフォームの生成に役立ちます。 私の考えでは、人的エラーが減るため、コードの品質が向上します。何かが正しく実装されていない場合、モデル内で破損します。これは、より多くの生成コードが破損するため、エラーがより早く表示される可能性があるためです。 コード品質の定義を求められたので、これを明確にしましょう。つまり、ソフトウェア品質です。 ソフトウェア品質：相互に影響するのは、1つの属性ではなく、効率、変更可能性、読みやすさ、正確さ、堅牢性、理解可能性、使いやすさ、移植性などの多くです。

12 development-process  code-quality  quality 

これらの 投稿は関連しているように見えますが、私の脳は溶け始めています：P 私の雇用主はソース管理の使用を開始しました。主に、彼らがより多くの開発者を雇う前に、「リポジトリ」は主に自宅で働く孤独な開発者のハードドライブだったからです。彼が書いた.NETコードはすべてまとめてチェックインされ、多くの重複した（読み取り：コピーアンドペースト）機能があります。現時点では、SCMシステムは栄光のバックアップです。 重複したコードの一部を共有ライブラリに引き込みたいです。元のリポジトリはそのままにしておき、何も壊さないようにします。必要に応じて既存のコードを移動および/またはリファクタリングできます。それで、ライブラリを含む新しいコードのためだけにリポジトリを設定しました。 私の問題は、過度のプロセスに悩まされることなくライブラリをバージョン管理することを中心にしています。ソリューションが生産性に影響を与え始めた場合、うまく落ちます。 私の強迫観念での理想的な解決策は、ライブラリを個別にビルドし、各依存プロジェクトを意図的に選択した互換性のあるバージョンに対してビルドすることです。そのようにして、どのクライアントがどのライブラリのどのバージョンを持っているか、バグをより確実に再現でき、製品とライブラリの独立したリリースブランチを維持でき、共有コードを変更するときに互いのプロジェクトを壊さないようにできます。 これにより、特に自宅で働く開発者にとっては、ライブラリの更新が面倒になります。少なくとも当初は（最終的に）共通部分をまとめると、ライブラリが急速に変化することを期待しています。私はこれを完全に考えすぎている可能性が高く、最新のライブラリコミットに対してすべてを構築するだけで構いませんが、少なくとも一部のコンポーネントを個別にバージョン管理する必要があると判断した日には備えたいと思います配布されました。一部のライブラリをGACにインストールする必要があるという事実により、バージョン管理は特に重要になります。 だから私の質問は：私は何が欠けているのですか？1つのソリューションに固執しているように感じますが、現在、変更をよりスムーズにするバリエーションを見つけようとしています。以前、この種の問題を解決するためにどのような戦略を使用しましたか？この質問はあちこちにあることを理解しています。不確実な点を整理し、明確にするために最善を尽くします。 そして、私はMercurialを使いたいと思っていますが、私たちはすでに集中型商用SCM（Vault）にお金を費やしており、切り替えはオプションではありません。また、ここでの問題は、バージョン管理ツールの選択よりも深くなると思います。

12 development-process  version-control  release  versioning 

この言葉を聞いたのは約15年前です。 私の理解は、ウィキペディアの記事やTechRepublicの記事で説明されているものと似ています。「友好的で、個人的な感情を脇に置いて、同僚と一緒に」仕事をします。相互に敬意を払ってピアレビューを行い、学習したいという欲求を含み、コードを「所有」していると感じないため、誰かがバグを提案したり、バグを修正したり変更する必要があると言ったとしても、あなたはそれについて弁明しませんそれ。 また、コードを改善することを目標に、他のプログラマーと良好な関係を築く態度を持つことが主な目的だと考えました。だから私はそれがあなたの仕事の質に誇りを持っているとか、あなたがしたことがあなたの顧客に問題を引き起こした場合に後悔を感じると両立しないとは見ていません。 しかし、最近の質問に対する答えから、他のプログラマの中には「エゴレスプログラミング」について異なる理解を持っていると思うようになります。では、正しい定義は何ですか？そして、その意味は何ですか？

12 development-process  terminology 

私は、CEOが製品チームを管理している会社で働いています。CEOは、機能をモックアップし、開発者のラップをドロップして、その機能を実装します。もちろんいくつかの反復がありますが、開発者の意見は尊重されます。しかし、このプロセスはどれほど効果があるのだろうか。 ジェイソン・カラカニスは次のように書いた。 Zuckerberg Doctrine：開発者は、製品マネージャーや設計者と比較して速度と機能が大幅に向上した製品を設計し、潜在的な間違いや欠点を上回ります。 ... それから私は本当に衝撃を受けました：開発者主導のスタートアップは常に製品をより速く生産します。 これは理にかなっています。技術者ではない人々が議論や議論をしており、Zuckerbergが次の機能をコーディングしています。これが、誰もFacebookに追いつくことができなかった理由です！ MySpacersは自社の製品を反復する方法について議論していましたが、Facebookは単に試してみました。 これは実際には実際にうまく機能しますか？

12 development-process  product-design 

私が関与したすべてのプロジェクトで、外部コンサルタントからの意見がありました。どのような構成管理を使用しているかについて質問されました。これらのいずれの場合でも、コンサルタントは構成管理を定義できませんでした。それで何ですか？

12 development-process  management  configuration 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 コンソールアプリ（私のお気に入り）、クイック＆ずさんなフォーム、MSペイント（GUI用）; 標準アプリケーションで最もよく機能するのは何ですか？どうして？

12 development-process  testing 

私はかなり大規模なアジャイルチームのソフトウェア開発者です（8人の開発者が1つのコードリポジトリに積極的に変更を加えています）。2週間ごとに、ソフトウェアの新しいバージョンを運用環境にプッシュします。現在のワークフローは次のとおりです。 新しいタスクを開始するとき、開発者はメインの開発ブランチ（gitを使用）から「機能ブランチ」を作成し、この新しいブランチで作業します 開発者がタスクの作業を完了すると、機能ブランチを開発ブランチにマージして戻します 開発者は、開発ブランチをQAブランチにマージします。 QAブランチからビルドがトリガーされます。このビルドの出力はQA環境に展開され、テスターがテストを開始できるようにします。 テスターがQAブランチにマージされたこれらの新機能の問題を見つけることは非常に一般的です。これは、常に、QA環境にいくつかの新しい機能が含まれていることを意味します-テスト済みでバグのないもの、壊れたものなど。QAビルドが実稼働対応状態になることはまれなので、これによりリリースが困難になります。 これを軽減するために、開発者がリリースの数日前に開発ブランチをQAブランチにマージしないことを意味する「QAフリーズ」を開始しようとしました。QA環境のバグ修正はQAブランチで直接行われ、開発ブランチにマージされます。理論的には、これによりQAの新しい壊れた機能が排除され、QAで既に発生している問題を修正できます。 この「QAフリーズ」の概念は部分的には成功していますが、調整が難しく、QAへのマージが許可されているかどうかについて人々はしばしば混乱します。また、「QAフリーズ」の期限を設定することは困難でした。誰もがフリーズとリリースの間に息を吹き込む部屋のアイデアを好みますが、実際には、デッドラインを尊重するよりも次のリリースで機能を持ちます。 1週間おきにリリースのクリーンビルドを確保するより良い方法はありますか？

12 agile  version-control  development-process  branching  release-management 

もともと、テストを作成するのは開発者の義務ですが、多くの場合/ e-mature開発者では、これらのケースが80％のカバレッジでさえないことに気付きました。 開発者ではなく、特定のプロジェクトのすべてのテストを作成するQA担当者がいますか？ それに短所はありますか？

12 development-process  tdd 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 少しの背景：私が始めた小さなオープンソースプロジェクトがあり、HTMLコードを生成するオブジェクト指向の手段を提供する基本的なフレームワークです（HTMLがあまり好きではないので、PHPが好きなので） 。いくつかのリリースされたソースといくつかのダウンロードがありますが、主にプロジェクトは私にとってのものであり、オープンソースの部分は副次的な利点にすぎません。 私がこのプロジェクトで開発できるようになった元のプロジェクトは、当分の間ほとんど休止状態になりました。つまり、この時点で私がそれに没入するすべての開発は個人的な時間のみです。残念ながら、私は現在、学士号を取得するために働いており、認定資格を取得しています。自宅に3ヶ月の赤ちゃんがいます。要するに、私が「自分の時間」に近づく頃には、私は仕事をする気がすることはめったになく、むしろただリラックスするような気がします。 それで、同じような立場にいると感じる人が他にいるなら、プロジェクトに取り組む意欲を保つためにどの戦略を使用しましたか？少なくとも100％の仕様をカバーするまでこれに取り組みたいと思っていますが、数か月後にソースをコミットしていません。手伝ってくれる人はいますか？

12 development-process  open-source 

背景：私は最近会社で一連のプロジェクトを継承しており、それらの処理方法に関するいくつかの基本的な問題を整理しようとしています。つまり、以前の開発者（もはや会社にいない）は、いかなる形式のソース管理も使用せず、ほとんどドキュメントを作成せず、実際には適切な開発プロセスもありませんでした。 そのため、私は3つのサーバーに相当するプロジェクト（開発、ステージング、プロダクション）を手に入れました。これらは、主にWebサイト、アプリケーション、および使用するサードパーティアプリケーションとAPI用に構築されたツールから成り立っています。私が最初に考えたのは、変更と修正が行われる前にこれらすべてをGitに取り込むことでしたが、それを行う最善の方法を見つけるのは困難です。 これまでの多くの開発は、運用サーバーで直接行われたため、各サーバーのコードベースに格差が生じました。すべての違いがどこにあるのかすぐにはわかりません-開発/ステージングに引き継がれないバグ修正と、ステージング/プロダクションに移行していない開発の新機能が見られます。 質問：これらを整理してGitに移動する最良の方法は何でしょうか？コードの違いに対応するためにレポジトリ/ブランチをどのように構成しますか？ 実稼働サーバーコードのクローンから開発を継続し、開発/ステージングコードベースを履歴参照として保持することを検討しました。とにかく開発/ステージングコードについて何も知らないことを考えると、これは潜在的に最初のポイントになるでしょうか？各Webサイト、ツール、スクリプトセットなどの本番サーバーのリポジトリを作成し、既存の開発/ステージングコードのブランチを作成するだけで、新しい開発は本番サーバーのコードベースから分岐します。これは理にかなっていますか？

11 web-development  git  development-process  github  project-structure 

私の会社では、各機能/バグ修正ブランチがdevでどのようにマージされるかを確認するために中間ビルドを行わないのが一般的です。毎日のビルドのみがあり、常に多くのテストの失敗とビルドエラーが発生します。私は、1000人以上の開発者がマージごとにビルドするのは理不尽だと言われています。 それで、私はCIがそれ以上の開発者（Microsoft、Facebook）を持っている会社でどのように組織されているかを検索しましたが、何も見つかりませんでした。たぶん、インサイダーは私に言うことができますか？

11 development-process  continuous-integration  large-scale-project 

私は、ソフトウェア開発における日常的な作業の量は、無視できないとはいえ、比較的小さく、そしてそうあるべきであり、これがソフトウェア推定の基本的な問題であると確信しています。 この結論に至った経緯を説明し、議論に重大な欠陥があるかどうかを教えてください。 高精度で推定できるのは、以前に行われたことを意味する日常業務です。研究と創造性を含む他のすべての種類の作業は、少なくとも+/- 20％の精度では、実際には推定できません。 ソフトウェア開発とは、繰り返し作業を避けることです。その基本原則の1つはDRYです（繰り返さないでください）。プログラマーが繰り返し作業をしていることに気づいたときはいつでも、この繰り返しを回避する抽象化を見つける時が来ました。これらの抽象化は、繰り返しコードを関数に抽出したり、ループに入れたりするような単純なものにすることができます。また、ドメイン固有の言語を作成するなど、より複雑にすることもできます。いずれにせよ、それらの実装には、研究（これを以前に行ったことはありますか）または創造性が伴います。 これらの2つのポイントから、上記の結論を導き出します。 実際、私はこの関係が他のすべての議論、ブログ投稿、またはソフトウェア推定に関する記事で言及されていない理由をかなり長い間疑問に思っていました。理論的すぎますか？私の仮定は間違っていますか？それとも、ささいなことですが、なぜ私が知っているほとんどの開発者は、+ /-20パーセント以上の精度で見積もることができると信じているのですか？

11 development-process  estimation