アジャイルチームは新しい機能を毎日提供する必要がありますか？

私の会社は、ウォーターフォールスタイルの開発からアジャイル/スクラムへの移行の最中です。とりわけ、私たちは私たちが持っている期待があることを告げている新しい作業を、テスト可能（QAによっては）毎日の終わりにしています。

開発者のほとんどは、会議やその他の企業のオーバーヘッドにより、1日約2時間を失います。つまり、6時間（せいぜい）の期間で、QAが機能するための完全な機能を生成するのに十分なコードを設計、作成、単体テスト、ビルド、デプロイ（リリースノート付き）する必要があります。ビルド/デプロイ/リリースノートは適切なCIセットアップで自動化できることを理解していますが、まだそこにいません。

また、サーバー側のコードを作成する大規模なオフショア部隊があり、12時間の時差によりこれがさらに困難になります。

機能をできるだけ早くエンドツーエンドで完了するために、ストーリーを狭くて深い垂直スライスに仕上げようとしますが、ほとんどの日はかなり必死に感じます。私はしばしば、QAが確実にビルドされるように、愚かで壊れやすいショートカットを取っている人々を捕まえます。この問題は、スプリントが数日間進行した後、不可避な欠陥が入り込み始め、同じ6時間のウィンドウに収まらなければならないときに悪化します。

これはアジャイルチームにとって通常のペースですか？CIセットアップを実装できたとしても、このペースを維持し、高品質のソフトウェアを作成する方法がわかりません。

編集： ここにいくつかの良い答えがあります。アジャイルチームが毎日新しい機能を提供すべきかどうか、私が本当に求めていたことを実感しました。それに応じてタイトルを更新しました。

最近アジャイルの名の下に犯されている犯罪は私を悲しくさせます。多くの人がこの移行に苦労しています。

アジャイルマニフェスト：「プロセスとツールよりも人々と相互作用を大切にしています。」人々が明らかに傷ついているとき、そのプロセスは間違っています。私はあなたにそれをする方法を教えたくありませんが、私がそれをする方法を共有します。

私のチームでは、重要な部分は、チームの残りの時間を無駄にするような方法で壊れた共有レポコードへのコミットを避けることです。この意味でのみ、「実用的なコードを毎日配信する」よう努めています。QAを破らないでください。他の開発者をブロックしないでください。理想的には、バグをチェックインしないことです。（はは）。

その意味は、毎日何かをコミットしなければならないということではありません。意味は、良いものだけをコミットする必要があるということです。これにより、毎日、だれでもコミットしたすべての良いもののビルドを取得できます。このようにして、チームはすべてのシリンダーで発砲し続けます。

私のチームではQAは一定です。私は商用製品を構築しているため、製品が廃止されるまでプロジェクトは終了しません。QAエンジニアは、テストに使用できる機能をテストします。QAエンジニアには常にバックログがあります。理想的に必要なすべてをテストまたは自動化するための十分なQA時間はありません。

開発者が機能または修正のために変更をマージする前に数日を必要とする場合、それは彼らが私たちの時間を危険にさらす前にすぐにコードを取得するのに役立つなら、それは大丈夫です。開発者は、チームまたはQAに影響を与えることなく、プライベートリポジトリまたはブランチにコードをコミットできます。開発者は、開発者のレポジトリまたはプライベートブランチからビルドされたコードで単体テストまたは回帰自動化を実行できます。特に危険なケースでは、QAエンジニアが開発者と協力して、マージする前にテストし、チームを遅延から保護します。

この意味で、私はあなたのマネージャーが望むものを実践しています。過去12年間、ほぼ毎日、私の開発チームは共有リポジトリで機能するコードを持っていました。いつでも出荷できる状態です。ときどきこれを達成できませんが、あまり心配する必要はありません。大きなツールの変更や困難なマージに対応することが意図的な場合もあります。

私にとって、アジャイル宣言は、1990年代に現れた開発プロセスに関する最高の新しい考え方を要約しています。私はこれらの原則を真に信じていますが、プロセスの詳細はさまざまです。私が見るように、アジャイルのポイントは、プロセスの奴隷になることではなく、製品とクライアントのニーズにあなたのプロセスを適応させることです。

昨日動作しているソフトウェアがある場合、なぜ今日動作しないのでしょうか？今日タスクを完了しなかった場合、今日のビルドは昨日と同じになります。毎日のビルドと開発のペースは別のものです。毎日のビルドがあるからといって、すべてのビルドに新しい機能があるわけではありません。

最終的にいくつかの機能が終了し、メインブランチでチェックインされると、ソフトウェアをビルドしてテストを実行する自動プロセスが必要になります。テストの構築または実行に問題がある場合は、チームに通知され、チームはそれを再び機能させるために努力を集中します。これがCIの仕組みであり、動作中のソフトウェアを常にリリースするのに役立ちます。

短い答え：いいえ。それは単に毎日達成することはできません。

ただし、アジャイルチームは、各スプリントで動作するソフトウェアピースまたはユーザーストーリーを提供することになっています。通常、進捗状況と障害を確認するために、ステータスミーティングが毎日開催されます。

品質ソフトウェアに関しては、継続的インテグレーション（CI）プロセスが導入されているため、品質管理が小さな作業（チェックイン）に適用され、設定された頻度で実行されます。またquality of software、すべての開発を完了した後に品質管理を適用する従来の慣行を置き換えることにより、を改善し、それを提供するのにかかる時間を短縮することも目標としています。

いいえ、毎日新しい機能を提供することを期待すべきではありません。すべての機能を、開発者が約6時間の開発時間で機能を終了できるほど小さなサイズに分解できるわけではありません。

スクラムを行う場合は、少なくとも2週間のスプリントで行う必要があり、機能が完了するまでに約0〜8日かかるサイズです。製品所有者への約束は、スプリントの終わりに本番環境に入れることができる、新しく、テストされ、検証された正しい作業コードを提供することです。（注：実際に本番環境に配置する必要はありませんが、目標は、必要に応じて実行することです）

優れた方法論により、CI（Continous Integration）サーバーをセットアップして、少なくとも1日に1回は動作するソフトウェアの作成を自動化することが提案されました。機能を終了したらすぐにコードをチェックインするという考え方は、次のビルドサイクルになり、テストのためにQAの手に渡ることができます。

目標は、スプリントの終わりまでに機能を実行およびテストすることです。ビルドを行うためにスプリントの最終日までQAを待機させてから、すべての機能をテストさせる必要はありません。彼らはそれをすべてテストする時間がなく、バグを修正する時間がありません...

CIサーバーをセットアップできない場合は、開発者が完成したコードをチェックインし、機能が完了してQAに引き渡す準備ができていると主張するたびに、QAの新しいビルドを手動で作成する必要があります。

実際にはプロジェクトのサイズに依存します。プロジェクトが大規模なプロジェクトである場合、これを実現する方法はありません。

継続的インテグレーションツールから得られるデイリー（またはそれ以上）のビルドは、動作するソフトウェアを意味しません。それはほとんどコンパイル可能なコードを意味しません。

日々のビルドを提供するプロジェクトが数多くありますが、これは継続的な統合のおかげで機能するソフトウェアです。少なくとも理論的には。

つまり、必ずしも新しい機能が含まれているわけではありません。マイナーなバグ修正はほとんどないか、まったくないかもしれません。

理論的には、QAにより多くの作業を毎日提供できない場合、開発者の数を増やすか、テスターの数を減らす必要があります。ひどいアイデア！

あなたの仕事は物事を成し遂げることです。

QAに、テストが完了したらテストするものがあることを伝えます。その理由を説明する必要があります。

「CI」の概念について混乱していると思います。CIが実際にどのように機能するかについて、Martin Fowlerによるこの優れた記事をご覧ください。それはあなたの質問に正しく答えるはずです。