スクラムスプリントで追加のコスメティック機能をどのように処理する必要がありますか？
私はスクラムのドキュメントを読んでいましたが、スプリントのタスクは「潜在的に出荷可能」である必要があると書かれています。
これが何を意味するのか混乱しています。 Sprint 1の目標が「ユーザー登録フォーム」だったとします。
何かを出荷する準備をするために、どれくらいの詳細を追加する必要がありますか？例えば：
- 派手なスタイリングなしでフィールドのあるシンプルなフォームを表示し、完了としてマークすることができます
- クライアント側の検証を完了としてマークできますが、サーバー側もオプションまたはその両方です
- フォームのjQueryファンシーツールヒント、ホバーオーバー、キャプチャ、色、ラベルを追加することもできます
- 次に、画面にエラーメッセージを表示する方法について多くのスタイルがあります
私は一つのトピックで際限なく行うことができます。それで、それをどのように分割するのか、そしてそれを出荷準備が整っていると考えることができるとき。
または、エラー、ポップアップ、ライトボックスのテキストをサブタスクとして表示するなど、可能な限り小さなものをすべて記述し、それらをスプリントとして配置する必要がありますか？これにより、プロジェクト全体で数千のタスクが発生します。
つまり、Internet ExplorerとFirefoxで機能するものがある場合は、それらもタスクとして分割する必要があります。それらに時間を費やす必要があり、マネージャーがその時間に何をしたかを尋ねられたとき、私は伝えるべきタスクはありませんが、実際にはそれらはすべてユーザー登録の一部です
これについては、インターネットではなく、製品の所有者とスクラムチームに同意してください。これは、完了の定義で決定する必要があり、チームの作業方法に大きく依存します。
機能は 'shippable'である必要がありますが（このスクラムではこの用語は嫌いです）、UIがなくても機能は出荷可能であると主張できます。多くの人々はスクラムでこの誤解に苦しんでいます-スプリントの目的はできるだけ多くの（理想的にはすべて）ストーリーを取得することですが、リリースできるものに組み込む必要はほとんどありません。
このようなことを早期に解決することが重要です。そのため、チーム全体の全員が共通の目標に取り組んでいます。スクラムの精神はコミュニケーションであるので、スクラムチームに尋ねて論理的な結論を導き出してください。
たとえば、別のチームによって、またはUIの専門家がフォームの外観を決定した後など、UIが通常は個別に処理されるチームで作業する場合があります。または、小さなプロジェクト/チームでは、UIが自分で構築されることが期待される場合があります。行く。
チーム全員が答えを知っている限り、答えが何であるかは関係ありません。
外観上の機能が機能の一部である場合、おそらくストーリーの一部として実行する必要があります。重要なのは、ストーリーが完成したら、特定の機能に対してこれ以上コーディングする必要はないということです。ただし、これは最終的には製品の所有者によって決定されます。化粧品の機能が必要な場合とそうでない場合があります。これは、受け入れ基準で詳しく説明する必要があります。
これは、必ずしもエンドユーザーが使用する準備ができていることを意味するのではなく、単にsomeoneの準備ができていることを意味します。誰かがテスターであったり、バックエンドチームなどの別のチームであったりする可能性があります。
これを開発者に尋ねると、答えは「わかります。製品の所有者が化粧品の機能が必要かどうかを教えてくれるからです」。
これを製品の所有者に求めている場合は、機能を複数のストーリーに分解するかどうかを決めるだけです。 あなたの顧客を満たすための手段としてあなたを満たさなければならないこと以外に要件はありません。
覚えておいてください：目標はスクラムに厳密に従うことではありません。目標は、高品質のソフトウェアをエンドユーザーに提供することです。このような質問に悩むときは、それをガイドとして使用してください。純粋に機能するパーツと同じストーリーに化粧品を追加すると、高品質のコードを顧客に提供するのに役立ちますか？または、それを2つのストーリーに分割すると役立ちますか？答えが明確であるか、それが問題ではなく、チームのために機能するものなら何でもできる。
「潜在的に出荷可能」とは、必ずしも出荷可能なものではなく、出荷可能なものを意味します。例えば：
ひどい見た目でフィールドで検証されていないWeb登録フォームは、学校のプロジェクトなど、状況によっては問題ないかもしれませんが、数百万ドル規模のビジネスでは、ブランドをエンドユーザーに表示するのに支障をきたします。コードは、出荷したいものでなくても出荷可能である場合や、マーケティングまたは法務により出荷が許可されている場合があります。
これは、プログラマー（および現在この段階にある他の人々（デザイナーなど））が現在のリリースを喜んで提供するものです。何らかの理由で、実際にはそのようにリリースされることはありません（例：誰にでも出荷できるようにするには、他の言語に翻訳する必要があります-カナダには、フランス語と英語を同等に考慮するソフトウェアを購入する政府に関する厳しい規則があります）。
これは品質チェックポイントです。すべての人の目を見て、追加の作業や最後のことを行ったかどうかを確認することなく、今の状態で出荷してもらえるかどうかを尋ねます。これは飛行機のエンジニアのチェックポイントと呼ばれています。あなたは技術者の目を見て、彼らが試験飛行に同行してくれるかどうか尋ねます。
アイデアは、できるだけアジャイルになることです。実際のユーザーに何かをすばやく提供できます。それが個人を選択するためのコードのベータ版コピーであるか、WebサイトでのA/Bテストであるかにかかわらず、より優れています。あなたの製品への期待によって定義されているように、ラフでラフなコードをユーザーに表示すると、役に立たないフィードバックが返されます。彼らはあなたが情報を探していないようなことについて話します：彼らはボタンが黄色であるか、テキストボックスがラベルと並んでいないことを好きではありません。それがIS十分に良い場合は、有用なフィードバックを得ることができます。このフィードバックをより早く得ることがより良いです！製品/市場の適合性、および試行した機能について行った仮定を検証できますビルド。
機能の出荷は、これの最も重要な部分です。開発チームを一緒に移動し、finishing User Storiesが重要です。何かが行われたと主張できるようになるのは大きな動機です。
私の理解では、各ストーリーは、someone、必ずしもエンドユーザーではない。そのため、ストーリーはいくつかの機能を提供する可能性があり、それをエンドユーザーにリリースするか、機能を繰り返し処理するかを選択できる製品所有者に提供できます。
そうは言っても、「エンドユーザーとして、私は登録することができます」という話にスタイリングを含めることは禁止されていません。私たちのチームでは、より高い予測可能性を維持し、約束したものを確実に提供できるように、すべてのストーリーをできるだけ小さくするように努めています。事前にデザインを用意していて、それを適用するのが簡単だと思う場合は、ストーリーに含まれています。設計にいくつかの反復があると思われる場合、それは別の話です-おそらく複数です。
この質問に対する他の優れた回答に加えて、外観上の機能は、スコープ-リソース-時間の三角形の可変スコープ部分と考えることもできます。そのストーリーの基本的な要件を満たしていることを確認し、時間がある場合はかなりのものを追加してください。
スクラムは、特定の機能が特定の時間に配信されることを保証するものではありません。それはあなたに与えられた時間で可能な最大の有用な仕事を与えると思われます。そのスプリント中に「オプション」のコスメティック機能が実行されない場合、それはすべきが不可能であったためです。
要件を設定する人、つまり「製品所有者」に依存します。プログラマーとして、私のWebサービスのビジネスロジックが正しく機能し、登録することでシステム内の他のリソースに対して認証を受けることができることを単に証明する、スタイルのない「登録フォーム」ページのコンテンツである可能性があります。実際、「出荷される可能性があります」。これは、必ずしもクライアントに出荷することを意味するわけではないため、これがトピックに関する最初のユーザーストーリーの結果になる可能性があります。特に、テクニカルチームと設計チームは、個別のバックログを持つ個別のリソースです。
より成熟したプロジェクトでは、最小限のスタイリングで機能の「開発者が設計した」バージョンをパイロットまたはベータ版クライアントに出荷できますが、機能の変更（フィードバックに基づく）と設計の完了の両方で同じ機能を再検討します。
アジャイル方法論の目的は、要件が反対ではなくソフトウェア開発プロセスを推進できるようにすることです。方法論の1つの説明が真正かつ唯一の正統的要件であると想定するという罠に陥らないでください。もちろん、特にスクラムが開発チームにカオスを課す言い訳になっている大規模な組織の場合は、言うよりも簡単です。