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

ソフトウェア開発のプロセスに関する質問。

9
開発者が自分のワークステーションで作業する方法の標準
開発者がプロ​​ジェクトの途中で数日間病気になったときに時々起こるような状況に出くわしたばかりです。 彼が自分のコードの最新バージョンをコミットしたのか、それとも私たちが見なければならないローカルマシンに何か新しいものがあるのか​​どうかについていくつかの質問がありました。彼が戻ってくる。 他の開発者の1人が彼としてログオンして、多くが同じプロジェクトのように見えるワークスペースを見つけて、どれが「現在」であるかが不明確になったタイムスタンプを見つけました（彼は、彼の「コア」1）。 明らかにこれは首の痛みですが、代替策（各開発者が最小の労力で物事を拾うことができるように各開発者が自分のマシンでどのように動作するかについての厳格な基準のようです）開発者の個人的な作業が流れ、個人レベルでの非効率につながります。 私は、チェックインコードの標準や、一般的な開発標準についても話していません。開発者がローカルでどのように動作するかについて話しているのです。 それでは、このような状況をどのように処理しますか？開発者に支払う代価は、彼らに最適な方法で作業することを許可されているのか、あなたが対処しなければならないことの1つですか？ または、開発者にこの分野の標準（特定のディレクトリの使用、標準の命名、Wiki上のメモなど）を遵守するよう依頼しますか？もしそうなら、あなたの基準は何をカバーしていますか、それらはどれくらい厳格ですか、どのようにそれらを取り締まりますか？ または、私が見逃している別の解決策はありますか？ [議論のために、開発者は彼がここで何をしているのかを話すために連絡できないと仮定します-メモリからどのワークスペースがどれであるかを知って記述できたとしても、単純で完璧ではない場合があります連絡しないでください。すべての不測の事態をカバーするソリューションが欲しいです。] 編集：誰かのワークステーションを通過するのは悪い形だと思います（それはなぜ興味深いのか、おそらくトピック外の質問です）、そして無制限のアクセスを見ていません。コードディレクトリが読み取り専用共有でセットアップされている標準のラインに沿ってもっと考えてください-何も変更できず、他に何も見えません。
1
フリーランサー：要件の収集についてはどうですか？
フリーランスのプログラマーとして： クライアントから要件を収集するためのプロセスは何ですか？ 要件収集プロセスにはどれくらい時間がかかりますか？これは修正されておらず、クライアントの応答方法などの変数があります。一般に、応答の遅延などを考慮して、最終要件に達するまでにどのくらい時間がかかりますか？ これらの要件を収集するために、どの通信チャネル（電子メール、電話、インスタントメッセンジャー、その他）を使用していますか？ 要件の収集に費やした時間は請求されますか？ 要件収集プロセスに成果物はありますか？もしそうなら、彼らは何ですか？
3
堅牢性と正確性の競争[終了]
閉じた。この質問には詳細または明確さが必要です。現在、回答を受け付けていません。 この質問を改善したいですか？詳細を追加し、この投稿を編集して問題を明確にします。 昨年は閉店しました。 要件の品質の段落の「コード完了2」を読んで、これを見つけました。 競合する属性間で許容できるトレードオフが指定されていますか（たとえば、堅牢性と正確性の間）。 （上記は要件の品質を確認するための大きなチェックボックスリストのポイントです） そのため、ウェブや学術書などで、堅牢性と正確性に関する多くの定義を見つけました。 例： 「Object Oriented Software Construction、2nd Edition、Bertrand Meyer、Prentice-Hall、1997」の本： 正しさ：システムの仕様、設計、および実装において[欠陥]がない程度。 堅牢性：無効な入力またはストレスの多い環境条件が存在する場合にシステムが機能し続ける度合い。 それにもかかわらず、なぜこの2つが対立するのか、どのような状況にあるのかは明確ではありません。 私の質問は、なぜこれらの2つの属性が競合するのかということです。
3
小さなチームにバージョン管理分岐ポリシーを導入する
私は最近会社で始めた請負業者です。 チームは3人の開発者であり、2人の下級から中級レベルの開発者で構成されており、同じレベルの別の開発者が間もなく開始され、私（6年xp）です。両方の既存の開発者にとって、それは大学/大学からの最初の仕事であり、彼らは以前に自分の仕事を監督する上級開発者を持ったことがありません。 明示的なバージョン管理ポリシーはありません。開発者はすべての開発をトランクで行い、開発マシンから直接本番環境に展開します。既存のチームは分岐に精通していません。 これをすべて変更し、CI、TDDテスト/ステージング/プロダクションサーバーなどを導入し、これを補完するバージョン管理ポリシーを導入します。 ソース管理システムはTFSであり、これまで使用したことはありません。1つの巨大なリポジトリとして構成されています。 私はそれらのいくつかの指針を書き留めましたが、チームの経験を念頭に置いて、追加/修正する必要がある他のものはありますか？ バージョン管理ポリシー 開発はトランクで行われます 変更に1週間以上かかると推定される場合は、ブランチで行う必要があります。トランクからブランチへの定期的なマージを行い、2つの同期がとれないようにします。 本番コード用に作成されたリリースブランチ。そのブランチには、安定したコードのみが含まれている必要があります。スプリントごとに1回、トランクから更新される1つのリリースブランチを作成するか、週ごとに個別のリリースブランチを作成することができます。 本番コードに影響する緊急のバグ修正を行う必要がある場合は、リリースブランチで行われ、トランクにマージされます。 1つのリリースブランチ戦略を採用する場合、トランクはスプリントの終わりに向かってスプリントごとに1回リリースブランチにマージされます。 リリース戦略ごとに個別のブランチを採用する場合、トランクはリリースブランチにマージされません。 一部のシナリオでは、分岐が多すぎる場合、異なる分岐でバグを2回修正する必要があります。短いスプリントをしている場合、これはあまり頻繁に起こるべきではありません。 3台のサーバーを使用する予定です。リポジトリ内の最新のコードを常に実行しているテスト環境。リリース候補コードおよびUATをステージング/テストするための最新のリリース候補を実行しているステージング環境、および運用環境。 私がこれを行うことを計画している理由は、これまでクライアントは内部ソフトウェアのみを実行していたためです。最新のプロジェクトは注目度の高いメディアクライアント向けであり、私は、チームが現在行っているものよりも専門的な開発モデルを採用する必要があると感じています。 たとえば、現時点では、ユーザーはバグレポートを使用してチームに電話をかけることができます。開発者はバグを見つけて修正し、自分のマシンで簡単な目玉テストを実行してから、実稼働環境に直接展開します。自動テストなどはありません。 後知恵では、機能ブランチはあまりにも遠いステップだと思うので、削除します。 したがって、本質的には、a）まったく分岐しない）b）リリースブランチとトランク、およびc）リリースとトランクごとのリリースブランチになります。 私は後者に傾いていました。私の最初の考えは、リリース候補と別々のサーバー（UAT / Production）で同時に稼働するリリースの両方を同時に持つことですが、事実上、トランクはいつでもリリース候補であるため、リリースは非常識に傾いています。私が考えたのは、利害関係者に開発コードを見せたくない場合は、別のリリース候補ブランチが必要になるかもしれないが、YAGNIとその他すべて.....
4
フロントエンド開発者は、バックエンド開発者向けにJSON形式を指定する必要がありますか？
私はプロジェクトでフロントエンドの役割を担っています。PHPがJavaScriptに返すJSONの正確な形式をバックエンドチームメイトに指定する必要がありますか？ たとえば、ここで説明する形式と同様の形式を使用する必要があることを伝えます。 フロントエンドで使用するためのJSONを適切に構成する方法 または、自分の役割を可能な限り無菌状態に保ち、単にバックエンドインターフェイスから必要な入力と出力を言葉で説明する必要がありますか？（もちろん、これが発生した場合、異なるデータ構造形式を処理することは私の側でより困難になる可能性があります）
9
雇用主の声に耳を傾け、CASEツールを使用する必要がありますか？
私の雇用主（開発者ではない）は、CASEツールが開発プロセスとドキュメントの改善に役立つと考えています。それについては定かではありませんが、私たちはローカルクライアント向けのモバイルバンキングソリューションを構築する5人の開発者から成る小さなチームです。CASEツールは購入する必要があるため時間とお金の無駄になり、慣れるまで時間がかかり、モデリングや作業のために効率的に作業する必要があると思います。コード生成は別の問題です。CASEで生成されたコードは、優秀な開発者が作成したコードほど優れていないと思います。 アジャイルの原則を守り、パターンを設計し、TDDを使用し、コードをクリーンに保つと思います。私たちは良いはずです。そして、分析と設計に関しては、ホワイトボード上の単純なUMLダイアグラムがトリックを行うはずだと思います。ドキュメントは適切で重要ですが、できる限り少なくする必要があります。ドキュメントに集中してコードを忘れてはなりません。これは私が思うことです。 私は正しいですか？または、雇用主の声に耳を傾け、適切なCASEツールの調査を開始する必要がありますか？
8
柔軟性のないプログラマーに対処する
長い間プロジェクトに取り組んでいるプログラマーは柔軟性に欠けることがあり、それらを推論することが難しくなります。たとえ彼らを納得させたとしても、彼らは私たちの提案を実行する可能性は低いでしょう。 たとえば、最近、ビルドとリリースのプロセスが複雑すぎて不要な障害物があるプロジェクトに参加しました。 欠陥管理ツールとバージョン管理ツールを統合するだけで、いくつかの開発オーバーヘッド（いくつかのスプレッドシートを埋めるなど）を取り除くことを提案しました（どちらもIBM-Rationalツールであるため、統合は非常に簡単な1回限りの作業です）。また、Maven＆Antなどのツールを使用すると（プロジェクトにはJavaといくつかのCOTS製品が含まれます）、ビルドとリリースを簡略化でき、手動のエラーと介入を減らすことができます。 私は何とか他の人を納得させ、概念実証を開発する努力をする準備ができています。しかし、「シニア」開発者は喜んではありません。おそらく、現在のプロセスが彼の価値を高めているからでしょう。 チーム内で摩擦を発生させずにこの状況をどのように処理しますか？
5
より表現力のあるプログラミング言語の進化により、ソフトウェア設計仕様の必要性は大幅に減少しましたか？
数年前の私を含む多くのIT担当者にとって、理想的なソフトウェア開発プロセスでは、コード行を記述する前に、多くのUMLダイアグラムを含む詳細な設計ドキュメントを作成する必要があります。（これはウォーターフォールモデルの説明のように見えますが、反復がより小さいことを除いて、アジャイルでも同じです。） 過去2、3年の間に、私は完全に考えを変えました。関連するテストケースを含む詳細な要件仕様は、絶対に不可欠であると私はまだ考えています。大規模なプロジェクトの場合、コーディングを開始する前に、アーキテクチャ全体の概要も必要になります。ただし、残りはすべてコードで可能な限り行う必要があります。理想的なケースでは、コード自体を除いてソフトウェア設計の説明はありません。 どのようにしてこの結論に達しましたか？以下にいくつかの引数を示します。 フィードバック 文書を書いたり、図を作成したりするツールはほとんどフィードバックを提供しません。はい、UMLダイアグラムの整合性チェックを行うモデリングツールがありますが、それらは制限されており、多くのオーバーヘッドが伴います。 フィードバックがなければ、エラーを認識して修正することは困難です。 コードを書くとすぐに、次のような多くのフィードバックが得られます。 コンパイラからのエラーと警告 静的コード分析結果 単体テスト エラーをすばやく認識して修正できます。 一貫性 コードがドキュメントと一致していることを確認するには、何度も確認する必要があります。頻繁な変更がある場合、コードとドキュメントの同期を保つのは困難です。 リファクタリング テキストの説明や図をリファクタリングするのは通常困難でエラーが発生しやすい一方で、コードをリファクタリングするための強力なツールとテクニックがあります。 この作業を行うための前提条件が1つあります。コードは読みやすく、理解しやすいものでなければなりません。これはおそらくAssembler、Basic、またはFortranでは達成できませんが、最新の言語（およびライブラリ）ははるかに表現力があります。 したがって、私の議論が有効であれば、ソフトウェア設計の仕様やドキュメントの軽量化や軽量化に向かう​​傾向があるはずです。この傾向の経験的証拠はありますか？
7
コード開発に適用される機械学習
私のバックグラウンドは機械工学ですので、この分野に対する私の無知をお許しください。 プログラミングとソフトウェア開発を本当に楽しんでいます。また、最近、スタンフォード大学のAndrew Ng教授が教える無料のオンラインMachine Learning（ML）クラスを受講しました。ここにリンクします。 この教授が、MLが決して影響を与えない分野を見つけるのは難しいと言うのを聞いたことがあります。 質問 私の質問は、機械学習をコード開発に適用するためにこれまでにどのような研究が行われてきたかということです。デバッグはどうですか？ 可能であれば、リソース/ソース/科学論文を含めてください。 多くの場合、ML およびソフトウェア開発（またはプログラミング）を検索すると、MLアプリケーションのソフトウェア開発（またはプログラミング）の結果につながるため、これを検索する運はありませんでした。
3
アジャイルはRADのバリアントですか？
ウィキペディアによると、アジャイルは「RAD」の一種であり、これは間違っていると思います。私が知っていることから、アジャイルはRAD自体が90年代に成功しなかったために開発されました（変更にはあまりにも厳格です）。それとも私は間違っていますか？ （備考：どうやらアジャイルソフトウェア開発に関するWikipediaの記事は、間に改善されたが、それだけで一覧表示されますRADをないスーパーセットとして、アジャイルの前身として）。 本Radical Project Management（Thomsett）からの参照 「..RAD、アジャイル、オブジェクト指向などの新しい開発の流行...」 CISA認定情報システム監査員： ..2 つの代替ソフトウェア開発を認識しています。メソッド：アジャイルで迅速なアプリケーション開発 ソフトウェアのアジャイル管理： アジャイルメソッドは、主にRADの軽量アプローチから派生しています。 ソフトウェア推定のベストプラクティス： swの主な方法。開発者 次のように要約できます 。1.ウォーターフォール.. 4. RAD 5.アジャイル この質問のポイントは次のとおり です。アジャイル型はRADですか、それともスタンドアロン開発アプローチですか？
6
スクラムと継続的インテグレーションによるソフトウェア開発のための優れたワークフロー
私は、スクラム方式を使用したソフトウェア開発会社において、継続的インテグレーションワークフローがどのように適合するかをよりよく理解するためのアプローチを研究しています。 私はこのようなことを考えています： それは素晴らしいワークフローでしょうか？
7
職場でのペアプログラミングはどのくらい一般的ですか？
私はいつもペアプログラミングに興味を持っていますが、12年の開発で、彼らがこのプラクティスを採用した場所で働いたことはないので、人々がそれをどう見るかについて常に懐疑的です。 これはお金/時間（同じコードで作業している1台のコンピューターで2人の人を見つけた先の尖った上司!!!!彼らはあえて！）または他の理由によるのだろうか？
5
厳格な非アジャイル手法を使用するチームにアジャイルを導入する方法は？
アジャイル以外の方法論に対して誇らしげに認定され、説明責任を実証するための顧客へのセールスポイントとして使用している会社を考えてみましょう。 かんばんやスクラムを、システム全体を壊さずに徐々に導入し、それでもなお説明責任/監査可能であると自信を持たせるにはどうすればよいですか？ これは「スクラムのようなアジャイルな方法論をどのように導入しますか」に関連する可能性がありますが、ここでは、会社がSDLCを誤ったふりをしてSDLCを管理する特定の方法を課しているという事実を回避/回避する方法について疑問に思っています監査証跡を持つ唯一の方法。
9
機能の追加をいつ停止するかをどのように知っていますか？
少し前に、非常に小さなpythonスクリプトを作成し、定期的にxmlフィードの新しいエントリをチェックし、存在する場合は新しいエントリをユーザーに警告しました。私は自分でこれを書いたので、本質的にはコンソールベースのプログラムであり、コンソールインターフェイスに慣れている人なら誰でも使用できます。 しばらくして、私はそれが他の人々にとってより有用であると判断し、それを整理し、入力をサニタイズし、バグを除去し始めました。スクリプトを書いたので、それを効率的、正確に使用する方法を知っていたので、他の人はそうではなかったかもしれないので、GUIを追加し始めました。これは単純なメニューとして始まり、その後、インターフェイスとオプションメニューの両方を備えたより完全なGUIに拡張されました。次に、保存済みのユーザー設定と、以前に検索したxmlフィード用のストレージを追加して、繰り返し検索を高速化しました。 問題が発生した場合のアプリケーションのデバッグに役立つロギングを追加し、選択したプラットフォームで使用可能な最新の安定したpythonコードベースにアプリケーションを持ち込み、ダイアログ機能を改善しました。 私は自分のコードをバグ修正してコメントしましたが、アルファテスターが利用できるようにする前にアプリを改善するためにできることはまだあると思います。私のオリジナルの20〜30行のスクリプトとはかけ離れています。私が予想していたことは、概念実証から許容可能な使用プログラムに移行するのに1〜2時間かかるだけで、10〜20倍かかりました。（私はまだ初心者で、スタッフには長い時間がかかりますが、それでも...） 素材の追加/調整/修正を停止し、赤ちゃんを屋外でクロールさせるタイミングをどのように知っていますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.