問題タブ [requirements]

私たちは、機能的に複雑な製品を開発している 3 人の開発者 (2 人は経験豊富ですが、この特定のビジネス セクターでは新しい) の小さなチームです。私たちはスクラムを使用しており、各スプリントの終わりにデモを行います。機能チームが多くのアイデアを持っていることは明らかですが、これらは開発チームに十分に伝えられておらず、デモは答えよりも多くの質問を提起しています.

機能的な人々からの入力の質を改善するための推奨事項はありますか?

詳細情報:問題の一部は、仕様やユーザー ストーリー自体がないことだと思います。個人的には、彼らはある種の要件を書き留める必要があると思います。どのようなものを書き留めるべきで、アジャイル プロセスを考えるとどのくらい複雑になるのでしょうか?

プロジェクトの要件を追跡するために使用できる wiki を探していますが、wiki を (フォーマット付きで) Microsoft Word にエクスポートできるようにしたいと考えています。これを行うwikiを知っている人はいますか？

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

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

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

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

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

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

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

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

私たちは現在の仕事でアジャイル開発を試みており、ほとんどの部分で成功しています。主な問題は、プロジェクトの開発者がスプリントの最初に要件を常に待っていて、最後まで物事を取り下げるために急いでいることだと思われます。要件を提供しているビジネスアナリストは、要件を達成するために常にノンストップで作業しています。

編集：追加情報： 私たちは、内部使用のためにCOTSアプリケーションをカスタマイズしています。私たちの「ユーザーストーリー」は、特定のスプリントでカスタマイズするアプリケーションの部分と、内部で統合するシステムで構成されています。さまざまなシステムとの統合は、すぐに作業を開始できるため、通常はかなりうまく機能します。「x画面のカスタマイズ」は、開発者がそれから何もできないため、主な問題領域です。BAから要件を取得するまで待ってから、実際に何かを実行する必要があります。

編集：より多くの洞察/混乱おそらく： これは大幅にカスタマイズされているCOTS製品であるため、問題の一部はカスタマイズされている画面がすでにそこにあることであるかどうか疑問に思います。人々は、ユーザーストーリーは「Xを実行する画面を作成する」の線に沿っているべきだと提案しています。それはすでに行われています。たぶん、これらの要件に対してユーザーストーリーを作成する良い方法はありません...たぶん、これはまったく新しい質問である必要があります。

私は金融会社の小規模な社内 IT 部門で開発者として兼務しており、プロジェクト管理がほとんど、またはまったく行われていない多数の中小規模のプロジェクトに携わってきました。これは常にスコープクリープを引き起こし、締め切りに間に合わず、短期間でユーザー/マネージャーを満足させるために優れた設計/コードを犠牲にしなければならないようです.

ユーザー/マネージャーの要求と期待を考慮して、コードを記述する前にユーザーの要件を明確にし、変更要求が適切に管理されるようにするために、開発者として何ができるでしょうか。

ありがとう。

私たちのチームは、どのようにして「プロダクト オーナー」から要求を収集し、摩擦をできるだけ少なくしながらも使いやすい方法で収集できるでしょうか?

ここにガイドラインがあります-それができない、またはビジネスが品質を気にするという決定を下す必要があるという投稿はありません、やだやだ。私が働いている製品は、何年にもわたって成功を収めてきた小さなグループです。私は彼らがそれを一段と高めるのを手伝いたいだけです。

基本的に、私は 1 人のプロダクト オーナーを含む 6 人か 7 人のチームに所属しています。彼女は素晴らしい仕事をしていますが、いくつかの異なる役割をこなしています (非常に小さなチームではよくあることだと思います)。通常、要件は散発的に与えられます (電子メールのやり取り、対面でのディスカッション、ミーティングなど)。それらはシステムに入力されることはなく、必要な機能を誰もが忘れたため、機能がリリースされなかったり、リリースが延期されたりすることがあります。

似たような状況で、これを克服する方法を見つけた場合は、ぜひお知らせください。この状況を緩和するためのコードを喜んで書きますが、プロダクト オーナーが何かを成し遂げるために行かなければならない Web サイトにはなりません。彼女は非常に忙しいので、これらの要件を収集するためにチームとして協力する方法が必要です。

私は現在、次のようなことを考えています: 開発者とチーム メンバーは、面と向かって議論された要件を収集し、wiki ページで議論された機能について簡単なメモを書きます。これらのページが更新されるたびに製品所有者に通知され、正確性を確保する責任は製品所有者にあります。

長所: 機能の記録がいくつかあります。短所: 開発者は、通常なら責任を負わないことに対して責任を負うことになります。私はここでそれで大丈夫です。こういう時こそチームワークだと思います。

もちろん、これを行うと、製品所有者が機能の正確さを保証するのに十分な時間がないことがわかります。最終的に彼女は過負荷であり、これはその事実を示すのに役立つと思いますが、最初にそのことに注意を引くことができる必要があります.

提案はありますか？

PS 彼女の時間は非常に限られているため、話し合いの後に要件を入力する必要があると期待するのは合理的ではないと考えられます。彼女には、それらについて一度話し合って先に進む時間しかありません。

2 人のアクター間の会話またはやり取りを含むプロセスをモデル化しているとしましょう。この例では、わかりやすいものを使用します:-

1. サプライヤーが価格表を作成し、
2. バイヤーは購入するアイテムをいくつか選択し、発注書を送信します。
3. サプライヤーは発注書を受け取り、商品を発送します。
4. サプライヤーが請求書を送付
5. 買い手は請求書を受け取り、支払いを行います

もちろん、これらの各ステップ自体は、すぐに複雑になる可能性があります。要件ドキュメントでこれをユースケースにどのように分割しますか?

このプロセスを 1 つのユース ケースとして扱うとしたら、1 冊の本を埋めることができます。

あるいは、上記の各ステップからユース ケースを作成すると、キャプチャする必要のある重要なインタラクションとフローの一部が隠れてしまいます。「注文書の受け取り」で始まり「請求書の送信」で終わるユースケースと、「請求書の受け取り」で始まり「支払いの実行」で終わる別のユースケースを用意することは理にかなっていますか?

何かアドバイス？

新しい機能セットを開発するために管理者の承認を得る必要があるエンタープライズ プロジェクトに取り組んでいるとします。通常、経営陣は、輝かしい新しい UI 機能を問題なく承認します。残念ながら、トランザクション、データの整合性、ワークフローのルーティング、構成可能性、セキュリティなど、アプリケーションの健全性にとって重要な舞台裏の問題を理解するのに苦労しています。これらの問題は技術的ではなく、すぐには見えないため、これが重要であることは明らかではありません。

これらのインフラストラクチャの問題に対処する必要があり、それがビジネス プロセスにとって重要であることをどのように彼らに納得させましたか?

1. すでに存在し、再利用可能なソフトウェア ソリューションの開発 (商用またはオープンソースのいずれか)。別名「車輪の再発明」。
2. 上記と同じですが、ソリューションが壊れています。別名「四角い車輪の再発明」。
3. 存在しない問題の解決策を開発する。

ここでも、 TRIZなどのより形式的なアプローチに興味があります。

クライアントがプロジェクトの範囲外の要件を要求した場合、プログラマーはどの程度柔軟に対応する必要がありますか？