アジャイルであるとはどういう意味ですか？

私たちは誰もがアジャイルな方法でやろうと言っているプロジェクトを持っていますが、アジャイルとは何かを明確に理解しているとは思いません。

以前のプロジェクトでは、計画会議を開いてから、製品バックログを定義し、2〜3週間のスプリントで開発者に作業を割り当てました。毎朝、スクラムミーティング（毎回1時間半行われているように見えた）があり、その後、各開発者がスクラムミーティングに参加しました。スプリントが終了し、完了していない作業が次のスプリントに追加されるまで、誰もテストを作成しませんでした。

開発者はお互いに話をすることはほとんどなく、開発に関与するTDDはありませんでした。実際、ほとんどの開発者は最初に仕様を持っていて、スプリントがアレンジされた2週間または3週間だけそれを使いました。クライアント/ステークホルダーとのコミュニケーションはほとんどありませんでした。

通常、QAは数か月後に関与し、それまでに要件が欠落していることがわかりました。これにより、必要な作業量がさらに増加し​​ました。明らかに、フィードバックループはありませんでした。

だから私の質問は、どこで間違ったのか、そしてチームが同じ間違いをするのをどのように防ぐことができるのかということです。

あなたが説明しているのは、定義によりアジャイルではありません （アジャイル宣言）、 それは毎日のステータスミーティングを伴うウォーターフォールです。アジャイルとは、製品の所有者、つまり顧客とのインタラクティブなフィードバックループがない場合、変化に容易に適応することを意味します。

アジャイルとは、製品の所有者/顧客との絶え間ないコミュニケーションを通じた、迅速な失敗に関するものです。失敗は遅かれ早かれ、より少ない作業が実行され、「失われる」ことが少なくなります。そして、あなたは「私たちはそれを間違って行うことに多くの時間を費やしたので、それを失敗に導くが、この同じ道を続ける必要があるので、正しくそれをする時間がない」という議論にとらわれない「。

あなたの管理が「SCRUM、しかし...」をしているように聞こえますが、「しかし」彼らは理解していない、または同意していないすべてのSCRUMを捨てて、いつもと同じ偶然の滝のように物事を行いますが、新しいピカピカの流行語の名前を付けました。

SCRUMでは毎日立ってないで提供に関する状況を管理し、あなたの仲間のチームメンバーがやっているし、お互いアウトしていない重複した作業を助けることができるか知っているので、それは、開発者との対話を強制することです。1人あたり45秒以上かかる場合は、間違っています。チームの透明性についてです。1人の人が1日間の仕事に相当するものについて同じステータスを複数日与えている場合、チームはすぐに人の問題を解決できます。

記述されているとおりにお互いのコードをテストしていない場合、正しく実行されていません。テストは、後から考えるのではなく、プロセスに組み込む必要があります。QAは計画セッションに含まれ、テストにかかる時間の見積もりを提供する必要があります。

Sprintのコミットメントを満たしておらず、物事をロールオーバーしていない場合、正しく実行していません。スプリントは、あまりにも多くの作業をコミットしている場合、コミットメントに関するものであり、それをやめ、成果物に正確にコミットできない場合、予測可能性または再現性を導入する方法はありません。

Jarrodが良い答えを提供しました（それに対する+1）。これについて少しお話したいと思います。

アジャイルは、製品の所有者（顧客）とチームとの間の迅速な失敗とフィードバックだけではありません。関係するすべての利害関係者間の迅速なフィードバックについてです。真にアジャイルであること（およびこれはマニフェストから直接得られる）とは、開発者がより良い製品を提供するのを助けるためだけにプロセスが存在することを認識することです。プロセスの上の人々は、チームが既存のプロセスが機能しないことを認識するとすぐに、それを変更して機能させることを意味します。

「スクラムが...」も問題ですが、このコインには両面があります。マニフェストを見ると、それはチームに関するものであり、ツール/プロセスがあなたのために機能していることがわかります。2つのチームが同じではないため、それぞれのチームの動作がわずかに異なるため、問題ありません。確かに、スクラムの方法論全体を取り上げて、それを手紙に沿って追ってみて、それがチームに効果があるかどうかを確認することができます。

別の方法は、別のプロセスをチームにプッシュし、スクラムが指示したとおりに全員をフォローさせる代わりに、アジャイルアプローチを試してください：チームとコミュニケーションを取り、一緒に問題の領域とソリューションを特定できるかどうかを確認します。その後、作業方法に徐々に変更を導入して、問題に対処します。

少し時間がかかるかもしれませんが...

1. チームが製品を提供する能力に最大の影響を与える最大の問題を最初に修正します。
2. 差し迫った問題を特定し、ソリューションの提案に参加することで、チームメンバーは特定のプラクティスが重要である理由を理解し、それらを実行するように指示されているため、単にそれを実行しません。

スクラムとデザインパターンを類推すると、提案した方法で作業することは、コードを可能な限りシンプルに保ち、必要なときにのみデザインパターンに収束するパターンへのコーディングに似ています。単にデザインパターンを選んでそれをローリングする（つまり、スクラムとそのすべてのプロセスを1つのセットとして盲目的に選択する）のとは対照的に、コードが他の方法よりも複雑で保守が困難になることがあります。

理解する鍵は、アジャイルは物事を行うための新しいプロセスを考え出すことではないということです。それは、既存のプロセス/プラクティスに対する継続的な変更と継続的な調整に関するものです。

チーム（およびその管理者）が本当に「アジャイル」になりたい場合、チームとしてアジャイルマニフェストとそのプリンシパルを読み、議論することから始めなければなりません。次に、作成されたアジャイル手法（たとえば、スクラム）の1つを選択し、そのトレーニングを取得して、それに従うことから始めます。それを修正する前にしばらくの間、かなり厳密にフォローすることをお勧めしますが、それは私だけです。

また、選択された特定のアジャイルプロジェクト方法論をサポートするために使用されるエンジニアリングプラクティスを深く検討する必要があります。