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

多くのスクラムの本や記事では、スプリントの失敗（チームがスプリントバックログの一部の機能を完了できなかった場合）はそれほど悪いことではなく、時々発生します。そして、次のスプリントで何かを改善します。そして、チームは彼らがコミットした仕事を完了しないことで罰せられるべきではありません。 これは開発者の観点からは素晴らしいように見えますが、深刻なクライアント向けに何かを開発しているソフトウェア会社「Scrum-Addicts LLC」（「Money-Bags Corporation」）があるとします。 Scrum-Addictsマネージャーは、Money-Bags用のソフトウェアを作成することを提案しています 彼らは機能のリストに同意し、Money-Bagsは出荷日を提供するように頼みます スクラム中毒マネージャーはスクラムチームに相談し、チームはすべての機能を完了するには3週間のスプリントが必要だと言っています Scrum-Addictsマネージャーは、安全のために1週間を追加し、1か月でソフトウェアを出荷することを約束し、Money-Bagsと契約を結びます 4回のスプリント（出荷期限）後、スクラムチームは機能の80％しか提供できません（新しいシステムでの経験不足、本番環境の以前の機能の重大なバグを修正する必要性など）。 スクラムが示唆しているように、この時点で、製品は潜在的に出荷可能ですが、Money-Bagsは契約で述べられているように機能の100％を必要とします。だから彼らは契約を破って何も支払わない。 スクラム中毒者は、マネーバッグからお金をもらえず、投資家は結果に失望し、それ以上会社を助けたがらないため、破産寸前です。 明らかに、スクラム中毒者の立場になりたいソフトウェア会社はありません。アジャイルとスクラムについて私が理解できないのは、チームが上記の状況を回避するために計画と期限に対処することを提案する方法です。要約すると、2つの質問があります。 誰が悪いのか？ 適切な計画を立てることが彼らの仕事だからです チーム。彼らができる以上の仕事をすることにコミットしたから 他の誰か 何を終わらせるべきなのですか？ マネージャは、期限を元のチームの推定値の2倍（または3倍）遅らせる必要があります。 チームメンバーは、何をしてもコミットしたすべての作業を行うように奨励する必要があります（失敗したスプリントに対してペナルティーを発行することにより） 会社の締め切りポリシーに適合しないため、チームはスクラムを削除する必要があります 私たちは皆、ソフトウェア開発をやめて修道院に参加すべきです ???

80 agile  scrum  sprint 

私たちのスプリント計画会議は面白くないだけでなく、実に恐ろしいものです。 会議は退屈で退屈で、永遠にかかります（1日ですが、ずっと長く感じます）。 開発者はそれについて文句を言い、今後の計画を恐れます。 私たちのルーチンはかなり標準的です（優先順位によってスプリントバックログに挿入されるユーザーストーリー>>ストーリーはタスクに分解されます>>タスクは時間単位で見積もられます>>繰り返し）、何が間違っているのかわかりません。 どうすれば会議をもっと楽しくすることができますか？ ... 詳細情報のリクエストへの応答として、さらに詳細を示します。 バックグラウンドアイテムがスプリントキックオフの前に挿入および優先順位付けされないのはなぜですか？ ユーザーストーリーは確かに優先されます。それらをタスクに分解するまで、どれだけ時間がかかるかわかりません！ここの（優れた）回答から、タスクをまったく推定すべきではなく、ユーザーストーリーのみを推定すべきであることがわかります。タスク（ストーリーではなく）を見積もる理由は、ストーリーの見積もりがひどく間違っているためです。しかし、それはまったく異なる質問の主題だと思います。 開発者が文句を言うのはなぜですか？ 会議は長いです。 会議は単調です。ストーリーごと、タスクごと、苦労（はい、苦労）にかかる時間とその内容を推定します。 タスクを見積もると、ユーザーストーリーの推定が無意味に見えます。 会議が長ければ長いほど、部屋に集中できなくなります。集中力の低い同僚ほど、会議に時間がかかります。再帰的なヘイトスパイラルが発生します。人々を集中させるために会議を2日間に分割することを検討しましたが、開発者はそれを聞きませんでした。計画の1日で十分です。これで2つになります。 私たちの問題の一部は、（より正確な推定を得るために）非常に小さな詳細になることです。しかし、おおよその見積もりをするときは、大したことはありません！ 質問を要約するには： 私たちは何を間違っていますか？ 一般的に会議をより楽しくするために、他にどのような方法がありますか？

51 agile  scrum  sprint  meetings  process-improvement 

私は50万行を超えるコードであるコードベースを使用しています。リファクタリングが非常に必要です。通常の2週間のスプリントよりも時間がかかるリファクタリング作業が特定されています。このサイトの他の回答で提案したように、これらを小さなタスクに分割することはできません。製品は反復の最後に動作する必要があり、部分的なリファクタリングは、アイテム間の依存関係が恐ろしいため、システムを使用できない状態のままにします。それでは、このハードルにアプローチする最良の方法は何でしょうか？繰り返しますが、それを小さな断片に分割することはオプションではなく、すでに行われています。 更新：人々はなぜこれが2週間のスプリントに収まらないのかの説明が必要なようです。コードを書くだけでなく、スプリントに関与します。私たちには、テストなしのコードはないというポリシーがあります。そのポリシーは常に存在するとは限らず、コードベースの大部分にはそれらがありません。また、統合テストの一部はまだ手動テストです。問題は、リファクタリング自体が非常に大きいということではありません。小さな変更がシステムの多くの部分に影響を与えるという事実があり、それらの部分が依然として正しく動作することを保証する必要があります。 毎月のホットフィックスがあるため、スプリントを延期または延長することはできません。したがって、スプリントを超えて拡張されるこの変更は、修正プログラムに追加される他の作業を停止できません。 リファクタリングと再設計：開発プロセスが2週間のサイクルでこのリファクタリングを処理するのに十分な効率がないため、再設計に名前を変更する必要はありません。将来的には、プロセスが改善されれば、2週間のサイクル内でまったく同じタスクを達成できると信じています。ここで問題になっているコードは、長い間変更する必要がなく、非常に安定しています。現在、会社の方向性が変化に適応しやすくなっているため、コードベースのこの部分が他の部分と同じように適応できるようにしたいと考えています。リファクタリングが必要です。ここでの回答に基づいて、通常のスプリントの時間枠でこのリファクタリングを機能させるために必要な足場が不足していることが明らかになりつつあります。 回答： これらの問題領域と欠落しているテストを特定する方法についてさらに学習できるように、Corbin Marchが初めて提案したブランチとマージのアプローチを実行します。前進するためには、Buhbが提案したテストに欠けている領域を特定するアプローチを採用し、それらを最初に実装してからリファクタリングを行う必要があります。ここで多くの人がリファクタリングの場合は常にそうすべきだと言っているように、通常の2週間のスプリントサイクルを維持することができます。

49 refactoring  sprint 

そのため、スクラムスプリントは、特定の機能セットを実装する必要がある固定期間です。そして、スクラムチームは、これらの機能を提供することに全力を注いでいる人々で構成されており、その大部分は通常、開発者とテスターです。 これらのルールを確立した後、スプリント全体でこれらすべての人々を忙しく保つ方法を疑問に思うかもしれません。スプリントの開始時にはまだテストするものはありません。また、スプリントの終了時には、通常、開発/修正するものがまったくないか、ほとんど残っていません。 これを処理する2つのアプローチを見てきましたが、どちらも問題を適切に解決していないようです。 1）チームメンバーに、タスクがなくなったときの対処方法を決定させます。 短所： 彼らがすることを徹底的に計画していない場合（すなわち、主要なリファクタリング、新しいテストフレームワークへの切り替え）、彼らの仕事は役に立たないか、途中で立ち往生するかもしれません 一方、そのような作業の計画には多くの時間がかかる可能性があり、クライアントは即座に価値をもたらさないものにチームが時間を浪費するのを見ることに失望するかもしれません 通常、このようなタスクは完全に見積もることができないため、未熟な労働者がスクラムボードや他の場所に反映されることなく、YouTubeの猫を見ることに時間を費やすことは非常に簡単です。 2）スプリント内に開発専用のスペースを確保し、スプリントの終了後にテストを開始します（開発者が次のスプリントから機能の作業を開始するとき） 短所： 現在のスプリント用の機能を開発している間、開発者は前のスプリントからバグを修正することに気を取られ、現在のスプリント中に行われると推定された量の作業を実行できない可能性があります 2つのスクラムボードが必要です。1つは現在のスプリント機能用で、もう1つは以前のスプリントバグ用です。 だから私の質問は、スプリント中に開発者とテスターの間で作業を適切に分散して、誰も作業で過負荷になったり、いつでもタスクなしで終わることがないようにする方法ですか？上記のアプローチを改善する方法はありますか？または、より良いアプローチがありますか？

33 agile  scrum  sprint 

チームメンバーが年次休暇を取っているとしましょう。彼はスプリント計画には参加しませんが、イテレーション/スプリントの半ばまでに戻ってきます。彼が50％のキャパシティを持っているとしましょう。つまり、イテレーションの後半で利用できるようになります。 彼が戻ってきた後に彼と計画セッションを持っています。 彼が年次休暇をとる前、すなわちスプリント計画の前に、彼と計画を立てる。 タスクのスケジュールを立てたり、スパイクなどの非スプリントタスクに割り当てたりしないでください。 スプリントプランニング中に同僚に代わって計画を立てさせ、欠席している人が戻ってきたときにタスクを追加したり、すべての作業を実行できない場合はスコープを解除することができます。 彼に別の開発者と一緒に座ってもらい、しばらくの間ペアプログラミングを行います。 他に何か.. 私はあなたが何をしているのか知りたいです。 注：私たちは（1）を行っていますが、正しくないと感じています。

18 scrum  sprint 

1週間のスプリントのスプリント計画に5時間以上かかりました。それは多すぎるようです。 ほとんどのチームメンバーはシニアではないため、スプリント計画で詳細を議論します。そうしないと、実装中にミスが発生し、スプリント中に再設計されます。 これにどう対処しますか？ 1週間のスプリントあたりわずか2時間の長さに合わせるために、計画中にどの程度詳細に議論する必要がありますか？

14 agile  scrum  planning  sprint 

スクラムを正しく理解していれば、次のスプリントでチームが引き受けることができる仕事を決定する方法は次のとおりです。 過去数回のスプリントで完了したポイントの数を平均します。 この量は平均速度です。次のスプリントでは、多くのストーリーポイントを取り上げます。 これは平均であるため、履歴が繰り返される場合、このスプリントは、ストーリーポイントが少なすぎる可能性が50％あり、ストーリーポイントが多すぎる可能性が50％あります。 50％のケースでは、できる限り多くのストーリーポイントを使用しました。 スプリントを完了できません。これは、スプリントのコミットメントを半分の時間で満たさないことを意味します。 追いつくために余分に働く。問題は、これが一方向にしかラチェットしないことです。スプリントを達成し、完了したストーリーポイントの数はそれを反映します。私たちは常に時間をかけて終了するので、私たちの平均は常に多くのストーリーポイントを達成し、遅れている点まで上昇傾向にあります。 平均速度とスプリントのコミットメントについての私の理解は正しいですか？ もしそうなら、平均より遅れているスプリントの50％に対して何をすべきでしょうか？ そうでない場合、何が間違っていますか？

14 scrum  user-story  sprint  scrum-master 

私は最近スクラムについて多くのことを読んでおり、スプリント中にスプリントのバックログを変更しても大丈夫かどうかについて、私にとって矛盾する情報を見つけました。スクラムのWikipediaの記事は、それがOKではない、と様々言う他の記事は、同様にこれを言います。また、私のソフトウェア開発教授は、スクラムの概要の中で同じことを教えました。 ただし、私はトレンチからスクラムとXPを読み、タスクボード上の計画外の項目のセクションについて説明します。そこで、スクラムガイドを調べて、スプリント中に「スプリント目標に影響する変更は行われていない」とスプリント目標の議論で「作業が開発チームの予想と異なることが判明した場合、その後、プロダクトオーナーと協力して、スプリント内のスプリントバックログの範囲を交渉します。」さらに、スプリントバックログの議論でも述べています。 スプリントバックログは、進行中の変更をデイリースクラムで理解できるほど十分に詳細な計画です。開発チームはスプリント全体でスプリントバックログを変更し、スプリント中にスプリントバックログが発生します。この出現は、開発チームが計画を進め、スプリント目標を達成するために必要な作業についてさらに学習するときに発生します。 新しい作業が必要になると、開発チームはそれをスプリントバックログに追加します。作業が実行または完了すると、推定残り作業が更新されます。計画の要素が不要と判断された場合、それらは削除されます。開発チームのみが、スプリント中にスプリントバックログを変更できます。スプリントバックログは、開発チームがスプリント中に達成する予定の作業の非常に目に見える、リアルタイムの画像であり、開発チームのみに属します。 したがって、この時点で私は完全に混乱しています。それについて考えると、2番目のアプローチを取る方が理にかなっています。バックログの個々の特定の項目は、私にとって最も重要なものではなく、むしろスプリントの目標であるように思われるため、スプリントの目標を変更するのではなく、バックログを変更できるのは理にかなっています。たとえば、製品の所有者とチームの両方がストーリーについて同じページにいると思っていたが、スプリントが進むにつれて誤解があることがわかった場合、そのストーリーを構成するタスクをそれに応じて変更することは理にかなっているようです。または、忘れられたストーリーまたはタスクがあり、スプリントの目標を達成するために必要な場合、スプリント中にストーリーまたはタスクをバックログに追加するのが最善だと思います。 しかし、スプリントのバックログへの変更は大丈夫ではないと断固として思われる人がたくさんいます。どういうわけかその位置を誤解していますか？それらの人々はどうにかしてスプリントのバックログを異なって定義していますか？スプリントのバックログについての私の理解は、スプリントのバックログは、ストーリーとそれらが分解されるタスクの両方で構成されるということです。 とにかく、私はこの問題に関する意見を本当に感謝します。私は、理想的なスクラムアプローチがスプリント中にスプリントバックログを変更することと、スクラムを開発にうまく使用する人々がスプリント中にスプリントバックログを変更できるかどうかの両方を把握しようとしています。

14 scrum  sprint  product-backlog 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 一部のスクラムソフトウェア管理ツールには、スプリントに明示的に名前を付けるためのこのオプションがあります。 スプリントに名前を付ける好ましい方法はありますか、それとも1、2、3、...などの単純なスキームを使用しますか？

13 scrum  sprint 

スプリントに割り当てられたストーリーを完成させるための態度はどうあるべきですか？明らかに、あなたはそれらをスプリントで終わらせることを優先したいのですが、私にとってアジャイルのポイントは動的であるということです。予想外のことが起こり、それらのストーリーが完了せず、次のスプリントにプッシュされるのと同じ時間に、何か間違ったことをしたという感覚は望みません。それは怖い経験やネガティブな経験ではないはずですよね？ 負けた/怖い経験は、逃したスプリントのコミットメントに受け入れられますか？開発者は、対処しなければならない予期しないタスクが発生した場合に、スプリントのコミットメントを逃したことに対して責任を負うべきですか？

12 agile  sprint 

私は4人の開発者のプロジェクトチームに所属しています。単一の作業項目で発生する余分な作業を処理する方法については、長い間議論を重ねてきました。 この余分な作業は通常、タスクにわずかに関連するものですが、アイテムの目標を達成するために必ずしも必要なわけではありません（意見かもしれません）。例には以下が含まれますが、これらに限定されません。 ワークアイテムによって変更されたコードのリファクタリング アイテムによって変更されたコードに隣接するコードのリファクタリング チケット周辺のより大きなコード領域を再構築します。たとえば、アイテムで単一の関数を変更した場合、クラス全体を再実行してこの変更により適切に対応できるようになることに気付きます。 変更したフォームのUIを改善する この余分な作業が小さい場合は問題ありません。問題は、この追加作業により、元の特徴点の推定を超えてアイテムが大幅に拡張されることです。5ポイントのアイテムは実際には13ポイントかかる場合があります。あるケースでは、振り返ってみると80ポイント以上であった13ポイントのアイテムがありました。 これをどのように処理するかについての議論では、2つの方法が考えられます。 同じ作業項目で余分な作業を受け入れ、誤推定としてそれを書き留めることができます。これに関する議論は次のとおりです。 この種のことを考慮して、スプリントの最後に「パディング」を計画しています。 常にコードを見つけたときよりも良い形にしてください。中途半端な作業をチェックインしないでください。 リファクタリングを後で行う場合、スケジュールを立てることが難しく、完了しない可能性があります。 あなたはすでにコードの奥深くにいるので、あなたは今この仕事を処理するのに最高の精神的な「状況」にいます。後で戻ってきたときにそのコンテキストを失うよりも、今それを邪魔にならないようにして効率的にする方が良いでしょう。 現在の作業項目に線を引き、追加の作業は別のチケットになると言います。引数は次のとおりです。 個別のチケットがあると、新しい見積もりが可能になるため、実際のポイント数について自分自身に嘘をついたり、見積もりの​​すべてがひどいことを認めたりする必要はありません。 スプリントの「パディング」は、チケット要件を完了するための直接的な障壁である予期しない技術的な課題のためのものです。これは、「便利な」だけの副次的なアイテムを対象としたものではありません。 リファクタリングをスケジュールする場合は、バックログの先頭に配置してください。 それが出てきたときにいくぶん恣意的であるように思われるので、私たちが推定においてこのことを適切に説明する方法はありません。コードレビューアは、「これらのUIコントロール（実際にはこの作業項目で変更しなかったもの）は少し混乱します。それも修正できますか？」これは1時間のようですが、「このコントロールが他のコントロールと同じ基本クラスから継承するようになった場合は、この（数百行の）コードをすべてベースに移動して、これらすべてを再配線しないでください。 、カスケード変更など？」そして、それは一週間かかります。 これは無関係な作業をチケットに追加することで「犯罪現場を汚染」し、元の特徴点推定を無意味にします。 場合によっては、余分な作業がチェックインを延期し、開発者間のブロッキングを引き起こします。 追加のものが2 FP未満の場合は同じチケットに入れられ、それ以上の場合は新しいチケットにするなど、一部の人はカットオフを決定する必要があると今言っています。 私たちはアジャイルを使用して数ヶ月しか経っていないので、これをどのように処理するかについて、この辺りの経験豊富なアジャイル退役軍人の意見は何ですか？

12 agile  refactoring  estimation  sprint 

スクラムのアイテムが予想よりも時間がかかる場合はどうすればよいですか？開発者が最初に考えたよりもずっと厳しいので、開発者が完了するのに苦労しているアイテムに気付いているので、私はこれを尋ねています。 そのような状況では スプリントのタイムラインを満たすために、アイテムをスプリントから製品カタログに戻しますか？ より簡単なスプリントアイテムに移動し、タイムラインの最後まで問題のあるスプリントを残す スプリントレビューで、現在のスプリントで利害関係者にアイテムを完成できない理由を正当化する 今後、このような状況をどのように回避できますか？それは事前の計画の欠如によるものですか、それともスプリントアイテムを小さなアイテムに分解する努力をしなかったのですか？

11 scrum  sprint 

私たちは、新しいプロジェクトを開始しようとしている5人の小さなグループです。これは、スクラムでオールインする最初のプロジェクトです。 プロジェクト（フレームワークなど）のベースをどのように確立するかについて、少し苦労しています。このようなタスクは、ユーザーが直接恩恵を受けるものではないため、ユーザーストーリーをどのように書くかを考えるのに苦労しています。 それで、一般に、フレームワークもベースライブラリも配置されていない状態でプロジェクトをゼロから開始する場合、スクラムをどのように使用しますか？

11 scrum  user-story  sprint 

私は、スクラムモデルに大まかに沿ってプロジェクトに取り組んでいます。2週間のスプリントを行っています。私が明確にしていない（そして相談する本がない）ことは、スプリント間で起こるはずのことです。製品が構築されて配信される「ラップ」プロセスがあるはずです。 これには通常どれくらい時間がかかりますか？ チーム全体が関与する必要がありますか？ 開発者が次のスプリントアイテムの作業を開始する前に、厳密に終了する必要がありますか？ コードのレビューとテストが行​​われるのはこれですか？ 3人の開発者がいて、合計で約1人のFTEがいます。したがって、スプリントは実際に非常に短いです。

11 agile  scrum  sprint 

基本的にはスクラムに従って、アジャイルなソフトウェア開発を行っています。私たちはスプリントレビューを行おうとしていますが、難しいと感じています。私たちのソフトウェアは多くのデータ処理を行っており、ストーリーはしばしばこれに関するさまざまなルールを変更することについてです。 UIまたは目に見えるワークフローの変更がない場合にスプリントで発生した変更をデモするためのいくつかのオプションは何ですか？その代わり、変更は数十分または数時間かかることもある処理ジョブの微妙なビジネスルールです？

10 agile  scrum  sprint