タグ付けされた質問 「sprint」

スプリントが早く終了したらどうしますか？ 現時点では、スプリントチームがスプリントが早期に終了した場合、バックログからストーリーを作成します。 バックログから取得したストーリーはどうなりますか？ストーリーは現在のスプリントに追加されますか？もしそうなら、これらの物語が間に合わないとしたらどうでしょう。その後、スプリントは失敗しましたか？

10 scrum  sprint 

私はスクラムミーティングで、開発者がストーリーについて現実的な見積もりを行うことが多いことに気付きました。ただし、かなり単純なストーリーであっても、構成、サードパーティコンポーネントのセットアップ、テスト、最終ビルドに多大な労力が必要であり、システムにはかなりの技術的負債が蓄積されているため、製品の所有者や管理者にとって見積もりが高すぎることがよくあります。 POは次のような見積もりを頻繁に打ち消そうとします。たとえば、「このストーリーには13ストーリーポイント[4日間]が必要です。これは不可能です。これを経営者に説明することはできません。誰かがこれをコーディングできるはずです。 3 SP [4時間以内]で！」その結果、開発者は5または8ストーリーポイント（1.5〜2日）の見積もり（スクラムの見積もりは、単なる予測ではなく、コミットメントと見なされます）にコミットするために腕をひねります。 もちろん、（主にテストと品質に関する）期待を排除する計画がなければ、これらのスプリントは頻繁に失敗します。開発者の見積もりは正直で現実的なものであり、見積もりを打ち負かしても実際に行われる作業に影響が及ぶことはありません。 「誰かがあなたにそうするように強いたからといって、あなたは不可能な約束をするべきではありません！」しかし私の意見では、開発者の仕事はソフトウェアの設計とコーディングであり、交渉や圧力に対抗することではありません！すべての取引のジャックが存在する可能性がありますが、通常は外部の顧客と直接取引しますが、これはオフィス開発者の大多数ではありません！ 私にとって、この実践は、プログラマーをぎくしゃくさせ、絶え間ないスプリントの失敗を引き起こし、現実的な見積もりを妨げるだけでなく、実際の改善点も探します。 スクラムガイドラインはこのトピックについて何を言っていますか、または彼らはそれに何を言っていますか？ 編集：時間をストーリーポイントに置き換えました。私は、タスクの詳細計画ではなく、Planning Pokerとストーリーポイントを使用して最初の見積もりフェーズを参照していました。日/時をそこに置いたのは、このような典型的な対話であり、ポイントではなく時間も含まれていたためです。混乱してすみません！ストーリーポイントの例は、時間の例よりも長い期間を表しています。 編集2現在、専用のスクラムマスターはなく、POは見積もり会議に関してその役割を果たします。したがって、中立的なまたは開発者のスクラムマスターではなく、権威として表示されるため、おそらくロールコンフリクトがこの不適切な交渉を悪化させています。おそらく、これが何もない限り、彼を「マスター」ではなく偏った参加者とすることで修正できます。

9 scrum  estimation  planning  sprint 

私はスクラムを使用していて、本当に気に入っています。ただし、私のショップは、開発作業の期間が2週間または4週間のプロジェクトに含まれています。私たちはすでにスプリントの長さを2週間に変更しました。ここの誰もが「それは1つ半のスプリントがあれば、スクラムになるでしょう」と言っています。 １年半のスプリントから多くの価値を得ることができるとは思いません。1回、2回、または1.5回の反復のみで反復的な開発プロセスの利点を得るにはどうすればよいでしょうか。

9 agile  scrum  sprint  iterative-development 

問題のケース： スプリントはほぼ終了し、私のスクラムチームの1つはいくつかのタスクを完了しませんでした。（この理由は、この質問では必須ではないので、それに応じて対処します。）それらの1つは、かなり多くのストーリーポイントを持つ古典的な「90％完了」のケースであり、次のスプリントの一部になります。こちらの質問です。 バックロググルーミングと次のスプリントのためのいくつかの予備的な見積もりを行い、この未完成のタスクを処理する方法について説明しました。このスプリントの速度にはカウントされないことに私たちは皆同意していますが、真の複雑さと実行された総作業を次のようにしたいので、5つのストーリーポイントではなく1でほぼ完全なケースを再推定しないでください。まだ見えています。そして推定を振り返ってみると正しかった。-私たちは（スケーリングされた）アジャイルに移行しているだけであり、一部の管理レベルでは、提供された製品よりも多くの点で生産性を維持していることを「確認」する必要があります。 明らかに、このスプリントの速度は低下しますが、転送された「既に完了した」パーツは、次のスプリントで再び上昇するはずです。 これまでのところ、全員が同意しています。 しかし、私たちのチームはかなり小さいので、4ポイントは大きなかたまりです。このタスクのみで適切なドキュメンテーションがあれば、意識的に4つのポイントの過負荷を計画できると提案しました。 それは実現可能なアプローチですか、それとも私は まだ予想していない問題に遭遇する ほんの数か月前にアジャイルに移行したチームに悪い例を示しますか？

8 agile  scrum  planning  sprint  scrum-master 

私たちは、プロジェクトに最適なスプリントの長さを見つけようとしていました。3週間ベースで作業した後、スプリントを2週間に削減すると、速度が向上すると考えました。 利点は明らかでした-短いフィードバックループ、小さなストーリー（ユーザー価値あり）など。一方で、セレモニー（企画、回顧）など、私たちが制作しておらず、より頻繁に発生するデメリットもたくさんあります。 新しいチームのために、最適なスプリントの長さをどのように決定できるのかと思っていました。

8 agile  scrum  sprint  feedback 

本番環境でのバグ管理の問題は、最近私の心の大きな特徴でした。Sprintはアイテムを追加することを意図していませんが、重大なバグの場合、これは単に避けられません。 このスプリントの中断をどうやって管理するのですか？スプリントに時間の「許容量」のパーセンテージを与えるだけで、スケジュールの80％を「念のため」にスプリントアイテムで満たすだけですか？

8 scrum  errors  sprint