スクラムは過大評価されている

ほとんどの企業は何らかのスクラムプロセスに従っています。通常、これは2～3週間のスプリントを伴います。各スプリントの終了時に、変更がデモされ、レトロスペクティブが実施され、バックログが整理されます。各スプリント中にタスク完了時間が記録され、これにより管理者はプロジェクトがいつ完了するかを将来に向けて予測することができます。

私が関わってきたスクラムプロジェクトの多くは、タスクへの「コミット」または「所有権の取得」を強調しています。スプリント終了時に、多くのエンジニアが未完了のタスクについて責任を問われます。スプリントベロシティは、繰り返し強調されるもう1つの考え方です。ベロシティを維持する必要があります！ソフトウェア作成がレースのようなものだと言うのは、そうではありません。エンジニアがメトリクスで責任を問われる場合、彼らはそのメトリクスに最適化します。これはあなたが望むものではありません。

スクラムはチームが従うための理解しやすいフレームワークを作成し、管理者に将来を予測するためのツールを提供します。ウォーターフォールを実践してきたチームはスクラムを簡単に理解できます。

スクラムの実践の多くは必要ありません。たとえば、ほとんどの問題追跡ソフトウェアにより、マネージャーはチケット完了の頻度に関するレポートを実行できます。この情報があれば、マネージャーはベロシティを推測できます。ベロシティをプロセスに組み込んで大事にする必要はありません。所有権の取得は茶番です。私たちは自然にそれを行います。それを明示的にすることは侮辱的です。私が関わってきたすべてのプロジェクトで、各エンジニアはアプリケーションの自分のスペースを持っています。

ソフトウェア配信を改善する他の方法：

• 週次デプロイが必要な場合は、スケジュールしてください。準備ができたものをデプロイしてください。
• バックログを整理しておきます。そうすればエンジニアは仕事がなくなることはありません。
• 私の意見では、レトロスペクティブは最も重要な非開発活動です。これなしでは、より良く、より効率的な組織になる可能性はありません。
• 自動化、自動化、自動化
• 機能のリストにコミットすることは馬鹿げています。タスクをランク付けし、できるものを完了してください。「タスクA」が完了しなかった理由について心配することは時間の無駄です。タスクが大きすぎるか、より優先度の高い作業が行われたかは明らかです。
• デモはクライアントが気にかけてフィードバックを提供しない限り、時間の無駄です。
• 日次ミーティングが必要な場合とそうでない場合があります。私は数日ごとにミーティングすることを好みます。

結局のところ、最も効率的な方法でクライアントに価値を提供することが重要です。