タグ付けされた質問 「feature-requests」

8
機能のリクエストとソフトウェアの変更をどのように管理しますか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 私はソフトウェアエンジニアであり、過去数年間、事実上ソフトウェアプロジェクトマネージャーになりました。そのため、R&D /エンジニアリング部門の健全性を維持するために、お客様はリクエストに応じて私に来ることに慣れています。私はこの分野での経験がないので、ソフトウェアプロジェクトのプロジェクトマネージャーとして行動するのは初めてです。私は他のものを管理しましたが、ソフトウェアは管理していません。 それでは、ソフトウェアプロジェクトをどのように管理し、優先順位をマークしますか?リクエストはまれにしか届かないため、他の人のために何かに取り組むことができ、その後、別の人が「急いで」仕事をする必要があります。ファーストカム、ファーストサーブと言う方が簡単ですか、それとも最もお金を持っている人ですか?

6
「メイン」機能のバックログと並行した「バイトサイズ」タスクのバックログ?
高度にサイロ化された「一匹狼」の開発部門構造で2年以上働いた後、アジャイルスクラムを採用しています。すごい。私はアジャイルが好きです。開発者として、無数の利害関係者が昨日プロジェクトを終えた後、プロジェクトをスローダウンすることなく、集中して忙しく生産的になります。 しかし、現在の「モデル」と対比してSCRUMに移行する側面が1つあり、開発部門以外の人は少しでも好きになれないと思います。それが、「待機中」に小さな変更を行う現在の能力です。私たちの開発の大部分は、社内での消費のみを目的としており、ほぼ全員が同じ建物内にいます。そのため、他の部門のリーダーまたはマネージャーが特定のアプリケーションの「コードベースの所有者」に来て、小さなものを要求することは長年にわたって一般的な慣習でした(それほど小さくはありませんが、これらの「ドライブバイ」に基づいた週プロジェクト)。私たちの上司でさえ、彼に持ち込まれたものをこのように中継することがあります。非常に頻繁に、その時点で問題のコードベースで作業している場合、ソースファイルをポップアップ表示するだけで、 基本的なアジャイルSCRUM方法論では、これらの調整は、欠陥(以前に消費したストーリーで指定された要件を満たしていない)または新しい小さなストーリー(記載されているすべての要件を満たしましたが、それらの要件は不完全、曖昧、または不正確でした) 、またはユーザーが新機能を見た後に配信後に変更されました)。どちらにしても、大半はないがほとんどゼロで、1-ポインタとなり、比較的低い優先度(システムは、現在の状態で使用可能ですが、それは次のようになりそうならば...ずっとクーラー)であることが、彼らがそうなって、バックログをトップダウンで操作するときにスプリントに持ち込まれます。 この可能性は、他の部門によるアジャイルプロセスへの積極的な反対の源として開発者会議で提起されました。これはIMOにとって有効な懸念事項です。POの背後にある利害関係者は、すべてが同じ視点を持っているわけではないため、最も重要なことについて常に同意するわけではありませんが、最終的な決定を下すのは通常マネージャーだけです。製品バックログに表示されます。 その後、暫定的に「キャンディジャー」と呼ばれる解決策が提案されました(別の用語は「グレービーボート」でした)。さまざまな部門の「リトルガイ」によって要求された小さな調整。既存のストーリーの欠陥ではなく、チーム内のコンセンサスまたは称賛により、開発者の1日の半分以下で済むと推定されます。エンドユーザーの意見では、ユーザーエクスペリエンスに対する即時の重要なプラスの影響が、プライマリバックログと並行してリストに追加されます。それらは「ストーリー」として識別されますが、優先順位付けの対象となる「大きな」ストーリーの主要なバックログとは別に保持されます。スプリントの通常の進行中にいつでも、これらの調整のいずれかを行うことができるシステムの領域で作業している場合、微調整を簡単にすることで、スプリントに微調整を加え、より大きなストーリーと一緒にコーディングできます。これをする大きなストーリーやその他のコミットされた作業の完了を危険にさらしてはなりません。POはこのリストにもアクセスでき、微調整を含む基本機能に触れる今後のユーザーストーリーに取り組んでいる場合、要件としてストーリーに組み込むことができます。その他。これにより、微調整がより早く実行される可能性が高くなると考えられていました。 これにより、スクラムマスターによる「ええと」のトレーニングが行われ、私たちの間に反応が生じました。バックログが1つあります。2つのバックログは、どの#1アイテムが本当に最も重要であるか、どのリストのアイテムが実際の速度を決定するか、2つのバックログのうちどちらが実際に属するかという問題を紹介しますどちらか一方に勝手に)。「プロセスを機能させる」と私たちは言いました。変更がエンドユーザーにとって本当に重要な場合、彼らは部門長が時間/お金の決定を行うのに十分な騒ぎをし、バックログのトップに対する開発チームの意識にぶつかるでしょう。 私は床に質問を投げかけると思った:あなたの意見では、「一口サイズ」の物語の平行リストは、小さく、有用であるが最終的には優先度の低い変更をより速くすることに価値があるか、それとも全体的に良い決定ですか?それらをメインのバックログに組み込み、スプリントへの組み込みを基本プロセスで管理するにはどうすればよいですか?

5
社内で営業担当者に使用できるシンプルな(無料?)機能要求追跡システムを知っている人はいますか?[閉まっている]
現在のところ、この質問はQ&A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 営業担当者からアプリを使用している顧客の悩みについて時々耳にしますが、現在これらを追跡する良い方法はありません。私は自分で1つを書くつもりでしたが、最初に尋ねると思いました。 私は文字通り新しい機能を追加するための小さなフォームに過ぎないので、stackexchangeの質問のようにリストに表示される、とてもシンプルなものを考えていました。その後、ユーザーはそれらに賛成票を投じることができます。または、ユーザーが要求に関連する何かについて不平を言うたびに記録することもできるため、実際のデータに基づいて優先順位を付けて注文することができます。その後、数日ごとに簡単に見て、何が起こっているのかを確認できます。それだけです、それ以上に複雑なものはありません。 何か知っていますか?

12
顧客からの「もう少しフィールドを追加できます」タイプのリクエストを処理する方法は?
非常に一般的には、1人の顧客のみが必要とするフィールドの機能要求があります。これは、せいぜい、アプリケーションのコードを乱雑にします。多くの場合、フィールドを追加してから数か月後にデータベースを調べると、実際には余分なフィールドさえ使用していないことがわかります。また、非常に古いアプリケーションであるため、単一のフィールドを追加するには、複数のコード変更、レポートの変更、およびフィールドを表示する必要のない他の顧客に影響を与えないようにする必要があります。 顧客がこれらの機能要求を実際に必要としていることをどのように確認できますか? 「本当に必要ない」と丁寧に言うには? 現在、特定の機能のリクエストに対して課金を開始しています。(以前は、機能要求は通常無料でした)他にできることはありますか?

3
コンパイラの作成コンパイラ-使用方法と機能に関する洞察
これは、言語設計で使用される概念をフレームワークの形で抽象化することを目的とした抽象化プロジェクトへの姉妹プロジェクトに焦点を当てた一連の質問の一部です。姉妹プロジェクトはOILexerと呼ばれ、一致時にコードインジェクションを使用せずに、文法ファイルからパーサーを構築することを目的としています。 構造タイピングに関連するこれらの質問に関連する他のいくつかのページは、ここに表示され、使いやすさはここにあります。フレームワークに関する問い合わせに関連するメタトピックと投稿する適切な場所は、こちらにあります。 特定の文法から解析ツリーの抽出を開始するところまで来ています。その後、DFAを使用して順方向パスを識別する再帰的降下パーサーが続きます(ANTLR 4のLL(*)と同様)。私はそれを開いて洞察を得るだろうと考えました。 パーサーコンパイラでは、どのような機能が理想的ですか? これまでのところ、実装されているものの簡単な概要です: テンプレート 特定の時点で何が有効であるかを把握しながら、予測を先読みします。 ルール内のリテラルを取得し、それらがどのトークンからのものであるかを解決するルール「非文字化」。 非決定的オートマトン 確定的オートマトン トークン認識のためのシンプルな字句状態マシン トークンの自動化方法: スキャン-コメントに役立ちます:Comment:= "/ *" Scan( "* /"); 減算-識別子に便利です:識別子:= Subtract(IdentifierBody、Keywords); 識別子がキーワードを受け入れないようにします。 エンコード-ベースN遷移のシリーズXカウントとしてオートメーションをエンコードします。 UnicodeEscape:= "\\ u" BaseEncode(IdentifierCharNoEscape、16、4); 16進数の4遷移を使用して、Unicodeを16進数でエスケープします。これとの違い:[0-9A-Fa-f] {4}は、Encodeを使用した結果の自動化で、許可される16進値のセットをIdentifierCharNoEscapeのスコープに制限します。したがって、\ u005cを指定すると、エンコードバージョンは値を受け入れません。このようなことには重大な注意事項があります。控えめに使用してください。結果として生じる自動化は非常に複雑になる可能性があります。 実装されていないのはCST生成です。これを機能させるには、適切なコンテキストを引き継ぐように決定論的自動化を調整する必要があります。 興味のある方のために、T *y♯プロジェクトの元のフォームをかなり印刷したものをアップロードしました。各ファイルは他のすべてのファイルにリンクする必要があります。それらに従うために個別のルールでリンクを開始しましたが、時間がかかりすぎました(自動化の方が簡単だったでしょう)。 さらにコンテキストが必要な場合は、それに応じて投稿してください。 編集5-14-2013:特定の言語でステートマシンのGraphVizグラフを作成するコードを書きました。 これがAssemblyPartのGraphVizダイグラフです。言語の説明でリンクされているメンバーは、そのルールのダイグラフを含む相対フォルダーにrulename.txtを持っている必要があります。例を投稿してから一部の言語の説明が変更されました。これは、文法に関することを簡略化するためです。これが興味深いgraphviz画像です。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.