今日、私はHabrに関する最初の記事を書くことにしました（厳密に判断しないでください）。
これについては、私からの以下の記事のほとんどと同様に、アジャイルについてお話します。 私の意見では、このシリーズのスクラムといくつかの瞬間は、この方向を好む人にとって興味深いものです。
この記事では、スクラムのゼロ反復、大衆での使用について話し、ゼロ反復が真のスクラムの一部であるのか、スクラムのブランド化を支持して名前を付けたダークスクラムバットの特徴であるのかを判断することも決めました。
準備作業を実行するためにZero Sprintの使用を練習しているチームと頻繁に会います。製品バックログと開発インフラストラクチャ（継続的統合サーバー）を通常の状態にして、作業の新しいフェーズの開始などにチームを準備します。彼らはそれがスクラムの一部であると決めましたか？ これはどれほど便利ですか？
この問題については、アジャイル界の有名人の声明に目を向けるのが最善だと思いました。
ジェフマッケナ言う：
この用語は、新しく形成されたチーム、またはスクラムを初めて使用するチームがよく使用します。 最初のバックログを合理化し、ビルドと自動テスト用のジョブとマシンを正常な状態に戻し、すべてのツールを準備し、少しトレーニングし、すべてが機能することを確認するためにもう少し作業します。これは「公式」スクラムではありません。しかし、これは一般的なケースであり、非常に一般的です。 チームは、実際の作業を攻撃するために（ゼロ反復後）完全に準備されることを期待しています！
Den Rausornは、ゼロ反復を次のように説明しました。
アイデアは単純です：初期スプリント（初期化、ゼロスプリント、またはゼロイテレーションと呼ばれます）を取得し、それに簡単な目標を設定します。
- 結果として、製品のバックログにある多くの品質要素を取得します
- 高品質のコードを記述できる機能を提供する最小限の開発環境を提供し、
- 最小限の作業コードを作成します。どんなに小さくてもかまいません
マークワウナは、ゼロスプリントがスパイクとして最適に使用されると考えています。
チームは、この反復の終了までに3つの結果を実行する必要があります
- 評価および優先順位付けされたすべての機能/ストーリーのリスト»
- すべての機能/ストーリーが必要な反復/スプリントに配置されるリリース計画
- アプリケーションアーキテクチャは、少なくとも高レベルで作成する必要があります。つまり、これらの機能の実装方法を明確にする必要があります。
スイスのアジャイルコーチであるPeter Stevensは、ゼロスプリントを使用して最も重要な機能（すべてではない）を評価し、「それが何を意味するのか」の定義に同意し、顧客の信頼を回復/向上させます。 他の多くの人と同じように、彼はこのスプリントの長さを他の人より短く、スプリントチームの通常の長さにすることを勧めています。
スクラムですか？ チームの通常のスプリント長とはまったく異なる長さの反復を取得しますが、スプリントの結果は潜在的に販売可能な製品ではありません。 それとも、そのような矛盾に目をつぶれるほど役立つのでしょうか？
多くのチームには、プロジェクト/リリースを開始する前にやることがたくさんあります。
ジョージ・ディンウィディは、チームがすべての予備作業を行おうとしても、今後のスプリントで完了しなければならない未完成の部分が常にたくさんあると考えています。 また、「変更を歓迎します！」 これは、インフラストラクチャの決定、テクノロジーの選択、ゼロイテレーションで定義された機能のリストがプロセスを制御することを意味し、その逆はありません。 ただし、各反復は、出力で動作中の製品を受け取る必要があります。
製品の提供を開始するために必要なことを自問してください。 それを取り、小さなスライスにカットします。 これらのスライスが機能していることをよく示す例を考えてください。 一部の部分には未回答の質問があります。 とりあえずこれらの部品を置いておきます。 コンセプト全体を最初から最後まで、またはその近くで実行する1つの中央部分を選択します。 チームの1つの反復として評価します。 評価は「正しい」必要はなく、ただ正しくなければなりません！ この製品の開発を開始してください！
ジョージによると、これは始めるための最良の方法です。 チームはテクノロジーに必要なスキルを習得してから、実際の作業を終えながらゆっくりと開発インフラストラクチャの構築を開始する必要があります。
はい、開発インフラストラクチャを完成させる必要があります。 これを完了するのにそれほど急いではいけません。 作業量を増やすような方法で改善し続けてください。 はい、技術的なスキルを改善する必要があります。 それは常にあるべきです。 実験を続け、境界を広げてください。 はい。バックログに追加し、優先順位を付け、ストーリーに分割し、再度優先順位を付ける必要がある機能がまだあります。 これは永遠に続きます。
また、何も表示されない反復はお勧めしません。 ただし、ゼロイテレーションの大部分は予備的なイベントで発生しますが、システムの「コア」をどれだけ小さくても、この段階ですでに最初から最後まで検証できるようにしたいと思っています。
Alistar Cowbernはこの問題に関してより厳しいです：
冒頭で明らかなビジネス価値をもたらさない何かをするときに、誰かがスクラムをチームとして使用することにプレッシャーをかけているという漠然とした疑念に苦しんでいます。 そして、この「誰か」が「O. 「これはスプリントゼロです！」つるはしを持った小作人が玄関口を離れるように...そして、他の人は、これが素晴らしい答えだと思い、何度も繰り返しました。 そして、それは文化の一部になりました。
スプリントゼロは、事前の計画と同一視すべきですか？ 事前の計画なしでゼロスプリントを想像するのは本当に難しいです。 これがプロジェクト憲章の一部であることを想像してください。 しかし、多くのチームは、ゼロイテレーション中にプロジェクトの目標とビジョンを議論しません。 多くの場合、バックログとインフラストラクチャの作成に時間がかかります。
このテーマに関するケン・シュヴァーバーは次のように述べています。
「スプリントゼロ」というフレーズは、最初のスプリントの開始前に発生する計画を説明するために作成されました。 また、計画では後で頻繁に変更されるアーティファクトが作成されるため、この段階で最小化する必要があり、スプリントのレビュー/スプリントの計画中にすべてのスプリントを行う必要があります
ゼロスプリントの問題に関するアジャイルの著名人の一般的な意見は、これがスクラムにとってまったく問題ではないことに同意する可能性が高く、可能な限り回避する方が良いことがわかります。 そして重要なことは、ビジネス価値を最初から追加することです。 あなたのチームは、すぐにビジネス価値を生み出し、途中でインフラストラクチャを徐々に構築し、技術スタックについて決定する代わりに、ゼロの反復を実行することに大きなプラスを見ますか？
彼が見た場合、あなたはあなた自身の質問に答える必要があります-これはすべて、「準備作業」がゼロ反復後または最初の後に終了しない状況のような匂いがしますか？チームの機能不全？ 答えが「いいえ」の場合、これがあなたの方法かもしれません。
場合によっては間違っているかもしれませんが。 たとえば、いくつかの準備段階の後にいくつかのチームが製品の大幅な増加を開始しやすいことを言及するのを忘れましたが、ゼロスプリントを回避するために使用できるアクションのリストはまだあります。
次の記事で自然に書くことについて。