タグ付けされた質問 「product-features」

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 詳細の追加を許可します：私は多くのコーダー、テスター、QAアナリスト、製品所有者などがいる施設で働いています。 私たちは、10年以上にわたって、くだらない（かなり機能的ではあるが）ソフトウェアを販売することができました。多くの機能があり、製品は競争力がありますが、そこには深刻なバグがあり、何千もの「ペーパーカット」があります-クライアントが慣れるのに少し面倒です。 コンピューターが私たちの生活を楽にするのに役立たないなら、私たちはそれらを使うべきではないと固く信じているからです。私は同僚に自信を持っています。彼らは賢く、能力があり、それを行うことに焦点が当てられているときに物事を改善することができます。 しかし、古い機能を閉じたり忘れたりすることなくバグを報告することは困難です。「昔のように機能しました」が典型的な答えです。また、QAがリグレッションを行うとき、彼らは、正しくないように見えるものと同じくらい異なるものを探す傾向があります。したがって、古い問題の修正はバグとして書き出すことができます。なぜなら、「それは私の時間よりも前からそうでした」からです。 私の若いコーダーは考えています：このおかしなことを書き直してください！営業に近い機会があったクライアントとして、私はこのアプローチに疑問の余地を与えたいと思います。 あなたの意見/経験にも興味があります。リスク、費用対効果、およびその他の非技術的要因を考慮してみてください。

18 business  product-features  usability 

少し前に、非常に小さなpythonスクリプトを作成し、定期的にxmlフィードの新しいエントリをチェックし、存在する場合は新しいエントリをユーザーに警告しました。私は自分でこれを書いたので、本質的にはコンソールベースのプログラムであり、コンソールインターフェイスに慣れている人なら誰でも使用できます。 しばらくして、私はそれが他の人々にとってより有用であると判断し、それを整理し、入力をサニタイズし、バグを除去し始めました。スクリプトを書いたので、それを効率的、正確に使用する方法を知っていたので、他の人はそうではなかったかもしれないので、GUIを追加し始めました。これは単純なメニューとして始まり、その後、インターフェイスとオプションメニューの両方を備えたより完全なGUIに拡張されました。次に、保存済みのユーザー設定と、以前に検索したxmlフィード用のストレージを追加して、繰り返し検索を高速化しました。 問題が発生した場合のアプリケーションのデバッグに役立つロギングを追加し、選択したプラットフォームで使用可能な最新の安定したpythonコードベースにアプリケーションを持ち込み、ダイアログ機能を改善しました。 私は自分のコードをバグ修正してコメントしましたが、アルファテスターが利用できるようにする前にアプリを改善するためにできることはまだあると思います。私のオリジナルの20〜30行のスクリプトとはかけ離れています。私が予想していたことは、概念実証から許容可能な使用プログラムに移行するのに1〜2時間かかるだけで、10〜20倍かかりました。（私はまだ初心者で、スタッフには長い時間がかかりますが、それでも...） 素材の追加/調整/修正を停止し、赤ちゃんを屋外でクロールさせるタイミングをどのように知っていますか？

16 development-process  product-features 

最近、フィーチャー交差に関するこの記事で説明されているものと同様の問題がますます多く見られます。私は通常、これらの問題を可能な製品構成の形で遭遇するのに対して、私はこれらを実際には異なる製品に帰する傾向があるものの、製品ラインと呼ぶこともあります。 このタイプの問題の基本的な考え方は単純です。製品に機能を追加しますが、他の既存の機能の組み合わせにより、どういうわけか物事は複雑になります。最終的に、QAは、これまで誰も考えていなかった機能のまれな組み合わせの問題を発見し、単純なバグ修正であったはずのものが、大きな設計変更が必要になることさえあります。 この機能の交差問題の側面は、驚くほど複雑です。現在のソフトウェアバージョンにN機能があり、1つの新しい機能を追加するとします。また、各機能をオンまたはオフにすることしかできず、2^(N+1)考慮できる機能の組み合わせがすでにあると言って、説明を簡略化しましょう。表現や検索用語が不足しているため、これらの組み合わせの存在を特徴の交差問題と呼んでいます。（より確立された用語のリファレンスを含む回答のボーナスポイント）。 ここで私が苦労している問題は、開発プロセスの各レベルでこの複雑な問題にどのように対処するかです。明らかなコスト上の理由から、それぞれの組み合わせに個別に対応することは、ユートピア的なところまでは非現実的です。結局のところ、私たちは正当な理由で指数関数的な複雑さのアルゴリズムに近づかないようにしていますが、開発プロセスそのものを指数関数的なサイズのモンスターに変えることは、まったくの失敗につながるはずです。 では、予算を爆発させず、まともな、有用な、専門的に受け入れられる方法で完全な体系的な方法で最良の結果を得るにはどうすればよいでしょうか。 仕様：新しい機能を指定する場合、他のすべての子とうまく機能することをどのように保証しますか？ 既存の各機能を新しい機能と組み合わせて体系的に検査できることがわかりますが、それは他の機能とは切り離されています。一部の機能の複雑な性質を考えると、この分離されたビューはすでに非常に複雑であることが多いため2^(N-1)、他の機能によって引き起こされた要因はもちろん、それ自体が構造化されたアプローチを必要としています。 実装：機能を実装する場合-すべてのケースでコードが適切に相互作用/交差することをどのように保証しますか。 繰り返しますが、私は純粋な複雑さについて疑問に思っています。2つの交差する機能のエラーの可能性を減らすためのさまざまな手法を知っていますが、妥当な方法で拡張できる手法はありません。ただし、仕様中の優れた戦略により、実装中は問題を回避できると思います。 検証：フィーチャーをテストする場合、このフィーチャーの交差スペースの一部しかテストできないという事実にどのように対処しますか？ 単一の機能を分離してテストしても、エラーのないコードの近くには何も保証されないことを知るのは十分に困難ですが、これを2^-N数分の1に減らすと、何百ものテストがすべての海洋の1滴の水をカバーしていないように見えます。さらに悪いことに、最も問題のあるエラーは、フィーチャの交差に起因するエラーであり、問​​題につながるとは予想されませんが、そのような強い交差が予想されない場合、これらのエラーをどのようにテストしますか？ 他の人がこの問題をどのように扱っているかを聞きたいのですが、私は主にこのトピックをより深く分析する文学や記事に興味があります。そのため、個人的に特定の戦略に従う場合、対応するソースを回答に含めるとよいでしょう。

11 complexity  product-features 

MySQL、SQL Server、Oracleなどの主要なRDBMSシステムのいずれも、フルテキストインデックス作成を適切にサポートしていないのはなぜですか。 ほとんどのデータベースはフルテキストインデックスをある程度サポートしていますが、通常は遅く、機能セットが小さいことに気づきます。本当に優れたフルテキストインデックスが必要なときは常に、データベースの外に出て、Lucene / SolrやSphinxなどを使用する必要があるようです。 これらの全文検索エンジンのテクノロジーがデータベースエンジンに完全に統合されていないのはなぜですか？データを最新の状態に保つことや、結果を他のテーブルと結合できないことなど、データをLucenceなどの別のシステムに保持することには多くの問題があります。これら2つのテクノロジーを統合できない具体的な技術上の理由はありますか？

11 database  product-features 

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

8 project-management  agile  product-features  code-ownership 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 この質問は同じラインに沿っているこのいずれかが、代わりにコードの品質について話を、私は、ユーザーの視点から、最終製品について話しています。時間と予算が限られていて、まともなソフトウェアから良質のソフトウェアに移行するためのソフトウェアの1つの属性（基本的な要件以外）しか保証できない場合、最も重要だと思うものは何ですか。 バグはできるだけ少ないですか？直感的なインターフェース？役に立つエラーメッセージ？優れた技術サポートとドキュメント？ソフトウェアをユーザーに安っぽく見せたくない場合は、常に何を含める必要がありますか？

8 product-features  quality