小さな懸念で彼らの方法をスクラムに変換することは可能ですか?
7 に答える
スクラムの 2 つのベスト プラクティスは次のとおりです。
スタッフを小さなチームにグループ化します。
コミュニケーションを迅速かつ効率的に保つ (特に会議)。
ええ、間違いなく、スクラムは小さな組織に適しています。実際、小さな組織として、スクラムの適用を開始するために必要な再編成は少なくて済みます!
一人でスクラムを行うこともでき、それを「ソロスクラム」と呼びます。
はい、でも...
小さな組織のスクラムで私が遭遇した問題は、プロダクト オーナーが頻繁に不在だったことです (他にも多くの責任があるため)。
言うまでもなく、これは敏捷性に深刻な影響を与える可能性があります。このような状況でスクラムを適用したい場合は、プロダクト オーナーの役割が時間のかかる役割であることを明確に伝えてください。
問題ない。私の経験では、大企業でさえアジャイル (スクラム) に移行することを決定し、「概念実証」として小さなチームでスクラムから始めています。
たとえば、私たちは 2 人の開発者として開始し、20 人以上の開発者、4 つのチーム、3 つの個別のプロジェクトでスクラムに移行しました。
スクラムは、次の理由から小規模な組織に最適です。
- 変更するコマンドアンドコントロールの考え方はあまりありません。
- スクラムチームとプロダクトオーナーの間のより簡単で非公式な話し合い。
- 開発チーム、ドキュメンテーションチーム、QAチームなどの明確に定義されたサイロは多くありません。したがって、製品に取り組んでいる人々からチームを形成し、それらを実行する方が簡単です。
- スクラムプロセスの設定を妨げる可能性のある以前のプロセスはあまりありません。
- 小規模な組織には通常、上級管理職に進捗状況を報告するための巨大なレポートを作成するオーバーヘッドがありません。あなたは彼らが望むときはいつでも彼らを壁の焼け落ちを見るために招待することができます。
これらは十分な理由だと思います。あなたの組織でそれを取り上げてください。
プロセスをよく知っている人があなたのためにそれを実装することを確認してください。また、最初のスプリントのコーチを取得するのも良いことです。
確かに、大規模なチームにのみ適用されるスクラムのいくつかの側面がありますが、小規模なチームでも機能します。
多くのことと同様に、「それがあなたのすることだ」という理由でやみくもにすべてに従うのではなく、会社やチームにとってうまくいくことだけを取る場合です.
私は、1 人の開発者と 3 週間の予算で、そのサイズのプロジェクトに関連するアイデアだけを削減して調整するだけで、非常にうまく機能するのを見てきました。それがまだスクラムとしてカウントされるかどうかはわかりませんが、うまくいきました。
最終的に、プロジェクト管理計画は何もないよりはましであり、問題があることに早く気付くほど、影響は少なくなります。