アジャイル開発の導入を検討する前に、組織/プロジェクトに最適なアジャイル開発を検討してください。たとえば、スクラムを検討している場合は、厳密に使用するか、スクラムのよりゆるい形式を使用するか、または別の方法で完全に適合するかどうかを検討してください。私の答えは、アジャイル手法としてのスクラムです。
スクラムは、技術革新が必要なプロジェクトに最適で、ほとんど知られておらず、実験が必要です。既存の製品の保守や定期的な保守作業の処理などを行うのに最適ではありません。幸いなことに、スクラムはゆるいフレームワークであり、できる限り最適な方法で使用できます。
メンテナンス作業には、かんばんの方が適している場合があります。または、スプリントを管理し、毎日のスタンドアップのようなことを行うために、いくつかのスクラム要素を試してみてください。これを「スクラム」と呼びます。「はい、私たちは会社でスクラムをしていますが...」。それは大丈夫です、それについて悪く感じないでください。
組織に適切なスクラムを導入するには、製品所有者と利害関係者の関与が必要です。あなたが小さな会社なら、その人は一人の人間、上司であり、大きな企業では製品マネージャーと部門長/上司であるかもしれません。スクラムを導入するための2つのルートを提案します。
1）既存の作業キューをすぐに管理するために、少し緩やかな形式でスクラムの使用を開始できます。しかし、かんばんにも注目してください。
2）革新、早期のフィードバックを必要とし、多くが不明な新しいプロジェクトで、より厳密な形式でスクラムの使用を開始します。スクラムがこの新しいプロジェクトに理想的であることを上司/製品所有者に提案できます。
でも覚えておいて！これはコードだけではありません。製品の所有者は重要な役割を担っており、自分の役割を理解し、果たす必要があります。これは、たとえば、すべての仕様を前もって記述するのではなく、最小限から始めて、急速に反復し、フィードバックを取得し、それを学習してフィードバックすることなどを意味します。スクラムの導入に熱心なプロダクトマネージャーと協力してみてください。ただし、プロダクトオーナー側からであり、理想的には彼/彼女は管理要求をかわしてスプリントを保護するのに十分なタフでなければなりません。
スクラムを導入するには、開発と製品管理からの団結した努力が必要です。
このような新しいプロジェクトでは、新しいチームを別の部屋に移動して、ポストイットメモを使用して、バックログ、進行中などのさまざまな状態で作業を視覚化してみてください。この段階で電子ツールに行き詰まらないでください、物事をできるだけシンプルにしてください。ポーカーを開始するときにカードでポーカーを計画するのは愚かなことだと思わないでください。チームのスピードが上がったら、おそらく数字を言うだけでは使用しないでしょう。
私の経験では、最初にスクラムを純粋な形式で導入し、その後、保守タイプの作業キューを増やすためにそれを緩和する方が簡単です。逆に難しいです。
私の最後のコメントは、スクラムが何らかの開発万能薬だと考えることに注意することです。そうではありません。スクラムは、製品革新のための便利でシンプルなフレームワークですが、ビジネスが必要とする他の方法を組み合わせて検討し、気にしないでください。