簡単な要約：「よく考えてください-速く書いてください。」 小さなチームに非常に適しています。
最初の日は2つの集会で始まりました。
最初の会議は、今後のプロジェクトの技術的な詳細に専念しました。 それらはすべて、たとえば次のような領域に分割されました。
- システムの改善
- 商品1
- 商品2
- 適応
各領域にはいくつかのタスクが含まれています。
2回目の集会は、私たちがどのように働くかについての入門講座でした。
重要なリソースは時間です。 彼らはすぐに言った：「あなたにはほとんど時間がなく、間違いを犯す権利もある」。
私たちは全員チームに分かれていました。 チームは専門知識の類似性の原則に従って分割されます。 たとえば、私はproduct1をよく知っており、私の隣人はproduct2を知っており、彼の隣人はproduct1を知っています。 したがって、最初のチームは私と隣人の隣人であり、2番目のチームは私の隣人です。 この分離は、SCRUMコンセプトからのわずかな逸脱です。
SCRUMは以下を想定しています。
1.チームのすべての人々はすべてを知っています。
2.誰でも隣人の仕事をすることができます。
このアプローチは、タスクを迅速に完了するために必要です。 プロジェクト自体は、「ワークパッケージ」（製品）と「機能」（機能または単なる機能）の存在を前提としています。 製品は特定の日付の前に終了する必要があります。 すべてを行うために-マネージャーはこの期間をスプリントに分割します。
スプリントは、フィーチャーを作成するための短い期間です。 スプリントは伸ばすことはできません。あなたはそれを捨てるか、別のものと交換することができます。 チームが計画より進んでいる場合は、スプリントを追加できます。 スプリントは交換できます。 つまり、出力で最終製品を提供する小さなプロジェクトのようなものです。
計画はリアルタイムで実行されるため、マネージャーとチームは作業のステータスを把握する必要があります。 これを行うために、彼らは毎日15分間正確に収集し、それぞれが3つの質問に答えます。
- 私は何をしましたか？
- 私は何をしますか？
- 問題はありますか？
集会は立ったままにしなければなりません。 私たちが言われたように、これは人々が椅子の上に広がって良い形にならないようにするためです。
ラリーはスクラムマスターによって編成されます（彼がどうやって外に出るのかわかりません）。彼の仕事はチームの問題を解決し、方向を決めることです。
ワークプロセス自体は2つの段階に分かれています。
- 機能の実装
- テスト中
後者がほぼ主な役割を与えられています。 機能は、テストされるまで完全とは見なされず、テストは成功しません。
プロジェクトに含まれるすべての製品のテストが毎日実行されます。
毎週、システム全体。 毎週のテストでは、当社の製品が他のプロジェクトの製品とどのように連携するかを示しています。
また、各デザイナーは、プロジェクトをメインブランチにマージする前に、自分の機能をテストする（テストを作成して実行する）必要があります。
チームでの私の役割の1つは、テストを担当することです。 私にとって、これは新しくて興味深い経験です。