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

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 4年前に閉鎖されました。 ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 私はチェックリストの大ファンです。ある旅行チェックリストは、チェックリストの移動、さらにはスクラムのチェックリストを。 コンテキスト：大企業に雇われ、ソフトウェア開発環境、プロセス、チームなど全体をセットアップする使命を与えられました。「カルテブランシュ」があります。ソフトウェアの有効な増分を作成する責任があります。プロジェクトサイズ：2000人/日。 次の（意図的に小さく不完全な）チェックリストに追加するアイテムは何ですか。 Continuous Integration Serverをインストールする DoDを書く 1ページのコーディングガイドラインを書く 製品バックログを作成する バグ追跡システムをインストールする 定期的なフェイスタイムのスケジュール

14 project-management  development-process 

十分にテストされたコードベースには多くの利点がありますが、システムの特定の側面をテストすると、ある種の変更に耐えるコードベースが得られます。 例は、特定の出力（テキストまたはHTMLなど）のテストです。多くの場合、テストは、特定のテキストブロックを一部の入力パラメーターの出力として期待するため、またはブロック内の特定のセクションを検索するために（単純に？）書き込まれます。 新しい要件を満たすため、またはユーザビリティテストがインターフェイスの変更をもたらしたため、コードの動作を変更するには、テストも変更する必要があります。おそらく、変更されるコードの具体的な単体テストではないテストでさえもです。 これらのテストを見つけて書き換える作業をどのように管理しますか？「すべてを実行して、フレームワークでそれらを整理する」ことができない場合はどうでしょうか。 他にどのようなテスト対象コードが習慣的に脆弱なテストになりますか？

14 development-process  tdd 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 私の現在の仕事では、要件の変更がたくさんあるように感じます。私たちは「アジャイル」ショップですので、私たちは調整することになっていると思いますが、時には変化は大きく、些細なことではありません。 私の質問は、変化のコストをどのように効果的に伝えるかです。アジャイルであるため、変更が十分に大きい場合、現在のスプリントから何かがドロップされますが、通常は次回に追加されます。私たちのモデルはSaaSであるため、最終顧客は事実上ビジネスそのものであり、彼らはn週間後にカット機能を取得することを知っています。 私は本当にそれだけ遅れたとして、通信に使用するものではありません、私は機能の除去である時に取得しようとしていますどのような推測のn週間。変更にかかるコストをビジネスに理解させるには、他にどのような方法が必要ですか？

14 development-process  agile 

私はExtreme Programming Explained、Second Editionを読み、第11章「制約の理論」で著者は古くて時代遅れの「プッシュ」開発モデルとXPの方法、「プル」開発モデルについて話しています。それは非常に重要な概念のように見えますが、非常に小さなパラグラフと、「滝」と反復プロセスの単なるイラストである2つの画像のみを必要とします。私は検索しましたが、本の残りの部分ではそれについてこれ以上説明しません。それについてのさらなる説明や議論もインターネットで見つけることができませんでした。 それらについての唯一の違いが、一方が「ウォーターフォール」であり、もう一方が反復的である場合、それらはなぜプッシュし、なぜプルするのでしょうか？ 誰が本当にこれら2つの違いが何であるかを理解し、いくつかの良い例を挙げていますか？

14 agile  development-process  extreme-programming 

私はソフトウェア開発チームのソフトウェアエンジニアです。過去3年間、社内顧客のために新製品を開発しました。この製品が完成したら、既存の製品の主要な新機能に取り組みます。特定の機能について、製品管理者は開発に150時間かかると推測しています。プロジェクトマネージャーと一緒に非常に詳細な計画を作成し、300時間の努力をしています。昨日私たちはこれについて議論し、彼らは私たちが物事を著しく過大評価していると考えています。 私たちの計画では、ユニットテストを書く時間を見積もっていましたが、彼らのアイデアは時間を節約するためにそれらをダンプすることです。まだ決定は下されていません。必要に応じて、この計画と単体テストを擁護します。しかし、ここで私が本当に嫌いなのは、経営陣が開発プロセスに干渉しているということです。開発プロセスからそれらを締め出すにはどうすればよいですか？また、ユニットテストを適切な状態に保つために、どのような引数を使用できますか（品質と長期的な時間の節約に加えて）。 ちなみに、当社には3つのエンジニアリングチームがあり、私が所属するチームはソフトウェアを予定通りに提供しています（10％のマージンを与えるか、またはマージンを取ります）。主に計画の過小評価が原因で、他のチームは常に遅れて配信します。彼らはコーディングのみを計画し、その周辺の管理、テスト、および取り扱いは計画していません。

14 development-process  management 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 2年前に閉店。 正式な方法を使用して、アプリケーションのコードを指定、証明、生成できます。これはエラーが発生しにくいため、主に安全/クリティカルプログラムで使用されます。 日常のプログラミングやWebアプリケーションなどでもっと頻繁に使用しないのはなぜですか？ 参考資料： 正式な方法 B法 ホアロジック

13 development-process  code-quality  formal-methods 

（フレームワークによれば）クロスプラットフォームであると想定されている、初期のC ++プロジェクトの1つを終えていました。ライブラリはすべてクロスプラットフォームであるため、OSXビルドを「後で」実行するのは簡単だと思い、プロジェクトをWindowsとVisual Studioで完全に開発しました。これは事実ではないことが判明しましたが、「Windowsコード」が正しく実行されず、修正すべきコンパイルエラーがいくつかありました。 コードがすべてのプラットフォームと互換性があることを事前に保証するために、どのような手法が存在しますか？すべてのプラットフォームを同時に開発し、新しいプラットフォームバージョンを次々に開発するのではなく、新しい機能が追加されたときに、すべてのプラットフォームに対して同時にコードをテストしますか？（*） ツールに依存するのではなく、使用するツールに関係なく、クロスプラットフォームの互換性を支援する「開発プロセス」ではなく、具体的にアドバイスを探します。上記の（*）のように。 具体的には、WDL-OL（https://github.com/olilarkin/wdl-ol）といくつかのクロスプラットフォームDSPライブラリを使用してVSTプラグインを開発しています。WDL-OLプロジェクトにはVSプロジェクトとXcodeプロジェクトの両方がセットアップされていますが、問題はライブラリーに起因し、コンパイラーの違いに起因すると推測します。

13 c++  development-process  cross-platform 

bugzilla、mantis、またはJIRAなどのバグ追跡/問題追跡ソフトウェアを、バグやタスクだけでなく、最終的に決定につながる議論を開始および維持するために使用した経験はありますか？ たとえば、開発者は、すべての保護フィールドを廃止し、それらにアクセスする保護メソッドを持つプライベートフィールドに変更する必要があると考えています。それは彼の呼び出しではなく、彼はそれを議論したいと思います。通常、彼は次の開発者会議でポイントを持ち出し、最後に決定が下されます。代わりに、私の考えは、彼が特定のタイプの「決定」の問題を開き、通常はバグやタスクを説明するように彼の意図を説明することでした。 他の開発者は、自分がそう思うとコメントすることができ、最終的に、問題は「受け入れられた」または「拒否された」としてクローズされます。 私がこれで見る利点： 非同期通信：決定のすべての影響を監督する時間がまだないときに、会議で意見を述べることを強制される人はいません。 決定に至る考慮事項の記録されたログ。後でその質問を再度提起した場合、彼はそれを参照することができます。 他の問題との関係を作ることができます。たとえば、タスクをフォローして決定に戻ることができます。 コミットなどのバージョン管理ソフトウェアとの統合は、決定にまでさかのぼることができます。 短所： 金色のハンマーの激しい匂い：通常、問題追跡ソフトウェアは実用的なアイテムを追跡するために使用されます 組織のオーバーヘッドは不均衡な場合があります。小さな非公式の会話の代わりに、書面でアイデアを伝える必要があります。

13 development-process  tools  issue-tracking 

詳しく説明すると、1人のプロジェクト（チームのソース管理、ドキュメント、ビルドなど）を実行している間に配置する必要があると考える人々と、2人目が来るまで何をする必要がないかを知ることに興味があります。プロジェクトに。 このシナリオを経験したことがある人なら誰でも、彼らの洞察に感謝します。

13 project-management  version-control  development-process  documentation  builds 

実際にコーディングを開始する前に、人々がソフトウェア製品をどれだけよく定義し、それが彼らにとってどれだけうまく機能しているかを知りたいと思いましたか？ユースケースの定義、リスクの分析、クラス図の描画などに言及しています。 最終製品が将来のリスクを回避できるようになるための十分なアイデアを持っていることは良いアイデアであることを知っていますが、適応するのが難しいほど製品を明確に定義しないことも重要です変化する。 他のより具体的な質問はおそらく次のとおりです。 通常、プロジェクトの時間の何パーセントが、開発前の計画段階で費やされますか？ コーディングを開始する前に満たそうとする特定の測定可能な基準はありますか、それとももっと直感的なものですか？ コーディングを開始する前にすべてのクラスの図を作成しますか、それとも物事が変化することを期待して、最初から動的なデザインを作成しようとしていますか？ 喜んで共有したい経験があれば最高です！

13 project-management  development-process  product-design  product-development 

私の状況の紹介 私は小さなWeb開発会社で働いています。私を含む4人のASP.NET開発者のチームがあります。ほぼすべてのプロジェクト（98％以上）は1人のプロジェクトで、完了までに1〜4週間かかります。ソースまたはバージョン管理は使用しません。唯一のものは、すべてのプロジェクトの最新のソース（==ライブアプリケーションのソース）を含むローカルサーバー上の共有フォルダーです。 まれに、同じプロジェクトで複数の人と作業する必要がある場合は、... Beyond Compareを使用します。1日に1、2回、開発者はお互いにコンパイルするバージョンがあるかどうかを尋ね、Beyond Compareを使用してコードを同期します。2人しかプロジェクトに取り組んでいない場合、これは「かなりうまく」機能しますが、3人目の開発者がプロ​​セスに入るとすぐに、管理不能なゴミになります。特に誰もがデータベースに変更を加え始めたとき。 私（および仲間の開発者の1人または2人）は、上司にGit、Mercurial、TFSなどの何らかの形式のソースおよびバージョン管理の使用を開始するように何度も言っています（私たちの上司は非常にマイクロソフトです）。残念なことに、上司はソースとバージョン管理システムに切り替えるメリットを認識していません。なぜなら、彼の目ではすべてがうまく動作し、新しいシステムのセットアップと全員の確認に時間とお金を費やしたくないからです。使い方を知っています。利点（コラボレーションの簡素化、アプリケーションのさまざまなバージョン、コードを変更するより安全な方法など）を彼に説明した後でも、彼はそれが必要だとは考えていません。 4人の開発者のうち、2人（私を含む）のみがソース管理（Git）の経験があります。そして、その経験は非常に限られています。Githubリポジトリーをコンピューターにクローンし、いくつかの変更を加え、コミットしてGithubにプッシュする方法を知っています。それでおしまい。 問題/懸念の説明 数週間以内に、私たちの標準のためのかなり大きなプロジェクトに取り組み始めます。おそらく、2〜3人の開発者がそれを完了するのに数か月かかります。私はプロジェクトリーダー（プロジェクトマネージャーおよびリードデベロッパー）になり、すべての責任を負います。Beyond Compareアプローチには問題がありますが、私の責任となるこの大きなプロジェクトでこの道を歩きたくありません。 私たちができることを疑うので 独自のGitサーバーをセットアップし、 みんなにGitを使って作業することを教え、 この大きなプロジェクトでGitをうまく活用し、 複数の人がソースやバージョン管理を使用せずに同じプロジェクトで共同作業できるようにする良い方法を知っている人がいるなら興味があります。 更新 皆の回答とコメントに感謝します。計画は次のとおりです。 開発者とミーティングを行い、すべての技術者がソース管理の実装について同じように感じるようにします。誰もが背後にいる場合、私たちはより強力なポイントを作ります。 アイデアを上司に提示し、ソース管理が本当に必要であることを彼に伝えます。 できるだけ早く実装してください。

13 development-process  version-control  teamwork 

時々プロジェクトに取り組んでいて、突然何かが突然現れて、作品に巨大なスパナを投げ込み、複雑さを大幅に高めることは、まれではあるが一般的な経験のようです。 たとえば、私は他のさまざまなマシンでSOAPサービスと通信するアプリケーションで作業していました。正常に動作するプロトタイプを作成し、その後、通常のフロントエンドを開発し、一般的に、すべてを素晴らしく、非常にシンプルで、簡単にフォローできる方法で実行しました。より広いネットワークでテストを開始し、接続の待ち時間とリモートマシンで計算を実行するのに必要な時間がSOAPサービスへのタイムアウトリクエストになったため、突然ページがタイムアウトするまで、うまくいきました。要求ごとに計算を実行するのではなく、バックグラウンドで段階的に更新できるように、要求を独自のスレッドにスピンアウトし、返されたデータをキャッシュするようにアーキテクチャを変更する必要があることが判明しました。 そのシナリオの詳細はあまり重要ではありません-実際、それは非常に予見可能であり、このタイプの環境用にこのタイプのアプリをたくさん書いた人々はそれを予想したかもしれないので、素晴らしい例ではありません-単純な前提とモデルから始め、突然プロジェクトの開発に複雑さをエスカレートさせることができます。 開発プロセスの後の段階で、またはテストの結果として、多くの場合仕様変更ではなく環境要因の結果として、これらのタイプの機能変更の必要性に対処するための戦略はありますか？可能性はあるが必ずしもそうではない可能性のある問題を軽減するソリューションを設計することで、同じくらい効果的である可能性が高いが、準備が整っていないソリューションを設計することで、時期尚早な最適化/ YAGNI /オーバーエンジニアリングのリスクを回避することのバランスをどのように取るか起こりうるあらゆる事態？ 編集：Crazy Eddieの答えには、「あなたはそれを吸い込んで、新しい複雑さを実装するための最も安価な方法を見つける」ということが含まれています。それで、質問に暗示されている何かを考えさせられましたが、具体的には挙げませんでした。 そのバンプにヒットしたら、必要な変更を組み込みます。プロジェクトをできるだけスケジュールに近づけるが、保守性に影響を与える可能性があることを行いますか、またはアーキテクチャに戻って、保守性が高いかもしれないが開発中にすべてを元に戻すより詳細なレベルでやり直しますか？

13 development-process  complexity  change 

ここで他の質問で書いたように、現在取り組んでいるプロジェクトにはソフトウェアプロセスがありません。意味することに何の（ハードコピー要件や仕様を含む）のドキュメント、無ソースコントロール、無バグデータベース（たぶん）、「固定」されているバグや新しいコードは、同じ時間、および正式なテスターで追加されていない-私たちは失敗するだろうジョエルテストひどく、面白くないです。 昨日、私のマネージャーは、これらの欠点を修正し始める方法についての文書を書くように私に頼みました。ここで6か月間、私は単なるインターンです。私は学校に戻るために11月に感謝祭の周りを離れます。ただし、このプロジェクトを正しい方向に進めることはできると思いますが、どこから始めればよいのかわかりません。私は現在、CiteSeerとWikipediaを使用して、ソフトウェアプロセスを説明し、それらを実装するいくつかの論文を見つけようと試みていますが、アドバイス、個人的な経験、またはブログ、論文、wiki記事などへのリンクは大歓迎です。

13 development-process  specifications 

文法、レクサー、パーサーに関する質問Clarificationに対する回答を読んでいると、答えは次のように述べています。 [...] BNF文法には、字句解析と構文解析に必要なすべてのルールが含まれています。 パーサーは文法に基づいているのに対し、これまでは常に字句解析は文法に基づいていないと考えていたため、これはやや奇妙に思えました。レクサーの作成に関する多数のブログ投稿を読んだ後、この結論に至りました。デザインの基礎として1つのEBNF / BNF を使用したことはありません。 パーサーと同様にレクサーがEBNF / BNF文法に基づいている場合、そのメソッドを使用してレクサーを作成するにはどうすればよいでしょうか？つまり、特定のEBNF / BNF文法を使用してレクサーを構築するにはどうすればよいですか？ EBNF / BNFをガイドまたは設計図として使用してパーサーを記述することを扱った多くの投稿を見てきましたが、レクサーデザインと同等のことを示すものは今のところ見つかりませんでした。 たとえば、次の文法を取ります。 input = digit| string ; digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ; string = '"', { all characters - …

12 design  design-patterns  development-process  grammar  lexer 

最近、アジャイルが使用される主な理由の1つは、クライアントが要件を頻繁に変更するためだと言っている多くの投稿を見てきました。 ただし、クライアントが要件を頻繁に変更しないとしましょう。実際、クライアントには多少あいまいな要件もありますが（不当にあいまいなものはありません）、要件はしっかりしていますが、とにかくアジャイルを使用しています。 私がアジャイルを採用する理由は、ソフトウェアが非常に複雑であるため、実際にそれらに直面するまで認識できない問題や詳細が存在するためです。ウォーターフォールのような本格的な重度の計画アプローチを行うこともできますが、その後、すべての高レベル設計と低レベルコーディングシグネチャを完成させるのに数か月かかります。ただし、システムには非常に具体的な固定アーキテクチャ設計があります。 私の質問は、これは悪い、カウボーイコーディング、アンチパターンなどと見なされますか？アジャイルでの「やろう」という考え方ではなく、要件が安定しているときにコーディングを開始する前に、ウォーターフォールを使用し、可能な限り詳細に計画する必要がありますか？ 編集：ここでの主要なポイントは、次のとおりです。要件の変更についてクライアントを責めることはできません。クライアントが私たちに非常に具体的な問題を指摘し、非常に合理的な詳細でウィッシュリストを提供し、私たちをそのままにしておくと仮定します最小のプロトタイプが完成したら終了します）。このシナリオでアジャイルを使用するのは間違っていますか？

12 agile  development-process