スクラムスプリントの追加の美容機能をどのように処理する必要がありますか？

私はスクラム文書を読んでいて、スプリントのタスクは「潜在的に出荷可能」でなければならないと言っています。

これが何を意味するのか混乱しています。Sprint 1の目標が「ユーザー登録フォーム」だったとします。

何かを出荷する準備をするために、どのくらい詳細を追加する必要がありますか？例えば：

1. 派手なスタイリングなしでフィールドを持つシンプルなフォームを表示し、完了マークを付けることができます
2. 完了マークとしてクライアント側の検証を行うことができますが、サーバー側もオプションまたは両方です
3. また、jQueryの便利なツールヒント、ホバーオーバー、キャプチャ、色、フォームのラベルを追加することもできます。
4. 次に、画面にエラーメッセージを表示する方法についてのスタイリングがたくさんあります

私は1つのトピックで無限に行うことができます。それで、それをどのように分割し、私はそれを出荷準備完了と考えることができます。

または、エラー、ポップアップ、またはライトボックステキストをサブタスクとして表示し、それらをスプリントとして配置するなど、できるだけ小さいものをそれぞれ記述する必要がありますか。これにより、プロジェクト全体で数千のタスクが発生します。

Internet Explorerで動作するものとFirefoxで動作するものがあれば、それらをタスクとして分割する必要があります。それらに時間を費やす必要があり、その時間にマネージャーがあなたに何をしたかを尋ねられたとき、私は伝えるべきタスクはありませんが、実際にはそれらはすべてユーザー登録の一部です

インターネットではなく、製品所有者とスクラムチームに同意してください。これは、完了の定義で決定する必要があり、チームの動作に大きく依存します。

機能は「出荷可能」である必要がありますが（Scrumではこの用語は嫌いです）、UIがなくても機能は出荷可能であると主張できます。スクラムでは多くの人がこの誤解に苦しんでいます。スプリントの目的は、できるだけ多くの（理想的にはすべての）「完了」を取得することですが、ほとんどの場合、リリースできるものに組み込む必要はありません。

チームの全員が共通の目標に向かって取り組んでいるように、このようなものを早期に解決することが重要です。スクラムの精神はコミュニケーションであるため、スクラムチームに尋ねて論理的な結論を導きます。

UIは通常、別のチームによって、またはUIの専門家がフォームの外観などを決定した後など、UIが通常個別に処理されるチームで作業する場合があります。また、小さなプロジェクト/チームでは、UIが行く。

チーム全員が答えを知っている限り、答えが何であるかは関係ありません。

表面的な機能が機能の一部である場合、おそらくストーリーの一部として実行する必要があります。重要なのは、ストーリーが完成したら、特定の機能についてこれ以上コーディングする必要はないということです。ただし、最終的にこれは製品の所有者によって決定されます。化粧品の機能が必要な場合とそうでない場合があります。これは、受け入れ基準に明記する必要があります。

それは必ずしもエンドユーザーが使用する準備ができていることを意味するものではなく、誰かのために準備ができていることを意味します。誰かがテスター、またはバックエンドチームなどの別のチームになる可能性があること。

開発者としてこれを尋ねている場合、答えは「製品の所有者が化粧品の機能が必要かどうかを教えてくれるので知っている」になります。

プロダクトオーナーとしてこれを求めている場合は、機能を複数のストーリーに分割するかどうかを決定する必要があります。顧客を満足させるための手段として、あなたを満足させなければならないこと以外に要件はありません。

覚えておいてください：目標はスクラムに厳密に従うことではありません。目標は、高品質のソフトウェアをエンドユーザーに提供することです。このような質問に苦労するときのガイドとしてそれを使用してください。純粋に機能的なパーツと同じストーリーに化粧品を追加すると、品質の高いコードを顧客に提供するのに役立ちますか？それとも、それを2つのストーリーに分けると役立つでしょうか？答えが明確であるか、それは重要ではなく、チームのために何でもできるのです。

「潜在的に出荷可能」とは、出荷可能なものとは限らないという意味です。例えば：

ひどく見え、フィールドで検証されていないWeb登録フォームは、学校プロジェクトのような状況では問題ないかもしれませんが、数百万ドルのビジネスでは、エンドユーザーに見せるためにブランドに損害を与えるでしょう。コードは、出荷したいものでなくても出荷可能である場合があります。また、マーケティングや法律により出荷できる場合もあります。

何らかの理由で実際にそのようにリリースされない場合でも（たとえば、デザイナーなど）プログラマー（およびデザイナーなどのこの時点で処理中のその他の人々）が、現状のままで喜んでリリースするものです。誰にでも出荷する前に他の言語に翻訳する必要があります-カナダは政府がソフトウェアを購入することに関して厳格な規則を設けており、フランス語だけでなく英語も同様に考慮しています）。

これは品質チェックポイントであり、すべての人を見て、今のままで出荷してもよいかどうかを尋ねます。余分な作業も、最後の1つを行ったかどうかの確認もありません。これを飛行機技師のチェックポイントと呼んでいます。あなたは目でエンジニアを見て、彼らがテスト飛行であなたに同行する気があるかどうか尋ねます。

アイデアは可能な限りアジャイルであることです。実際のユーザーに何かを早く届けることができます。個人を選択するためのコードのベータ版であるか、ウェブサイトでのA / Bテストであるかは、より良いことです。あなたの製品に対する期待によって定義されているように、ユーザーが粗すぎるコードを表示すると、役に立たないフィードバックを与えてしまいます。たとえば、ボタンが黄色で表示されたり、テキストボックスがラベルと一致しないことを嫌います。それが十分であれば、有用なフィードバックを得ることができます。このフィードバックを迅速に得ることができればよいほどです。製品/市場の適合性、および構築しようとした機能について行った仮定を検証できます。

機能の出荷は、これの最も重要でない部分です。開発チームを動かし、ユーザーストーリーを完成させることが重要です。何かが完了したと主張できるポイントに到達することは、大きな動機付けです。

私の理解では、それぞれの物語は「でき-完了」しなければならない、それはによる消費のための準備ができている限りの「出荷可能」誰か、必ずしもエンドユーザー。そのため、ストーリーはいくつかの機能を提供し、それが製品所有者に提供され、製品所有者はそれをエンドユーザーにリリースするか、機能を再度繰り返すことを選択できます。

とはいえ、「エンドユーザーとして、私は登録できる」というストーリーにスタイリングを含めることを妨げるものではありません。私たちのチームでは、すべてのストーリーをできるだけ小さくして、より高い予測可能性を維持し、約束したことを実現できるようにします。事前にデザインの準備ができていて、それを適用するのが簡単だと思う場合、それはストーリーに含まれています。設計に何らかの反復があるかもしれないと思う場合、それは別の話です-おそらく複数。

この質問に対する他の優れた答えに加えて、表面的な機能は、スコープ-リソース-時間の三角形の可変スコープ部分と考えることもできます。そのストーリーの基本的な要件を満たしていることを確認し、時間があればきれいなものを追加してください。

スクラムは、一定の時間内に特定の機能の配信を保証するものではありません。それは、与えられた時間内に可能な最大限の有用な仕事をあなたに与えることになっています。「オプションの」化粧品の特徴は、そのスプリント中に終わらない場合は、それがなければならない、彼らは不可能だったためです。

要件を設定する人、つまり「製品所有者」に依存します。プログラマーとして、私はスタイルのない「登録フォーム」ページに満足するかもしれません。このページは、私のWebサービスのビジネスロジックが正しく機能し、登録することでシステム内の他のリソースに対して認証できることを証明するだけです。実際、「潜在的に出荷可能」というのは必ずしも文字通りクライアントに出荷することを意味するわけではないため、特に技術チームと設計チームは、個別のバックログを持つ個別のリソースです。

より成熟したプロジェクトでは、最小限のスタイリングで「開発者設計」バージョンの機能をパイロットクライアントまたはベータクライアントに出荷しますが、機能の変更（フィードバックに基づく）と設計完了の両方で同じ機能を再検討します。

アジャイル手法の目的は、要件ではなく、ソフトウェア開発プロセスを推進することです。方法論の説明の1つが、真正かつ唯一の正統的な要件であると仮定するというtrapに陥らないでください。もちろん、特にスクラムが開発チームに混乱をもたらす言い訳になっている大規模な組織にいる場合は、言うよりも簡単です。