ここでのパーティーには少し遅れましたが、あなたが書いたことに基づいた私の見解です.
現在、スクラムはプロジェクト管理の方法論であり、開発の方法論ではありません。しかし、私の意見では、開発プロセスを整備することが重要です。それがなければ、構築するのではなく、反応することにほとんどの時間を費やします。
私はテストファーストの男です。私の開発プロセスでは、最初にテストを作成して、要件と設計上の決定を実施します。あなたのチームはそれらをどのように実施していますか? 私がここで言いたいのは、単純に「フェンス越しに物を投げる」ことはできず、失敗以外は何も期待できないということです。その失敗は、テスト チーム (十分にテストを行わず、問題を見逃してしまう) によるものか、開発者 (問題を解決する製品を構築しないことによる) によるものです。最初にテストを書かなければならないと言っているのではありません。反復の終わりに到達します。
私は、デス・スパイラル・メソッドと呼んでいるこの開発方法論の中で、まさにあなたがいる場所にいました。私は政府 (米国) 向けのソフトウェアを何年もこのようなモデルで構築してきました。それはうまく機能せず、多額の費用がかかり、遅れたコード、貧弱なコードを生成し、士気には何もしません。そもそも回避できたはずのバグを修正することにすべての時間を費やしても、前進することはできません。私はその事件で完全に打ちのめされました。
QA に問題を見つけてほしくありません。あなたは本当に彼らを失業させたいのです。私の目標は、すべてが機能するため、QA をびっくりさせることです。確かに、それは目標です。実際には、彼らは何かを見つけるでしょう。私は超人ではありません。私は失敗する。
スケジュールに戻る...
私の現在の仕事では、スクラムを行っていますが、それを呼んでいません。ここではラベルには興味がありませんが、時間通りに高品質のコードを作成することに関心があります。全員が乗船しています。何をいつテストする準備ができているかを QA に伝えます。彼らが2週間早くノックしに来れば、彼らは手と話すことができます. 誰もがスケジュールを知っており、リリースに何が含まれるかを知っており、QA に進む前に製品が宣伝どおりに機能する必要があることを誰もが知っています。それで、それはどういう意味ですか？QA に「XYZ をわざわざテストしないでください。XYZ は壊れており、リリース C まで修正されません」と伝え、QA がそれをテストする場合は、その声明を指摘し、時間を無駄にしないように伝えます。厳しいかもしれませんが、時には必要です。失礼なことは言いませんが、誰もが「ルール」を知る必要があります
あなたの経営陣は参加しなければなりません。そうでない場合は、問題が発生します。QA はショーを実行できず、開発グループもショーを完全に実行できません。すべてのグループ (グループが 1 つのグループに 1 人だけである場合や複数の帽子をかぶっている人物であっても) は同じページにある必要があります: 顧客、テスト チーム、開発者、管理者、および他のすべての人。通常、戦いの半分以上はコミュニケーションです。
おそらく、あなたはスプリント中に達成できる以上のものを噛み砕いています. そうかもしれません。どうしてそんなことをするのか？スケジュールを合わせるには？もしそうなら、それは経営陣が介入して問題を解決する必要があるところです. QAにバグのあるコードを提供している場合は、彼らがそれを投げ返すことを期待してください. 未完成の 8 つのものよりも、機能する 3 つのものを与える方がよいでしょう。目標は、イテレーションごとに完全に実装される一連の機能を作成することであり、中途半端なものをまとめることではありません。
これが意図されたとおりに受け取られることを願っています-暴言ではなく励ましとして。私が言ったように、私はあなたがいる場所にいましたが、楽しくありません。しかし、希望はあります。スプリントで物事を好転させることができます。おそらく、次のスプリントでは新しい機能を追加せず、単に壊れているものを修正するだけです。それはチームで決めなければなりません。
テスト コードを書くためのもう 1 つの小さなプラグイン: 「最初にテストを書く」アプローチを採用して以来、私は自分の製品に対してはるかにリラックスし、自信を持っていることに気付きました。すべてのテストに合格すると、テストなしでは絶対に持てないレベルの自信が持てます。
頑張ってください！