そのような状況では、外部のコンサルティングを注文し、数ヶ月間あなたの会社にプロのスクラムマスターを「呼び出す」ことは完全に論理的なようです。 これは理想的なケースであり、単なる夢です。
実際には、開発チームは管理側からランダムに受け取ったタスクに長い間うんざりしており、管理者は開発の不透明性、期限の絶え間ない失敗、製品品質の低さに苦しんでいます。 同時に、トップマネジメントは、プロのスクラムマスターのサービスへの予算の割り当てについて聞きたくありません。
このような状況では、開発者には2つの方法があります：耐え続けるか、自分の手で主導権を握ります。
2番目の方法を選択しました。今日は、マネージャーではなく技術スペシャリストである会社でスクラムを実装した経験についてお話しします。 カットの下で、実際の経験、落とし穴、そしてあえてする人のための実践的なアドバイス。
背景
何よりもまず、開発者によるスクラムの導入は困難で恩知らずの取り組みです。 これを決定するためには、開発者として、本当に正当な理由が必要です。
チームの開発プロセスに問題があることを示すいくつかの正式な兆候を次に示します。
- 開発者は絶えず引き出され、タスクからタスクに切り替えられます。
- 開発者へのタスクは不均一であり、何もありません。それから閉塞です。
- 開発者は異なるタスクを受け取り、製品全体を見ることができません。
- 異なる開発者からのタスクをまとめると、意図したとおりに機能しない製品になります。
- 製品テストは開発と離婚しているため、製品の安定化サイクルが長くなります。
- 締め切りは常にオンです。
これらのすべての点は、開発者としての快適さに直接影響します。 上記のリストで自分のポイントの半分以上を指摘している場合は、チームにスクラムを導入することを検討する必要があります。スクラムを使用すると問題を解決できるためです。
上記の項目が困惑していて、スクラムを導入するというアイデアが次のような結果になった場合：
- バーで別の会社の友人との議論。
- 「新しいもの」を試してみたいという欲求。
- 退屈
- ...
その後、ほとんどの場合、あなたはそれを取る必要はありません。 あなたの仕事を楽しんで、そのような労働条件を提供してくれるマネージャーを称賛してください。
ステージ1.準備
スクラムの理論を完全に学びます。 これは非常に重要です。 Henrik Knibergの本「 Scrum and XP：notes with the best 」をお勧めします 。これは、プロセスのすべてのポイントを段階的に説明する非常に有名なスクラムマニュアルです。 それを読んだ後、スタンドアップを同時に失敗せずに実行する必要がある理由、デモで得点できない理由、Planning Pokerのタスクを評価する必要がある理由を理解してください。 これがどのように接続されているかについて理解があります。
スクラムの特定のプラクティスの適切性についてまだ質問がある場合は、本をもう一度読んでください。 質問がまだ残っている場合-多分あなたはスクラムの実装を取り上げるべきではありません。
開発者の間で仲間を見つけます。 昼食時に、このプロセスの実施後に得られる利点を教えてください。 スクラムが開発者に課した義務について言うことを忘れないでください。
ほとんどの人は良い仕事をサポートする準備ができています。 変化に反対するのは普通だと言う人がいるかもしれません。 ただし、現在のプロセスが開発者にとって不快であると考えているチームがあなただけである場合、おそらくこのチームでスクラムの実装を取り上げるべきではありません。
リーダーシップの中から仲間を見つけましょう。 リーダーにそれを伝えるほど、成功する可能性が高くなります。
部長から始めてください。 高く移動します。 中小企業（最大50人）では、ディレクターまでずっと行きたいと思っています。 現在のプロセスとその問題を説明する30分間のプレゼンテーションを行います。 スクラムがそれらを解決する方法を説明してください。
ほとんどのマネージャーは、中立的にイニシアチブを取る必要があります。 しかし、少なくとも1人のリーダーがあなたの側に立って、サポートを約束する必要があります。 この男を覚えておいてください、彼は将来あなたにとって非常に役立つでしょう。
単一のリーダーをあなたの側に引き付けることに失敗した場合、あなたは間違いなくこの会社でスクラムの実装を引き受けるべきではありません。
スクラムマスタリングに時間がかかるため、技術者としての効率が30％低下することを明確に説明してください。 前の手順が成功した場合、これは適切に認識されます。 この段階で急いで給与の引き上げを求めないでください。まだ何もしていないので、もっと支払う必要があります。
完了した作業をもう一度見てください。 それが、これらすべての会話、紛争、スピーチです。 これがあなたにとって複雑で、これがあなたが次の6-9ヶ月でやりたいことでないならば、あなたはスクラムの実装を引き受けるべきではありません。 スクラムの実装は人々と協力しているからです。 それはまともな時間と精神的なエネルギーを奪います。 最初に、必ずそれをメインの技術的なアクティビティと組み合わせる必要があります。
これがノーリターンのポイントです。 確立されたプロセスを破壊していません。 あなたはまだ拒否することができます。 さらに、そのような機会はありません。 さらに進んで拒否すると、悪化させるだけです。見返りを与えずに、同僚にプロセスを中断させます。 誰もがそのような人々を憎んでいます。
ステージ2.実装
管理者と一緒に、スクラムチームを形成するプロジェクトを選択します。 理想的なチームは、4〜6人のクロスファンクショナル開発者です。 これはほとんど起こりません。開発者は独自の専門分野を持っているため、テストに参加したくありません。 したがって、3〜4人の非機能開発者と1〜2人のテスターも非常に優れたチームです。 あなたはこれらの男の一人でなければなりません。 そして今、あなたはスクラムマスターです。
いかなる場合でも、会社全体または所属していないチームでスクラムをすぐに実装することに同意しないでください-あなたはコントロールを失います。
重要なポイント：経営陣にチームに公式にスクラムを実施しており、あなたがスクラムマスターであることを正式に知らせてもらいます。
プロのスクラムマスターは、オンライントラッカーでスクラムアクティビティを追跡できるサービスとプラグインのポートフォリオをすべて備えてチームに参加します。 これはあなたの専門分野ではないので、複雑なツールを気にしないでください。
それどころか、アナログツールを使用します。手書きのステッカーが付いたオフラインホワイトボード、ピン留めされたレトロスペクティブシート、隣接するボード上のマーカーで描かれたバーンダウン。 スクラムの形成段階では、そのようなことはオンラインの対応物よりもさらに明白です。
次のステップは、バックログの形成、最初の計画、スタンドアップ、デモ、レトロです...技術者のスクラムマスターには特別な機能はありません。本に従ってください。
しかし、1つは、スクラムマスターがマネージャーであるということです。 これで、チーム、さらにはチームの製品所有者でさえも、特定のレバレッジを利用できます。 そして、あなたは（！）これらのレバーを使用する必要があります。
例で説明します。
例1
チームの製品所有者は、以前にタスクを設定したマネージャーです。 ここで、スクラムマスターとして、彼のタスクを設定します。バックログを優先順位付きの状態に維持し、ユーザーストーリーを正しく形成し、現在のスプリントに新しいタスクをスローしないようにします。
会社の階層では、この人は通常の開発者であるあなたよりも優れていると仮定しますが、スクラムのパラダイムでは、この人がチームに対する義務を果たすことを確認できます。
例2
あなたはC ++開発者であり、彼はスクラム実装の前にタスクを設定するC ++テクライドです。 あなたは同じスクラムチームに所属しています。 スタンドアップの1つで、この技術専門家は優先度の低いタスクに従事していると宣言していますが、ボード上ではスプリントにタスクがあり、さらに重要なことがわかります。 ルールに従って、優先度の高いタスクに切り替えるように彼に依頼する必要があります。 通常これで十分です。 しかし、時にはこれはテクライドから怒りを引き起こします。「どうですか、部下が私に何をすべきかを教えてくれます！」ボスの立場からボスに話をするためには、外交の才能が必要です。 ただし、この時点で自分自身を容赦すると、チームはすぐにルール違反を感じます。つまり、他のチームメンバーが別のルールに違反するようになります。
非常に多くの場合、この瞬間はスクラムマスタ技術者にとって最も難しいものです。 そのようなときは、チームとプロダクトオーナーの利益にアピールすることをお勧めします。チームやマネージャーに反対したい人はほとんどいません。 そのような問題のエスカレーションを使用して、最も極端な場合に上級管理職に依頼してください。
ステージ3.開発
最初は、チームのパフォーマンスが低下する可能性があります。これは、開発プロセスが変更されたときの正常な動作です。
しかし、2、3のスプリントの後、あなたと他の開発者はスクラムの利点を感じます：タスクは混oticとした方法で飛んでおらず、2週間の確実性が現れ、チーム全体が共通の問題を解決することに没頭し、テストは開発直後に行われます。
製品の所有者は、開発が何をしているかを理解し、スプリントの終了までに計画されたタスクのほとんどが完了するという確信を持ちます。 レトロでこれを強調することを忘れないでください：技術者は誇張し、問題だけを表明する傾向があります。
あなたのチームがうまくいっていれば、他のチームと経験を共有したくなるかもしれません。 これで時間をかけてください。
最初に、他のチームがスクラムを実装するように依頼するのを待ちます。
第二に、最初のチームで交代要員を準備し、その後でのみ、第二のチームでスクラムを確立します。 もちろん、スクラムマスターとしてだけでなく、開発者としてもこの2番目のチームに参加する必要があります。
会社の開発プロセスに関するすべての質問があなたに向けられ、あなたが彼らのサポートに時間を費やさなければならないという事実に備えてください。
重要なポイント：この段階で、スクラムの実装結果がすでに表示されている場合は、スクラムマスタリングの追加料金について経営陣に相談してください。 給与に+ 15％を要求するのは普通です。 この活動には強さと神経が必要であり、熱意が長続きしないことを説明します。 そしてそれは本当に！ 私は、純粋な熱意が無給のハードワークに対するresりに道を譲った多くの技術のスクラムマスターを見ました。 その結果、会社はスクラムマスターと開発者の両方を失いました。
ステージ4.批判
これは奇妙に思えるかもしれませんが、チームの快適なプロセスが長くなればなるほど、あなたの住所に不満が生じます。 これが人間の精神の仕組みです。私たちはすぐに善に慣れ、それに気づくのをやめ、否定を膨らませる傾向があります。
しばらくすると、チームメンバーから、スクラムがあまり良くないことがわかります。 彼らは、あなたがスプリントに合わせてスタンドアップに行かなければならないと言います。 これは特に、スクラムの導入後に参加し、以前ほど見なかった若い開発者に当てはまります。
これは正常です。 前と同じように説明文で写真をいくつか用意し、時々不満を示します。 彼はキャンプファイヤーの先輩のようなものであるため、製品オーナーとのこのような会話に参加することもあります。過去の時間に関する彼の話は、チームによって非常に鮮明に認識されます。
一般的に、管理者は、実装の最初の段階でスクラムに不満を抱いています。初めてのスプリントに新しいタスクを導入することの禁止に直面したときです。 しかし、最初のデモの後、彼らはプロセスの利点がこの制限を上回ることを理解しています。 数か月以内に、マネージャーはスクラムの主な鑑定家になります。
繰り返しますが、チームの技術者はネガティブなものを膨らませることが多く、マネージャーはより現実的に写真を見ます。 したがって、批評家があなたをつついていると感じたら-製品所有者とコーヒーを飲んで、彼は間違いなくサポートします、そしてそのような瞬間のサポートは非常に重要です。
しかし、批判も建設的です。 スクラムをゼロから完全に調整することは不可能なので、常にヒントを聞いて、プロセスで試してみてください。 提案された各変更に、「どのような問題を解決しますか？」と「これによりどのような問題が発生しますか？」という2つの質問に答えます
スタンバイ時間を午前10時から午後6時に変更することは重要ですか？ または、立ち上がり時間をフローティングにしますか？ デモをキャンセルするとどうなりますか？ または、新しいタイプの会議を思い付きますか？
この点で、スクラムはソフトウェアフレームワークに非常に似ています。変更を加えることはできますが、変更の目的を理解している場合にのみ有用です。
この変更がプロセスにどのように影響するか、一貫性を維持するために必要な追加手順を明確に認識する必要があります。
普遍的なアドバイスはありませんが、プロセスに徐々に変更を加え、開発者として評価することを忘れないでください。 変更がアイデアを満たさない場合は、大胆にロールバックします。
おわりに
この記事の目的は、スクラム導入の旗を掲げた技術専門家に特有の瞬間を強調することです。 もう一度繰り返します。これは、どのような状況でも「バックグラウンド」とは見なされないアクティビティであり、これは非常に困難です。
うまくいけば、誰かがそれをよりよく準備できるようになります。 そして、誰かがそれが価値がないことを理解し、少なくとも何らかの形で会社の作業プロセスを最終的に破ることはありません。
質問があるか、自分の経験がありますか？ コメントへようこそ！