これを言って、スクラムは何らかの理由で実際の生活に適用できない難解なテクニックであると理解されています。 たとえば、「Scrumには多くの生地が必要であり、私たちの手段の範囲内で生活する必要があります」または「Scrumでは、開発者は超普遍的である必要がありますが、ありません。」 もしそうなら、それは「あなたは頭で考える必要がある」と結論付け、すべてが独自の方法で行われる必要がある。 このアプローチの結果、ワークフローにいくつかの改善が現れますが、全体的には何も変わりません。これは、スクラムが現実世界とは関係のないファンタジーであることをさらに確信させます。 そうではありません。
スクラムを実装しようとするほぼ全員が、2つの重要な間違いを犯します。 第一に、事業との関係を変えずに開発のみでスクラムを導入しようとしているため、ベンチャーの失敗が保証されます。 第二に、スクラムは部分的に実装しようとしていますが、これもまたベンチャーを絶望的にしています。
この投稿では、会社全体でこのアイデアに対するサポートを得た後にのみ、スクラムを開発に実装する理由を説明します。
ゲームとしてのスクラム
スクラムの最も正確な説明は、 スクラムガイドのフロントページにあります。
スクラムはゲームのルールです。
スクラムはプロセスの説明（計画、毎日、レビュー、レトロ）だけでなく、ゲーム参加者の役割、お互いの関係、共有する価値の定義でもあります。
たとえば、チェス。 2人のプレーヤーがフィールド上でピースを移動します。 1つは白だけです。 もう一方はただの黒です。 騎士とポーンが動く一連の動きとルールがあります。 深刻なチェスはしばらくの間再生されます。
プレーヤーが「チェス」をしていると言ったが、実際にチェスの駒でチェッカーを続けている場合はどうなりますか？ 「チェス」をプレイしているときに、1人のプレイヤーが実際のチェスのルールに従い、2人目のプレイヤーが「チャパエフ」をプレイするとどうなりますか？
スクラムガイド-思慮深く、合理的で、深く、バランスのとれた、理解しにくい文書。 2016年の現在の版までに、彼は20歳以上です （Scrumは1995年に公表されました）が、そのボリュームはわずか17ページです。 会社の仕事を整理するだけで十分ですか？ いいえ、チェスのルールのようにうまくプレイする方法を学ぶには十分ではありません。
同時に、スクラムガイドは真空から出たものではなく、実際、生産で開発された作業組織の原則と技術に基づいており、実際にその価値を証明しました。 歴史は、成功の度合いが異なる実際の理論的原理の適用例を知っています。
Hennig Brandは 、錬金術の原理に基づいて、尿から水分を蒸発させて金を獲得しようとしました。 主なアイデアは、両方とも黄金だったということでした。 これは、ベンチャー企業が完全に失敗したということではありません。 その結果、1669年に彼はリンを受け取りました。これは金と同様に、一定の商業的価値があります。 しかし、それはまだ純粋な運でした。 これらの原則に基づいて構築された「スタートアップ」は、当初は所有者にいくらかの収入をもたらしましたが、全体としてすぐに失敗し、比較的少量で販売されました。
一方、 ハンフリー・デヴィは 、電気分解の原理に基づいて、1807年にカリウム、ナトリウム、バリウム、カルシウムを発見しました（これは決してそれらによって発見された化学元素の完全なリストではありません）。 その結果を自然以外の方法で呼び出すことは困難です。 しかし、それは彼の個人的な才能、忍耐力、大胆不敵さを損なうものではありません。
スクラムとゴールドラットの制約理論
The Goalのビジネス管理理論の第一人者であるEliyahu M. Goldrattは、 The Theory of Constraintsの著者であり、製造プロセスのボトルネックを見つけて排除するためのテクニックを説明しています。 「明らかではないですか？」で、彼は、店舗倉庫システムの作業を再編成することにより、最も人気のある商品の不足アイテムの数を減らすことにより、売上を増やす方法について話しています。
彼の理論は、会社の真の結果を達成するために、これらすべてのプロセスを同時に、複雑に再編成し、すべての関係者の利益を考慮に入れなければならないという考えに基づいています。 彼はこのアイデアを前の「目標を超えて」をまとめた本で表現しています。 逆説は、会社のプロセスの一部のみ、たとえば開発のみを最適化すると、ビジネス全体が成長するだけでなく、ユニットの従業員に悪影響を及ぼし、作業の生産性が大幅に向上することです。
これはスクラムに完全に適用されます。 社内全体でスクラムの作業を理解し、同意することなく、開発時にのみ実装することは、明らかに悪い考えです。 はい、スクラム技術は開発機能を大幅に拡張できます。 これにより、アプリケーションの多くの新機能が迅速かつ効率的にリリースされます。その結果、ユーザーにとってはまったく不要になります。 「あなたの製品は複雑すぎます。私たちはそれを理解できませんでした、悲しい笑顔です。」 結果は、ビジネス側のフラストレーションと開発側のフラストレーションです。
みんなのためのゲーム
開発プロセス中に何かを変更する前に、社内の全員がスクラムを完全に認識する必要があります。 特に、これにはスクラム値の一般的な受け入れが必要です（スクラムガイド、スクラム値：コミットメント、勇気、集中、開放性、敬意。）：勤勉、勇気、集中、開放性、敬意。
スクラムの価値を無視すると、それがもたらすすべての利点を簡単に破壊してしまいます。
事業主が製品開発者が製品の開発に関する決定を下す権利を尊重せず、特定の行動計画を彼に課す場合、スクラムチーム全体がすぐに適応する機会を奪われます。
製品所有者が製品の価値を高める義務を果たしていない場合、それは彼の唯一の責任であり、ビジネス所有者の信頼をどのように維持できますか？
製品所有者が製品を変更して何か新しいことに挑戦する勇気を持っていない場合、製品の価値をどのように高めることができますか？ 結局のところ、改善は最終的には変更です。
製品所有者が開発チームの自己組織化の権利を尊重せず、毎日チームの作業に干渉し、絶えず計画を変更し、作業のすべての段階を監視する場合、開発チームは生産性を向上させることができません。 彼女の仕事の結果は安定して悲惨で平凡なものになるでしょう。
開発チームがスプリントの目標を達成するという約束を果たしていない場合、プロダクトオーナーの独立性と信頼をどのように維持できますか？
スクラムチームが特定のスプリントの特定の目標に作業を集中できず、代わりに多くの分野で努力をスプレーする場合、具体的な結果をどのように達成しますか？ また、選択した方向をさらに発展させる価値があるかどうか、またはその逆を理解することができるため、作品が否定的ではあるがリターンを示さない場合は、すべてをそのまま返し、行われたことを捨てる必要があります。 そして、製品から行われたことを捨てることができるようにするために、それは不必要であることが判明し、勇気と決意も必要です。
すべての関係者が直面している問題でお互いに開かれておらず、商業的または技術的な計画の困難を隠そうとする場合、それはまだ時間の経過とともに知られるようになります。 しかし、信頼と尊敬は失われます。
「はい、彼らは言う、私たちは皆スクラムが何であるかを理解しており、その原則に従って行動するだろう」と言うだけでは十分ではありません。 まず、誰もがスクラムガイドを読む必要があります。 真剣に、あなたは読む必要があります。 問題と誤解について話し合い、合意する必要があります。 すべての競合が解決したら、それぞれの側は、スクラムでの作業またはスクラムチームとのやり取りの意図を直接的かつ明確に述べる必要があります。 そして、そのときだけ行動を開始することが可能になり、あなたは断固として即座に行動する必要があります。
プロセスについて共通の理解を得るには、全員が共通の用語を順守する必要があります。 これは些細で形式主義のように見えますが、本当に重要です。 ビジネスオーナーがプロダクトオーナーを「プロダクトマネージャー」、開発者が「ボス」、そしてプロダクトオーナー自身が「天皇」などと呼ぶ場合、相互理解に達したと言えるでしょうか。
スクラムの全体的なビジネス戦略を達成することは、重要かつ挑戦的な仕事です。 彼女の決定がなければ、先へ進むことは無意味です。 ただし、実行可能です。 しかし、これは最初の一歩に過ぎず、困難はまだ始まったばかりです。
次の投稿では、開発中のスクラムの実装における典型的な間違い、それらがスクラムの利点をゼロに減らす理由、およびそれらを修正する方法をより詳細に明らかにしようとします。
ドミトリー・マモノフ
開発部
マスターのマージ部門、
gitの作業部門、
ジュニアバッシュコンソールオペレーター