スクラムの実装には、様々なバリエーションがありますが、以下がアンワイヤード・ロジックによる一般的に受け入れられているベストプラクティスです。
スプリントゼロ(Sprint Zero)
スプリントゼロには、すべてのプロジェクトに適用する一定の時間がありません。スプリントゼロの長さは、各プロジェクトによって異なります。
キックオフの際に、スプリントゼロで何が必要かを議論し、その長さを決定するために、ある程度の時間を割り当てる必要があります。基本的に、最初の数時間は準備完了の定義を議論するため、「このプロジェクトを始めるために何が必要か?」を議論するためにに費やされるべきでしょう。
スプリントゼロで議論すべき標準的な項目は次のとおりです。
- アーキテクチャ & デザイン – 有効なエクササイズの中で「システムから抜け出す」ためにこの議論を行い、凝り固まった考えを取り除くことが重要です。
- チームトレーニング – スキルのギャップを早期に特定し、必要なトレーニングを計画します。
- 製品のビジョンは、スプリントゼロ中に作成し、できるだけ早く周知させるべきです。
- 技術環境の整備は、スプリントゼロでほぼ完了しておく必要があります。これには、開発、テスト、ステージング、および実稼働環境を含みます。可能であれば、製品の環境を移行させるために必要な展開ツールもここで完了させておくと良いでしょう。
- 「Done」の定義の協議、策定
- 最初のストーリーワークショップ – リリース計画戦略に従って作成および計画されたストーリーまたはテーマ。初期のスプリントで発生するストーリーは、より具体的かつ詳しく作成する必要があります。
- 起動に必要な最低限の実行可能なソリューションと、最初のリリース計画の作成。
リリースプランニング(Release Planning)
これは、最小限実行可能なソリューション、または顧客に提供したいエクスペリエンスを定義するエクササイズです。この経験またはビジョンがリソースに必須得あり、すべてのストーリーがそのビジョンに沿っていなければなりません。 これにより、リリースに必要最低限の機能一式が決定し、「いつ完了するのか」という質問に対する答えを得ることができます。
チームのベロシティがなければ、リリースプランニングは困難であることを理解することが重要です。
スプリントプランニング(Sprint Planning)
あらゆるプロジェクトにおいて、プロダクトオーナーはプロジェクトの開始時に自分のビジョンをチームに説明する必要があります。 これは、製品開発におけるチームのインスピレーションになります。 製品ビジョンに加えて、特定のスプリントまたはリリースのビジョンについても必要に応じて更新または説明する必要があります。
プロダクトオーナーは、入バリュー/ハイリスクなストーリーと共にビジョンを提示します。チームは、そのビジョンとストーリーを取り入れて、ストーリーをタスクに分解し始めます。タスクは時間単位で推定します。
また、チームはキャパシティプランニングを実施して、スプリントの作業量にコミットします。
ストーリー作成(Story Writing)
ストーリーの構成は次のとおりです。
- タイトル
- <ユーザー>として、私は<結果>を実現するために<アクション>ができる/をしてほしい。
スクラムは、結果と実用的な製品に焦点を合わせ、そこに到達する方法についてはあまり焦点を当てません。ストーリーも同様のアプローチに従って、機能ではなく、ストーリーで提供するエクスペリエンスに焦点を当てます。これを行うためには、顧客のペルソナ、つまりその顧客が何をする必要があるかを本当に理解する必要があります。
最終的に、ストーリーはタスクに分けられます。
攻略方法とヒント
ストーリーに何かを入れ忘れてしまったけれど、既にストーリーが完了してしまっている場合、関係のないストーリーにタスクとしてただ付け加えることができます。もしくは、弊社では「ゼロバグ」ポリシーを採用しているので、忘れてしまったアイテムをバグとして扱うこともできます。
タスク(Tasks)
タスクは通常、分解されたストーリーの一部であり、時間単位で推定されます。しかし、特定のストーリーには収まらないけれど、完了しなければならないものもあります。そういう場合は、タスクを作成してスプリントに組み込んでも問題ありません。ただし、それはベロシティの一部として追跡されず、どちらかと言うと、技術的負債という言葉が適しています。
スパイク(Spikes)
スパイクは、将来のストーリーのための議論をすることです。 これらは、ストーリーが計画されているスプリントに先立って議論する必要があります。 ストーリーが発生している同じスプリントでスパイクを実行しないでください。それだと飛行中に飛行機を構築しようとしているのと同じです。
スパイクの目標または目的は、ストーリーを十分に事前に話し合い、ストーリーを構築するときがきたらすべてが話し合われるようにすることです。 議論する内容がいくつかある場合、1つのストーリーに対して複数のスパイクを作成するのが一般的です。
推定(Estimating)
ストーリーポイントでストーリーのサイズを推定することで、リリースプランニングに反映され、特定のストーリーの作成をいつ試み、いつ完了するかを確認することができます。これは、XSからXXLのTシャツサイズやフィボナッチ数列などを使って表現されます。
ストーリーが推定されたとみなされる前に、プランニングポーカーを使って、すべてのメンバーがそのサイズに同意する必要があります。
それらのポイントは、相対的なサイズであり、時間に対応していないことに注意することが重要になります。1、2、3、5、8、13、20、40、60、100という修正版のフィボナッチ数列を使用します。目標は、正確な推定値ではなく、類似したサイズのアイテムをグループ化することです。
推定するときは、複雑性、労力、疑念の3つの異なる側面を考慮する必要があります。
複雑性は、私たちが理解する必要があるものです。解決できると確信を持つだけでなく、何をすべきなのか、何をしたいのかを具体的かつ正確に把握する必要があります。
労力とは、完了するまでに必要な作業量です。 どうすればいいのか分かっていても、作業を完了するまでに多くの時間を要するかもしれません。
疑念は、できるかどうか分からない項目のことです。解決策を見つけるために見当違いの場所を探しているかもしれませんし、単に技術が違うかもしれません。
推定の際には、上記3つのすべてを考慮に入れましょう。
プロトタイピング(Prototyping)
スクラムでは、廃棄作業を実施することを強く推奨しています。同じものをもう一度作り直したり、誰もが触れることができるものを構築することで、より良い具体的なフィードバックを得ることができます。
グルーミング(Grooming)
通常、グルーミングはスプリントの中間あたりで1~3時間ほどかけて実施されます。グルーミングは、今後のストーリーについて話し合い、チーム内で共通の理解を確保するために行います。「Ready」の定義は、完了する必要のある項目を誘導していくために使用されます。
Doneの定義(Definition of Done)
DoDでは、プロジェクト中に様々なレベルで多くのことを完了する必要があります。タスクレベルが最も詳細ですが、各ステップは、その前のDoDにもどついて構築されます。
バグ(Bugs)
バグは、スプリントの終わりまで存在していてはいけません。バグが発見された場合は、やっている作業を一旦止めて、すぐにそのバグを修正します。
レトロスペクティブ(Retrospectives)
レトロスペクティブは、チームが作業方法やチームワークについて振り返り、最終的な改善する時間のことです。レトロスペクティブの計画を作成し、すべての項目について話し合うことが重要です。すべての人がここにいる理由と何を達成しようとしているのかを理解していることが重要になります。
レトロスペクティブは、人々が積極的に参加したいと思えるような、楽しくインタラクティブなものであるべきです。
レトロスペクティブは、誰もが、良いと思っていること、改善すべきだと思っていること、思っていることを何でも声に出すチャンスです。セクションごとにホワイトボードに3列を作って、各参加者が5~10項目を書き出していきます。各参加者につき3票を持っており、優先順位を付けるために、最も重要だと思う項目に票を入れます。そして、最も投票数の多かった項目から議論します。
もしレトロスペクティブが訳に立たなかったり、参加者が本当の問題を提起していない場合は、チームの信頼関係に問題があるでしょう。私たちは、8~10年間共に働いてきた仲間であり、家族や友人よりも一緒にいる時間が長いのです。だから、どんなことでも話せる安全な環境であるのだと伝えましょう。
一般的なゴールは:
- ペアプログラミング
- テスト駆動開発
- 時間追跡
技術的負債(Technical Debt)
技術的負債とは、解決したいがまだ実現していない技術的問題として定義されます。良い例としては、レガシーコードです。パフォーマンス、UX、操作など、特定の項目をキャッチしたい場合は、スプリントゼロに似たキャッチアップスプリントを実行することができます。
コメント
0件のコメント
サインインしてコメントを残してください。