スクラム：ユーザーストーリーのデザイン/ UXが実装と同じスプリントで発生しても問題ありませんか
私は現在、スプリント（2週間）中で、デザイナーが特定のユーザーストーリーの要件とUXを定義することを任されています。
同じスプリントで、私はこのデザインを実装します。スプリントの計画中、私はこの未定義のユーザーストーリーがどのくらいの時間を要するかについて、大まかな推測をしなければなりませんでした。
今日、ようやくデザインを受け取りました。残念ながら、設計は不完全で曖昧であり、設計よりもクライアントの要件に似ています。しかし、これからも、まだ十分に見積もっていないことがわかります。
さらに悪いことに、これは初めてではありません。最後のスプリントでは、まったく同じことが起こりました。私はそれを私たちの回顧でフラグを立てました、そして、スクラムマスターはこれを解決する方法の答えを持っていませんでした。皮肉なことに、バーンダウンが目標に達していない場合、彼はイライラします...
今、私は彼の仕事を成し遂げるためにデザイナーに尋ねる/協力する必要があります。私は他のすべてのタスクを完了しているので、これは私を遅らせます。
だから私の質問は
- B）今はどのようにスプリントにアプローチすべきですか？現在のユーザーストーリーを再推定して、バーンダウンがバーンアップに変わり、無能/非生産的と見なされるのを確認しますか？または、「デザイナーが適切なデザインを作成するのを助ける」という行に沿って、現在のスプリントに新しいタスクを追加します
スプリント計画で依存関係をどのように処理しますか？
理想的には、開発以外の依存関係はスプリント計画の前に処理されるため、努力量を見積もるバックログ項目を適切に定義できます。
しかし、それが「あなたのためのただの開発」である最後のスプリントである場合、それはおそらくこのスプリントのための単なる開発になるでしょう。そこで、実際にそこで見積もりを増やし、次に同様の状態にある次のタスクを行う必要があります。これは正当な判断を下すものではなく、それをそのようにやってしまうのは間違いです。
それが行うことは、推定するための比較的堅実な設計なしの推定の不確実性を示しています。おそらく、これにより、マネージャは製品のバックログ項目が適切に定義されていることを確認することができます。しかし、最悪の場合、それはあなたの背中を覆います。仕事が予算不足になったときに文句を言う人はいません。
しかし、あなたはそれをしなかった、そして今あなたの質問は...
どうすればスプリントにアプローチできますか？
プロジェクト管理ツールとしてのスクラムの主な目的は、問題を早期に特定することです。それをあなたの管理にフラグを立てて、彼らにスプリントをどうするかを決めさせてください。彼らがあなたを責めようとするなら、謙虚に、彼らがあなたが将来同じような状況に近づくように提案する方法を尋ねてください。
結局のところ、これらはプロジェクト管理の問題であり、自分のバブルの中でそれらを解決しようとすると、失敗するように設定されています。そして、あなたがそうするとき、あなたがそれにフラグを立てたときに問題を解決することに失敗したマネージャーではなく、あなたに落ちるのであなたは怒るでしょう。
まず、ストーリー/タスク間の依存関係と、ストーリー/タスクの範囲/努力の不確実性には大きな違いがあります。
Dependenciesは、依存するタスク/ストーリーに、それが依存するタスク/ストーリーよりも低い優先度を与えることによって処理され、おそらくそれより前に開始できない注釈他のタスク/ストーリーが完了しました。
不確かさは、ストーリーで実行する必要がある作業を明確にすることにより、計画会議で対処する必要があります。不確実性を十分に取り除くことができない場合、ストーリーはおそらくあなたの "Definition of Ready" に適合せず、スプリントに受け入れられるべきではありません。
何らかの理由でストーリーが実際にスプリントに入る必要がある場合、残された唯一の選択肢は、リスクバッファーを推定に追加することです。
現在のスプリントで、ストーリーに取り組むことができない場合は、次の毎日のミーティングでそのことを報告し、チームの全体的なスプリントの目標に到達するために可能なあらゆる作業を実行してください。また、ブロックされたものとして、また何によってストーリーに注釈を付けることもできます。
スプリントが開始された後、スプリントに新しいタスクを追加することは原則として不可能です。
また、タスクが見積もりよりも多くの作業であることが判明した場合、見積もりを変更することはありませんが、タスクの進捗状況と残りの作業を正確に報告します。
結局、スクラムでは、何かを提供することを約束するのはチームです。その約束をすることができない場合、それはチーム全体の失敗であり、チーム内の個人の失敗ではありません。
スプリントの計画中に、私はこの未定義のユーザーストーリーにかかる時間について、大まかな推測をしなければなりませんでした。
それはあなたがした間違いです。誰もチームにスプリント内のタスクを強制的に受け入れることはできません。少なくともワイヤフレームがなければ（たとえば）、タスクをスプリント内で推定して受け入れることができないと述べるのはあなたの仕事です。あなたのスクラムマスターは実際にはプロジェクトマネージャーであり、事態を悪化させるだけのようです。
（有効なビジネス上の理由から）スプリント内で達成する必要がある場合、そのようなタスクにどのようにアプローチしますか？さて、最初にデザインの期限を設定する必要があります。そうしないと、デザインを実装できなくなります。たとえば、ストーリーは受け入れられますが、デザインは最初の1週間以内に配信され、2週間以内に実装されます。次に、設計者と緊密に連携して、スプリントに実装できるようにする必要があります。スクラムは機能横断的なチームを想定しており、デザイナーと一緒に作業を整理するのはあなた次第です。そうは言っても、スプリントでタスクを受け入れる場合（チームが決定するのはチーム次第です）、スプリント内で完了するように作業を管理し、関連するリスクを管理するのはチームの責任です。他の人が彼/彼女の仕事を終えてあなたの仕事を終わらせるのを待つべきではありません。組織のより大きな機能障害を明らかにしようとしている可能性があります。
デザインに関するタスクはストーリーとして表現されていますか？また、チームの定義は何ですか？
- 物語は準備ができています
- 物語ができた
各ストーリーには独自の要件と受け入れ条件が必要ですが、すべてのストーリーに適用できる一連のルールを作成することをお勧めします。たとえば、ストーリーが完成するのは（そしてその場合に限ります！）エンドツーエンドのアーキテクチャスタディが終了し、デザインが利用可能であり、ストーリーがチームによって推定されている場合です。受け入れの最小条件は次のとおりです。自動テストが行われ、OKであり、テストスーツに統合され、コードレビューが行われます。
ストーリーの準備ができていない場合は、スプリントに組み込まないでください。受け入れの条件が満たされない場合、それは終了しません。
あなたのケースでは、チームは準備ができているために、開発ストーリーは完全なデザイン（少なくともワイヤーフレーム、これを自分の現実に合わせて調整する）を持つ必要があると決定する可能性があります。その場合、同じスプリントで設計と開発を処理することはできません。チームは、UX /デザインストーリーがワイヤフレームデザインを最低限生成するように決定することもできます。そうでない場合、ストーリーは受け入れられないため、それに依存するストーリーを開始できません。
準備ができているという強力なルールを持つことは良いことだとマネージャーに簡単に納得させる必要があります。スプリント中に複雑さを再評価することは悪い習慣です。これは、チームの速度が不確実であり、マネージャーとして、彼らがチームの仕事と将来について悪いビジョンを持っていることを意味します。
スプリントは通常、ストーリーが明確になったときに開始されます。この段階で、プロダクトバックログが確立され、優先順位が付けられます。デザインを持たずに始めた場合、デザインなしで何ができるのか、そうでないのかは明らかだったはずです...
設計がクライアントとPOの間で「急上昇」している間に即興する必要がある場合、POは新機能が現れたらすぐにチームにチームに通知する必要があります。これはスクラムの「柔軟性」の意味です-進行中の状況に適応します状況。開発チーム、スクラムマスター、およびプロダクトオーナーは恒久的に通信する必要があります。そうしないと、変更に対するリアルタイムの反応はありません。
もう少しトレーニングは害を及ぼすことはできません...おそらくデザイナーと一緒に働くことはあなたがいくつかの新しいUXスキルを身につける機会になるでしょうか？ ...それは、ガラスが半分空ではなく半分になっていることを観察しています:)）