この入門レベルの記事では、スプリントの仕組みと、リリース品質の増分を生成するためにチームメンバーがどのように協力することが期待されているかを見ていきます。

最初の日:Sprint Planning

製品所有者を含むチーム全体がスプリントの最初の日に会い、スプリント計画セッションを行います。 これは、スプリントが開始されるとすぐに起こる最初のことです。

準備

スプリント計画は準備する必要があります。 最も重要な準備は、製品バックログが見積もりと受け入れ基準を使用して適切なレベルの詳細に洗練されていることを確認することです（これが製品バックログの洗練の目的です）。 次に、製品所有者はプロダクトバックログの作業を注文し、チームと貴重なスプリント目標を交渉する方法についての一般的なアイデアを持ってい 目標を交渉するためのオプションも、洗練の際に考慮され、バックログの順序付けに反映されるべきです。 また、チームはこのスプリントのための能力、つまりどれだけの仕事を引き受けることができると信じているかを知る必要があります。 彼らは、この予算の大きさを確認するために、以前のスプリントでの経験を使用することができるかもしれません。

最初に配信される値を計画

各スプリントは、完了した作業の貴重な増分、フィット、即時リリースの準備ができている必要があります。 製品所有者は、”価値”が何を意味するのかについて完全に責任を負い、チームがスプリントごとに価値を最大化できるように製品バックログを注文す したがって、チームが最初に行う必要があるのは、このスプリントでプロダクトバックログのどの項目を処理するかを計画し、最後までに最高の価値を提供できるようにすることです。

これを行うために、チームは製品所有者と協力して、スプリントの予測容量に合ったプロダクトバックログから最も価値のある項目を選択します。 プロダクトバックログの各項目は、チームによって見積もりが与えられている必要があるので、彼らはどのくらいの作業が関与する可能性があるか

スプリントの目標に同意してください

この作業の選択は、無関係で異種の項目のグループ化だけではなく、凝集的でなければなりません。 スプリントは、重要な何かを達成するための時間の箱入りの機会であることを覚えておいてくださ たとえば、スプリントの終わりまでに、一貫性のある機能が提供されたり、重大なリスクが軽減されたりする可能性があります。 スプリントの目標は、この目的、選択された作業の包括的な意義、および選択の背後にある一貫性の単純な表現です。

良いスプリントの目標は、チームが焦点とコミットメントを実証し、それが満たされるようにコラボレーションと作業の再計画を可能にすることが

次の作業がどのように行われるかを計画

スプリントバックログは、最終目標を念頭に置いた作業 また、その目標がどのように達成され、関連する作業がどのように実行されるかについての計画でもあります。 これは、関与する可能性のある技術的なタスクを特定して注文することによって行うことができます。 実際には、スプリントバックログは、スプリントの目標を達成するための計画であり、実行する必要がある作業の予測です。

この予測を技術レベルで計画するのはチーム次第であるため、製品所有者はスプリント計画のこの部分に出席する必要はありません。 ただし、製品所有者は、たとえリモートでのみであっても、チームが持つ可能性のある質問に答え、作業の範囲について必要な明確化を提供するために利用 スプリント中に複数のリリースが予想される場合は、POと合意し、スプリントバックログで説明する必要があります。

スプリント計画の終わりまでに、チームはスプリントの目標を達成するために必要な作業を良好に予測したと確信する必要があります。 チームが完全に所有しているスプリントバックログでその計画をキャプチャします。 チームは、スプリントのバーンダウンなど、ある時点でどれだけの作業が残っているかを明確に理解して、すぐにその計画の実装を開始できるはずです。

毎日、毎日

チームがスプリントバックログを計画したら、作業を開始 彼らはタスクとして物事を計画している場合、彼らはそれらのタスクが完了していることを確認するために、チームとして、お互いに協力します。 彼らは、タスクボードと残りの作業のスプリントバーンダウンを使用して進捗状況を追跡することができます。

各チームメンバーは、スクラムタスクボードとスプリントバーンダウンを更新しておき、他の人が情報を信頼できるようにします。 情報ラジエーターは常に真実を伝える必要があります。

毎日スクラムを開催

毎日、同時に、開発チームは、スプリントの目標に近づけるために何をするかを満たし、計画します。 この会議は毎日のスクラムと呼ばれ、15分以上かかることはありません。

作業の計画は完全に彼らに属しているので、開発チームのメンバーだけが参加すべきです。 これは、スプリント中に学んだ新しい発見と教訓の結果として、スプリントバックログを再計画するための時間の箱入りの機会です。 チーム全体が参加する必要があります。 各チームメンバーは次のことを考慮できるはずです。

• チームがスプリントの目標を達成するために昨日行ったこと
• チームがスプリントの目標を達成するために今日やろうとしていること
• 邪魔になっている障害

毎日のスクラムの終わりまでに、チームは次の24時間の明確な計画と、それを達成するためにどのように協力する必要があるかを理解する必要があります。 彼らはまた、スクラムマスターの注意を必要とする障害のリストを持っている必要があります。

プロダクトバックログの絞り込み

スクラムでは、プロダクトバックログの絞り込みは正式なイベントではなく、進行中のアクティビティであり、ユーザーストーリーなどのプロダクトバックログ項目に詳細、順序、見積もりを追加するプロセスです。 これをどのくらいの頻度で行うかはスクラムチーム自身が決定しますが、毎日のルーチンに洗練を構築することは確かに良い考えです。 スプリント中にチームの合計時間の10％以上を洗練する必要はありません。 ほとんどのチームでは、週に数時間または数時間を過ごすことを好む人もいますが、1日30分で十分かもしれません。 重要なことは、スプリント計画が障害なく行われるように、プロダクトバックログがタイムリーに洗練されていることを確認することです。 製品所有者を含むチーム全体が参加する必要があります。

絞り込みセッションは、通常、製品所有者が現在のプロダクトバックログをチームに提示することから始まります。 バックログは、電子スクラムボードや他のコラボレーションツールなどの多くの形式で保持されていてもよく、単にスプレッドシートであってもよいです。 プロジェクターや共有画面は非常に便利です。

チームはプロダクトバックログの上部から開始し、順番に各項目を精製し、下方に自分の道を働きます。 彼らはそれぞれを調べ、その範囲と、その完了に必要な受け入れ基準について議論します。 各項目は計画の火かき棒のような技術を使用してそれから推定される。 大きい項目はより大きい細部を捕獲するより小さい物に破壊されるかもしれない。 エピックは、例えば、ユーザストーリーに分解することができる。

セッションのタイムボックスがなくなると、チームは停止します。 彼らは次の時間を中断したところから再開し、最終的にはバックログが最新の状態に保たれるように再び先頭から開始します。

Always collaborate

アジャイルの実践では、チームメンバーは決して孤立して働くことはありません。 実際、チームワークは非常に重要なので、役割は開発者ではなく開発チームです。

これは、各開発チームメンバーが作業の進行に共同で責任を負うため、一日を通して同僚と協力しなければならないことを意味します。 すべての問題や失敗は、チームとその成功によって共同で所有されています。 コラボレーションは、毎日のスクラムなどのイベントに限定されるものではなく、チームがスプリント全体を通して行うすべてに適用されます。

コラボレーションの例には次のものがあります:

• バックログから新しい作業を持ち込む前に、ピアが進行中の作業を完了するのを助ける
• ペアプログラミング、キーボードを交互に使用して、お互いの作業を支援し、チェックするなど
• ピアレビュー
• 助けを求め、それを与えることに熱心である
• 仕事がある場所に行き、仕事が彼らに渡されるのを待つのではなく、
• すべての仕事が実際に仕事の定義を満たしていることを確認する。完了
• チームの即時の注意を必要とする問題を解決するためにスクラムを呼び出す
• 障害を上げる 情報が最新であり、信頼できるようにスクラムタスクボードとバーンダウンチャートを更新する
• スキルと知識の共有

最終日：レビューと回顧

スプリントレビューを開催

チームが効率的にコラボレーションしている場合は、彼らはスプリントの目標を達成するために協力し、リスクを管理し、必要に応じて計画を調整します。 彼らは、各メンバーが進行中の作業を完了するのを助けるために彼らの個人的な責任としてそれを見た残りの作業の均一なバーンダウンを通じて、ス 彼らは、製品所有者と招待された利害関係者に実証するための貴重な増分を持っています。 レビューは、チームが楽しみにしているものです。それはチームが準備しなければならないものでもあります。

実行された作業のデモンストレーションには十分な時間を許可する必要があります。 この目的のために、タスクはスプリントバックログで計画され、レビューが行われた作業と現在利用可能な値に正義をもたらすことを確認することができます。 また、製品所有者が利害関係者を招待することが良い考えであると考えている場合は、それらの招待状が送信されているはずです。 レビューは、行われた仕事を祝うために、その成果を披露する機会であるので、自信が触発され、チームへの継続的な投資が正当化されるかもしれません。

スプリントレビューは、検査と適応の機会でもあります。 製品の所有者は、製品がどれだけうまく機能しているかを説明し、招待されたパーティーから直接フィードバックを得て、製品のバックログをさらに改善す 何らかの理由で作業が完了していない場合は、将来のスプリントへの計画の可能性のために、製品バックログでも確認され、再推定されます。

その後、スプリント回顧を行います

スプリントレビューは、製品と配信された値を見て、行われている作業で、そ
次はスプリント回顧を行うことです。 レトロスペクティブでは、チームがフォローしているプロセスを考慮します。 彼らはできると効果的に働いているか。 前者は後者で検討のためのアイデアを紹介することができるので、レビューの直後に回顧展を開催することが一般的に最善です。

開発チーム全体、製品所有者、およびスクラムマスターは、誰もがチームの仕事の成功に共同で責任があるため、すべての回顧に出席する必要があります。 これは、任意の問題の中心に取得し、それらを解決するのに役立ちますアクションを識別し、無料でオープンなセッションを持っていることは本当に重 回顧展は、次の宣言から始めることができます:

“私たちが発見したものにかかわらず、私たちは、当時知っていたこと、自分のスキルと能力、利用可能なリソース、手元の状況を考えると、誰もが最高の仕事をしたことを理解し、真に信じています。”

“レトロ”では、誰もが等しい声を持っています。 スクラムマスターが容易にすることができる一つのアプローチは、識別することです:

• うまくいったこと
• うまくいかなかったこと
• 改善のためのアイデア
• 例外的なことをしたチームメンバーのためのシャウトアウト

タイムラインを確立することは、スプリント中の重要なイベントについての参加者の思い出をジョギングするのに役立ちます。