スクラムが時々失敗するのはなぜですか？

あなたの友人の中には、おそらくスクラムを試し、拒否することを決めた人々がいます。 おそらくあなた自身がこのような状況にあったのでしょう。 スウェーデンのマイクロソフト社内トレーナーであるジムコプリンとスクラムを学びました。 彼はすべてがスクランブルされたいくつかの会社で働いていました。 また、古典的な開発方法論が使用されていたものでも。 この記事では、自分の意見を述べ、スクラムの秘密を明らかにしようとします。なぜスクラムの秘密が多くの人に与えられないのか。 カットの下で読んでください。



スクラムとは何ですか？ なぜ必要なのですか？また、その利点は何ですか？ 多くの人がファッションステートメントとしてスクラムを使用し始めているため、これらは重要な質問ですが、それはツールであり、非常に具体的です。 まず、 柔軟な開発方法論であり、 積極的に変化する要件に比較的簡単に適応できるようにします 。 例を挙げましょう。あるプロジェクトで、彼らは古典的なマルチページビデオアプリケーションを作成することに決めました。数か月後、彼らは上部に1ページのアプリケーションを作成することに決め、コードの半分を削除し、半分を書き直す必要がありました。 数か月後、彼らはビデオだけでなく写真に対しても何をすべきかを決定しましたが、これにはデザインの完全な再設計が必要です。 しばらくして、チーフデザイナーと上級管理職が変わり、新しいデザイナーはどのように、何をすべきかについて彼自身のアイデアを持っていました。 これは、実際のユーザーのレイアウトをテストし、ユーザーのフィードバックに応じて常に何かを変更したマーケティング部門からの通常の編集や基本的な変更をカウントするものではありません。 はい、おそらくこの場合、スクラムは非常に柔軟性を与えるため必要です。 さらに、これはそのようなプロジェクトが存在する唯一の方法です。 もちろん、スタンドアップ、回顧などのための時間の損失、コードの無条件の共同所有、および同時タスクの数の制限が全体的な効率を低下させますが、これはプロジェクトが高い変動性の下で安定して動くためのわずかな費用です。 スクラムは、良い人生からではなく、必要から生まれました。



別の例：Webスタジオが50番目のプロジェクトを実施しており、これは一般的なCMSの典型的なオンラインストアです。 顧客は、自分が何を望んでいるのか分からないが、経験豊富なマネージャーが混乱した考えを正しい方向に導き、合意された仕様とレイアウトが表示されるようにします。 今月、デザイナーは既に3つの同じプロジェクトを完了しており、彼のすべての創造性を結びつけて、完全な仕事で仕事をしています。 彼らはそれをチェックすることさえしません。なぜなら彼らはそれが長い間働いており、常に素晴らしい仕事をしていることを知っているからです。 レイアウトデザイナーとプログラマーは、片方の目でハブを読み、もう片方の目でIDEを見て、単調に通常の作業を行います。 仕事は顧客に引き渡され、彼は、まあ、彼が初めてそれを受け入れて、編集のリストを展開してはいけません。 スクラムはそのようなプロジェクトで動作しますか？ それを理解しましょう。 マネージャーは最初に作業計画を作成できますか？ もちろんできます。 顧客は開発中に突然主要なモジュールを放棄できますか？ 少なくとも彼がすでに行った仕事にお金を払わなければならないということはまずないと思います。 そうでないとしても、そのような状況は、めったに起こりません。 過去の経験に基づいて、専門家はプロジェクトをさらに発展させ、変更に対して安全にする方法を提案できますか？ もちろん、彼らはそのようなタスクに多くの専門知識を持っているからです。 どこかで古典的なアプローチが失敗したとしても、これらの損失はドラムを打つほど大きくはありません。



スクラムは非常に柔軟ですが、無料ではありません。 あなたのプロジェクトへの回答：本当に大きな変動があるので、傷が必要ですか？ スクラムがプロジェクトで機能しなかった場合はどうしますか？ 答えは簡単です。使用しないでください。つまり、あなたのケースには適していないということです。 あなたはテイラーとドラッカーの作品を読むことができます; ITでは、古典的な管理の成果を過小評価しています。 古典的な方法論で管理されているプロジェクトの締め切りに間に合わせる方法 （コマーシャルブレイク）に関する私の記事を読むことができます。 適切な設定でうまく機能するものをあきらめる必要はありません。効率を上げるための古典的な方法はたくさんあります。



しかし、もちろんこれを監督に説明することはできません。 経営陣は、スクラムが他の方法で動いていない不安定なプロジェクトに取り組んでいることに気付いたとき、これは普遍的な錠剤であると考え始めます。 スクラムは進歩的で革新的であり、スクラムで作業していると言うと、クラシックで作業する場合よりもクールに聞こえます。 また、ITの管理（正直に言うと）は初期段階にあり、他の業界の管理よりもはるかに遅れていることは重要ではありません。 結局のところ、日付を正確に計画する方法さえ学んでいません。 しかし、分業、責任範囲の割り当て、モチベーション、コントロールなど、実績のある実用的な管理手法を忘れて、新しくて高度なものすべてを求めています。 ITではすべてが異なるという神話があります。たとえば、バスファクターが増加するため、コードの共同所有は有用です。 しかし、他の業界はこれにどのように対処しますか？ 役人は、例えば、バス要素を増やすことはしませんが、それどころか、ぼやけた責任は官僚主義の兆候と見なされます。 ところで、今流行している継続的インテグレーション（素晴らしいこと）は、実行と制御の機能の平凡な分離であり、私たちの誕生とコンピューターの発明のずっと前に発明された原理です。 そして、実際には、Scramovのスタンドアップラリーは、ほとんどの企業で各営業日の初めに開催される通常のソビエト計画会議です。 したがって、同僚は、古典を読み、彼らがあなたに売ろうとしているものに批判的です。



まとめ：プロジェクトで非常に大きなばらつきがある場合-スクラムは作業の効率を高めることができます。 計画を立て、1〜2か月で何が起こるかを大まかに知っている場合-スクラムを使用しないでください。あまり役に立ちませんが、時間や使いやすさなどで支払う必要があります。そこからのアイデアがあなたにとって興味深いと思われ、それがうまくいくと思われる場合は、スクラムを部分的に使用してください-最も重要なことは、熱狂的にせずに自由にそれらを拾い上げて使用することです。 この記事が有用であり、適切なタイミングで方法論を選択するのに役立つことを願っています。



PS：この記事で述べられていることはすべて、著者の個人的な意見であり、10年以上にわたるソフトウェア開発の実践で得たものです。 多くの点は主流とは異なり、あなた自身の頭で考え、絶対的な真実のために何も取らない。 一致または反対する経験があれば、コメントに記入してください。 そして、スクラムポーカーとスクラムプリファレンスで幸運を祈ります！