定義された役割を持つチームでスクラムを機能させる方法は？

いくつかの背景情報

私は社内のソフトウェア開発チームの一員です。で構成されます

• 5人の開発者（2〜5年の経験があり、私もその1人です）
• 3人の実装スタッフ（ソフトウェアの展開とトレーニングを行います）
• および1人のプロジェクトマネージャー。

多くの小規模から中規模のプロジェクトを開発しており、それらのスケジュールは通常重複しています。開発は次のようになります。

1. 「クライアント」は一連の初期要件を提供します
2. 上記の仕様に合わせてシステムを開発します
3. システムを「クライアント」に提示する
4. 「クライアント」は、上記のプレゼンテーションに基づいて追加の要件を提供します
5. 「クライアント」の新しい要件がなくなるか、展開の対象日が近づくまで2〜4を繰り返します
6. システムをセットアップして展開する

これは、ほとんどの場合、期限を処理する「クライアント」であるという事実（これはプログラマーとPM.SEで私が見ているものからの赤旗です）であり、明確な開発方法論に従っていませんカウボーイコーディング、メンテナンス不可能なコード、本番環境を通過するバグなどが含まれます。それが、スクラムのようなアジャイルベースの方法論を採用することを選んだ理由です。

なぜスクラムなのか？

それは私たちのマネージャーのイニシアチブであり、現在の状況を考えると誰もがそれに同意するようです。

スクラムの問題

スクラムの一部の要素は、特にアジャイル開発者の「すべての取引」という性質に簡単に対処できない現在のセットアップと競合しています。展開チームはプログラミングの方法を知らず、開発者は平均以下のコミュニケーションとトレーニングのスキルを持っています。そして、このラインナップはすぐに変わることはありません。

質問

方法論としてのスクラムの有効性に影響しますか？補償するために他の変更を行う必要がありますか？それとも、考えを完全に捨てて、別の方法論について考える方が良いでしょうか？

実際、あなたの現在の働き方は、あなたが思うようにスクラムからそれほど離れていません。

スクラムでは、要件の初期セットを取得し、それらを実装して結果を実証します。また、実証に基づいて、新しい要件をユーザーに与えることができます。
あなたの状況では、あなたが話した「クライアント」にスクラムのプロダクトオーナーの役割を与えることができます（彼らはすでにプロジェクト内で優先順位を設定し、ロールアウトの準備をすることでその役割を果たしているようです）。
大きな変更の1つは、反復の長さです。スクラムでは、反復は1週間から4週間の間に続くはずです。

チームの構成とジャックオブトレードの誤fallについて：スクラムでは、全員がジャックオブトレードになる必要はありません。スクラムは、チームが全体として、要件のリストから展開済みまたは展開可能なものに製品を取得するために必要なすべての能力を持っていることを要求します。
あなたの状況では、プロジェクトごとに1人以上の開発者（主に実装とテスト作業を行う）と、主にマニュアルの作成と機能のトレーニング資料に焦点を合わせる「実装スタッフ」のメンバーで構成されるチームを簡単に見ることができます開発者は現在実装しています。

クライアント/プロダクトオーナーが展開の青信号を出した後、スクラムチームの作業はほぼ完了します。そのため、開発者は別のプロジェクトに移動できます（そして、展開後の問題を修正するためにオンデマンドでのみ利用できます）。スタッフはトレーニングの実施とロールアウトのサポートに切り替えることができます。

そのリリースに必要な機能に十分な柔軟性がある限り、期限があるという事実は実際の問題ではありません。

あなたは代替案を求めているので、私はeXtreme Programming（XP）と言います。具体的には、ここでペアプログラミングが役立つと思います。

異なるスキルを持つ人々を一緒にペアにすることで、コーヒーを作る、テストする、トレーニングするなどのスキルは関係ありません。チーム全体にスキルを広めることができます。

しかし、正直に言うと、SCRUMがあなたにとってそれほど遠くないようには思えません。SCRUMの一部は柔軟性があり、チームに最適なものを見つけることです。XPの一部は、チームを尊重し、順応することです。たぶん100年後には、より完全に発達した専門的でハードなルールと速いルールを持っているかもしれませんが（疑いはありますが）、今のところ、あなたのために働くことは私たちが持っているすべてです。重要なことは、フィードバックループを持つことです。何かがうまくいかない場合、チームはそれについて話し合い、何かがうまくいくまで新しいことを試す必要があります。

定義された役割を持つチームでスクラムを機能させる方法は？

早くやれよ。スクラムガイドによると、誰もが開発者ですが、ここ地球に戻って、さまざまな人々がさまざまなものをテーブルに持ち込みます。私はほぼリンチしまった私は他の人がソフトウェアを書く間、一部の人々はテスターが実際にあることを示唆したとき。

対処したいことがいくつかあります。

スプリント

最初の開発段階に続いて、表面上はスプリントと呼ばれる一連の作業が行われているように思えます。これを分割することを検討してください。クライアントは何かを早期に見るだけでなく、開発のマイルストーンが発生するたびに、より良い感覚を得ることができます。

締め切りを修正

これは何度も何度も発生し、実際、私が現在働いている開発者の側では、とげのない棘です。スクラムはスプリントの推定値を設定します-これ以上はありません。はい、一連のスプリントの後に目標を達成する可能性がありますが、クライアントが初期バージョンに目を向けると、スコープが大幅にクリープする可能性があります。これ自体は問題ではありませんが、クライアントは後のスプリントでさらに作業が行われ、既知の要件を超えていることを認識しておく必要があります。

あなたの状況は、かんばんに対してより良い一致であるかもしれません。これは、現在のプロジェクトを混乱させるようなビッグバンの紹介がないことを意味します。まず、ボード上のタスクを視覚化し、回顧や毎日のミーティングなどのプラクティスを採用することから始めます。

スクラムはそれほど規範的ではないため、スクラムよりも少し注意する必要があります。そのため、適切なアジャイルマインドセットを教え込むのではなく、以前に行ったものに戻る傾向があります。

スクラムは、オーバーラップする個別のプロジェクトではうまく機能しません。これは、完全なスプリントのためにプロジェクトに取り組んでいる人々の安定したセットがないためです。したがって、冗長性などの概念は、単にあなたを落ち込ませる可能性があります。

しかし、次のストーリーに取り組む前に、まずクライアントに最高のコスト/利益をもたらすストーリーを取り上げ、完全自動化テストを含めて展開するのに十分な品質まで実装することは有用な概念です。同様に、ストーリーが「完了」と見なされる前に、ストーリー用に記述されたすべてのコードを別の開発者がレビューする必要があります。

実装スタッフはトレーニングおよびリファレンスドキュメントを作成する必要があり、コードを作成する前に各ストーリーごとに作成（最初のドラフト）できるため、受け入れテストになります。

実装スタッフの入力が開発者にとって最も役立つ各プロジェクトの開始時に、前のプロジェクトの展開に100％コミットしていることがわかると思います。したがって、開発者が現在のプロジェクトのコードを書いている間に、実装スタッフが次のプロジェクトのストーリーとユーザードキュメントの作成に取り組むことができるかどうかを検討してください。

テストで使用される例を記述した実装スタッフとの「行動主導の開発」が機能する場合があります。

だからあなたを助ける少しのスクラムがありますが、スクラムを使う代わりにスクラムに頼ってみてください。