問題タブ [backlog]

私たちは、ソフトウェアでやらなければならないことの大量のバックログを、多くの異なるカテゴリで抱えています。たとえば、次のとおりです。

• 当社の製品が解決すべき新しい問題領域
• 既存の問題領域をサポートする新機能
• 既存のユーザーから要求された新しい機能
• 使いやすさと「見た目」の向上
• バックエンドへのアーキテクチャのアップグレード
• バグの修正

これらすべてを賢明な方法で管理することは、製品管理の仕事ですが、多くの理由で注意が必要です。まず、さまざまなものを保持するさまざまなシステムがあります (ファイル内の市場要件ドキュメント、バグ データベース内のバグ、ヘルプ デスク システム内の顧客要件、イントラネット上のエンジニアリングのウィッシュ リストなど)。次に、アイテムの多くは、サイズ、範囲、複雑さ、そしてもちろん価値が大きく異なります。つまり、選択は、リストを優先順位で並べ替えるほど単純ではありません。

現在、私たちはかなり大きく、複雑な製品と多くの顧客を抱えているため、基本的なソリューション (スプレッドシート、Google ドキュメント、ベースキャンプの To-Do リスト) だけでは、これに対処するには十分ではありません。物事をさまざまな方法でグループ化し、継続的に優先順位を付け、現在行っていることとこれから行うことを明確にする方法が必要です。ツールを管理するだけで誰かの時間を費やす必要はありません。

ビジネスが常に既存の顧客にとって最も価値のあることを行い、新しい顧客の獲得を支援し、ソフトウェアの内部を正常に保つことができるように、これをどのように管理しますか?

これは開発側とは異なることに注意してください。すべてを反復的かつアジャイルな方法で開発し、設計と実装のために何かを選択したら、それを実行できます。一番難しいのは、次に何をすべきかを考えなければならない部分です！

うまくいく方法やツールは見つかりましたか？もしそうなら、共有してください！(そして、答えも知りたい場合は、質問を評価して、表示されたままにしてください:)

補遺:もちろん、最初にすべてのバグを修正するのは良いことですが、顧客のマシンに実際にインストールされる実際のシステムでは、それは必ずしも実用的ではありません。たとえば、非常にまれにしか発生せず、修正に膨大な時間とアーキテクチャ上の大変動が必要なバグがある場合は、しばらく放置することがあります。または、誰かが何かを使いにくいと考えているバグがあるかもしれません。それを修正するには、その領域の大幅な改良を待つ必要があると考えています。そのため、すべてをすぐに修正するのではなく、忘れないように開いたままにしておく理由はたくさんあります。さらに、最も難しいのはバグ以外の優先順位付けです。何も持っていないと想像してみてください:)

「サーバーをv1からv2にアップグレードする」、「起動パフォーマンスを向上させる」、「ログインモジュールをリファクタリングしてコードの複雑さを軽減する」などの技術的な項目が製品のバックログに含まれる場合、技術的でない製品所有者がそれらに優先順位を付けるにはどうすればよいですか。対他のより機能的なバックログアイテム？

技術的なもののために別のバックログがあるべきですか？製品のバックログで機能的および技術的なものを優先できる2人の共同POの役割を担う必要がありますか？

アジャイルの原則、特にスクラムの原則と XP のようなユーザー ストーリーを開発プロセスに適用しようとしているときに、アーキテクチャに関する問題に直面しました。

私たちはまだアーキテクチャ中心の開発に結び付きすぎているかもしれませんが、アジャイル モデリングの原則と組み合わせて、強力なコンポーネント ベースの開発を維持しようとしています。私たちの目標は、開発中に進化しやすい小さなデザインを前もって用意することです。

私が探しているのは、私のアーキテクチャとその内部のコンポーネントに関するバックログのストーリーに入れることができるものです: 使用の話だけでなく、開発の話です。システム ストーリーは別の種類のユーザー ストーリーである可能性があります。これは、厳密にはビジネス価値に関連するものではなく、システムのアーキテクチャと品質の問題に関連するものです。

編集： 「開発者の話」に関するオールボー大学のこの研究 を見つけました。

経験、アイデア、または反対はありますか?

前もって感謝します！(これは私の最初の質問です! :D)

スクラム プロジェクトの優れた視覚化/追跡の作成に苦労しているため、いくつかの代替案を検討しています。興味深い概念の 1 つに、ストーリー マッピングがあります。フラット バックログの代わりにストーリー マップを使用することについて何か意見はありますか?

スクラムプロジェクトを管理するためにAgiloをインストールしましたが、その問題があります。1つのバックログしか処理できません。どうすれば異なるバックログを持つことができますか？

御時間ありがとうございます！

私は巨大なプロジェクトに取り組んでいます。私たちがプログラミングをしている間、最終的には、すべての開発者がチームと一緒に座ってユーザー ストーリーのサイズを決定する、エンドレスなバックログ サイジング セッションのミーティングを行います。

スクラムに懐疑的な人々は、このプロセスに時間がかかりすぎて、開発時間が無駄になっていると言っています。

私の質問は、ユーザー ストーリーのサイズを調整するのに平均でどのくらいの時間がかかるかということです。また、これらのサイジング セッションをより迅速に行うためのヒントはありますか?

Windows ポートのバックログ キューには最大 200 の上限があるようです。本当ですか？もしそうなら、私は制限を変更できますか？

Windows XP Professional で ServerSocket.accept(backlog) を実行しています。

Windows Server に移行する必要がありますか?

Socket クラスを使用する場合、あるポートでサーバーへの TCP 接続を確立しますが、サーバー上では、ServerSocket は各受け入れ要求に対して複数のクライアント接続を処理し、それをスレッドに委譲して要求を処理することができます。しかし、ServerSocket クラスが同じポートで複数の tcp 接続を受け入れるにはどうすればよいでしょうか。

許可する接続数または許可される最大バックログを決定するのはOS次第であることを意味しますか?これは、OS上のアプリケーションによって制御できます(つまり、JavaはOSによってサポートされる最大バックログによって制限されます)。 TCP仕様にバックログ接続の制限はありますか?

敬具、
ケシャブ

私は最近、開発サイクルのためにスクラムを導入し始めた会社にインタビューしました。開発者の一人に彼らの経験はどうだったのか聞いたところ、彼らは計画プロセスから完全に切り離されたようです。彼は、特定のスプリントに何が入ったかについての入力を許可されず、計画やグルーミング活動にも参加しませんでした。

基本的に、最後のスプリント（または2つ）の開始時に、彼はやることリストを手渡されました。彼はアイテムをそれぞれのタスクに分解する必要がありましたが（スプリントで作業できるようにするため）、計画活動には関与していませんでした。私は彼がアイテムがどれだけの努力をするかもしれないかについて多くのインプットを許されたのではないかと疑っています-建築家がチームのためにこれを決定したのではないかと思います。

これはスクラムの処理方法ですか？私の現在のチームは、すべての計画活動に完全に参加しており、機能に対処する方法と、機能にかかる可能性のある作業についての情報を継続的に追加しています。私は、開発者に入力を求めずにやることリストを渡すだけの会社に少し懐疑的（そして神経質）です。

注：スプリントが開始されると、リストは実際には優先されるToDoリストであることを理解しています。私の懸念は、最初から計画プロセスに情報を提供していないことです。

バックログを整理していて、完全に有効であるが優先度が非常に低いユーザーストーリーが表示された場合、それを削除する必要がありますか？バックログは、作業に取り掛かる可能性のあるユーザーストーリーだけであると想定されているのでしょうか、それとも、ブレーンストーミング中に得たアイデアであっても、製品に関連するすべてのユーザーストーリーである必要があります。アイデアが顧客の要求として生まれたが、それが製品所有者の観点から優先度の高いアイテムではない場合はどうなりますか？